Регулярное обновление Kubernetes — медаль с двумя сторонами. С одной стороны, с выкаткой обновлений оперативно фиксятся проблемы, добавляются новые возможности и реализации. С другой — для многих пользователей из-за отсутствия компетенций и понимания нюансов настройки обновление K8s до новой версии сопряжено со сложностями. Пробуем исправить ситуацию: рассказываем, как обновиться, чтобы ничего не сломать.

Меня зовут Алексей Волков. Я менеджер продукта Cloud Containers, сервиса по управлению кластерами Kubernetes в VK Cloud. В этой статье я привёл основные из рекомендованных разработчиком практики по обновлению кластера Kubernetes, которые помогут исключить ошибки и сопутствующие проблемы во время апдейта. 

Предисловие

В Kubernetes применяется стандартное семантическое управление версиями со схемой major.minor.patch. Новая минорная версия K8s выпускается примерно раз в три месяца, обновления с исправлениями ошибок обычно выкатываются каждый месяц. При этом Kubernetes поддерживает ветки релизов для трёх предыдущих версий (например, 1.25, 1.24 и 1.23 при обновлении K8s до версии 1.26), а также обеспечивает обратную совместимость — функции, доступные в 1.24, будут работать и в 1.26.

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

Лучшие практики обновления кластера

Не стоит игнорировать документацию от провайдера

Работа с Kubernetes в облаке предполагает учёт правил и манифестов, установленных конкретным облачным провайдером, это касается и алгоритмов обновления кластеров. Поэтому изучение документации провайдера — первое, с чего нужно начинать любые манипуляции. Зачастую в документации раскрыты все нюансы и даны рекомендации по работе с кластером. Например, такие пошаговые инструкции по работе с Kubernetes доступны пользователям VK Cloud.

Перед обновлением важно делать бэкапы

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

• текущего состояния;
  
• работающей нагрузки;
  
• конфигураций, которые работают внутри Kubernetes.
  

Для этого можно применять разные инструменты. Например, Velero с плагином VK Cloud может делать бэкапы как самой конфигурации, так и данных, хранимых на PV, подключённых к Kubernetes. Сами конфигурации лучше хранить в GitLab — в таком случае не придётся делать их копии. 

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

Одна из основных фич Kubernetes — автоматическое перераспределение нагрузки в случае недоступности нод. Это становится возможным, в частности, благодаря тому, что во время запуска кластера, как правило, закладывается запас резервных нод, которые можно задействовать при необходимости. 

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

С точки зрения Kubernetes неважно, почему нода недоступна, — в случае как её падения, так и её обновления K8s просто переносит нагрузку на свободную ноду, поддерживая работу кластера. Поэтому во время обновления важно учитывать, какой реальный запас свободных нод есть в кластере. Например, недопустимо параллельно обновлять 30 нод, имея в запасе лишь 15, иначе всё, что крутится на ноде, будет потеряно. К тому же, помимо замещаемых нод, надо иметь дополнительный резерв на случай падения тех, которые продолжают работать под нагрузкой. То есть надо иметь минимум 30 + n% в резерве. В таком случае обновление будет идти по следующему принципу: 

1. 30 нод версии 1.25 стали недоступны из-за начатого обновления.
   
2. K8s перенёс нагрузку с них на доступные ноды.
   
3. После обновления 30 нод поднялись с версией 1.26.
   
4. Начался новый цикл обновления следующих 30 нод.
   
5. K8s видит свободные 30 нод версии 1.26 и переносит нагрузку на них. 
   

По такому алгоритму обновляется весь кластер. Таким образом, при параллельном обновлении надо настраивать допустимое количество недоступных нод с учётом имеющихся ресурсов. Как правило, это значение устанавливается на уровне 1% от общего количества нод.

Стоит оговориться, что приложения должны быть запущены в режиме HA в несколько реплик и на разных нодах. Также кластер должен иметь более трёх мастер-нод, чтобы обеспечить доступность API кластера.

Обязательно изучите API зависимостей

Обновлению в обязательном порядке должна предшествовать проверка API зависимостей. Такая необходимость связана с тем, что в новой версии могут использоваться новые или существенно изменённые реализации, сущности и методы, к переходу на которые кластер надо подготовить. Например, в версиях 1.25–1.26 вносились изменения в драйверы дисковой подсистемы, при этом старые драйверы начали удалять и деприкейтить. Соответственно, при обновлении с 1.24 на 1.25 пользователям пришлось учитывать «новую реальность». Такие глобальные изменения бывают не часто, но случаются.

