2017-02-22 23 views
0

У меня есть кубернетовый кластер с одним ведущим и четырьмя узлами. 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%) 

Есть ли что-либо конкретное, что нужно сделать, чтобы привести узел обратно в оперативном режиме после перезагрузки системы?

+0

Как вы развернули/создали этот кластер? Можете ли вы проверить, используют ли другие узлы докеры 1.13.x или если они все еще на 1.12.x? –

ответ

0

Моя команда смогла решить эту проблему, понизив докер до 1.12. Представляется, что проблема связана с этим вопросом:

https://github.com/kubernetes/kubernetes/issues/40182

После понижения докеров до 1.12, все теперь работают.