偶爾會創建一個沒有網絡的pod，導致pod重複失敗，導致CrashLoopBackOff

偶爾，我看到一個問題，在沒有網絡連接的情況下pod將啓動。因此，吊艙進入CrashLoopBackOff並且無法恢復。我能夠再次運行pod的唯一方法是運行kubectl delete pod並等待其重新計劃。這裏的活躍度探測失敗的例子，由於這個問題：偶爾會創建一個沒有網絡的pod，導致pod重複失敗，導致CrashLoopBackOff

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)

我也注意到，有吊艙IP沒有iptables的條目時發生這種情況。當pod被刪除並重新安排（並且處於工作狀態）時，我擁有iptables條目。

如果關閉容器中的livenessprobe並將exec執行到其中，我確認它沒有與羣集或本地網絡或Internet的網絡連接。

希望聽到任何有關它可能是什麼的建議，或者我可以考慮進一步排查此情況。

目前運行：

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"}

OS：

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"

來源

2017-02-14 jswoods

對於未準備好的端點（例如：crashloopbackoff中的死容器），您不會獲得iptables條目。您應該首先診斷網絡問題，「沒有網絡連接」是什麼意思？你可以到達google.com嗎？您是否可以在同一集羣中訪問另一個Pod或Service？請開始調試：https：//kubernetes.io/docs/user-guide/debugging-services/並報告哪一步失敗。 –

看起來你的網絡驅動程序不能正常工作。沒有關於您的設置的更多信息，我只能向您建議以下內容：

找出使用哪個網絡驅動程序？你可以通過檢查kubelet --network-plugin標誌來判斷。如果沒有指定網絡插件，則使用本地碼頭網絡。
鑑於網絡驅動程序，請檢查pod網絡設置並查看缺少的內容。使用tcpdump查看數據包的位置。

來源

2017-02-16 23:50:52 freehan

我沒有足夠的積分評論所以這個答案是響應普拉香特B（https://stackoverflow.com/users/5446771/prashanth-b）

讓我更詳細地描述「無網絡連接」。當我進入一個正在遭受最初描述的症狀的豆莢時，這就是我所看到的那種網絡問題。

在這個例子中，我們有一個容器正在遭受沒有任何網絡連通性的容器。

首先我ping pod中物理節點（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 
#

從同一個集羣中，並在同一物理節點的工作不莢，我會嘗試連接到一個空閒端口上莢開放上的另一盒。

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

從物理節點無法連接端口80

[email protected] ~ $ curl 172.20.68.16:80 
curl: (7) Failed to connect to 172.20.68.16 port 80: No route to host

莢IP我通過故障排除指南看着https://kubernetes.io/docs/user-guide/debugging-services/，但該指南是針對診斷問題kubernetes服務連接到一個或更多豆莢。在我的情況下，我們遇到了一個不可預知的行爲，創建了一個不是服務特定的pod。例如，我們在跨越數十個「部署」的3個不同的集羣中每週看到這樣的1-3次。它從來沒有出現過這個問題，我們唯一的辦法就是刪除它，然後正確地實例化它。

我已經通過故障排除指南的相關部分並將其發佈到此處。

這裏我們看到kubelet和KUBE-代理正在運行

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-代理是達不到這個同一節點上其他莢代理。

[email protected] ~ $ 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。當這種症狀再次發生時，我將開始準備一些額外的命令來運行。我還會運行大量的部署創建，因爲我們得到的壞莢的數量與正在創建的新莢數量有關。

來源

2017-02-17 20:00:50

針對freehan（https://stackoverflow.com/users/7577983/freehan）

我們正在使用您指出的是本土泊塢窗其中一個默認網絡插件。

關於使用tcpdump捕獲數據包路徑的建議。你知道一個簡單的方法來確定哪個veth與給定的pod關聯嗎？

我打算運行安裝了tcpdump的容器，並在從容器啓動出站網絡流量時觀察與問題容器關聯的流量上的流量（例如：ping，dig，curl或給定的任何內容莢）。

讓我知道你是否有其他想法，我會嘗試。

來源

2017-02-17 20:06:33

我想我們正在碰到這個bug https://github.com/coreos/bugs/issues/1785。我已經驗證了我可以重現我們版本的docker/coreos上列出的錯誤。將核心/碼頭和驗證。

來源