Kubernetes-HA. Разворачиваем отказоустойчивый кластер Kubernetes c 5 мастерами

[@HeOS]

После того как мастер инициализируется, kubeadm выведет на экран служебную информацию. В ней будет указан token и хэш для инициализации других членов кластера. Обязательно сохраните строчку вида: kubeadm join --token XXXXXXXXXXXX 172.26.133.21:6443 --discovery-token-ca-cert-hash sha256:XXXXXXXXXXXXXXXXXXXXXXX, где нибудь отдельно, так как данная информация выводится один раз; если токены будут утеряны, их придется генерировать заново.

Совсем не обязательно это делать. :) Всегда можно воспользоваться командой на любом из мастеров (если мне не изменяет память):
kubeadm token create --print-join-command.

Сам каждый раз сохранял ее, а потом покопался в доках немного и был счастлив. :)

[@rjeka]

Это так но токен будет уже другой. Токен который генерируется при инициализации, больше не доступен. Вроде как был issue на гитхабе по этому поводу, но я давно за ним не следил.

[@HeOS]

Для чего вам токен, который генерируется при инициализации?

[@rjeka]

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

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

Но в общем Вы правы, сохранять ее не обязательно. Нам просто так удобнее.

[@Logout_90]

Спасибо за статью. Хочу отметить, что kubeadm не единственный способ установки kubernetes. Автор рассматривал альтернативные пути установки и настройки кластера? К примеру, максимально с infrastructure as code в моем понимании соотносится kubespray. Его можно запихнуть внутрь ci/cd, выполнять развертывание на тестовом кластере, гонять тесты testinfra, а потом применять на прод. При этом все выполняется не вручную, что минимизирует количество ошибок, повышает управляемость кластера.

[@HeOS]

Kubespray, насколько мне известно, не в активной стадии разработки и разработчики не гарантируют поддержку свежих фич Kubernetes'а в коде. Так что я тут согласен, что использование Kubeadm или установка компонентов один за другим больше подходят.

[@past]

Тоже разворачиваем у себя с помощью kubespray. Судя по их гитхабу, разработка идет очень активно.

[@ct0r]

Kubespray огонь. Лучшего способа я пока не нашел. И разрабатывается активно, уж не знаю, откуда инфу про обратное вы почерпнули.

[@IgorStepin]

kubeadm хорош тем, что ставит кластер уже внутри ОС, а за предварительное развертывание не отвечает. Т.е. с его помощью можно строить свои CI pipelines. Пробовали еще kops, но его возможностей не хватило даже для AWS, не говоря уже о других площадках.

В целом, думаю, all-in-one победят, но позже, пока что они сыроваты (как и многое в Kubernetes, даже kubeadm в альфе/бете в зависимости от компонента).

[@rjeka]

Да конечно рассматривали, в том числе и так называемый Kubernetes The Hard Way. Но времени как всегда не хватает. Для начала я считаю что kubeadmin рабочий вариант.
Для CI\CD мы используем dspp + helm

[@Macbet]

Поправьте меня если не прав, но разве в последних версиях k8s'а kubespray не признали deprecated ??

[@kvaps]

Спасибо за статью,
Единственное что не понятно зачем использовать docker-compose когда существуют static pods?

[@shuron]

"Kubernetes c 5 мастерами"

А сколько у вас Worker'ов?
И неужели такая критичность высокодоступности мастеров?

[@rjeka]

Очень критична. Это было пожелание инвесторов. У нас банковский продукт. Даунтайм в случае чего должен быть минимальный.
Я бы честно говоря ограничился 3 )))

[@IgorStepin]

Наверное, автор знает, но для тех, кто только разбирается, может быть интересно:
— рабочие ноды и поды прекрасно работают без живых мастеров: мастера нужны только чтобы менять конфигурацию кластера
— на мастерах всё состояние хранится в etcd
— etcd можно бекапить и восстанавливаться из бекапа
— если кластер совсем маленький и тестовый, то и на мастерах тоже можно размещать рабочую нагрузку: `kubectl taint nodes --all node-role.kubernetes.io/master-`

Т.е. если у вас мало динамики изменения структуры кластера, то, скорее всего, и одного мастера c ежечасными бекапами etcd хватит. Лучше, конечно, 3: тогда восстановления будут практически автоматические. А вот 5 и больше — такие случаи бывают, но редко когда нужно.

[@rjeka]

Ответил выше. Но это было не наше условие. На кластере размещается банковский продукт. Я бы ограничился 3 мастерами.
Да рабочие ноды работают без мастера. Точнее работают до первого сбоя. Нам нужен постоянный контроль кластера, с минимальным даунтаймом.

[@turbotankist]

Очень важная деталь! почти нигде в открытой документации не говорят — закрывать порты etcd — 2378,2379 и т.д. для доступа только между другими мастер-нодами, а из интернета особено закрыть нужно, т.к. etcd ничем не ограничивает клиентский доступ… сертификаты только для api-сервера работают, а не для etcd.
Не забывайте!

[@rjeka]

Честно говоря как то исторически сложилось, что я работал с flanel, и у меня не возникало с ним никаких проблем. Была мысль попробовать сalico но руки так и не дошли