服务网格 ASM：为什么为Pod注入Sidecar后，Pod处于init crash的状态

问题现象

为Pod注入Sidecar之后，执行以下命令，查看Pod状态，发现Pod处于init crash的状态。

kubectl get pod

预期输出：

NAME                 READY       STATUS                    RESTARTS        AGE
details-v1-u****     0/2         Init:Error                1               12h
productpage-n****    0/2         Init:CrashLoopBackOff     3               12h

然后执行以下命令，查看istio-init容器日志。

kubectl --kubeconfig=${USER_KUBECONFIG} -c istio-init logs ${pod}

预期输出：

......
......
-A ISTIO_OUTPUT -d 127.0.**.**/32 -j RETURN
-A ISTIO_OUTPUT -d 192.168.0.1/32 -j RETURN
-A ISTIO_OUTPUT -j ISTIO_REDIRECT
COMMIT
2022-03-23T06:42:21.179567Z    info    Running command: iptables-restore --noflush /tmp/iptables-rules-1648017741179373856.txt4205119933
2022-03-23T06:42:21.185698Z    error    Command error output: xtables other problem: line 2 failed
2022-03-23T06:42:21.185720Z    error    Failed to execute: iptables-restore --noflush /tmp/iptables-rules-1648017741179373856.txt4205119933, exit status 1

可以看到istio-init容器日志包含Failed to execute: iptables-restore信息。

问题原因

检查是否曾经手动通过docker container rm/docker container prune/docker system prune等命令清理了已经退出的istio-init容器，或者是否存在清理容器的相应的定时任务。

清理已退出的istio-init容器，会导致K8s检测到Pod关联的容器不存在，此时K8s会重新启动被删除的容器。由于之前已创建了iptables规则，istio-init容器不能再次执行iptables规则，导致新启动的istio-init容器设置iptables规则失败而崩溃。

解决方案

您需要重建Pod，重建后，服务的Pod将恢复正常状态。