容器设计模式

• sidecar是K8S倡导的容器设计模式，InitContainer就是典型的sidecar设计模式

如果要把war放到tomcat去运行，典型部署方式

• 1、war，tomcat打到一个镜像，缺点：war/tomcat更新，即需重新打包镜像
• 2、镜像打包只包括tomcat、hostPath挂载宿主机、将war挂载进tomcat容器。缺点：维护分布式存储、无状态变的有状态、不可迁移。需要保证pod启动时拉取到最新war

解法

• 创建InitContainer，定义Volume名，并执行mountPath挂载
• tomcat业务容器，共用宿主机的volumes名，并挂载至webapps

Init Container，复制war包至容器的volume，并退出

业务容器运行时，已经存在war包 smaple.war；当执行tomcat容器，去挂载时，会找到sample.war

即可，不维护共享存储问题、一个组合不同角色的容器，按照类Init Container编排方式，统一打包一个应用，
用Pod的这种概念，即K8S经典容器设计模式，Sidecar

Sidecar典型场景

场景1

Sidecar典型场景：
  前置条件、ssh脚本编写（原本需要ssh进去执行的脚本）
  日志收集，仅仅是进程可包装为一个pod去收集
    业务容器写日志至volume，日志容器共享该volume将日志转发至远端存储，如Fluentd等
  debug应用，定义一个额外Container，去exec应用pod的namespace
  监控进程，作为一个sidecar启动起来

将辅助功能从业务容器解耦，即可独立发布sidecar容器，设计模式的威力（独立发布、能力复用）

场景2 代理proxy

• 代理容器对业务容器屏蔽被代理服务集群，简化业务代码实现逻辑

pod内应用访问集群外服务
方法1：通过修改代码修改、指向服务访问地址
方法2：通过访问sidecar容器里的proxy服务，通过proxy容器访问集群外服务；优势：sidecar容器proxy服务和业务容器进程，共享network namespaces，并无性能损耗。

场景3 适配器

• 适配器容器将业务容器暴露出来的接口转换为另外一种格式

如 将/metrics监控接口地址改变为/health健康检查接口，才能被metrics识别
不用改代码，额外写一个Adapter，并将请求转发给metrics即可。优势：同pod，直接共享network namespace、无性能损耗

总结

• Pod 是 Kubernetes 项目里实现“容器设计模式”的核心机制；

• “容器设计模式”是 Google Borg 的大规模容器集群管理最佳实践之一，也是 Kubernetes 进行复杂应用编排的基础依赖之一(容器和应用之间往往是有进程组的关系，容器比作进程，pod就是进程组)

• 所有“设计模式”的本质都是：解耦和重用（带来的好处）。（sidecar设计模式对k8s是非常重要的，比如新的开源项目envoy都是依赖于sidecar这样的设计模式及）

• Pod 与容器设计模式是 Kubernetes 体系里面最重要的一个基础知识点

• 重新审视一下使用 Pod 方式，是不是或多或少采用了所谓“富容器”这种设计呢？这种设计，只是一种过渡形态，会培养出很多非常不好的运维习惯。

• 强烈建议逐渐采用容器设计模式的思想对富容器进行解耦，将它们拆分成多个容器组成一个 Pod。这也正是当前阿里巴巴“全面上云”战役中正在全力推进的一项重要的工作内容。

参考：

• blog.csdn.net/qq_34556414…