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

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

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

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

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

sudo systemctl status k0scontroller

sudo k0s status

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

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

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

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

1. Получите имена и текущее состояние рабочих узлов, выполнив на любом контроллере следующую команду:

   sudo k0s kubectl get nodes

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

2. Перед обновлением рабочего узла запретите размещение подов на этом узле, выполнив следующую команду:

   sudo k0s kubectl cordon <имя_рабочего_узла>

   После этого в выводе команды sudo k0s kubectl get nodes узел будет отображаться в статусе Ready,SchedulingDisabled.

3. Получите имя рабочего узла, на котором выполняется Ядро KUMA, выполнив на любом контроллере следующую команду:

   sudo k0s kubectl get pods -n kuma -o wide

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

   sudo k0s kubectl rollout restart deployment core-deployment -n kuma

   Во время переноса Ядра KUMA на другой рабочий узел доступ к Ядру KUMA будет приостановлен примерно на 10 минут.

5. Проверьте состояние Ядра KUMA, повторно выполнив команду:

   sudo k0s kubectl get pods -n kuma -o wide

   Статус пода должен быть Running. Имя рабочего узла в столбце NODE должно измениться.

6. Остановите сервис k0sworker на выводимом рабочем узле с помощью следующей команды:

   sudo k0s stop

7. Обновите операционную систему.
8. Запустите сервис k0s на рабочем узле с помощью команды:

   sudo k0s start

9. Убедитесь, что сервис k0s успешно запущен, выполнив на рабочем узле следующие команды:

   sudo systemctl status k0sworker

   sudo k0s status

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

   k0s status должен вернуть Status: Running.

10. Разрешите запускать поды на обновленном рабочем узле, выполнив на любом контроллере следующую команду:

    sudo k0s kubectl uncordon <имя_рабочего_узла>

11. Убедитесь, что рабочий узел в кластере доступен, выполнив на любом контроллере следующую команду:

    sudo k0s kubectl get nodes

    Статус обновленного рабочего узла должен быть ready.

12. После возвращения рабочего узла в кластер убедитесь, что все реплики томов восстановлены и доступны, выполнив следующую команду:

    sudo k0s kubectl get volume -n longhorn-system -o json | jq '.items[0].status.robustness'

    Статус должен быть healthy. Если статус degraded, то одна из реплик недоступна или пересобирается.

13. Если вы хотите отслеживать процесс пересборки тома, выполните следующую команду:

    sudo k0s kubectl get engine -n longhorn-system -o json | jq '.items[0].status.rebuildStatus'

14. Если нужно просмотреть текущее состояние реплик, выполните следующую команду:

    sudo k0s kubectl get replicas -n longhorn-system

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

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

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

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

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

1. Подготовить резервный балансировщик со всеми необходимыми обновлениями, продублировать конфигурацию NGINX или другого используемого балансировщика трафика с основного балансировщика на резервный. Для NGINX, настраиваемого установщиком KUMA, это файлы /etc/nginx/nginx.conf и /etc/nginx/kuma_nginx_lb.conf.

   FQDN резервного балансировщика должен совпадать с FQDN основного балансировщика. Нужно убедиться, что сервис балансировщика успешно запущен и правила межсетевого экрана, примененные к основному балансировщику, применимы и к резервному балансировщику.

2. Переключить трафик на резервный балансировщик, изменив IP-адрес резервного балансировщика на IP-адрес основного балансировщика. На основном балансировщике IP-адрес должен быть временно изменен на другой IP-адрес, чтобы не было конфликта IP-адресов. Убедитесь, что Ядро KUMA на резервном балансировщике работает штатно.

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

3. Произвести необходимые работы на основном балансировщике трафика.
4. Произвести обратную смену IP-адресов на основном и резервном балансировщиках.
5. Убедиться, что Ядро KUMA на обновленном основном балансировщике работает штатно.

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

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