Для изучения зависимостей можно и нужно:

• Отслеживать уведомления от системы. При выкатке глобальных изменений, способных повлиять на кластер, пользователь получает сообщение, что, например, деплоймент скоро переедет и что лучше сразу обновиться, потому что в следующей версии текущие деплойменты работать не будут.
  
• Изучить changelog для версии Kubernetes. Для каждого обновления выпускается официальный changelog и документация на сайте K8s, где подробно описывается, что именно изменено в новой версии. Так можно убедиться, что апдейт не повлияет на кластер и что его можно накатывать.
  
• Использовать инструменты для проверок изменений. Для автоматической проверки изменений в версиях разработаны отдельные приложения. Зачастую алгоритм работы у них сходен: выбираем исходную версию, версию обновления и получаем все изменения в виде перечня с указанием всех деприкейтнутых либо полностью удалённых API.
  

Если не сделать этого и запустить обновление вслепую, можно либо полностью обрушить кластер, либо допустить сбои в его работе.

Обновление внутри кластера предполагает чёткий порядок

В Kubernetes предусмотрена чёткая иерархия и вертикаль зависимостей сущностей K8s друг от друга — их нужно учитывать. Поэтому на верхнем уровне обновление нужно выполнять последовательно:

1. Сначала Kubernetes Control Plane.
   
2. Потом узлы в кластере.
   
3. Затем клиенты — например kubectl.
   

Следом выполняют настройку манифестов и других ресурсов с учётом изменений API в новой версии Kubernetes.

В свою очередь, для обновления Kubernetes Control Plane есть своя чёткая последовательность:

1. Etcd (все экземпляры).
   
2. kube-apiserver (все хосты уровня управления).
   
3. Kube-controller-manager.
   
4. Kube-scheduler.
   
5. Менеджер облачного контроллера.
   

Обновление на уровне узлов происходит по принципу rolling update (шаг за шагом):

1. Сначала обновляется master-узел. Он выводится из кластера, обновляется, проходит проверку успешности обновления и возвращается обратно в кластер. Следом по такому же принципу обновляются все master-узлы кластера. 
   
2. Потом обновляются worker-узлы в группах.
   

Такой порядок важен, поскольку кластер более свежей версии может работать с нодами более старшей, но не наоборот. Ситуация упрощается, если обновление не требует ручного вмешательства, — например, в VK Cloud обновление автоматизировано, поэтому думать о порядке обновлений не надо. 

Порядок обновления на уровне кластеров тоже имеет значение

Зачастую в проекте формируют разные кластеры, отвечающие за разные задачи, — классически это dev, stage, prod. Исходя из назначения, они имеют разный приоритет и разный «уровень чувствительности» к потенциальным проблемам — например, ошибка в тестовом кластере не так критична, как сбой в проде. Поэтому целесообразно выстраивать следующую очередь обновления:

1. Dev.
   
2. Stage.
   
3. Prod.
   

Причём при обновлении dev и stage важно собирать все артефакты, обнаруженные в плане особенностей, нюансов и необходимой предварительной подготовки кластеров, чтобы при апдейте прода максимально сократить риск появления трудностей.

Важный критерий безопасного обновления — минимальная нагрузка

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

Так или иначе, в момент обновления лучше вообще не работать с кластером. Причём это касается как dev-кластеров, так и прода. Для этого нужно либо предупредить всех сотрудников, работающих с кластером, либо временно ограничить доступ к нему. В противном случае можно получить ряд проблем. Например, при попытке применить что-то или запустить пайплайн он упадёт, потому что API-сервер в процессе обновления может стать недоступным, если в кластере одна мастер-нода. Вместе с тем вся нагрузка продолжает работать, то есть отсутствие в кластере мастер-ноды не означает, что перестал работать весь кластер (пока Control Plane не сказал что-то другое) — это говорит только о том, что управление этим кластером отсутствует.

Выводы

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

Вы прямо сейчас можете воспользоваться Kubernetes от VK Cloud. Для тестирования мы начисляем новым пользователям 3 000 бонусных рублей и будем рады вашей обратной связи.

Stay tuned

Присоединяйтесь к телеграм-каналу «Вокруг Kubernetes», чтобы быть в курсе новостей из мира K8s: регулярные дайджесты, полезные статьи, а также анонсы конференций и вебинаров.