У меня есть настройка кластера kube с помощью kubeadm init (в основном по умолчанию). Все работает, как задумано, за исключением того факта, что если один из моих узлов переходит в автономный режим, когда на нем работают модули, они остаются в состоянии Running
неопределенно долго. Из того, что я прочитал, они должны иметь статус go до Unknown
или Failure
, а после --pod-eviction-timeout (по умолчанию 5m) они должны быть перенесены на другой здоровый узел.
Вот мои стручки после 20 + минут, когда Узел 7 находился в автономном режиме (я также оставлял его более двух дней один раз без переназначения):
kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
workshop-30000-77b95f456c-sxkp5 1/1 Running 0 20m REDACTED node7 <none> <none>
workshop-operator-657b45b6b8-hrcxr 2/2 Running 0 23m REDACTED node7 <none> <none>
kubectl get deployments -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
deployment.apps/workshop-30000 0/1 1 0 21m workshop-ubuntu REDACTED client=30000
deployment.apps/workshop-operator 0/1 1 0 17h ansible,operator REDACTED name=workshop-operator
Вы можете видеть, что стручки все еще помечены как Running
, тогда как их развертывания имеют Ready: 0/1
.
Вот мои узлы:
kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
kubernetes-master Ready master 34d v1.17.3 REDACTED <none> Ubuntu 19.10 5.3.0-42-generic docker://19.3.2
kubernetes-worker NotReady <none> 34d v1.17.3 REDACTED <none> Ubuntu 19.10 5.3.0-29-generic docker://19.3.2
node3 NotReady worker 21d v1.17.3 REdACTED <none> Ubuntu 19.10 5.3.0-40-generic docker://19.3.2
node4 Ready <none> 19d v1.17.3 REDACTED <none> Ubuntu 19.10 5.3.0-40-generic docker://19.3.2
node6 NotReady <none> 5d7h v1.17.4 REDACTED <none> Ubuntu 19.10 5.3.0-42-generic docker://19.3.6
node7 NotReady <none> 5d6h v1.17.4 REDACTED <none> Ubuntu 19.10 5.3.0-42-generic docker://19.3.6
В чем может быть проблема? Все мои контейнеры имеют датчики готовности и живучести. Я пробовал искать в документах и в других местах, но не смог найти ничего, что решило бы это.
В настоящее время, если узел выходит из строя, я могу получить только те модули, которые были на нем. быть перенесенным на живой узел, если я вручную удаляю их с --force и --graceperiod = 0, что противоречит некоторым основным целям Kubernetes: автоматизации и самовосстановлению.
Согласно документам : https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod - время жизни If a node dies or is disconnected from the rest of the cluster, Kubernetes applies a policy for setting the phase of all Pods on the lost node to Failed.
---------- Дополнительная информация ---------------
kubectl describe pods workshop-30000-77b95f456c-sxkp5
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled <unknown> default-scheduler Successfully assigned workshop-operator/workshop-30000-77b95f456c-sxkp5 to node7
Normal Pulling 37m kubelet, node7 Pulling image "REDACTED"
Normal Pulled 37m kubelet, node7 Successfully pulled image "REDACTED"
Normal Created 37m kubelet, node7 Created container workshop-ubuntu
Normal Started 37m kubelet, node7 Started container workshop-ubuntu
Warning Unhealthy 36m (x2 over 36m) kubelet, node7 Liveness probe failed: Get http://REDACTED:8080/healthz: dial tcp REDACTED:8000: connect: connection refused
Warning Unhealthy 36m (x3 over 36m) kubelet, node7 Readiness probe failed: Get http://REDACTED:8000/readyz: dial tcp REDACTED:8000: connect: connection refused
Я полагаю, что эти сбои в тесте живучести и готовности были вызваны медленным стартом Кажется, что он не проверяет живучесть / готовность после того, как узел выходит из строя (последняя проверка была 37 минут go).
Это кластер с собственным размещением со следующей версией:
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-11T18:14:22Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-11T18:07:13Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}
Спасибо всем, кто помог.
РЕДАКТИРОВАТЬ: Это была либо ошибка, либо потенциальная неправильная конфигурация при начальной загрузке с kubeadm. Полная переустановка кластера kubernetes и обновление с 1.17.4 до 1.18 решили проблему, и теперь модули переносятся из мертвых узлов.