即使Kubernetes無法訪問，爲什麼Kubernetes顯示節點仍然準備就緒？

我正在運行配置有主節點和3個節點的Kubernetes集羣。即使Kubernetes無法訪問，爲什麼Kubernetes顯示節點仍然準備就緒？

#kubectl get nodes 
NAME  STATUS AGE 
minion-1 Ready  46d 
minion-2 Ready  46d 
minion-3 Ready  46d

我已經在羣集中啓動了幾個豆莢，發現豆莢處於掛起狀態。

# kubectl get pods -o wide 
NAME  READY  STATUS RESTARTS AGE  IP  NODE 
httpd  0/1  Pending 0   10m  <none> 
nginx  0/1  Pending 0   11m  <none>

其中莢「的httpd」 YAML文件：

# cat http.yaml 
apiVersion: v1 
kind: Pod 
metadata: 
    name: httpd 
    labels: 
    env: test 
spec: 
    containers: 
    - name: httpd 
    image: httpd

在調試失敗的原因發現，這對夫妻配置的節點都沒有準備好。主站只能訪問一個節點。

# ping minion-1 
PING minion-1 (172.31.24.204) 56(84) bytes of data. 
64 bytes from minion-1 (172.31.24.204): icmp_seq=1 ttl=64 time=0.575 ms

而其他節點是不可達：

# ping minion-2 
PING minion-2 (172.31.29.95) 56(84) bytes of data. 
From master (172.31.16.204) icmp_seq=1 Destination Host Unreachable 

# ping minion-3 
PING minion-3 (172.31.17.252) 56(84) bytes of data. 
From master (172.31.16.204) icmp_seq=1 Destination Host Unreachable

，我這裏有疑問是

1）爲什麼Kubernetes顯示節點作爲準備，即使他們不主人可以到達？

2）爲什麼豆莢創造失敗？

Is it because of unavailability of nodes or any configuration issue in yaml file? 

# kubectl describe pod httpd 
Name:   httpd 
Namespace:  default 
Node:   /
Labels:   env=test 
Status:   Pending 
IP: 
Controllers: <none> 
Containers: 
    httpd: 
    Image:      httpd 
    Port: 
    Volume Mounts:    <none> 
    Environment Variables:  <none> 
No volumes. 
QoS Class:  BestEffort 
Tolerations: <none> 
No events.

以下是Kubernetes和ETCD版本。

]# kubectl --version 
Kubernetes v1.5.2 
[[email protected] ~]# et 
etcd  etcdctl  ether-wake ethtool 
[[email protected] ~]# etcd --version 
etcd Version: 3.2.5 
Git SHA: d0d1a87 
Go Version: go1.8.3 
Go OS/Arch: linux/amd64

來源

2017-10-15 Here_2_learn

Kubernetes不使用ICMP協議來檢查節點主節點的連接性。

當通信node→api-server工作並且這是通過https協議完成時，節點變成Ready。在kubernetes文檔主連接https://kubernetes.io/docs/concepts/architecture/master-node-communication/

爲什麼pod沒有預定 -

你可以閱讀更多關於關於節點？此問題的答案可能在master日誌中，請檢查kube-apiserver.log,kube-scheduler.log。原因是羣集配置錯誤。

首先運行它在一個單一的網絡來抓住事物和雙重檢查路由。

來源

2017-10-15 18:47:34 3h4x

正如您所說的，通信是通過https協議完成的，但這是否意味着它只檢查初始連接，而不檢查節點的活躍性？ –

即使Kubernetes無法訪問，爲什麼Kubernetes顯示節點仍然準備就緒？

回答

相關問題