Skip to content

Latest commit

 

History

History
50 lines (37 loc) · 5.98 KB

why_not_kubespray.md

File metadata and controls

50 lines (37 loc) · 5.98 KB

Почему не kubespray

Существует много способов установки кластера kubernetes. В основном, для установки я пользовался ansible playbooks проекта kubespray. Но со временем он перестал меня устраивать и пришлось искать альтернативы.

Несмотря на то, что kubespray закрывает почти все потребности по установке и управлению кластером, в процессе работы с ним выявились недостатки. Некоторые из них можно игнорировать, но другие стали мешать жить "в мире с собой".

Скорость работы. Kubespray тормоз. Редкостный тормоз. Он делает свое дело не спеша. Причина понятна - слишком универсальный инструмент. На этот недостаток можно закрыть глаза, но тратить от 20 минут на почти каждое действие - напрягает.

Через пару лет, после установки кластеров у нас поменялось окружение. В основном ИБ закрыло прямой доступ в интернет и ограничили доступы к хранилищам контейнеров. И тут мы обнаружили, что мы не можем при помощи kubespray добавлять/удалять ноды кластера. Приходится сильно перестраивать конфигурацию kubespray.

В принципе, можно было от него отказаться и начинать работать при помощи базового kubeadm. Но! Тут мы наступили на грабли, равномерно расставленные kubespray при первоначальной установке кластеров. Он почти всё ставил сам. Причем ставил этот так, что kubeadm не видел эти "особенности". Поэтому после добавления новой ноды приходилось делать много дополнительной работы.

Грабли вызваны тем, что изначально kubespray для управления кластером не пользовался kubeadm. Все файлы, конфиги, приложения устанавливал сам. Со временем начали постепенно внедрять kubeadm и далеко не всё успевали под него переделать.

Например: на каждой worker ноде кластера устанавливается nginx, кеширующий запросы к kubernetes API! Разумеется kubeadm не знает про эту фишку и не ставит nginx. После запуска ноды, вроде все нормально, но почему-то на ноде не работают сервисы. А не работают они только потому что kube-proxy не может получить их список из kubernetes API. При этом под kube-proxy не рестартует, проходит все ливнес пробы. И вот сидит админ и думает, почему все на ноде зелёное, но ни одно приложение на этой ноде (и только на ней) не работает нормально?

Под nginx ставится при помощи кубелета. Т.е. его манифест и конфигурационный файл надо поместить в определённые директории. Kubespray это умеет, kubeadm нет.

Или. Конфигурация сетевого драйвера кластера. Kubespray добавлял и конфигурировал тот же calico не стандартно. При помощи костылей и подпорок. При добавлении ноды при помощи kubeadm приходится эти костыли в виде дополнительных конфигов, руками подставлять в нужные места.

И самое обидное, что с этими вопросами могут разобраться только админы третей линии поддержки. А нам лениво заниматься добавлением, удалением нод. Поэтому стало понятно - надо менять инструменты и инструкции для второй линии.

Почему сразу не пользовались kubeadm?

Когда в моей жизни появился kubernetes хотелось всё сделать быстро и без особого погружения. Kubespray позволял реализовать эту концепцию без особых усилий. Кроме собственно установки кластера, он ставил полезные фишки, которые рекомендуют все гуру от куба. А kubeadm про эти фишки не знал. Кроме того, спрей мог установить кучу дополнительных приложений прямо из коробки. Например, он умеет ставить ArgoCD.

Опять же, удобно использовать админам второй линии поддержки. Показали пару файлов, где менять параметры. Описали несколько основных команд и всё работает. В случае kubeadm срок погружения и количество инструкций будет больше.