Комментарии 19
После того как мастер инициализируется, kubeadm выведет на экран служебную информацию. В ней будет указан token и хэш для инициализации других членов кластера. Обязательно сохраните строчку вида: kubeadm join --token XXXXXXXXXXXX 172.26.133.21:6443 --discovery-token-ca-cert-hash sha256:XXXXXXXXXXXXXXXXXXXXXXX, где нибудь отдельно, так как данная информация выводится один раз; если токены будут утеряны, их придется генерировать заново.
Совсем не обязательно это делать. :) Всегда можно воспользоваться командой на любом из мастеров (если мне не изменяет память):
kubeadm token create --print-join-command.
Сам каждый раз сохранял ее, а потом покопался в доках немного и был счастлив. :)
Это так но токен будет уже другой. Токен который генерируется при инициализации, больше не доступен. Вроде как был issue на гитхабе по этому поводу, но я давно за ним не следил.
Для чего вам токен, который генерируется при инициализации?
Статья изначально была для корпоративной вики.
В моей работе токены нужны, для того что бы разместить их в документации по проекту.
В случае необходимости масштабируемости проекта, наши сервис инженеры или младшие админы могут подготовить виртуалку и ввести новую ноду в кластер просто посмотрев в документацию. У них нет доступа до кластера, что бы сгенерировать новый токен.
В данном контексте статьи, я акцентировал на этом внимание для тех кто только начинает разбираться с кубернетесом и без данной строчки, дальнейшие шаги будут более проблематичны, но не критичны.
Но в общем Вы правы, сохранять ее не обязательно. Нам просто так удобнее.
В моей работе токены нужны, для того что бы разместить их в документации по проекту.
В случае необходимости масштабируемости проекта, наши сервис инженеры или младшие админы могут подготовить виртуалку и ввести новую ноду в кластер просто посмотрев в документацию. У них нет доступа до кластера, что бы сгенерировать новый токен.
В данном контексте статьи, я акцентировал на этом внимание для тех кто только начинает разбираться с кубернетесом и без данной строчки, дальнейшие шаги будут более проблематичны, но не критичны.
Но в общем Вы правы, сохранять ее не обязательно. Нам просто так удобнее.
Спасибо за статью. Хочу отметить, что kubeadm не единственный способ установки kubernetes. Автор рассматривал альтернативные пути установки и настройки кластера? К примеру, максимально с infrastructure as code в моем понимании соотносится kubespray. Его можно запихнуть внутрь ci/cd, выполнять развертывание на тестовом кластере, гонять тесты testinfra, а потом применять на прод. При этом все выполняется не вручную, что минимизирует количество ошибок, повышает управляемость кластера.
Kubespray, насколько мне известно, не в активной стадии разработки и разработчики не гарантируют поддержку свежих фич Kubernetes'а в коде. Так что я тут согласен, что использование Kubeadm или установка компонентов один за другим больше подходят.
kubeadm хорош тем, что ставит кластер уже внутри ОС, а за предварительное развертывание не отвечает. Т.е. с его помощью можно строить свои CI pipelines. Пробовали еще kops, но его возможностей не хватило даже для AWS, не говоря уже о других площадках.
В целом, думаю, all-in-one победят, но позже, пока что они сыроваты (как и многое в Kubernetes, даже kubeadm в альфе/бете в зависимости от компонента).
В целом, думаю, all-in-one победят, но позже, пока что они сыроваты (как и многое в Kubernetes, даже kubeadm в альфе/бете в зависимости от компонента).
Да конечно рассматривали, в том числе и так называемый Kubernetes The Hard Way. Но времени как всегда не хватает. Для начала я считаю что kubeadmin рабочий вариант.
Для CI\CD мы используем dspp + helm
Для CI\CD мы используем dspp + helm
Поправьте меня если не прав, но разве в последних версиях k8s'а kubespray не признали deprecated ??
Спасибо за статью,
Единственное что не понятно зачем использовать docker-compose когда существуют static pods?
"Kubernetes c 5 мастерами"
А сколько у вас Worker'ов?
И неужели такая критичность высокодоступности мастеров?
Наверное, автор знает, но для тех, кто только разбирается, может быть интересно:
— рабочие ноды и поды прекрасно работают без живых мастеров: мастера нужны только чтобы менять конфигурацию кластера
— на мастерах всё состояние хранится в etcd
— etcd можно бекапить и восстанавливаться из бекапа
— если кластер совсем маленький и тестовый, то и на мастерах тоже можно размещать рабочую нагрузку: `kubectl taint nodes --all node-role.kubernetes.io/master-`
Т.е. если у вас мало динамики изменения структуры кластера, то, скорее всего, и одного мастера c ежечасными бекапами etcd хватит. Лучше, конечно, 3: тогда восстановления будут практически автоматические. А вот 5 и больше — такие случаи бывают, но редко когда нужно.
— рабочие ноды и поды прекрасно работают без живых мастеров: мастера нужны только чтобы менять конфигурацию кластера
— на мастерах всё состояние хранится в etcd
— etcd можно бекапить и восстанавливаться из бекапа
— если кластер совсем маленький и тестовый, то и на мастерах тоже можно размещать рабочую нагрузку: `kubectl taint nodes --all node-role.kubernetes.io/master-`
Т.е. если у вас мало динамики изменения структуры кластера, то, скорее всего, и одного мастера c ежечасными бекапами etcd хватит. Лучше, конечно, 3: тогда восстановления будут практически автоматические. А вот 5 и больше — такие случаи бывают, но редко когда нужно.
Очень важная деталь! почти нигде в открытой документации не говорят — закрывать порты etcd — 2378,2379 и т.д. для доступа только между другими мастер-нодами, а из интернета особено закрыть нужно, т.к. etcd ничем не ограничивает клиентский доступ… сертификаты только для api-сервера работают, а не для etcd.
Не забывайте!
Не забывайте!
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Kubernetes-HA. Разворачиваем отказоустойчивый кластер Kubernetes c 5 мастерами