开发者学堂课程【理解 Pod 和容器设计模式：【公开课】理解 Pod 和容器设计模式】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/826/detail/13946
【公开课】理解 Pod 和容器设计模式
内容介绍：
一、Pod 的实现机制
二、详解容器设计模式
三、总结
一、Pod 的实现机制
1.Pod 要解决的问题
如何让一个 Pod 里的多个容器之间最高效的共享某些资源和数据?
容器之间原本是被 Linux Namespace 和 cgroups 隔离开的
2.共享网络
容器 A 和 B
通过 Infra Container 的方式共享同一个 Network Namespace:
镜像: k8s.gcr.io/pause; 汇编语言编写的、永远处于“暂停";大小100~200 KB
直接使用 localhost 进行通信
看到的网络设备跟 Infra 容器看到的完全一样
一个 Pod 只有一个 IP 地址，也就是这个 Pod 的 NetworkNamespace 对应的 IP 地址
所有网络资源，都是一个 Pod 一份，并且被该 Pod 中的所有容器共享，整个Pod的生命周期跟 Infra 容器一致，而与容器 A 和 B 无关
Pod 不会重建，也不会重启
3.共享存储
apiversion : v1
kind: Pod
metadata:
name : two-containers
spec :
restartPolicy : Never
volumes:
- name : shared-data
hostPath :
path: / data
containers :
- name: nginx-container
image: nginx
volumeMounts :
- name: shared-data
mountPath: /usr/ share/nginx / html
- name : debian-container
image: debian
volumeMounts:
- name : shared-data
mountPath: / pod-data
command: [ " /bin/sh" ]
args: [ "-c", "echo Hello from the debian container > / pod-datalindex.html" ]
shared-data 对应在宿主机上的目录会被同时绑定挂载进了上述两个容器当中
二、详解容器设计模式
举例:WAR 包+ Tomcat 的容器化
方法一:把 WAR 包和 Tomcat 打包进一个镜像
无论是 WAR 包和 Tomcat 更新都需要重新制作镜像
方法二︰镜像里只打包 Tomcat。使用数据卷(hostPath)从宿主机上将 WAR 包挂载进 Tomcat 容器
需要维护―套分布式存储系统，容器可迁移，不固定
容器本身要依赖一套持久化的存储
有没有更通用的方法?
1.InitContainer
Init Container 会比 spec.containers 定义的用户容器先启动，并且严格按照定义顺序依次执行
/app 是一个 Volume
一个 Pod 里的多个容器可以共享 Volume
Tomcat 容器，同样声明了挂载该 Volume 到自己的 webapps 目录下
故当 Tomcat 容器启动时，它的 webapps 目录下就一定会存在 sample.war 文件
apiversion : v1
kind: Pod
metadata :
name: javaweb-2
spec:
initcontainers:
- image: resouer/ sample:v2
name: war
command: [ "cp" , " l sample.war" , " l app" ]
volumeMounts :
- mountPath: l app
name: app-volume
containers:
- image: resouer/tomcat : 7 .0
name: tomcat
command:[ "sh","-c","l root/apache-tomcat-7.0.42-v2/bin/ start.sh" ]
volumeMounts:
- mountPath: lroot/ apache-tomcat-7.0.42-v2/webapps
name: app-volume
ports :
- containerPort: 8080
hostPort: 8001
volumes :
- name: app-volume
emptyDir: {}
2.容器设计模式: Sidecar
通过在 Pod 里定义专门容器，来执行主业务容器需要的辅助工作
比如︰
原本需要 SSH 进去执行的脚本
日志收集（本身是一个进程，可以打包到 Pod 中做数据工作）
Debug 应用
应用监控
优势︰
将辅助功能同主业务容器解耦．实现独立发布和能力重用
3.Sidecar：应用与日志收集
业务容器将日志写在 Volume 里
Volume 在 Pod 中共享
日志容器共享该 Volume 从而将日志转发到远程存储当中
Fluentd 等，都是这样的工作方式
4.Sidecar：代理容器
代理容器：有一个 Pod，需要访问外部系统或外部服务，但是这些外部系统或服务是一个集群状态
代理容器对业务容器屏蔽被代理的服务集群，简化业务代码的实现逻辑
提示:
容器之间通过 localhost 直接通信
代理容器的代码可以被全公司重用
不会降低性能
5.Sidecar：适配器容器
适配器容器将业务容器暴露出来的接口转换为另一种格式
举例:
业务容器暴露出来的监控接口是 /metrics
Monitoring Adapter 将其转换为 /healthz 以适配新的监控系统
提示:
容器之间通过 localhost 直接通信
代理容器的代码可以被全公司重用
三、总结
Pod 是 Kubernetes 项目里实现“容器设计模式"的核心机制
“容器设计模式"是 Google Borg 的大规模容器集群管理最佳实践之一
也是 Kubernetes 进行复杂应用编排的基础依赖之一
所有“设计模式"的本质都是:解耦和重用
