У меня есть кубернетовый кластер с одним ведущим и четырьмя узлами. kube-proxy работал отлично на всех четырех узлах, и я мог обращаться к службам на любом из узлов независимо от того, где он был запущен; то есть. http://node1:30000 через http://node4:30000 давал тот же ответ.Узел kubernetes не отвечает после перезагрузки
После перезагрузки узла4, запустив shutdown -r now, он вернулся, но я заметил, что узел больше не отвечает на запросы. Я бегу следующую команду:
curl http://node4:30000
Если я запустить его с компьютера или с любого другого узла в кластере - node1 через node3 или мастер - я получаю:
curl: (7) Failed to connect to node4 port 30000: Connection timed out
Однако, если я запускаю его из node4, он отвечает успешно. Это заставляет меня поверить, что kube-proxy работает нормально, но что-то предотвращает внешние подключения.
Когда я бег kubectl описания узла node4, мой вывод выглядит нормально:
Name: node4
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
kubernetes.io/hostname=node4
Taints: <none>
CreationTimestamp: Tue, 21 Feb 2017 15:21:17 -0400
Phase:
Conditions:
Type Status LastHeartbeatTime LastTransitionTime Reason Message
---- ------ ----------------- ------------------ ------ -------
OutOfDisk False Wed, 22 Feb 2017 08:03:40 -0400 Tue, 21 Feb 2017 15:21:18 -0400 KubeletHasSufficientDisk kubelet has sufficient disk space available
MemoryPressure False Wed, 22 Feb 2017 08:03:40 -0400 Tue, 21 Feb 2017 15:21:18 -0400 KubeletHasSufficientMemory kubelet has sufficient memory available
DiskPressure False Wed, 22 Feb 2017 08:03:40 -0400 Tue, 21 Feb 2017 15:21:18 -0400 KubeletHasNoDiskPressure kubelet has no disk pressure
Ready True Wed, 22 Feb 2017 08:03:40 -0400 Tue, 21 Feb 2017 15:21:28 -0400 KubeletReady kubelet is posting ready status. AppArmor enabled
Addresses: 10.6.81.64,10.6.81.64,node4
Capacity:
alpha.kubernetes.io/nvidia-gpu: 0
cpu: 2
memory: 4028748Ki
pods: 110
Allocatable:
alpha.kubernetes.io/nvidia-gpu: 0
cpu: 2
memory: 4028748Ki
pods: 110
System Info:
Machine ID: dbc0bb6ba10acae66b1061f958220ade
System UUID: 4229186F-AA5C-59CE-E5A2-258C1BBE9D2C
Boot ID: a3968e6c-eba3-498c-957f-f29283af1cff
Kernel Version: 4.4.0-63-generic
OS Image: Ubuntu 16.04.1 LTS
Operating System: linux
Architecture: amd64
Container Runtime Version: docker://1.13.0
Kubelet Version: v1.5.2
Kube-Proxy Version: v1.5.2
ExternalID: node4
Non-terminated Pods: (27 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits
--------- ---- ------------ ---------- --------------- -------------
<< application pods listed here >>
kube-system kube-proxy-0p3lj 0 (0%) 0 (0%) 0 (0%) 0 (0%)
kube-system weave-net-uqmr1 20m (1%) 0 (0%) 0 (0%) 0 (0%)
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.
CPU Requests CPU Limits Memory Requests Memory Limits
------------ ---------- --------------- -------------
20m (1%) 0 (0%) 0 (0%) 0 (0%)
Есть ли что-либо конкретное, что нужно сделать, чтобы привести узел обратно в оперативном режиме после перезагрузки системы?
Как вы развернули/создали этот кластер? Можете ли вы проверить, используют ли другие узлы докеры 1.13.x или если они все еще на 1.12.x? –