1. 2026年的CKA备考为什么绕不开SideCar这个点先说清楚一件事这不是一个官方认证名称而是我自己备考2026年CKACertified Kubernetes Administrator时建的专项笔记代号。CKA这个认证最大的特点就是跟着Kubernetes版本滚动更新每年题型重心都会往新特性上偏移。我在梳理近两年的考纲变化时发现Sidecar容器已经从“了解即可”的边缘知识点逐渐变成了多容器Pod考题里躲不开的核心选项。为什么这么说因为CKA历来的传统考题就是多容器Pod设计只不过以前考的主要是“共享进程命名空间”“共享存储卷”这些基础用法。但从Kubernetes 1.28开始sidecar容器有了原生支持1.29又补齐了生命周期顺序控制这让考试出题人有了新的写题素材既要考察你对Pod编排基础的理解又能顺带检验你是否了解新版特性。可以这么说2026年的考场上如果出现“给现有Deployment增加一个sidecar容器”“调整sidecar容器启动顺序”这种题目我一点都不意外。这个系列笔记适合正在备考CKA的运维工程师、刚入门的K8s学习者也适合那些已经在生产环境用Istio、Envoy但没搞懂底层容器机制的人。我在这篇文章里把SideCar的前世今生、底层原理、实操写法、考试坑点一次性讲透内容全部基于Kubernetes 1.29到1.31之间稳定可用的特性不涉及任何实验性API。2. Sidecar容器的新旧之争以前叫模式现在叫一等公民2.1 先搞明白Sidecar到底解决什么问题Sidecar直译是“三轮摩托的边斗”在架构设计里指伴随主应用运行、辅助主应用完成特定功能的独立进程。经典的场景有三个日志采集如Filebeat跟随Nginx容器、流量代理如Istio的Envoy跟随业务容器、配置同步如Consul Template跟随Web容器。在1.28版本之前我们实现Sidecar模式用的是普通容器加command: [/bin/sh, -c, tail -f /dev/null]这种trick让辅助进程始终跑着不退出。问题在于这样做槽点很多生命周期完全不受控主容器挂了辅助容器还在跑Pod停止时清理顺序无法保证共享卷的写入时机也没有任何保障。说白了这只是“用普通容器模拟Sidecar”Kubernetes本身并不知道谁主谁辅。KEP-753原生Sidecar容器支持提案要解决的正是这个根本问题。它在1.28版本以alpha特性引入1.29版本正式beta。核心变化只有一行配置——在容器定义里加上restartPolicy: AlwaysKubernetes就不再把它当普通容器对待而是认定这个Pod里存在一个原生Sidecar。2.2 原生Sidecar的关键行为变化从使用角度讲原生Sidecar和普通容器最直观的区别体现在启动顺序和退出顺序上。Kubernetes从1.29开始保证了严格的生命周期次序Pod内的容器会先启动所有Sidecar容器等它们全部就绪后再启动主容器。这个设计非常合理解释了Sidecar的定位它必须先于主容器把日志管道铺好、把网络代理拉起、把配置文件同步到位主容器启动时才能直接“踩在已经铺好的路上跑”。退出顺序则相反Pod进入Terminating状态后先结束主容器再结束Sidecar容器。这个细节在生产环境非常重要尤其是Istio这类流量代理场景——如果Envoy先挂了业务容器还在收流量那整个请求路径就断了。Kubernetes原生Sidecar解决了这个顺序问题避免了很多线上事故。2.3 探针、就绪与重启策略的联动逻辑Sidecar容器同样支持startupProbe、livenessProbe和readinessProbe而且探针的行为会直接影响主容器的启动。这里有个比较隐蔽的细节值得单独拿出来讲原生Sidecar容器的readinessProbe如果失败它会阻止主容器的启动完成。也就是说Kubernetes把Sidecar的就绪状态当作主容器是否可启动的信号之一。我之前实测过一个场景Redis作为Sidecar给主应用做本地缓存我把readinessProbe设成了检查redis-cli ping结果Redis还没完全起好主容器就一直不启动。Pod状态卡在ContainerCreating日志里没有任何报错排查了半小时才找到原因。所以2026年的CKA备考者需要记住一个结论原生Sidecar不仅仅是“给容器加个restartPolicy”而是一套完整的生命周期管理语义。理解这套语义比背YAML重要得多。3. 实战拆解用CKA风格的考题练习原生Sidecar3.1 考题背景与部署目标CKA考试通常会给一个实际场景让你修改或创建资源。这里我模拟一道非常接近真题风格的题目在namespaceapp-team中创建一个名为webapp的Deployment副本数为1。Pod需要包含两个容器主容器web镜像nginx:1.27监听80端口Sidecar容器logger镜像busybox:1.36每5秒向/var/log/nginx/access.log追加一行访问记录要求两个容器必须共享/var/log/nginx目录logger必须是原生Sidecar即它不会导致主容器重启验证Sidecar容器已成功输出日志这道题覆盖了五个CKA核心考点Deployment创建、多容器Pod编排、emptyDir卷共享、原生Sidecar配置、日志验证。下面从头到尾写一遍。3.2 YAML编写与关键字段解释先创建一个Deployment的YAML文件文件名为webapp-deploy.yamlapiVersion: apps/v1 kind: Deployment metadata: name: webapp namespace: app-team labels: app: webapp spec: replicas: 1 selector: matchLabels: app: webapp template: metadata: labels: app: webapp spec: volumes: - name: shared-nginx-log emptyDir: {} containers: - name: web image: nginx:1.27 ports: - containerPort: 80 volumeMounts: - name: shared-nginx-log mountPath: /var/log/nginx - name: logger image: busybox:1.36 restartPolicy: Always command: [/bin/sh, -c] args: - | while true; do echo Access log entry at $(date) /var/log/nginx/access.log sleep 5 done volumeMounts: - name: shared-nginx-log mountPath: /var/log/nginx核心是logger容器里的restartPolicy: Always这一行。加了这一行Kubernetes才会把logger识别为原生Sidecar。如果去掉它logger就是个普通容器行为会回到老版本的“trick模式”启动顺序和退出顺序都不再受控。emptyDir卷在这里承担了两个容器之间的数据交换通道。Nginx的访问日志默认写到/var/log/nginx/access.log而logger容器把这个目录挂载到了同一位置通过共享文件系统的形式实现了日志的读取。注意题目没有要求logger真的去解析日志只要求追加内容所以这个写法完全合规。3.3 应用配置与验证路径应用配置的命令没什么特别之处kubectl create namespace app-team kubectl apply -f webapp-deploy.yaml查看Pod状态和容器启动情况kubectl get pods -n app-team -l appwebapp kubectl get pod -n app-team pod名 -o jsonpath{.spec.containers[*].name}第二个命令会输出类似web logger的结果说明两个容器都在Pod里。验证Sidecar日志是否真的在写kubectl exec -n app-team pod名 -c logger -- tail -n 5 /var/log/nginx/access.log这里-c logger指定进入Sidecar容器执行命令查看共享卷里的日志文件。你会看到类似下面的输出Access log entry at Mon Jan 13 10:24:01 UTC 2025 Access log entry at Mon Jan 13 10:24:06 UTC 2025 Access log entry at Mon Jan 13 10:24:11 UTC 2025这就验证了Sidecar容器在正常工作。但我想强调的是这道题在真实考试里通常会多问一步如果你删掉logger容器的restartPolicy: Always字段再查看Pod的容器启动顺序会发生什么变化这个问题的答案就是我下一节要讲的坑。4. 实操中容易踩的坑从挂科边缘到豁然开朗4.1 restartPolicy与Pod RestartPolicy的字段混淆这是我在练习中最先踩到的坑。Kubernetes有两个长得像但完全不同的字段spec.restartPolicyPod级别的字段决定容器退出后是否重启可选值为Always、OnFailure、Never默认Alwaysspec.containers[].restartPolicy容器级别的字段目前唯一支持的值就是Always用于标记原生Sidecar很多人在写Deployment时习惯性地把restartPolicy放在spec下面然后在同时定义Sidecar时又忘了一个关键点在Pod模板里spec.restartPolicy如果指定为Never或OnFailure那么所有容器都不会被重启包括标记为Sidecar的容器。这会导致Kubernetes把restartPolicy: Always的原生Sidecar语义覆盖掉Sidecar容器崩溃后不会被重新拉起。简单说原生Sidecar依赖的是容器级别的restartPolicy: Always但它仍然受Pod级restartPolicy的宏观约束。在Deployment场景中由于Job、CronJob这类工作负载默认就有不同的重启策略要求考试时一定要看清楚题目给的是哪种工作负载类型。我见过一个典型的错题解法题目要求创建一个CronJob里面带一个Sidecar容器做日志转发结果直接在容器的restartPolicy里写了Always。但CronJob的Pod模板如果指定了spec.restartPolicy: Never那么这个Pod永远没法成功完成——因为Sidecar容器会保持运行不退出Job就永远不会进入Completed状态。你说这道题是不是陷阱拉满4.2 资源限制与Sidecar的“隐藏成本”原生Sidecar在资源管理上的一个特点是它的容器启动后会一直运行到Pod生命周期结束。这意味着Sidecar消耗的资源CPU、内存和主容器一样是长期占用的不是启动完就释放。在CKA考题里题目有时会给出资源配额ResourceQuota或LimitRange的要求。比如命名空间app-team的ResourceQuota限制了每个Pod的requests.cpu总和不超过500m而你给主容器分配了400mSidecar又分配了200m那Pod创建就会直接报错Error from server (Forbidden): error when creating webapp-deploy.yaml: pods webapp-xxxx is forbidden: exceeded quota: ...这个时候有两个解法要么降低主容器的requests要么把Sidecar的resources字段删掉让它不单独声明。但删掉Sidecar的resources字段不等于它不占资源——如果命名空间有LimitRange默认值会自动套用照样可能超配额。我的建议是考试里只要看到ResourceQuota或LimitRange这两个关键词做题前第一步一定是把Pod里所有容器的resources都列出来算一遍不要只盯着主容器。这道题我错过一次那真的是整道题只拿了零分因为没有创建成功任何资源。4.3 探针共享与端口冲突Sidecar也有网络栈还是那个容易被忽略的点Sidecar容器和主容器共享同一个网络命名空间。也就是说它们看到的localhost是同一个。如果Sidecar容器里运行的服务监听了一个端口主容器又在同一端口上监听就会直接冲突Pod里的第二个容器会一直处于CrashLoopBackOff状态。这在考试场景里通常不会直接考但生产环境很常见。比如Istio注入Envoy Sidecar后Envoy默认占用15000、15001等端口这些端口不能跟业务容器的监听端口冲突。CKA题目如果让你排查一个多容器Pod反复崩溃的原因优先检查端口占用、共享卷的权限SCC/SELinux、以及VolumeMount路径是否写错——这三个原因加起来占了这类故障的八成以上。5. 从SideCar延伸到CKA-2026的整体备考策略5.1 2026年CKA技能域的可能侧重点CKA的考试大纲虽然每年会有微调但核心技能域一直是围绕集群架构、工作负载调度、存储、网络、安全和故障排查这六个大方向。我按“2026年大概率会加重比例”的角度推演过一遍Sidecar容器恰好能串联起其中好几个考点工作负载设计多容器Pod编排、Init容器与Sidecar容器的分工、Deployment滚动更新策略存储与共享emptyDir在容器间共享数据、CSI驱动的挂载、持久卷的ReadWriteMany权限安全上下文Sidecar容器是否继承Pod的SecurityContext、是否运行特权容器、Seccomp和AppArmor配置故障排查Pod启动顺序异常、容器CrashLoop、Sidecar探针失败导致的Pending状态更值得留意的是Gateway API在近两年的Kubernetes版本里逐步成熟内置的GAMMA倡议正是围绕Sidecar模式的南北向流量治理展开的。如果2026年CKA考题里出现“使用Kubernetes Gateway API配置流量策略”类的题目那和Sidecar的关系会非常紧密——因为典型的实现方式就是往工作负载里注入一个Sidecar代理。5.2 多花时间在“容器交互”而不是单一对象操作上很多备考者喜欢刷单一资源的题创建Deployment、创建Service、创建PVC。但2026年的CKA显然会更倾向于跨越两个以上的资源类型来出综合场景题。就拿Sidecar这个点来说一道高质量考题可能会要求你创建命名空间并打上标签创建Deployment里面配置一个原生Sidecar容器和主容器创建一个Headless Service让业务容器能被集群内其他Pod发现创建一个NetworkPolicy放行特定来源访问这个Service这类题目考的不再是“你会不会写某个YAML字段”而是“你能不能让整套资源协同运转”。我建议备考时专门挑这种多资源串联的题来练哪怕不考试对你的生产环境排障思路也是很好的锻炼。5.3 备考时间线的实操建议以一个已经有K8s基础、每天能投入两小时的人来说我建议的备考节奏是第1-2周通读当前版本CKA考纲重点是Workloads和Troubleshooting两个域把Deployment、StatefulSet、DaemonSet、Job、CronJob全部过一遍第3-4周集中练习多容器Pod场景包括Init容器、Sidecar容器、临时容器ephemeral container这是最容易拉分的部分第5周主攻网络和存储策略搭配Sidecar场景做综合题第6周刷真题模拟不限时先做完再定时模拟找到自己的弱点第7周查漏补缺尤其是RBAC、etcd备份恢复、集群升级这三类操作型大题性价比极高5.4 考试中的时间分配与命令速查技巧CKA考试是线上实操时长两小时24道题左右但题量每年可能有浮动。我的个人经验是选择题直接快速判断不要恋战大操作题先看清要求再动手写YAML不要一上来就敲命令。有几个命令我觉得值得记住能提升操作速度# 查看Pod里每个容器的启动状态和重启次数 kubectl get pod -n app-team pod名 -o wide kubectl describe pod -n app-team pod名 | grep -A 20 Events: # 进入Sidecar容器执行命令 kubectl exec -it pod名 -c logger -- /bin/sh # 快速查看镜像版本避免记错tag kubectl run nginx-test --imagenginx:1.27 --dry-runclient -o yaml | grep image # 获取所有Pod的容器名称列表 kubectl get pods -n app-team -o jsonpath{range .items[*]}{.metadata.name}{: }{.spec.containers[*].name}{\n}{end}6. 我的Sidecar学习笔记里最想保留的三条经验第一原生Sidecar真正解决的痛点不是“怎么跑一个伴随容器”而是“怎么控制伴随容器与主容器的生死顺序”。如果离开Kubernetes 1.29之后的行为变化去理解Sidecar就会错过它在设计层面最重要的价值。第二CKA的考试环境版本每年更新但底层原理基本不变。我在练习时特意用kubectl version确认过考试环境的版本发现原生Sidecar特性在1.29版本之后表现非常稳定对初学者很友好。如果你手头用的还是老版本也可以先用普通容器加Init容器的方式模拟类似效果但千万别在考试里混用这两种写法。第三真正值钱的不是“会写带有restartPolicy: Always的YAML”而是知道YAML里每一层配置会对集群调度器产生什么实际影响。这也是CKA跟那些选择题认证最大的区别它考的是你能不能在一个真实集群环境里把设计变成可用且可维护的资源。把这个系列命名为CKA-2026-SideCar初衷就是想记录从Surface层到底层原理的完整路径。这篇写完之后我下一个要拆解的笔记是“InitContainer与Sidecar的协作边界”两者经常一起出现但分工完全不同。等我把这个系列整理完会在后续文章里把完整的备考YAML合集和踩坑清单共享出来希望能帮到正在备考或者准备往云原生方向转型的读者。
2026 CKA备考：原生Sidecar容器原理与实操
1. 2026年的CKA备考为什么绕不开SideCar这个点先说清楚一件事这不是一个官方认证名称而是我自己备考2026年CKACertified Kubernetes Administrator时建的专项笔记代号。CKA这个认证最大的特点就是跟着Kubernetes版本滚动更新每年题型重心都会往新特性上偏移。我在梳理近两年的考纲变化时发现Sidecar容器已经从“了解即可”的边缘知识点逐渐变成了多容器Pod考题里躲不开的核心选项。为什么这么说因为CKA历来的传统考题就是多容器Pod设计只不过以前考的主要是“共享进程命名空间”“共享存储卷”这些基础用法。但从Kubernetes 1.28开始sidecar容器有了原生支持1.29又补齐了生命周期顺序控制这让考试出题人有了新的写题素材既要考察你对Pod编排基础的理解又能顺带检验你是否了解新版特性。可以这么说2026年的考场上如果出现“给现有Deployment增加一个sidecar容器”“调整sidecar容器启动顺序”这种题目我一点都不意外。这个系列笔记适合正在备考CKA的运维工程师、刚入门的K8s学习者也适合那些已经在生产环境用Istio、Envoy但没搞懂底层容器机制的人。我在这篇文章里把SideCar的前世今生、底层原理、实操写法、考试坑点一次性讲透内容全部基于Kubernetes 1.29到1.31之间稳定可用的特性不涉及任何实验性API。2. Sidecar容器的新旧之争以前叫模式现在叫一等公民2.1 先搞明白Sidecar到底解决什么问题Sidecar直译是“三轮摩托的边斗”在架构设计里指伴随主应用运行、辅助主应用完成特定功能的独立进程。经典的场景有三个日志采集如Filebeat跟随Nginx容器、流量代理如Istio的Envoy跟随业务容器、配置同步如Consul Template跟随Web容器。在1.28版本之前我们实现Sidecar模式用的是普通容器加command: [/bin/sh, -c, tail -f /dev/null]这种trick让辅助进程始终跑着不退出。问题在于这样做槽点很多生命周期完全不受控主容器挂了辅助容器还在跑Pod停止时清理顺序无法保证共享卷的写入时机也没有任何保障。说白了这只是“用普通容器模拟Sidecar”Kubernetes本身并不知道谁主谁辅。KEP-753原生Sidecar容器支持提案要解决的正是这个根本问题。它在1.28版本以alpha特性引入1.29版本正式beta。核心变化只有一行配置——在容器定义里加上restartPolicy: AlwaysKubernetes就不再把它当普通容器对待而是认定这个Pod里存在一个原生Sidecar。2.2 原生Sidecar的关键行为变化从使用角度讲原生Sidecar和普通容器最直观的区别体现在启动顺序和退出顺序上。Kubernetes从1.29开始保证了严格的生命周期次序Pod内的容器会先启动所有Sidecar容器等它们全部就绪后再启动主容器。这个设计非常合理解释了Sidecar的定位它必须先于主容器把日志管道铺好、把网络代理拉起、把配置文件同步到位主容器启动时才能直接“踩在已经铺好的路上跑”。退出顺序则相反Pod进入Terminating状态后先结束主容器再结束Sidecar容器。这个细节在生产环境非常重要尤其是Istio这类流量代理场景——如果Envoy先挂了业务容器还在收流量那整个请求路径就断了。Kubernetes原生Sidecar解决了这个顺序问题避免了很多线上事故。2.3 探针、就绪与重启策略的联动逻辑Sidecar容器同样支持startupProbe、livenessProbe和readinessProbe而且探针的行为会直接影响主容器的启动。这里有个比较隐蔽的细节值得单独拿出来讲原生Sidecar容器的readinessProbe如果失败它会阻止主容器的启动完成。也就是说Kubernetes把Sidecar的就绪状态当作主容器是否可启动的信号之一。我之前实测过一个场景Redis作为Sidecar给主应用做本地缓存我把readinessProbe设成了检查redis-cli ping结果Redis还没完全起好主容器就一直不启动。Pod状态卡在ContainerCreating日志里没有任何报错排查了半小时才找到原因。所以2026年的CKA备考者需要记住一个结论原生Sidecar不仅仅是“给容器加个restartPolicy”而是一套完整的生命周期管理语义。理解这套语义比背YAML重要得多。3. 实战拆解用CKA风格的考题练习原生Sidecar3.1 考题背景与部署目标CKA考试通常会给一个实际场景让你修改或创建资源。这里我模拟一道非常接近真题风格的题目在namespaceapp-team中创建一个名为webapp的Deployment副本数为1。Pod需要包含两个容器主容器web镜像nginx:1.27监听80端口Sidecar容器logger镜像busybox:1.36每5秒向/var/log/nginx/access.log追加一行访问记录要求两个容器必须共享/var/log/nginx目录logger必须是原生Sidecar即它不会导致主容器重启验证Sidecar容器已成功输出日志这道题覆盖了五个CKA核心考点Deployment创建、多容器Pod编排、emptyDir卷共享、原生Sidecar配置、日志验证。下面从头到尾写一遍。3.2 YAML编写与关键字段解释先创建一个Deployment的YAML文件文件名为webapp-deploy.yamlapiVersion: apps/v1 kind: Deployment metadata: name: webapp namespace: app-team labels: app: webapp spec: replicas: 1 selector: matchLabels: app: webapp template: metadata: labels: app: webapp spec: volumes: - name: shared-nginx-log emptyDir: {} containers: - name: web image: nginx:1.27 ports: - containerPort: 80 volumeMounts: - name: shared-nginx-log mountPath: /var/log/nginx - name: logger image: busybox:1.36 restartPolicy: Always command: [/bin/sh, -c] args: - | while true; do echo Access log entry at $(date) /var/log/nginx/access.log sleep 5 done volumeMounts: - name: shared-nginx-log mountPath: /var/log/nginx核心是logger容器里的restartPolicy: Always这一行。加了这一行Kubernetes才会把logger识别为原生Sidecar。如果去掉它logger就是个普通容器行为会回到老版本的“trick模式”启动顺序和退出顺序都不再受控。emptyDir卷在这里承担了两个容器之间的数据交换通道。Nginx的访问日志默认写到/var/log/nginx/access.log而logger容器把这个目录挂载到了同一位置通过共享文件系统的形式实现了日志的读取。注意题目没有要求logger真的去解析日志只要求追加内容所以这个写法完全合规。3.3 应用配置与验证路径应用配置的命令没什么特别之处kubectl create namespace app-team kubectl apply -f webapp-deploy.yaml查看Pod状态和容器启动情况kubectl get pods -n app-team -l appwebapp kubectl get pod -n app-team pod名 -o jsonpath{.spec.containers[*].name}第二个命令会输出类似web logger的结果说明两个容器都在Pod里。验证Sidecar日志是否真的在写kubectl exec -n app-team pod名 -c logger -- tail -n 5 /var/log/nginx/access.log这里-c logger指定进入Sidecar容器执行命令查看共享卷里的日志文件。你会看到类似下面的输出Access log entry at Mon Jan 13 10:24:01 UTC 2025 Access log entry at Mon Jan 13 10:24:06 UTC 2025 Access log entry at Mon Jan 13 10:24:11 UTC 2025这就验证了Sidecar容器在正常工作。但我想强调的是这道题在真实考试里通常会多问一步如果你删掉logger容器的restartPolicy: Always字段再查看Pod的容器启动顺序会发生什么变化这个问题的答案就是我下一节要讲的坑。4. 实操中容易踩的坑从挂科边缘到豁然开朗4.1 restartPolicy与Pod RestartPolicy的字段混淆这是我在练习中最先踩到的坑。Kubernetes有两个长得像但完全不同的字段spec.restartPolicyPod级别的字段决定容器退出后是否重启可选值为Always、OnFailure、Never默认Alwaysspec.containers[].restartPolicy容器级别的字段目前唯一支持的值就是Always用于标记原生Sidecar很多人在写Deployment时习惯性地把restartPolicy放在spec下面然后在同时定义Sidecar时又忘了一个关键点在Pod模板里spec.restartPolicy如果指定为Never或OnFailure那么所有容器都不会被重启包括标记为Sidecar的容器。这会导致Kubernetes把restartPolicy: Always的原生Sidecar语义覆盖掉Sidecar容器崩溃后不会被重新拉起。简单说原生Sidecar依赖的是容器级别的restartPolicy: Always但它仍然受Pod级restartPolicy的宏观约束。在Deployment场景中由于Job、CronJob这类工作负载默认就有不同的重启策略要求考试时一定要看清楚题目给的是哪种工作负载类型。我见过一个典型的错题解法题目要求创建一个CronJob里面带一个Sidecar容器做日志转发结果直接在容器的restartPolicy里写了Always。但CronJob的Pod模板如果指定了spec.restartPolicy: Never那么这个Pod永远没法成功完成——因为Sidecar容器会保持运行不退出Job就永远不会进入Completed状态。你说这道题是不是陷阱拉满4.2 资源限制与Sidecar的“隐藏成本”原生Sidecar在资源管理上的一个特点是它的容器启动后会一直运行到Pod生命周期结束。这意味着Sidecar消耗的资源CPU、内存和主容器一样是长期占用的不是启动完就释放。在CKA考题里题目有时会给出资源配额ResourceQuota或LimitRange的要求。比如命名空间app-team的ResourceQuota限制了每个Pod的requests.cpu总和不超过500m而你给主容器分配了400mSidecar又分配了200m那Pod创建就会直接报错Error from server (Forbidden): error when creating webapp-deploy.yaml: pods webapp-xxxx is forbidden: exceeded quota: ...这个时候有两个解法要么降低主容器的requests要么把Sidecar的resources字段删掉让它不单独声明。但删掉Sidecar的resources字段不等于它不占资源——如果命名空间有LimitRange默认值会自动套用照样可能超配额。我的建议是考试里只要看到ResourceQuota或LimitRange这两个关键词做题前第一步一定是把Pod里所有容器的resources都列出来算一遍不要只盯着主容器。这道题我错过一次那真的是整道题只拿了零分因为没有创建成功任何资源。4.3 探针共享与端口冲突Sidecar也有网络栈还是那个容易被忽略的点Sidecar容器和主容器共享同一个网络命名空间。也就是说它们看到的localhost是同一个。如果Sidecar容器里运行的服务监听了一个端口主容器又在同一端口上监听就会直接冲突Pod里的第二个容器会一直处于CrashLoopBackOff状态。这在考试场景里通常不会直接考但生产环境很常见。比如Istio注入Envoy Sidecar后Envoy默认占用15000、15001等端口这些端口不能跟业务容器的监听端口冲突。CKA题目如果让你排查一个多容器Pod反复崩溃的原因优先检查端口占用、共享卷的权限SCC/SELinux、以及VolumeMount路径是否写错——这三个原因加起来占了这类故障的八成以上。5. 从SideCar延伸到CKA-2026的整体备考策略5.1 2026年CKA技能域的可能侧重点CKA的考试大纲虽然每年会有微调但核心技能域一直是围绕集群架构、工作负载调度、存储、网络、安全和故障排查这六个大方向。我按“2026年大概率会加重比例”的角度推演过一遍Sidecar容器恰好能串联起其中好几个考点工作负载设计多容器Pod编排、Init容器与Sidecar容器的分工、Deployment滚动更新策略存储与共享emptyDir在容器间共享数据、CSI驱动的挂载、持久卷的ReadWriteMany权限安全上下文Sidecar容器是否继承Pod的SecurityContext、是否运行特权容器、Seccomp和AppArmor配置故障排查Pod启动顺序异常、容器CrashLoop、Sidecar探针失败导致的Pending状态更值得留意的是Gateway API在近两年的Kubernetes版本里逐步成熟内置的GAMMA倡议正是围绕Sidecar模式的南北向流量治理展开的。如果2026年CKA考题里出现“使用Kubernetes Gateway API配置流量策略”类的题目那和Sidecar的关系会非常紧密——因为典型的实现方式就是往工作负载里注入一个Sidecar代理。5.2 多花时间在“容器交互”而不是单一对象操作上很多备考者喜欢刷单一资源的题创建Deployment、创建Service、创建PVC。但2026年的CKA显然会更倾向于跨越两个以上的资源类型来出综合场景题。就拿Sidecar这个点来说一道高质量考题可能会要求你创建命名空间并打上标签创建Deployment里面配置一个原生Sidecar容器和主容器创建一个Headless Service让业务容器能被集群内其他Pod发现创建一个NetworkPolicy放行特定来源访问这个Service这类题目考的不再是“你会不会写某个YAML字段”而是“你能不能让整套资源协同运转”。我建议备考时专门挑这种多资源串联的题来练哪怕不考试对你的生产环境排障思路也是很好的锻炼。5.3 备考时间线的实操建议以一个已经有K8s基础、每天能投入两小时的人来说我建议的备考节奏是第1-2周通读当前版本CKA考纲重点是Workloads和Troubleshooting两个域把Deployment、StatefulSet、DaemonSet、Job、CronJob全部过一遍第3-4周集中练习多容器Pod场景包括Init容器、Sidecar容器、临时容器ephemeral container这是最容易拉分的部分第5周主攻网络和存储策略搭配Sidecar场景做综合题第6周刷真题模拟不限时先做完再定时模拟找到自己的弱点第7周查漏补缺尤其是RBAC、etcd备份恢复、集群升级这三类操作型大题性价比极高5.4 考试中的时间分配与命令速查技巧CKA考试是线上实操时长两小时24道题左右但题量每年可能有浮动。我的个人经验是选择题直接快速判断不要恋战大操作题先看清要求再动手写YAML不要一上来就敲命令。有几个命令我觉得值得记住能提升操作速度# 查看Pod里每个容器的启动状态和重启次数 kubectl get pod -n app-team pod名 -o wide kubectl describe pod -n app-team pod名 | grep -A 20 Events: # 进入Sidecar容器执行命令 kubectl exec -it pod名 -c logger -- /bin/sh # 快速查看镜像版本避免记错tag kubectl run nginx-test --imagenginx:1.27 --dry-runclient -o yaml | grep image # 获取所有Pod的容器名称列表 kubectl get pods -n app-team -o jsonpath{range .items[*]}{.metadata.name}{: }{.spec.containers[*].name}{\n}{end}6. 我的Sidecar学习笔记里最想保留的三条经验第一原生Sidecar真正解决的痛点不是“怎么跑一个伴随容器”而是“怎么控制伴随容器与主容器的生死顺序”。如果离开Kubernetes 1.29之后的行为变化去理解Sidecar就会错过它在设计层面最重要的价值。第二CKA的考试环境版本每年更新但底层原理基本不变。我在练习时特意用kubectl version确认过考试环境的版本发现原生Sidecar特性在1.29版本之后表现非常稳定对初学者很友好。如果你手头用的还是老版本也可以先用普通容器加Init容器的方式模拟类似效果但千万别在考试里混用这两种写法。第三真正值钱的不是“会写带有restartPolicy: Always的YAML”而是知道YAML里每一层配置会对集群调度器产生什么实际影响。这也是CKA跟那些选择题认证最大的区别它考的是你能不能在一个真实集群环境里把设计变成可用且可维护的资源。把这个系列命名为CKA-2026-SideCar初衷就是想记录从Surface层到底层原理的完整路径。这篇写完之后我下一个要拆解的笔记是“InitContainer与Sidecar的协作边界”两者经常一起出现但分工完全不同。等我把这个系列整理完会在后续文章里把完整的备考YAML合集和踩坑清单共享出来希望能帮到正在备考或者准备往云原生方向转型的读者。