Чему учит Kubernetes The Hard Way?
Kubernetes The Hard Way — широко известный репозиторий, описывающий установку и настройку кластера с нуля без вспомогательных утилит на виртуальные машины Google Cloud. Обычно для разворачивая кластера используют kubeadm или kubespray, но пройти the hard way часто рекомендуют в учебных курсах по администрированию кубера. На Cloud Guru есть даже отдельный курс, посвященный этому. В свободное время я поднял кластер, и делюсь своими соображениями о том, чему это может научить.
Примечание: Выполнить такой проект можно бесплатно, например, если воспользоваться виртуалками, предоставляемыми бесплатно Oracle Cloud. На Хабре есть несколько статей об этом: про само предложение, про получение машин на ARM, про разворачивание на них кластера.
Моей целью было попрактиковаться в Linux troubleshooting и поглубже изучить Kubernetes. Поскольку сам по себе the hard way описан в репозитории по ссылке и в десятке других туториалов, рассматривающих нюансы, этот пост не содержит инструкций. Он про то, есть ли вообще смысл это делать.
В целях обучения я несколько изменил условия по сравнению с теми, которые описаны в найденных мною инструкциях. Вот они:
Я использовал Oracle Linux вместо привычной мне Debian/Ubuntu. Oracle Linux основана на дистрибутиве Red Hat, в которой по умолчанию включена SELinux и заблокировано большинство сетевых соединений.
Самая свежая версия Kubernetes: v1.27.1, а не v1.21.0, установка которой описана в репозитории.
Управляющая нода на amd64, а четыре рабочих на ARM. Забегая вперед, развертывание на ARM не принесло ожидаемых сложностей.
Помимо этого я впервые пользовался Oracle Cloud, но интерфейс у них напоминает AWS, так что разобраться было несложно.
Встретившиеся проблемы
Большинство проблем, с которыми я столкнулся, были вызваны именно использованием малознакомого дистрибутива. Начнем с того, что SELinux по какому-то невыясненному мною до конца принципу просто-напросто блокирует запуск некоторых бинарников в качестве сервисов. Необходимо поменять security context для этих файлов.
Другая история — настройка firewalld, который сначала блокирует практически все соединения. Причем все это заблокировано еще и в настройках подсети в Oracle Cloud. Конечно, можно просто разрешить все соединения, но более осторожная настройка требует понимания, что с чем и по какому порту разговаривает. Таких правил пришлось сделать много.
В свежей версии Kubernetes некоторые ключи запуска и настройки манифестов уже не работают, однако он сам кричит об этом, поэтому это не представляет никаких трудностей. Инструкция для v. 1.21.0 почти без изменений работает и на v. 1.27.1. Самым неочевидным моментом было то, что у kubelet и containerd должен быть указан один и тот же драйвер cgroups. У меня все заработало лишь после того, как я добавил строчку cgroupDriver: "systemd" в /var/lib/kubelet/kubelet-config.yaml.
Выводы
Так чему же учит прохождение Kubernetes The Hard Way?
Во-первых, что устанавливать Kubernetes из бинарников, кроме как в учебных целях, нет никакого смысла. Поддержка такого кластера определенно будет вызывать боль. Стоит воспользоваться по крайней мере kubeadm. А в целом — после такого опыта начинаешь особенно ценить managed kubernetes решения.
Во-вторых, учебный смысл таких проектов весьма ограничен. По существу он сводится к тому, чтобы прочувствовать архитектуру самого кубера. После него сложно забыть, какие есть компоненты, и как они друг с другом взаимодействуют. Но Kubernetes The Hard Way почти не учит администрировать кластер, не учит правильно деплоить приложения и т.д. и т.п.
В-третьих, прохождение the hard way в незнакомых условиях в основном обучает тебя особенностям этих условий, а не особенностям самого кубера. Иными словами, если используешь Oracle Linux, то разбираться придется в специфике этого дистрибутива, а не в особенностях функционирования на нем компонентов кубера.
Если подвести итог: стоило ли оно того? Думаю, я стал немного глубже понимать Kubernetes, но метод достижения этого выбран не самый удачный. Можно было просто повторить некоторые разделы курса подготовки к сертификации CKA.
Одновременно я потренировался в Linux troubleshooting на незнакомом дистрибутиве, и вот это было полезно. Большая часть времени у меня ушла на это. В этой части проект, пожалуй, себя оправдал.
