kubernetes - kubectl get pods返回不一致的结果

Question

当我执行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 pod实例。
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/的未同步内容有关吗？

Answer 1

您的广告连播处于CrashLoopBackoff状态。
这意味着该容器中的某些容器正在退出(主进程已退出)，并且该容器一次又一次地重新启动。

根据运行get po命令的时间，您的pod可能会显示为Running(该进程尚未退出)或CrashLoopBackoff(kubernetes正在等待，然后重新启动Pod)。

您可以通过查看输出中的Restarts计数器来确认是这种情况。

我建议您查看重新启动的Pod日志，以了解它们为何失败。