В настоящее время я работаю с кластером Kubernetes, размещенным на AWS с EKS, который сталкивается со странными (для меня) сбоями. Наши узлы (тип экземпляра c5.2xlarge, AMI ami-0f54a2f7d2e9c88b3/amazon-eks-node-v25) продолжаются до тех пор, пока без видимого изменения нагрузки не начнут проявляться огромные объемы ошибок. kubelet журналы. (Я смотрю на это через journalctl -u kubelet).
Сообщения об ошибках не рисуют последовательную историю - разные узлы показывают разные наборы событий до сбоя, но в конечном итоге узел входит в NotReady штат. Иногда они выздоравливают сами по себе, но вероятность и время этого варьируются.
Вот пример журналов, непосредственно предшествующих изменению статуса на одном узле:
Dec 05 21:41:57 ip-10-0-18-250.us-west-2.compute.internal kubelet[4051]: W1205 21:41:57.671381 4051 fs.go:571] Killing cmd [nice -n 19 du -s /var/lib/docker/overlay2/2af435b23328675b6ccddcd29da7a8681118ae90c78755933916d15c247653cc/diff] due to timeout(2m0s)
Dec 05 21:41:57 ip-10-0-18-250.us-west-2.compute.internal kubelet[4051]: E1205 21:41:57.673113 4051 remote_runtime.go:434] Status from runtime service failed: rpc error: code = DeadlineExceeded desc = context deadline exceeded
Dec 05 21:41:57 ip-10-0-18-250.us-west-2.compute.internal kubelet[4051]: E1205 21:41:57.676913 4051 kubelet.go:2114] Container runtime sanity check failed: rpc error: code = DeadlineExceeded desc = context deadline exceeded
Dec 05 21:41:57 ip-10-0-18-250.us-west-2.compute.internal kubelet[4051]: E1205 21:41:57.809324 4051 remote_runtime.go:332] ExecSync e264b31c91ae2d10381cbebd0c4a1e3b0deeefcc60dd5762b7f6f3ac9a7c5d1a '/bin/bash -c pgrep python >/dev/null 2>&1' from runtime service failed: rpc error: code = DeadlineExceeded desc = context deadline exceeded
Dec 05 21:41:57 ip-10-0-18-250.us-west-2.compute.internal kubelet[4051]: I1205 21:41:57.833254 4051 kubelet.go:1799] skipping pod synchronization - [container runtime is down]
Dec 05 21:41:57 ip-10-0-18-250.us-west-2.compute.internal kubelet[4051]: I1205 21:41:57.843768 4051 kubelet_node_status.go:814] Node became not ready: {Type:Ready Status:False LastHeartbeatTime:2018-12-05 21:41:57.843747845 +0000 UTC m=+6231.746946646 LastTransitionTime:2018-12-05 21:41:57.843747845 +0000 UTC m=+6231.746946646 Reason:KubeletNotReady Message:container runtime is down}
Dec 05 21:41:57 ip-10-0-18-250.us-west-2.compute.internal kubelet[4051]: I1205 21:41:57.933579 4051 kubelet.go:1799] skipping pod synchronization - [container runtime is down]
Dec 05 21:41:58 ip-10-0-18-250.us-west-2.compute.internal kubelet[4051]: I1205 21:41:58.159892 4051 kubelet.go:1799] skipping pod synchronization - [container runtime is down]
Dec 05 21:41:58 ip-10-0-18-250.us-west-2.compute.internal kubelet[4051]: I1205 21:41:58.561026 4051 kubelet.go:1799] skipping pod synchronization - [container runtime is down]
Dec 05 21:41:59 ip-10-0-18-250.us-west-2.compute.internal kubelet[4051]: I1205 21:41:59.381016 4051 kubelet.go:1799] skipping pod synchronization - [container runtime is down]
Dec 05 21:42:00 ip-10-0-18-250.us-west-2.compute.internal kubelet[4051]: I1205 21:42:00.985015 4051 kubelet.go:1799] skipping pod synchronization - [container runtime is down]
В других случаях все идет наперекосяк из-за кучи предупреждений о том, что NetworkPlugin cni failed on the status hook for pod "<pod-name>": CNI failed to retrieve network namespace path: cannot find network namespace for the terminated container "<container-ID>".
Третий сценарий на самом деле не отображает изменение статуса узла, но завершается
kubelet_node_status.go:377] Error updating node status, will retry: error getting node "<node-private-ip>": Unauthorized
Это происходит после других ошибок формы
cni.go:227] Error while adding to cni network: add cmd: failed to assign an IP address to container
и
raw.go:87] Error while processing event ("/sys/fs/cgroup/devices/system.slice/run-27618.scope": 0x40000100 == IN_CREATE|IN_ISDIR): inotify_add_watch /sys/fs/cgroup/devices/system.slice/run-27618.scope: no such file or directory
Это стало настоящей головной болью, поскольку узлы прекращают работу с, казалось бы, непредсказуемой частотой и без последовательного поведения при ошибках. Что может быть объединяющей причиной (или причинами) этих неудач?
Я рад предоставить дополнительную информацию о кластере или более подробные журналы, так что любезно дайте мне знать. Спасибо заранее за любую помощь!