有时会在没有网络的情况下创建 pod，这会导致 pod 反复失败并出现 CrashLoopBackOff答案

【问题标题】：Occasionally pods will be created with no network which results in the pod failing repeatedly with CrashLoopBackOff有时会在没有网络的情况下创建 pod，这会导致 pod 反复失败并出现 CrashLoopBackOff
【发布时间】：2017-07-03 03:02:59
【问题描述】：

有时，我会看到 Pod 在没有网络连接的情况下启动的问题。因此，pod 进入 CrashLoopBackOff 并且无法恢复。我能够让 pod 再次运行的唯一方法是运行 kubectl delete pod 并等待它重新安排。以下是由于此问题导致的活性探测失败的示例：

Liveness probe failed: Get http://172.20.78.9:9411/health: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

我还注意到，发生这种情况时，pod IP 没有 iptables 条目。当 pod 被删除并重新安排（并且处于工作状态）时，我有 iptables 条目。

如果我关闭容器中的 livenessprobe 并执行它，我确认它与集群或本地网络或互联网没有网络连接。

想听听关于它可能是什么的任何建议，或者我可以研究什么以进一步解决这种情况。

目前正在运行：

Kubernetes 版本：

Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.7",
GitCommit:"92b4f971662de9d8770f8dcd2ee01ec226a6f6c0", 
GitTreeState:"clean", BuildDate:"2016-12-10T04:49:33Z", 
GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}

Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.7",  
GitCommit:"92b4f971662de9d8770f8dcd2ee01ec226a6f6c0", 
GitTreeState:"clean", BuildDate:"2016-12-10T04:43:42Z", 
GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}

操作系统：

NAME=CoreOS
ID=coreos
VERSION=1235.0.0
VERSION_ID=1235.0.0
BUILD_ID=2016-11-17-0416
PRETTY_NAME="CoreOS 1235.0.0 (MoreOS)"
ANSI_COLOR="1;32"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://github.com/coreos/bugs/issues"

【问题讨论】：

您不会获得未准备好的端点的 iptables 条目（例如：crashloopbackoff 中的死容器）。您应该首先诊断网络问题，“没有网络连接”是什么意思？您可以访问 google.com 吗？你能到达同一个集群中的另一个 pod 或服务吗？请开始调试：kubernetes.io/docs/user-guide/debugging-services 并报告哪一步失败。

标签： kubernetes kubelet

【解决方案1】：

您的网络驱动程序似乎无法正常工作。如果没有关于您的设置的更多信息，我只能建议您以下几点：

找出使用了什么网络驱动程序？您可以通过检查 kubelet --network-plugin 标志来判断。如果没有指定网络插件，那么它使用的是本地 docker 网络。
给定网络驱动程序，检查 pod 网络设置并查看缺少的内容。使用 tcpdump 查看数据包的去向。

【讨论】：

【解决方案2】：

我没有足够的积分来评论，所以这个答案是为了回应 Prashanth B (https://stackoverflow.com/users/5446771/prashanth-b)

让我更详细地描述“没有网络连接”。当我执行到一个遭受最初描述的症状的 pod 时，这就是我看到的网络问题。

在此示例中，我们有一个 pod，它正在遭受似乎没有任何网络连接的 pod 的影响。

首先，我从 pod ping 物理节点（eth0 接口）的可路由 ip。这适用于同一节点上正常工作的 pod。

# ping 10.30.8.66
PING 10.30.8.66 (10.30.8.66): 56 data bytes
92 bytes from tv-dmx-prototype-3638746950-l8fgu (172.20.68.16): 
Destination Host Unreachable
^C

尝试内部或外部 DNS 解析。我不希望 ping 工作，但这是容器中唯一可用的工具来进行名称解析。由于没有网络，我无法安装其他任何东西。

# ping kubernetes
^C
# ping www.google.com
^C
#

我将尝试从同一个集群中的另一个 pod 和与不工作的 pod 位于同一物理节点的另一个 pod 连接到该 pod 上打开的端口。

/ # telnet 172.20.68.16 80
telnet: can't connect to remote host (172.20.68.16): Host is unreachable
/ #

从物理节点我无法连接端口 80 上的 pod ip

core@ip-10-30-8-66 ~ $ curl 172.20.68.16:80
curl: (7) Failed to connect to 172.20.68.16 port 80: No route to host

我查看了https://kubernetes.io/docs/user-guide/debugging-services/ 的故障排除指南，但该指南旨在诊断将 kubernetes 服务连接到一个或多个 pod 的问题。在我的场景中，我们在创建一个不特定于服务的 pod 时遇到了不可预测的行为。例如，我们每周会在跨越数十个“部署”的 3 个不同集群中看到 1 到 3 次这种情况。有问题的部署绝不是同一个部署，我们唯一的办法是删除 pod，之后它会被正确实例化。

我已经阅读了故障排除指南的相关部分并将其发布在此处。

这里我们看到 kubelet 和 kube-proxy 正在运行

root       7186   7167  2 Jan19 ?        15:14:25 /hyperkube proxy          --master=https://us-east-1-services-kubernetes.XXXXX.com 
 --proxy-mode=iptables --kubeconfig=/var/lib/kube-proxy/kubeconfig
core      25646  26300  0 19:22 pts/0    00:00:00 grep --colour=auto -i hyperkube


kubelet --address=0.0.0.0 --pod-manifest-path=/etc/kubernetes/manifests --enable-server --logtostderr=true --port=10250 --allow-privileged=True --max-pods=110 --v=2 --api_servers=https://us-east-1-services-kubernetes.XXXXXX.com --enable-debugging-handlers=true --cloud-provider=aws --cluster_dns=172.16.0.10 --cluster-domain=cluster.local --kubeconfig=/var/lib/kubelet/kubeconfig --node-labels=beta.kubernetes.io/instance-type=c4.8xlarge,failure-domain.beta.kubernetes.io/region=us-east-1,failure-domain.beta.kubernetes.io/zone=us-east-1d,kubernetes.io/hostname=ip-10-30-8-66.ec2.internal,public-hostname=ec2-52-207-185-19.compute-1.amazonaws.com,instance-id=i-03074c6772d89ede8

我已经验证 kube-proxy 正在通过访问同一节点上的其他 pod 进行代理。

core@ip-10-30-8-66 ~ $ curl 172.20.68.12 80
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.11.4</center>
</body>
</html>
curl: (7) Couldn't connect to server

刚刚部署了一个新版本的应用程序，但我丢失了用于故障排除的 pod。当此症状再次出现时，我将开始准备一些额外的命令以运行。我还将运行大量的部署创建，因为我们得到的坏 pod 的数量与正在创建的新 pod 的数量有关。

【讨论】：

【解决方案3】：

回应freehan (https://stackoverflow.com/users/7577983/freehan)

我们正在使用默认的网络插件，正如您所指出的，它是本机 docker 插件。

关于使用 tcpdump 捕获数据包路径的建议。您知道确定哪个 veth 与给定 pod 关联的简单方法吗？

我计划运行一个安装了 tcpdump 的容器，并观察与问题 pod 相关的 veth 上的流量，同时从 pod 启动出站网络流量（例如：ping、dig、curl 或给定 pod 中可用的任何内容)。

如果您有其他想法，请告诉我，我会尝试。

【讨论】：

【解决方案4】：

我认为我们正在解决这个错误https://github.com/coreos/bugs/issues/1785。我已经验证我可以重现我们的 docker/coreos 版本中列出的错误。将 coreos/docker 和验证。

【讨论】：