LabHub
学习 学习路径 课程

边车与多容器组合模式

边车不是免费的

在 LabHub 中继续学习

一句话总结

附加一个侧翼卡片的话,**增加帕德的请求量,增加机动时间,增加一个失败点。**只有在有超过代价的收益时才附加。

流程图: 增加帕德的请求量,增加机动时间,增加一个失败点。 · 资源增加。 · 也可以预约。 · 机动性变慢。

为什么需要这个?

以“再加一个功能吧”为由增加侧翼,某一刻帕德就会变成五个集装箱。这时发生的事情是这样的。

**资源增加。**帕德的要求量是集装箱的总和。在侧车上requests.cpu: 100m给的话,200个Pad可以预约20个核心。Scheduler会根据总数来找位置,所以节点密度会降低。即使不实际使用,也可以预约。

**机动性变慢。**正式的侧翼车(restartPolicy: Alwaysin init容器)比本体先弹出。如果代理弹出需要3秒,所有帕德的移动速度会增加3秒。在滚动更新中,这个会乘以帕德的数量。

**失败点增加。**如果侧卡以OOM的方式死亡,那么在那个容器重新启动期间,PAD会失去准备状态,如果重复的话,整个PAD将无法使用,变成CrashLoopBackOff。如果日志收集器设置是将缓冲区堆积在内存中的话,那么流量聚集的时候就会正好发生这种情况。

怎么行动

决定资源时的标准很简单。

容器 requests limits
本体 实际使用量的p50 p99 + 余量
侧车 非常小(10~50m) 充足

调整侧卡的limits的话,本体也会一起死亡。requests要小一点,limits要大一点才是正确答案。因为这是和本体相反的方向,所以很容易搞混。

结束顺序也很重要。如果主机还在处理请求时,代理先崩溃,这些请求就会失败。正式的侧卡会在主机结束后结束,所以这个问题已经解决了,但在之前preStop用勾球让对方坚持几秒的回击是很常见的。

常见的误解

“侧翼车即使死了,本体也会活下来” — 帕德是一个重启单元。restartPolicy是pad级别,如果一个容器一直死掉,整个pad就会进入CrashLoopBackOff。

“不给资源就不用” — 如果不给requests,QoS会变成BestEffort,在内存压力时**最先死亡。**如果侧卡先死亡,主机也会一起死亡。

开始和结束顺序问题

侧车箱的旧烦恼是顺序。主集装箱先离开,侧车箱 如果没有(代理)的话,第一次请求会失败,结束时,侧卡会先死,最后 请求和日志会消失。

❌ 옛 동작
   시작: 모든 컨테이너 동시 → 프록시가 늦으면 초기 요청 실패
   종료: 모든 컨테이너 동시 → 프록시가 먼저 죽으면 하류 호출 실패

✅ 네이티브 사이드카 (k8s 1.29+)
   initContainers 에 restartPolicy: Always 를 주면
   시작: 사이드카가 Ready 가 된 뒤에 메인이 시작
   종료: 메인이 끝난 뒤에 사이드카가 종료
spec:
  initContainers:
    - name: proxy
      image: envoyproxy/envoy:v1.31
      restartPolicy: Always        # ← 이 한 줄이 네이티브 사이드카로 만든다
  containers:
    - name: app
      image: myapp:1.0

以前,应用程序会插入等待代理的代码preStopsleep乙 使用了连接的绕行路。现在不需要了。先确认集群版本后 使用是这个功能的唯一条件。

Job没有结束的问题

如果配置工作板上有侧卡,即使主程序结束,侧卡也会继续运行Job 永远是Running。CronJob每天积累的错误在这里发生。

原生侧卡也能解决这个问题——主程序结束后,容器管理器会放在侧卡上。 发送SIGTERM。如果是1.29以前的话,主程序结束时会向侧卡发送信号。 必须亲自输入脚本。

不要将资源翻倍

如果每个辅助车都充分掌握要求和限额的话,一个辅助车实际需要的两倍 预约。节点只能进入一半。

侧车 常见请求 实际需要
日志采集器 100m / 128Mi 一般20m / 64Mi
代理(Envoy) 500m/512Mi 根据流量50~200m
地表出口商 100m / 128Mi 10m / 32Mi

**实测后减少。**如果对数百个垫子过度抓取100m的话,核心数十个就会乱动。 有。kubectl top pod --containers查看每个容器的实际使用情况。

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

在装载侧卡之前需要问的一个问题是——不能用DaemonSet吗?

每个节点一个就可以完成的事情(日志收集、节点指标)如果每个板块都附上容器的话,进程数就会增加到板块数。只有三种情况下侧卡是合理的。

  1. 需要PAD的网络命名空间(代理,mTLS)
  2. 需要Pad的体积(特定路径的文件)
  3. 必须按租户分开隔离(设置因设备而异)

如果三个都不中,DaemonSet就很便宜。