容器设计模式

容器设计模式

参考：

• 论文 Design Patterns for Container-based Distributed Systems
• 《Kubernetes与云原生应用》之容器设计模式
• 《Kubernetes 与云原生应用》专栏

Single-container management patterns

• upward

容器向上暴露一组接口提供应用信息，比如监控信息（QPS，health），性能数据（threads, stack, lock）。以K8S为例，提供livenessProbe/readinessProbe探针保证容器的健康状态。

• downward

完整的容器生命周期管理。以K8S为例，通过设置terminationGracePeriodSeconds时间，可以优雅的关闭容器，即K8S首先会发送SIGTERM信号，然后时间到期之后，发送SIGKILL信号。应用程序可以通过捕获SIGTERM信号，来释放资源，保存数据，防止数据丢失。

除此以外，K8S还提供volume挂载downwardAPI，让容器获取Pod信息。

Single-node, multi-container application patterns

单节点模式，由一组共生容器组成，并且共同调度到一个节点上。容器管理系统会将这些容器作为一个原子单位共同调度。在K8S中，称之为Pod。

Sidecar pattern

利用同一Pod中容器可以共享存储空间的能力。将应用容器与工具容器解耦。比如：

• 一个java web应用容器，一个tomcat工具容器，应用容器先将war包cp到共享的emptyDir中，tomcat运行共享目录war包。
• 应用容器写日志到共享目录，fluentd容器读日志。

虽然可以将应用容器与工具容器集成在一个容器中，但是分开会有一下好处：

Benefit：

• 更细粒度的分配资源。通过cgroup配置web容器更多内存，cpu；而日志容器则配置在web服务不忙时，占用CPU
• 边界分明。web服务和日志采集服务可以分为两个团队并行开发，互相解耦，提高效率
• 复用镜像。类似日志采集镜像可以复用给其他的应用服务
• 故障隔离。由于在不同的容器，所以日志采集服务挂了，web服务仍然可以继续提供服务
• 方便部署，单独升级、回滚。

Ambassador pattern

利用同一Pod中容器可以共享网络栈，类似反向代理。例如业务容器通过twemproxy ambassador访问memcache。应用容器以为自己访问的是本地的memcache，但是其实访问外面分布式部署的memcache集群。

不知道Service Mesh-envoy容器算不算这种模式。

Adapter pattern

和设计模式中的适配器模式类似，无需修改应用容器，仅仅通过适配器容器就可以对外界提供统一的接口。典型场景：监控。监控容器对外提供统一的监控接口，监控容器内部对应用容器的各个指标做收集，聚合等等操作。

Multi-node application patterns

Leader election pattern

Work queue pattern

Scatter/gather pattern