Обслуживание хостов в кластере 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

k0sworker.service должен быть в состоянии active (running).

k0s status должен вернуть Status: Running.
Разрешите запускать поды на обновленном рабочем узле, выполнив на любом контроллере следующую команду:
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 в случае проблем с основной виртуальной машиной.

В начало