Я установил kubernetes на одноузловой сервер с помощью kubeadm. Я обнаружил, что при выполнении установки в определенном порядке все запускается и работает нормально. Это включает в себя основные компоненты системы kube (сервер api, прокси, планировщик, etcd и т. д.), которые были запущены и запущены первыми (кроме coredns), после чего был установлен плагин cilium CNI с помощью helm для работы в сети (в результате чего coredns заработал).
После этой установки я смог успешно установить и использовать другие службы, такие как NVIDIA's GPU Operator и kubeflow. Однако после перезагрузки я обнаружил, что различные компоненты входят в состояние аварийного цикла.
Я думаю, что это как-то связано с порядком инициализации различных ресурсов и длительностью различных тайм-аутов. Есть ли способ установить порядок запуска различных компонентов при загрузке? Или, возможно, настроить соответствующий тайм-аут по умолчанию или поведение pod'ов при сбое?
Вероятно, здесь имеет место эффект домино, когда сбой одного компонента приводит к сбою другого, что в свою очередь приводит к постоянному увеличению времени простоя и, в конечном итоге, к неотзывчивости кластера.
Для дополнительной информации, я сохранил правила iptables, чтобы они применялись при загрузке. Кроме того, обычно все основные компоненты переходят в состояние выполнения, за исключением планировщика kube, который остается в состоянии аварийного цикла. Затем другие компоненты также начинают падать, что выглядит как эффект домино.
До сих пор я в основном пытался обновить файлы манифеста в /etc/kubernetes/manifests/, чтобы использовать различные тайм-ауты и failureThresholds для системных подов kubernetes, однако, похоже, это не решило проблему. Я мог бы воспроизвести поведение перезапуска сервера, сначала остановив службу kubelet и уничтожив все работающие поды/контейнеры, а затем перезапустив kubelet.
решение1
Оказывается, эта проблема очень похожа на ту, что описана в этом GitHubпроблема. По сути, без указания SystemdCgroup = trueопции для моей контейнерной среды выполнения CRI (которая былаnvidiaвремя выполнения контейнеравместо значения по умолчанию runc), модули продолжали необъяснимо падать. Это происходило из-за нарушения правила единственной записи cgroups, поскольку драйвер по умолчанию для управления cgroups — это , cgroupfsкоторый не совместим с systemd. Вы можете увидетьдокументациядля более подробной информации. Он также включает полную спецификацию конфигурации плагина CRIздесь.
Другие соответствующие контейнерные ресурсы: