容器设计模式
参考:
- 论文 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
和设计模式中的适配器模式类似,无需修改应用容器,仅仅通过适配器容器就可以对外界提供统一的接口。典型场景:监控。监控容器对外提供统一的监控接口,监控容器内部对应用容器的各个指标做收集,聚合等等操作。