Question

有时候，我会看到一个问题，即如果没有网络连接，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"

Answer 1

看起来您的网络驱动程序无法正常运行。如果没有关于您的设置的更多信息，我只能建议您：

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

Answer 2

我没有足够的评论点，所以这个答案是对Prashanth B的回应（https://stackoverflow.com/users/5446771/prashanth-b）

让我描述＆＃34;没有网络连接＆＃34;更详细。当我执行其中一个遭受最初描述的症状的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上打开的端口。

/ # 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次，跨越数十个部署＆＃39;。从来没有相同的部署有问题，我们唯一的办法是删除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的数量有关。

Answer 3

回应freehan（https://stackoverflow.com/users/7577983/freehan）

我们正在使用默认的网络插件，正如您所指出的那样是原生的docker one。

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

我打算运行一个安装了tcpdump的容器，并在启动来自pod的出站网络流量时观察与问题pod关联的veth上的流量（例如：ping，dig，curl或给定pod中可用的任何内容））。

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

Answer 4

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

偶尔会创建没有网络的pod，这会导致pod使用CrashLoopBackOff

4 个答案: