Istio CNI 处理坏 Pod 的 repairPods、deletePods 与 labelPods 三种模式怎么选【免费下载链接】istioConnect, secure, control, and observe services.项目地址: https://gitcode.com/GitHub_Trending/is/istio在 Istio 以 CNI 插件方式接入后istio-cni-nodeDaemonSet 在每个节点上安装 CNI 插件并负责 Pod 网络配置个别 Pod 的 Istio 初始化会失败注入的istio-validationinit 容器反复 crashPod 无法完成 sidecar 引流配置。此时由 CNI 节点代理内置的 repair 控制器接管处理——它的总开关repair.enabled默认为true而具体怎么处理这个坏 Pod由repairPods、deletePods、labelPods三个模式决定且 values.yaml 中明确注释Repair controller has 3 modes. Pick which one meets your use cases. Note only one may be used.这篇文章基于仓库中的 Helm values、模板和cni/pkg/repair源码说明三个模式各自做什么、需要什么权限以及如何配置和验证结果。repair 控制器眼中的坏 Pod是哪些选模式之前先明确控制器到底在监控什么因为三种模式共享同一套检测逻辑见 repaircontroller.go 的matchesFilterPod 必须带sidecar.istio.io/status注解DaemonSet 通过环境变量REPAIR_SIDECAR_ANNOTATION指定见 daemonset.yaml存在名为repair.initContainerName默认istio-validation的 init 容器该 init 容器当前状态不是Completed/退出码 0——源码注释强调如果容器成功退出永远不会把该 Pod 判定为 broken其LastTerminationState匹配过滤器init 容器终止消息和退出码默认不过滤。控制器还只处理本节点上的 Pod按spec.nodeName做 field selector 过滤所以哪个节点上坏了就由该节点的istio-cni-node代理处理。三种模式分别做什么模式默认值检测到坏 Pod 后的动作额外 RBAC其他要求repairPodstrue在 Pod 已启动的情况下动态进入其网络命名空间重新程序化 iptables或 nftables引流规则无clusterrole.yaml 中注释No privileges needed需要securityContext.privileged/CAP_SYS_ADMINDaemonSet 已授予SYS_ADMIN、SYS_PTRACE等deletePodsfalse直接删除坏 Pod由调度器重新调度pods: delete删除时使用UIDResourceVersion前置条件确保删的是自己刚看到的那个 PodlabelPodsfalse给坏 Pod 打标签cni.istio.io/uninitializedtruekey/value 默认值来自 values.yaml之后由用户自行修复通常是删除pods/status: patch, update模板注释说明pods/status比完整 pod 权限低无自动修复能力values 中的原文注释补充了各自的边界repairPodsPod 此时处于 crashloopthis may take a few minutes to become fully functional based on when the retry occurs——恢复耗时取决于重试时机deletePodsThese will then be rescheduled, hopefully onto a node that is fully ready且it can delete any Pod属于较高权限labelPodsThis is only capable of identifying broken pods; the user is responsible for fixing them (generally, by deleting them)同时提示修改 Pod metadata/status 也可能带来较广影响。另外注意两点源码行为若同时打开多个开关ReconcilePod的判断顺序是repairPods→deletePods→labelPods即repairPods优先生效labelPods是幂等的Pod 已带该 label key 时直接跳过日志already has label with key ..., skipping指标计resultskip不会反复 patch。怎么选按仓库文档给出的事实对应到使用条件默认保持repairPods: true推荐起点。它不需要任何额外 RBAC权限要求节点侧 capability在 DaemonSet 中已经配好适合希望 Pod 原地恢复、且不额外授权的场景。代价是恢复不是立即完成的——Pod 还在 crashloop要等重试周期文档明确说may take a few minutes。选deletePods当坏的原因是 Pod 被调度到了尚未完全就绪的节点时更合适——删除后重新调度hopefully onto a node that is fully ready。前提是你愿意给 istio-cni 的 ServiceAccount 授予删除任意 Pod 的 RBAC。选labelPods适合不想让 CNI 代理自动改/删 Pod 的环境让它只负责标记实际修复动作通常是kubectl delete留给人工或其他自动化。它不提供自愈只是把坏 Pod 暴露出来。如何配置修改repair段后随你的 helm install/upgrade 命令下发即可values 中已有默认值下面是一个切换到deletePods模式的完整示例其余字段含义见 values.yamlrepair: enabled: true labelPods: false deletePods: true repairPods: false initContainerName: istio-validation brokenPodLabelKey: cni.istio.io/uninitialized brokenPodLabelValue: true这些值会渲染为 ConfigMapistio-cni-config中的环境变量REPAIR_ENABLED、REPAIR_REPAIR_PODS、REPAIR_DELETE_PODS、REPAIR_LABEL_PODS、REPAIR_INIT_CONTAINER_NAME、REPAIR_BROKEN_POD_LABEL_KEY/VALUE见 configmap-cni.yamlDaemonSet 的install-cni容器通过envFrom读取它。与模式选择直接相关的两个附带变化RBACrepair.enabled为 true 时会创建-repair-roleClusterRoleeventscreate/patch podswatch/get/list然后按上面表格的模式追加权限/proc 挂载只有repairPods或 ambient 开启时DaemonSet 才只读挂载节点的/proc——repair 模式需要它来进入 Pod 网络命名空间。切到deletePods/labelPods后不再需要该挂载。如果集群启用了global.nativeNftables: truerepair 控制器程序化的是 nftables 规则而不是 iptables 规则redirectRunningPodNFTrepaircontroller.go。initContainerName必须与实际注入的校验容器名一致否则控制器不会把 Pod 识别为坏 Pod。验证结果以下验证手段均来自仓库中的真实实现看节点上 istio-cni-node Pod 的日志cni/README.md 的 Troubleshooting 章节给出的方式。需要替换namespace为 istio-cni 所在命名空间、node为出问题的节点名kubectl -n namespace logs -l k8s-appistio-cni-node -c install-cni \ --field-selector spec.nodeNamenode按模式应出现的日志源码中的真实字符串控制器启动starting CNI sidecar repair controller若repair.enabledfalse则是CNI repair controller is disableddelete 模式Pod detected as broken, deleting: namespace/podlabel 模式Pod detected as broken, adding label: namespace/pod重复命中时Pod namespace/pod already has label with key cni.istio.io/uninitialized, skipping。排查粒度不够时README 建议设置values.global.logging.levelcni:debug,ambient:debug。看 Pod 上的事件控制器通过事件记录器namecni-repair在 Pod 上写事件reason 为DeleteBrokenPod消息pod detected as broken, deleted失败时but failed to delete: ...或LabelBrokenPodpod detected as broken, labeled可用kubectl describe pod pod查看。看指标repair 控制器上报 monitoring.go 中定义的istio_cni_repair_pods_repaired_total标签type取值repair/delete/labelresult取值success/skip/fail该指标暴露在 DaemonSet 的 15014 监控端口上Pod 带prometheus.io/scrape注解path/metrics。labelPods 模式下的收尾用kubectl get pods -A -l cni.istio.io/uninitializedtrue找出被标记的坏 Pod再按 values 注释的说法自行修复generally, by deleting them——这一步由你完成控制器不会代劳。限制与边界三个模式互斥only one may be used且代码顺序上repairPods优先repair 只处理带sidecar.istio.io/status注解、且istio-validationinit 容器 crashloop 的 Pod从未注入 sidecar 或没有该 init 容器的 Pod 不在处理范围内README 中描述的 created in corner cases 即此类场景repairPods恢复的是 Pod 的网络引流配置应用容器本身的 crashloop 不受它影响恢复要等重试发生本文只覆盖 sidecar 的 repair 场景ambient 模式有独立的控制器与配置见 cni/README.md 指向的 ambient 架构文档不在本文范围内。【免费下载链接】istioConnect, secure, control, and observe services.项目地址: https://gitcode.com/GitHub_Trending/is/istio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考