Ах, Kubernetes с высокой доступностью! Звучит почти как название нового блокбастера: «Кубернетес 9.4: Возвращение отказоустойчивости». Только представьте: вы — герой, который сражается с монстрами под названием «простой» и «отказ», вооружившись волшебным мечом kubeadm на непобедимом Rocky Linux 9.4.
Итак, пристегните ремни, сегодня мы отправимся в эпическое путешествие по настройке кластера Kubernetes так, чтобы он не просто работал, а работал как швейцарские часы — даже если один из узлов решит взять отпуск.
Начнем с того, что у нас есть три узла для плоскости управления и три рабочих узла. Почему именно три? Потому что два — это уже не кластер, а один — вообще одиночество. Помните анекдот про двух системных администраторов?
Один говорит другому: «Пойдем на обед». Второй отвечает: «Не могу, меня кластер сломал». Вот тут-то и нужен HA!
Для наших главных героев (узлов) рекомендуются железные характеристики: минимум 4 ГБ RAM и 4 CPU для мастеров и внушительные 16 ГБ RAM и 8 CPU для рабочих пчелок. А еще у нас есть маленький помощник — HAProxy, который стоит на страже порядка с двумя гигабайтами памяти и парочкой процессорных ядер. Он словно добрый сторож у ворот вашего замка Kubernetes.
Теперь о DNS-записях — без них наш кластер будет как вечеринка без приглашений: никто не придет.
Мы прописываем имена типа k8smas1.kalyuzhnyy.lan и их IP-адреса в IDM — это как раздавать бейджики гостям на входе в клуб. А если вы вдруг захотите настроить HAProxy самостоятельно, советую заглянуть на мой сайт в раздел «Инструменты системного администратора» — там столько полезного! Кстати, вспомнил одну историю: админ решил настроить HAProxy вручную и забыл включить нужные сервисы в firewall.
В итоге весь кластер дружно сказал ему «прощай» ровно через пять минут после запуска. Не повторяйте его ошибок!
Говоря о firewall’ах, будьте готовы открыть целый букет портов — ведь Kubernetes любит говорить со всеми своими компонентами одновременно, как многоголовый дракон из сказок.
На мастер-узлах нужно разрешить службы kube-apiserver и kube-controller-manager; на рабочих узлах тоже не забыть про kube-worker. Это вам не просто порты открыть — это почти как устроить вечеринку для всех друзей вашей сети.
А теперь серьезный момент — отключаем подкачку (swap). Почему?
Потому что Kubernetes любит жить быстро и без тормозов! Если swap включен, он может привести к непредсказуемым приключениям в вашем кластере… Представьте себе анекдот про программиста: «Почему ты выключил swap?» – «Чтобы память была чистая!» В общем, swapoff -a — и никаких компромиссов! Не забудьте потом поправить /etc/fstab и обновить grub конфигурацию.
SELinux тоже требует внимания – он должен быть в режиме permissive (разрешающем), иначе ваш кластер начнет вести себя как капризный кот: вроде бы делает то, что надо, но постоянно царапается. Поэтому setenforce 0 и правка конфигурационного файла – обязательны.
Пришло время поговорить о контейнерной среде выполнения!
Мы выбрали CRI-O — легковесный зверь среди контейнеров, который идеально подходит для высоконагруженных систем. Хотя можно было бы взять Docker или containerd… Но зачем нам лишний вес? Вспоминается история из жизни одного администратора: он поставил Docker вместо CRI-O ради эксперимента… Через час кластер упал от перегрева процессора!
Так что поспешайте медленно.