挂上边车再量一量资源

在 TT Lab 中继续学习

目标

实际挂上一个 sidecar，并用数字确认它的代价。资源如何叠加、谁先启动、哪些东西被共享，这些都直接向集群查询。

为什么重要

sidecar 看起来只是“多加一个功能”，实际上是部署单元变大。Pod 的请求量会累加，启动会变慢，故障点也多了一个。如果不了解这些代价就一味增加，不知不觉就会出现包含五个容器的 Pod。

环境

这个 Pod 用 kwok 启动一个真正的 kube-apiserver。Pod 并不会真的运行，但规格、状态和 QoS 的计算全部是真实的。

步骤

没有 sidecar 的 Deployment → /root/sc/01-plain.yaml
添加正式 sidecar → /root/sc/02-sidecar.yaml
请求量之和 → /root/sc/03-sum.txt
启动顺序 → /root/sc/04-order.txt
被共享的内容 → /root/sc/05-share.txt
通过卷连接 → /root/sc/06-volume.yaml
QoS 等级 → /root/sc/07-qos.txt
与 DaemonSet 的比较 → /root/sc/08-decide.md

参考

正式 sidecar 是在 initContainers 中设置了 restartPolicy: Always 的容器。这与直接往 containers 里再加一个容器不同。
sidecar 的资源设置是 requests 设小、limits 设宽松，与主容器正好相反。

先从没有 sidecar 的 Pod 开始

没有 sidecar 的 Deployment → /root/sc/01-plain.yaml

在 /root/sc/01-plain.yaml 中写入只有一个容器的 Deployment。名称为 web，镜像为 nginx:1.27-alpine，replicas 为 2，并在 resources.requests 中设置 cpu 100m、memory 128Mi。用 kubectl apply -f 应用它。

挂上正式 sidecar

添加正式 sidecar → /root/sc/02-sidecar.yaml

在同一个 Deployment 中加入 sidecar，保存为 /root/sc/02-sidecar.yaml 并应用。

不要放进 containers，而是放进 initContainers 并设置 restartPolicy: Always。这是 Kubernetes 1.29 起的正式 sidecar，它先于主容器启动，并在主容器结束后一起终止。名称为 proxy，镜像随意（busybox:1.36 加 sleep infinity），requests 为 cpu 50m、memory 64Mi。

Pod 的请求量是各容器之和

请求量之和 → /root/sc/03-sum.txt

用 kubectl get pod <파드> -o jsonpath（占位符为 Pod 名称）分别取出两个容器的 cpu requests，并把它们的和写入 /root/sc/03-sum.txt，格式为一行 본체 + 사이드카 = 합（韩文，意为“主容器 + sidecar = 总和”），单位为 m。调度器寻找位置时看的就是这个总和。

谁先启动

启动顺序 → /root/sc/04-order.txt

用 kubectl get pod <파드> -o jsonpath='{.status.initContainerStatuses[*].name} {.status.containerStatuses[*].name}'（占位符为 Pod 名称）确认，并在 /root/sc/04-order.txt 中写两行：（1）先启动的容器名称；（2）为什么必须是这个顺序。想一想，如果代理启动得晚，最初的几个请求会去哪里。

共享什么

被共享的内容 → /root/sc/05-share.txt

在 /root/sc/05-share.txt 中写下两个容器共享的内容和不共享的内容，共四行：网络 / 文件系统根 / 进程列表 / 卷。每行的格式为 <항목>: 공유|비공유（占位符为项目名称，取值为表示“共享”或“不共享”的韩文词，二者择一），不共享的项目还要补充说明怎样做才能共享。

通过卷连接

通过卷连接 → /root/sc/06-volume.yaml

要让 sidecar 读取主容器写入的文件，就必须在两侧挂载同一个卷。创建一个 emptyDir，让主容器把它挂载到 /var/log/app，让 sidecar 挂载到 /logs，把对应的清单写入 /root/sc/06-volume.yaml 并应用。

确认 QoS 等级

QoS 等级 → /root/sc/07-qos.txt

查看 kubectl get pod <파드> -o jsonpath='{.status.qosClass}'（占位符为 Pod 名称）的结果，并在 /root/sc/07-qos.txt 中写两行：（1）等级；（2）如果完全不设置 requests 会是哪个等级，以及为什么危险。BestEffort 在内存紧张时最先被终止。

DaemonSet 是否更合适

与 DaemonSet 的比较 → /root/sc/08-decide.md

在 /root/sc/08-decide.md 中写三行。（1）在 sidecar 站得住脚的三个条件中，这个场景符合哪一个；（2）如果都不符合，为什么 DaemonSet 更合适；（3）从资源角度看有什么差别。这就是挂上 sidecar 之前应该先问的问题。