Ладно. “В следующий раз” наступил.
Обновление самого кластера. Чарты обновили, деплои проверили - теперь очередь за нодами.
В случае managed - EKS, GKE, AKS - там действительно есть кнопка. С нюансами: надо следить за версиями аддонов, нод-групп, и не прыгать через минорные версии. Но в целом - терпимо.
В случае self-hosted - обновляем сами. В kubeadm нет кнопки “обновить кластер”. Есть последовательность, которую нельзя перепутать:
- Бэкап (он должен быть регулярным, но особенно - перед обновлением)
kubectl drain <node>- выгоняем поды с нодыapt-mark unhold kubelet kubeadm kubectlapt install kubelet=1.32.0-1.1 kubeadm=1.32.0-1.1 kubectl=1.32.0-1.1- версию указываем явноkubeadm upgrade apply- на мастере, потомkubeadm upgrade nodeна воркерах- Правим если что-то не так
kubectl uncordon <node>, проверка- Повторяем для каждой следующей ноды
Одна нода за раз. Не все сразу.
В случае kubespray, talos и подобных - обновляем через ту же систему. Но сверяем версии зависимостей: kubespray тоже не всегда успевает за upstream k8s.
После обновления: проверить поды, метрики, алерты.
Потом повторить всё то же самое на проде - с учётом косяков, найденных в деве.
Прошло две недели. Очередной созвон.
“Обновляю ноды, осталась последняя треть.”
Это не прокрастинация. Это реально столько занимает.
Пока идёт обновление - в голове одновременно: совместимость версий, какая нода уже обновлена, что сломалось в деве и надо учесть на проде, не забыть проверить алерты после каждой ноды. Один человек. Полное внимание.
У него куча заметок, списков, чтобы не забыть и не перепутать ничего. К сожалению, это его личные заметки, а не документация. Документацию он сделает потом, если успеет после обновления и до следующей “срочной” задачи. Хорошо бы хоть список траблшутинга был читаемым.
Если не написать документацию сразу - через месяц разобраться в заметках можно только воспроизведя весь процесс заново. При следующем обновлении он сможет быстрее фиксить проблемы. Но не избежать их.
Для менеджера это значит: новая фича - подождёт. Срочный фикс - зависит от серьёзности. Онбординг нового разработчика - не лучшее время. Обновление кластера блокирует не одну задачу - оно блокирует весь ритм команды на недели.
Bus-factor здесь не абстрактный. Это конкретно: уйдёт - и вместе с ним уйдут те заметки, список граблей с прошлого обновления, понимание “почему мы делаем вот так, а не иначе”. Следующий человек начнёт сначала. С теми же граблями.
У вас есть runbook по обновлению кластера? Или это “спросить Васю”?
Подписывайся. Пока Вася ещё здесь.
P.S. Это было обновление самого кластера. Но есть ещё один уровень - базовая ОС под ним. Об этом в очередной следующий раз.