kubectl get pods возвращает противоречивые результаты - PullRequest
Новая
       4

kubectl get pods возвращает противоречивые результаты

1 голос
/ 15 июня 2019

Когда я выполняю kubectl get pods, я получаю разные выходные данные для одного и того же модуля.

Например: 

$ kubectl get pods -n ha-rabbitmq
NAME            READY   STATUS    RESTARTS   AGE
rabbitmq-ha-0   1/1     Running   0          85m
rabbitmq-ha-1   1/1     Running   9          84m
rabbitmq-ha-2   1/1     Running   0          50m

После этого я выполняю ту же команду, и вот другой результат: 

$ kubectl get pods -n ha-rabbitmq
NAME            READY   STATUS             RESTARTS   AGE
rabbitmq-ha-0   0/1     CrashLoopBackOff   19         85m
rabbitmq-ha-1   1/1     Running            9          85m
rabbitmq-ha-2   1/1     Running            0          51m

У меня есть 2 мастер-узла и 5 рабочих узлов, инициализированных с помощью kubeadm. Каждый главный узел имеет один экземпляр встроенного модуля etcd.

Результат kubectl get nodes: 

$ kubectl get nodes -owide
NAME              STATUS   ROLES    AGE     VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
k8s-meb-master1   Ready    master   14d     v1.14.3   10.30.29.11    <none>        Ubuntu 18.04.2 LTS   4.15.0-51-generic   docker://18.9.5
k8s-meb-master2   Ready    master   14d     v1.14.3   10.30.29.12    <none>        Ubuntu 18.04.2 LTS   4.15.0-51-generic   docker://18.9.6
k8s-meb-worker1   Ready    <none>   14d     v1.14.3   10.30.29.13    <none>        Ubuntu 18.04.2 LTS   4.15.0-51-generic   docker://18.9.5
k8s-meb-worker2   Ready    <none>   14d     v1.14.3   10.30.29.14    <none>        Ubuntu 18.04.2 LTS   4.15.0-51-generic   docker://18.9.5
k8s-meb-worker3   Ready    <none>   14d     v1.14.3   10.30.29.15    <none>        Ubuntu 18.04.2 LTS   4.15.0-51-generic   docker://18.9.5
k8s-meb-worker4   Ready    <none>   14d     v1.14.2   10.30.29.16    <none>        Ubuntu 18.04.2 LTS   4.15.0-51-generic   docker://18.9.5
k8s-meb-worker5   Ready    <none>   5d19h   v1.14.2   10.30.29.151   <none>        Ubuntu 18.04 LTS     4.15.0-20-generic   docker://18.9.5

Может ли эта проблема быть связана с несинхронизированным содержимым для /var/lib/etcd/ в главных узлах?

1 Ответ

1 голос
/ 15 июня 2019

Ваши стручки находятся в состоянии CrashLoopBackoff. Это означает, что некоторые контейнеры внутри модуля выходят (основной процесс завершается) и модуль снова и снова перезапускается.

В зависимости от того, когда вы запускаете команду get po, вы можете увидеть ваш модуль как Running (процесс еще не завершился) или CrashLoopBackoff (kubernetes ждет, прежде чем перезапустить ваш модуль.

Вы можете подтвердить это, посмотрев на выходной счетчик Restarts.

Я предлагаю вам взглянуть на журналы перезапуска модулей, чтобы понять, почему они не работают.

...