Comments 14
Учитывая что поддержка docker удалена из 1.24, тк в doker не реализовали CRI, то строить кластер на докере наверно не лучшая идея. Хотя, добавить мастеров, и воркеров на других контейнер-рантаймах будет не сложно (как я понимаю).
Второй совет, видимо, добавить еще контрол-плейн нодов, тк документация советует минимум 3, особенно если кластер большой и распределенный.
Ну и с т.з. безопасности снимать NoSchedule на контрол-плейне в книгах не рекомендуют. А вот взлетит ли ваш конфиг без этого? Я сам только начинаю, и строю кластер на calico+clonghorn как в книге.
Огромное спасибо за фидбек, учту описанные моменты. А насчёт работоспособности без NoSchedule, всё будет работать и не снимая его, т.к. все использованные в статье сервисы имеют Tolerations и будут развёрнуты. Метка была убрана, чтобы в дальнейшем можно было разместить сбор метрик для мониторинга, т.е., чтобы поды могли размещаться и на мастер ноде. Ещё одна причина это вероятная нехватка ресурсов.
Пытался найти в поисковиках, но на нашел книгу где описывается настройка кластера c Calico и longhorn
Репа с плейбуками для "подготовки" стендов к каждому уроку (в тч там есть устровка ванильного кубера, с Calico и longhorn. Урок 6).
Но я дела не в AWS и не в Vargant, и в добавок на Debian, а не Ubuntu, по этому плйбук не работает для меня. Приходится все делать вручную. зато лучше разбираешься :)
Здравствуйте, поделисьтесь пожалуйста названием книги.
Лучше конечно вместо Flannel использовать другой CNI плагин – Calico или Cilium например. Дело в том, что Flannel не поддерживает NetwokPolicy, что с точки зрения безопасности не есть хорошо.
Аннотация ingress.class в 1.22 была объявлена как deprecated. https://kubernetes.io/blog/2021/07/14/upcoming-changes-in-kubernetes-1-22/ Честно говоря не понимаю практический смысл ручного поднятия куба. Если чисто для себя, есть уже замыленная статья "Kubernetes hard way" где всё описано. Есть kubespray который позволяет штамповать кластера под копирку и при этом можно легко добавлять/удалять ноды.
2023 год на дворе, а кластера все так развертывают kubeadm+flannel для петпроектов.
Ну возьмите вы коробочные решения от Флант Deckhouse, или talos от Sidero Labs. Да на крайний случай даже обычный Docker Desktop уже умеет кластер.
Зачем нужны эти лишние движения по разворачиванию вручном режиме? Профита никакого.
Для обучения много профита. Лучше понимаешь как оно там под капотом. Потом будет проще траблшутить.
Как выше отметил @S1M есть прекрасная статья в оригинале "Kubernetes hard way" и цикл статей от @dobry-kot где рассказывается про внутренности Кубика.
Господи, сколько советчиком. Все человек правильно делает. Тот кто предлагает кубспрей, а вы пробовали поддерживать такое решение в большом кластере и распределенной команде специалистов разного уровня? Врятли есть что-то страшнее этого. Коробочные решения это тоже такое себе ведь вы теряете в гибкости и ресурсах, тот же ранчер содержит больше элементов которые не нужны зачастую. Вот хард Вэй это отличное начало чтобы разобраться. Касаемо лонгхорна - он хорош, но линстор вроде как быстрее и надёжнее. Нфска на воркере это совсем не очень. Но чтобы понять, что такое сторэджкласс достаточно.
Но все это очень просты темы. Все пишут о том как развернуть кластер, но никто не пишет о том как например обновить сертификаты кластера, особенно если изменился рут са. Я имею ввиду именно внутренние серты кластера.
Ага особенно если этот рут СА не один, а свой для каждого сервиса :) про это вообще мало пишут, я для себя в самосборном кластере решаю эту задачу выписывая сертификаты из vault и следит за ними consul-template но это сугубо тестовое решение пока что. А вообще смена са это боль и страдание не только в кубах, а везде и всегда.
Создание Kubernetes-кластера на пальцах или почему это не сложно