istio-init容器Init:CrashLoopBackOff故障解决

istio-init容器Init:CrashLoopBackOff故障解决

最近在测试istio时,经常发现注入过sidecar的pod过段时间就变成了Init:CrashLoopBackOff状态。如:

我的kubernetes版本为1.14.10,istio版本为:1.5.1
查看istio-init容器的日志,发现有如下的报错:

从报错来看,istio-init容器重启了,并且在重启时,执行iptables报错。这就奇怪了,正常来说,init容器是执行完成后就结束,并不会再次执行的。

把pod删除,让其重新创建一个新的pod,发现是可以正常启动的。

Pod 重启,会导致 Init 容器重新执行,主要有如下几个原因:

  • 用户更新 PodSpec 导致 Init 容器镜像发生改变。应用容器镜像的变更只会重启应用容器。
  • Pod 基础设施容器被重启。这不多见,但某些具有 root 权限可访问 Node 的人可能会这样做。
  • 当 restartPolicy 设置为 Always,Pod 中所有容器会终止,强制重启,由于垃圾收集导致 Init 容器完整的记录丢失。

基于以上原因,怀疑是我定时清理docker磁盘导致的。我定时清理方式如下:

于是手动又执行了一次docker system prune -a -f,发现果然istio-init容器又重启报错了。

网上查了一下,发现已经有人提过issue了.
https://github.com/istio/istio/issues/19717
https://github.com/kubernetes/kubernetes/issues/67261

发生的原因主要是init容器是执行完后就退出的,也就是是一个停止的容器。

执行docker system prune -a -f清理会把已经停止的容器清理掉。kubelet发现这个容器被清理掉后,又把这个init容器给重启了。目前看来还没有fix这个问题。

不过可以通过以下方式规避:

One thought on “istio-init容器Init:CrashLoopBackOff故障解决

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注

3 × 1 =

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据