Docker 经常使用模式

Deployment

Service

Daemonset

这种模式就是确保在每一个k8s的node节点上建立一个pod实例，有且仅有一个实例。当node被添加到集群中，Pod也被添加上去。当node被从集群移除，这些Pod会被垃圾回收。删除一个DaemonSet将会清理它建立的Pod。

DaemonSet 的典型应用场景有：

• 在集群的每一个节点上运行存储 Daemon，好比 glusterd 或 ceph。
• 在每一个节点上运行日志收集 Daemon，好比 flunentd 或 logstash。
• 在每一个节点上运行监控 Daemon，好比 Prometheus Node Exporter 或 collectd。

其实 Kubernetes 本身就在用 DaemonSet 运行系统组件。执行以下命令：

kubectl get daemonset --namespace=kube-system

kubectl get pods --namespace=kube-system -o wide

能够看到flannel, kube-proxy等以daemonset形式存在的资源

Daemonset对应的属性例如label,镜像若是更新那么须要更新pod. DaemonSet目前有两种升级策略，能够经过.spec.updateStrategy.type指定：
OnDelete: 该策略表示当更新了DaemonSet的模板后，只有手动删除旧的DaemonSet Pod才会建立新的DaemonSet Pod
RollingUpdate： 该策略表示当更新DaemonSet模板后会自动删除旧的DaemonSet Pod并建立新的DaemonSetPod

sidecar 挎斗模式

将应用程序的组件部署到单独的进程或容器中，以提供隔离和封装。 使用此模式还可使用异构组件和技术来构建应用程序。

此模式之因此称做“挎斗”(Sidecar)，是由于它相似于三轮摩托车上的挎斗。 在此模式中，挎斗附加到父应用程序，为应用程序提供支持性功能。 此外，挎斗与父应用程序具备相同的生命周期：与父应用程序一块儿建立，一块儿停用。 挎斗模式有时也称为搭档模式，这是一种分解模式。
挎斗服务不必定要属于应用程序的一部分，而只是与应用程序相链接。 无论它位于哪一个位置，父应用程序都会跟随。挎斗是连同主应用程序一块儿部署的支持性进程或服务。 以三轮摩托车为例，挎斗附加在一辆三轮摩托车上，每辆三轮摩托车有自身的挎斗。 一样，挎斗服务与其父应用程序具备相同的生命周期。 对于应用程序的每一个实例，都会部署一个挎斗实例，并连同应用程序实例一块儿托管该挎斗实例。

使用挎斗模式的好处包括：

• 在运行时环境和编程语言方面，挎斗与其主应用程序相互独立，所以，无需为每种语言开发一个挎斗。

• 挎斗能够访问主应用程序所能访问的资源。 例如，一个挎斗能够监视该挎斗和主应用程序使用的系统资源。

• 挎斗与主应用程序保持密切的距离，所以二者之间的通讯不存在明显的延迟。

• 即便是对于不提供扩展性机制的应用程序，也仍可使用挎斗来扩展功能，只需在主应用程序所用的同一主机或子容器中，将挎斗附加为自身的进程便可。

挎斗模式一般与容器一块儿使用，于是称做挎斗容器或搭档容器。

问题和注意事项

• 请考虑部署服务、进程或容器时所用的部署和打包格式。 容器特别适合用于挎斗模式。
• 在设计挎斗服务时，请慎重决定进程间通讯机制。 除非达不到性能要求，不然请尽可能使用不区分语言或框架的技术。
• 在将功能放入挎斗以前，请考虑该功能是做为独立的服务仍是更传统的守护程序运行更有利。

• 此外，请考虑是否可以以库的形式或使用传统扩展机制实现功能。 特定于语言的库可能提供更深度的集成和更少的网络开销。

  什么时候使用此模式

  在如下状况下使用此模式：
• 主应用程序使用一组异类语言和框架。 使用不一样框架以不一样语言编写的应用程序可使用挎斗服务中的某个组件。
• 某个组件由远程团队或不一样的组织拥有。
• 某个组件或功能必须共置在应用程序所在的同一台主机上
• 但愿某个服务与主应用程序具备相同的总体生命周期，但同时又能独立更新该服务。

• 须要精细控制特定资源或组件的资源限制。 例如，想要限制特定组件使用的内存量。 可将组件部署为挎斗，而后独立于主应用程序管理内存用量。

  此模式可能不适用于如下状况：

• 当进程间通讯须要优化时。 父应用程序与挎斗服务之间的通讯会产生必定的开销，执行调用时存在明显的延迟。频繁通讯的接口可能没法接受这种弊端。
• 在某些小型应用程序中，为每一个实例部署挎斗服务所产生的资源开销会抵消隔离所带来的优点。

• 当服务须要以不一样于或独立于主应用程序的方式缩放时。 若是存在这种状况，将功能部署为独立的服务可能更好。

  示例

  挎斗模式适用于许多方案。 一些常见示例：

• 基础结构 API。 基础结构开发团队建立了一个连同每一个应用程序一块儿部署的服务，而不是特定于语言的客户端库，来访问基础结构。 该服务做为挎斗加载，为基础结构服务（包括日志记录、环境数据、配置存储、发现、运行情况检查和监视程序服务）提供一个公用层。 挎斗还监视父应用程序的主机环境和进程（或容器），并将信息记录到集中式服务。
• 管理 NGINX/HAProxy。 将 NGINX 与用于监视环境状态的挎斗服务一块儿部署，而后，在须要更改状态时更新 NGINX 配置文件并回收进程。
• 表明挎斗。 将表明服务部署为挎斗。 应用程序经过表明发出调用，后者可处理日志记录、路由、断路、和其余链接相关功能。

• 卸载代理。 将 NGINX 代理放在 node.js 服务实例的前面，以便为服务提供静态文件内容