Обслуживание хостов в кластере Kubernetes

В процессе работы периодически возникает необходимость перезагрузки, установки обновлений или обновления ОС на рабочих узлах и контроллерах кластера Kubernetes. В следующих разделах этой статьи описывается порядок вывода хостов в обслуживание, позволяющий минимизировать простой Ядра KUMA в отказоустойчивой конфигурации.

Перед выполнением манипуляций с хостами необходимо создать резервную копию Ядра KUMA.

Обслуживание контроллеров

Контроллеры кластера следует выводить в обслуживание исключительно по одному. Перед выводом контроллера в обслуживание не требуется выполнить каких-либо предварительных действий. После выполнения обслуживания или обновления следует убедиться, что служба контроллера успешно запущена, проверив состояние сервиса с помощью следующих команд:

sudo systemctl status k0scontroller

sudo k0s status

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

Обслуживание рабочих узлов

Рабочие узлы кластера следует выводить в обслуживание исключительно по одному.

Чтобы выполнить обслуживание рабочих узлов:

Получите имена и текущее состояние рабочих узлов, выполнив на любом контроллере следующую команду:
sudo k0s kubectl get nodes

Все рабочие узлы должны быть в состоянии ready, иначе вывод из работы последующих узлов может привести к полной недоступности Ядра KUMA.
Перед обновлением рабочего узла сначала необходимо запретить размещение подов на данном узле. Чтобы запретить размещение подов, на любом контроллере выполните следующую команду:
sudo k0s kubectl cordon <имя_рабочего_узла>

После этого в выводе команды sudo k0s kubectl get nodes узел будет отображаться в статусе Ready,SchedulingDisabled.
Чтобы получить имя рабочего узла, на котором выполняется Ядро KUMA, на любом контроллере выполните следующую команду:
sudo k0s kubectl get pods -n kuma -o wide
Если Ядро KUMA работает на этом рабочем узле, необходимо перезапустить развертывание Ядра KUMA, чтобы Ядро KUMA переехало на другой рабочий узел, и дождаться успешного запуска Ядра KUMA на другом рабочем узле. Чтобы перезапустить развертывание Ядра KUMA, выполните следующую команду:
sudo k0s kubectl rollout restart deployment core-deployment -n kuma

На время переезда Ядра KUMA на другой рабочий узел доступ к Ядру KUMA будет приостановлен ориентировочно до 10 минут.
Чтобы проверить состояние Ядра KUMA, повторно выполните следующую команду:
sudo k0s kubectl get pods -n kuma -o wide

Статус пода должен быть Running, имя рабочего узла в колонке NODE должно измениться.
Остановите сервис k0sworker на выводимом рабочем узле с помощью следующей команды:
sudo k0s stop
Выполните обновление ОС
Запустите сервис k0s на рабочем узле с посощью следующей команды:
sudo k0s start
Убедитесь, что сервис k0s успешно запущен, выполнив на рабочем узле следующие команды:
sudo systemctl status k0sworker

sudo k0s status
Разрешите запускать поды на обновлённом рабочем узле, выполнив на любом контроллере следующую команду:
sudo k0s kubectl uncordon <имя_рабочего_узла>
Убедитесь, что рабочий узел в кластере доступен, выполнив на любом контроллере следующую команду:
sudo k0s kubectl get nodes

У обновлённого рабочего узла должен быть статус ready.
После возвращения рабочего узла в кластер нужно убедиться, что все реплики томов восстановлены и доступны. Чтобы просмотреть состояние тома, выполните следующую команду:
sudo k0s kubectl get volume -n longhorn-system -o json | jq '.items[0].status.robustness'

Статус должен быть healthy, если degraded, то одна из реплик недоступна или пересобирается.
Чтобы отслеживать прогресс пересборки тома, выполните следующую команду:
sudo k0s kubectl get engine -n longhorn-system -o json | jq '.items[0].status.rebuildStatus'
Чтобы просмотреть текущее состояние реплик, выполните следующую команду:
sudo k0s kubectl get replicas -n longhorn-system

Все реплики должны быть в статусе running.

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

Обслуживание балансировщика трафика

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

Если планируется длительный простой основного балансировщика или существенные обновления, мы рекомендуем сделать следующее:

Подготовить резервный балансировщик со всеми необходимыми обновлениями, продублировать конфигурацию Nginx или другого используемого балансировщика трафика с основного балансировщика на резервный. Для Nginx, настраиваемого установщиком KUMA, это файлы /etc/nginx/nginx.conf и /etc/nginx/kuma_nginx_lb.conf. FQDN резервного балансировщика должен совпадать с FQDN основного балансировщика. Необходимо убедиться, что сервис балансировщика успешно запущен и что правила межсетевого экрана, применённые к основному балансировщику, применимы и к резервному балансировщику.
Переключить трафик на резервный балансировщик, поменяв IP-адрес резервного балансировщика на IP-адрес основного балансировщика. На основном балансировщике IP-адрес должен быть временно изменён на какой-то другой IP-адрес, чтобы не было конфликта IP-адресов. Убедитесь, что Ядро KUMA на резервном балансировщике работает штатно.
В момент переключения трафика текущие сессии могут прерваться. Если наблюдаются какие-то неполадки, вы можете указать прежние IP-адреса и продолжить работу на основном балансировщике в прежней конфигурации.
Произвести необходимые работы на основном балансировщике трафика.
Произвести обратную смену IP-адресов на основном и резервном балансировщиках.
Убедиться, что Ядро KUMA на обновлённом основном балансировщике работает штатно.

Последний шаг может не понадобится, если технической необходимости в возврате в эксплуатацию бывшего основного балансировщика нет, то есть производится однократная замена балансировщика на обновлённый хост.

Поскольку требования к ресурсам балансировщика трафика минимальны, мы рекомендуем иметь резервный клон виртуальной машины с балансировщиком для быстрого восстановления доступа к Ядру KUMA в случае каких-то проблем с основной виртуальной машиной.

В начало