即使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协议来检查节点主节点的连接性。
当通信node
→api-server
工作并且这是通过https
协议完成时,节点变成Ready
。在kubernetes文档主连接https://kubernetes.io/docs/concepts/architecture/master-node-communication/
为什么pod
没有预定 -
你可以阅读更多关于关于节点? 此问题的答案可能在master
日志中,请检查kube-apiserver.log
,kube-scheduler.log
。原因是群集配置错误。
首先运行它在一个单一的网络来抓住事物和双重检查路由。
正如您所说的,通信是通过https协议完成的,但这是否意味着它只检查初始连接,而不检查节点的活跃性? –