Ключевые проверки перед обновлением
Перед переходом на Kubernetes 1.37 критически важно оценить готовность кластера и узлов, чтобы исключить простой сервисов. Начните с инвентаризации статических подов (static Pods), которые управляются напрямую kubelet через манифесты на узле, минуя API-server. Убедитесь, что их спецификации совместимы с новой версией, а зависимости — актуальны. Проверьте конфигурацию SELinux: изменения политик или режимов могут заблокировать запуск компонентов control-plane и рабочих нагрузок после обновления. Отдельно проанализируйте флаги запуска kubelet: устаревшие параметры будут отклонены, поэтому сопоставьте текущий набор флагов с документацией к версии 1.37 и удалите всё лишнее.
Не забудьте проверить:
- Совместимость CNI-драйвера и плагинов метрик/логирования.
- Версии etcd и требования к хранилищу объектов.
- Политики Pod Security Standards и RuntimeClass для runtime-контейнеров.
- Наличие резервных копий манифестов нестандартных аддонов.
Порядок работ при использовании kubeadm
Для кластеров, развёрнутых через kubeadm, придерживайтесь строгой последовательности действий. Сначала обновите контрольные плоскости (control-plane nodes) по одной, начиная с неосновного узла, если используется HA-конфигурация. На каждом этапе фиксируйте состояние компонента и проверяйте работоспособность API-сервера.
Алгоритм обновления одного узла:
- Отведите узел из балансировки трафика; опционально выполните cordon и drain, корректно завершая поды с учётом disruption budgets.
- Обновите пакеты kubeadm до целевой версии 1.37.
- Выполните 'kubeadm upgrade plan', изучите предупреждения и примените апгрейд конфигурации командой 'kubeadm upgrade apply v1.37.x'.
- Обновите kubelet и kubectl на узле, затем перезапустите сервис kubelet.
- Верните узел в работу (uncordon) и убедитесь в готовности всех системных подов.
Повторите процедуру для остальных мастер-узлов, а затем последовательно обновите рабочие узлы аналогичным образом, используя 'kubeadm upgrade node' без повторного применения изменений к control-plane.
Управление static Pods и инфраструктурными компонентами
Особое внимание уделите статическим подам — они не проходят через обычный цикл Deployment и не подчиняются стандартным механизмам отката. Если ваш etcd или API-сервер работают как static Pods, их манифесты лежат в директории, указанной параметром --pod-manifest-path у kubelet. Перед обновлением сохраните копии этих файлов. После выполнения 'kubeadm upgrade' проверьте, не были ли переписаны манифесты, и сравните поля image, аргументы командной строки и volume-монты. При необходимости скорректируйте их вручную и принудительно перезагрузите kubelet для перечитывания конфигурации.
Проверьте компоненты CoreDNS и kube-proxy: даже если они управляются как Addons, версия их образов должна соответствовать уровню API вашей control-plane. Заранее задайте нужные теги в ConfigMap kube-system/coredns и DaemonSet'ах во избежание подтягивания неподдерживаемых версий.
Флаги kubelet и политики безопасности хоста
В новых релизах часто депрекейтятся или удаляются флаги kubelet. Переведите настройки в файл конфигурации (KubeletConfiguration) и укажите путь к нему через --config. Типичные проблемные зоны: параметры, связанные с Container Runtime Interface (CRI), обработкой событий и управлением ресурсами (systemReserved, kubeReserved). Включите защиту от нехватки памяти через evictionHard и настройте Node Allocatable, чтобы избежать OOM на системных сервисах.
Если включён SELinux, переключитесь на политику targeted и режим enforcing, предварительно прогнав нагрузки с audit2allow для выявления блокировок. Для контейнерного runtime подтвердите поддержку seccomp-профилей по умолчанию и AppArmor, если вы используете соответствующие аннотации в подах.
Стратегия восстановления и проверка работоспособности
Любое обновление требует плана отката. До начала работ сделайте снапшоты etcd и бэкапы критичных CRD вместе с их экземплярами. Сохраните вывод 'kubectl get all -A -o yaml' и дамп актуальных конфигмапов аддонов. Держите под рукой образы предыдущей версии kubelet/kubeadm на случай невозможности загрузки новых пакетов.
После завершения обновления проведите сквозное тестирование:
- Доступность API и TLS-сертификатов (check-expiration).
- Прохождение health-check'ов readiness/liveness ключевых приложений.
- Корректность Service Discovery через ClusterIP и Ingress.
- Работоспособность сетевых политик и правил RBAC.
- Стабильность CI/CD-пайплайнов и регулярок автоскейлинга.
Настройте мониторинг задержек apiserver, ошибок таймаутов webhook'ов и утечек PID на узлах. Это поможет быстро обнаружить скрытые регрессии, проявляющиеся только под нагрузкой.