在大多数的简单pod，都是有一个container。然而在实际中，会根据系统的需要设计不同的pod，pod中的容器数量就会不止一个。
三种常见的pod设计风格中
Sidecar containers
此种风格一般用于文件或者资源共享，常见的模型有消费者-生产者模型。生产者把数据放置到共享空间，消费者读取该共享空间的数据
Example:
apiVersion: v1
kind: Pod
metadata:
name: counter
spec:
containers:
- name: producer
image: busybox
args:
- /bin/sh
- -c
- >
i=0;
while true;
do
echo "$i: $(date)" >> /var/log/1.log;
echo "$(date) INFO $i" >> /var/log/2.log;
i=$((i+1));
sleep 1;
done
volumeMounts:
- name: varlog
mountPath: /var/log
- name: count-consumer-1
image: busybox
args: [/bin/sh, -c, ‘tail -n+1 -f /var/log/1.log‘]
volumeMounts:
- name: varlog
mountPath: /var/log
- name: count-consumer-2
image: busybox
args: [/bin/sh, -c, ‘tail -n+1 -f /var/log/2.log‘]
volumeMounts:
- name: varlog
mountPath: /var/log
volumes:
- name: varlog
emptyDir: {}
Ambassador containers
代理者模式，通常用于某一个container对外提供接口访问，外部请求只能够通过此代理容器来实现访问内部其他容器，内部容器也仅仅是只通过此代理来和外部请求进行信息交互。
Example:
apiVersion: v1
kind: ConfigMap
metadata:
name: fruit-service-ambassador-config
data:
haproxy.cfg: |-
global
daemon
maxconn 256
defaults
mode http
timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms
listen http-in
bind *:80
server server1 127.0.0.1:8775 maxconn 32
-------
apiVersion: v1
kind: Pod
metadata:
name: fruit-service
spec:
containers:
- name: legacy-fruit-service
image: linuxacademycontent/legacy-fruit-service:1
- name: haproxy-ambassador
image: haproxy:1.7
ports:
- containerPort: 80
volumeMounts:
- name: config-volume
mountPath: /usr/local/etc/haproxy
volumes:
- name: config-volume
configMap:
name: fruit-service-ambassador-config
最后以此命令模仿外部访问
kubectl run busybox --image=busybox --rm -it --restart=Never -- curl $(kubectl get pod fruit-service -o=custom-columns=IP:.status.podIP --no-headers):80
Adapter containers
内部容器数据输出到外部时，数据会先通过一个容器进行格式转换，来使外部得到统一规范的数据
参考官网：https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/
kubernetes Multi Container Pods - 多容器模型Pod
原文：https://www.cnblogs.com/kknight/p/14835498.html