GKE: узел перезапущен/отсутствует коды

Question

Добрый день,

Запуск кластера с одним узлом. Заметил, что за ночь все мои стручки пропали без вести.

kubectl get events 

не получил меня.

Проверка узла

# kubectl get no 
NAME       STATUS AGE 
gke-sg-etl-4ff0f964-node-jny8 Ready  20d 

Проверка контейнера на узле я заметил, что некоторые системные контейнеры для всего 21 часов, в то время как некоторые другие будут 2 недели:

CONTAINER ID  IMAGE                 COMMAND     CREATED    STATUS    PORTS    NAMES 
b451ef51174d  gcr.io/google_containers/glbc:0.6.0         "/glbc --default-back" 21 hours ago  Up 21 hours        k8s_l7-lb-controller.96ad8505_l7-lb-controller-v0.6.0-keutx_kube-system_5ecb8fe7-0054-11e6-a3f3-42010af0003e_9af0cd81 
86483feba88c  gcr.io/google_containers/defaultbackend:1.0       "/server"    21 hours ago  Up 21 hours        k8s_default-http-backend.33869026_l7-lb-controller-v0.6.0-keutx_kube-system_5ecb8fe7-0054-11e6-a3f3-42010af0003e_1fffdcaf 
73bc0bbd18a1  gcr.io/google_containers/pause:2.0          "/pause"     21 hours ago  Up 21 hours        k8s_POD.364e00d5_l7-lb-controller-v0.6.0-keutx_kube-system_5ecb8fe7-0054-11e6-a3f3-42010af0003e_6b0f3678 
95f0bdb6b87c  gcr.io/google_containers/exechealthz:1.0        "/exechealthz '-cmd=n" 21 hours ago  Up 21 hours        k8s_healthz.2bec1471_kube-dns-v11-ce2vc_kube-system_1c42c00f-0056-11e6-a3f3-42010af0003e_4e729ced 
efde9c110e3c  gcr.io/google_containers/skydns:2015-10-13-8c72f8c      "/skydns -machines=ht" 21 hours ago  Up 21 hours        k8s_skydns.66853ac4_kube-dns-v11-ce2vc_kube-system_1c42c00f-0056-11e6-a3f3-42010af0003e_10c173ea 
0db98a8b6b83  gcr.io/google_containers/kube2sky:1.14         "/kube2sky --domain=c" 21 hours ago  Up 21 hours        k8s_kube2sky.4e15015f_kube-dns-v11-ce2vc_kube-system_1c42c00f-0056-11e6-a3f3-42010af0003e_23182cb4 
c103d90e1bd9  gcr.io/google_containers/etcd-amd64:2.2.1        "/usr/local/bin/etcd " 21 hours ago  Up 21 hours        k8s_etcd.6d563523_kube-dns-v11-ce2vc_kube-system_1c42c00f-0056-11e6-a3f3-42010af0003e_987562c7 
3b21c42444de  gcr.io/google_containers/pause:2.0          "/pause"     21 hours ago  Up 21 hours        k8s_POD.e2764897_kube-dns-v11-ce2vc_kube-system_1c42c00f-0056-11e6-a3f3-42010af0003e_08f0734a 
7e642f5a1fe0  gcr.io/google_containers/kubernetes-dashboard-amd64:v1.0.0    "/dashboard --port=90" 21 hours ago  Up 21 hours        k8s_kubernetes-dashboard.deca92bd_kubernetes-dashboard-v1.0.0-whzec_kube-system_19ab34c7-0056-11e6-a3f3-42010af0003e_433eec1f 
2d0f5f11ad65  gcr.io/google_containers/pause:2.0          "/pause"     21 hours ago  Up 21 hours        k8s_POD.3a1c00d7_kubernetes-dashboard-v1.0.0-whzec_kube-system_19ab34c7-0056-11e6-a3f3-42010af0003e_0dfc9856 
c210ea10b8ea  gcr.io/google_containers/heapster:v1.0.0        "/heapster --source=k" 21 hours ago  Up 21 hours        k8s_heapster.ce50f137_heapster-v1.0.0-el2r7_kube-system_1994710e-0056-11e6-a3f3-42010af0003e_b63303ac 
a449b69dd498  gcr.io/google_containers/pause:2.0          "/pause"     21 hours ago  Up 21 hours        k8s_POD.6059dfa2_heapster-v1.0.0-el2r7_kube-system_1994710e-0056-11e6-a3f3-42010af0003e_3a238507 
b9eaaa1cae94  gcr.io/google_containers/fluentd-gcp:1.18        "/bin/sh -c '/usr/sbi" 2 weeks ago   Up 2 weeks        k8s_fluentd-cloud-logging.fe59dd68_fluentd-cloud-logging-gke-sg-etl-4ff0f964-node-jny8_kube-system_da7e41ef0372c29c65a24b417b5dd69f_dd3f0627 

Я понимаю что узел, возможно, был перезапущен.

Где я могу понять, почему это произошло? Моя интерпретация заключается в том, что это нормально, но я все равно хотел бы получить немного понимания (стручки - это «домашние животные», а не «скот»).

Answer 1

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

Есть несколько путей, которые вы можете исследовать в этой ситуации, но у меня нет ни одного ответа, который всегда будет отвечать вам. Вот несколько вещей, которые вы могли бы попробовать:

• Запустить kubectl get pods -a, в котором будут возвращены все контейнеры, в том числе те, которые больше не работают. Если контроллеры должны были воссоздавать стручки, вы должны иметь возможность видеть статус завершения тех, которые больше не работают.
• SSH к узлу и запустите last | grep boot, чтобы увидеть, когда он был последним загружен.
• SSH к узлу и запустите docker ps -a, чтобы просмотреть все контейнеры, в том числе те, которые перестали работать. Если некоторые из них остановились, исследуйте их, используя docker logs или docker inspect.
• SSH на узел и исследовать файл /var/log/kubelet.log, чтобы узнать, есть ли у него какие-либо подсказки о том, почему были перезагружены контейнеры.