把什么放在旁边

一句话总结

Pad内的容器**共享网络命名空间和卷。**只有在想共享这两个东西时才会附加容器。除此之外，不附加。

为什么需要这个？

以“再加一个功能吧”为由增加侧翼，帕德就会变重，分配单位变大，一个坏掉就会重新开始。侧翼不是免费的。

值得附加的理由最终是三个中之一。

图案	做什么	例
侧卡	不触动本体，增加功能	收集日志、转换指标、更新证书
大使	代替主机与外部通信	服务消息代理、DB连接池
适配器	将本体的输出转换为标准格式	应用程序固有指标 → 普罗米修斯格式

区分三者的标准是交通的方向。侧车在旁边支撑，大使站在出入口处，适配器改变了回复 incoming request 的形式。

怎么行动

只有准确知道可以共享和不能共享的东西，才能进行设计。

已共享	未共享
网络（相同的localhost，相同的IP）	文件系统根（各自自己的镜像）
IPC，卷（仅限安装的）	进程列表（默认值 — shareProcessNamespace: true可以连接）

所以，如果侧卡要读取本体的日志，就必须将相同的卷装在两侧的驱动器上。emptyDir一个本体是/var/log/app啊，收集器是/logs是安装在上的样子。

1.29 修复的旧问题

以前，侧车只是“再装一个集装箱”。所以两种东西不一致。

1. **无法保证移动顺序。**如果主体比代理先出现，则第一次请求会失败。
2. **Job还没有结束。**即使本体结束了，侧卡也一直活着，Job永远都在Running。

从1.29开始initContainers在restartPolicy: Always提供后，会变成正式的侧卡。就像初始化容器一样，比本体先启动，本体结束后一起终止。

spec:
  initContainers:
    - name: proxy
      image: envoyproxy/envoy:v1.31-latest
      restartPolicy: Always      # ← 이 한 줄이 사이드카로 만든다
  containers:
    - name: app
      image: myapp:1.0

常见的误解

**资源请求增加。**帕德的请求量是集装箱的总和。在侧车上requests.cpu: 100m给的话，100个帕德可以预约10个核心。日程安排器会根据这个总数来找位置，所以一个侧车可以大大降低群集密度。

侧卡总是正确的。每个节点都有一台DaemonSet收集器的价格通常更便宜。如果每个板子上都贴上收集器，就会进行相应的进程。侧卡收集器只在需要隔离与其他板子时（多台式机）或文件路径特殊时使用。

先考虑不粘的一面。

侧车看起来很方便，所以很容易增加。但是，在粘贴之前，先看看在其他位置可以做同样的事情吗，结论是相当多数人认为不粘贴更好。

想做的事情	不是搭便车	什么时候才是搭便车呢
日志收集	每个节点都有一台收集器	文件路径特殊或需要隔离租户时
暴露指标	应用程序直接暴露	如果是无法修复代码的商用程序时
认证书更新	控制器更新秘密，应用程序重新读取	应用程序只能读取文件，不能重新读取时
设置刷新	将设置哈希放入板模板中滚动	没有重新启动时需要反映时

**如果不符合表格的右侧列，则不附加。**因为侧卡每个板子都乘以，所以板子200个的话，200个进程和200个份额的请求量会增加。而且那个容器的映像更新、漏洞应对、设置更改都会叠加到本体的部署上。

如果决定粘在一起的话，就一起决定几个。比本体先浮起来后死吗(前面看到的restartPolicy: Always), 如何设定限制(堆栈缓冲器的收集器特别要充足)，还有 侧卡失败时主体应该是什么样子。最后一个容易被遗忘，比起代理死后主体不断收到请求全部失败，通过readiness从流量中退出的情况大多数都比较好。为此，主体的readiness应该同时查看侧卡的状态。

在实际工作中真正重要的东西

侧卡与主机共享生命周期。如果侧卡因OOM而死亡，其容器重新出现期间，主机期待的功能会停止，如果重复重启，则PAD会进入CrashLoopBackOff，整个无法使用。因此，侧卡的内存限制要充足，并且不要比主机先死亡。如果是日志采集器在内存中堆积缓冲区的设置，尤其如此。