即使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 

Kubernetes不使用ICMP协议来检查节点主节点的连接性。

当通信nodeapi-server工作并且这是通过https协议完成时,节点变成Ready。在kubernetes文档主连接https://kubernetes.io/docs/concepts/architecture/master-node-communication/

为什么pod没有预定 -

你可以阅读更多关于关于节点? 此问题的答案可能在master日志中,请检查kube-apiserver.log,kube-scheduler.log。原因是群集配置错误。

首先运行它在一个单一的网络来抓住事物和双重检查路由。

+0

正如您所说的,通信是通过https协议完成的,但这是否意味着它只检查初始连接,而不检查节点的活跃性? –