«Обзор возможностей Kubespray»: Отличие оригинальной версии и нашего форка

23 сентября 20.00 МСК Сергей Бондарев проведёт бесплатный вебинар «Обзор возможностей Kubespray», где расскажет, как готовят kubespray, чтобы получилось быстро, эффективно и отказоустойчиво.

Сергей Бондарев расскажет отличие оригинальной версии и нашего форка:

«Обзор возможностей Kubespray»: Отличие оригинальной версии и нашего форка

Отличие оригинальной версии и нашего форка.

Те, кто с кубспреем уже сталкивался, наверное сейчас недоумевают, почему я kubeadm противопоставляю кубспрею, ведь кубспрей для создания кластера, как раз и вызывает кубадм и на первый взгляд выглядит, как скрипт установки пакетов и автоматизированного запуска.

Но так было не всегда, изначально кубспрей устанавливал все компоненты самостоятельно:

  • собирал кластер etcd;
  • устанавливал кублеты, генерил сертификаты, конфиги и токены доступа для статик подов контролплейна и прочих служебных компонентов;
  • создавал сервис аккаунты для рабочих узлов и подключал их в кластер.

Но в позапрошлом году они этот функционал выпилили, оставив только кубадм. Который в то время был не очень. Мне стало обидно и я сделал свой форк, в котором сохранил классический режим установки, и собственно теперь поддерживаю этот форк в актуальном состоянии, черри-пикая коммиты из оригинального кубспрея к себе. Попутно допиливая классический режим под новые изменения.

В итоге разница между кластерами, созданными моим форком и оригинальным — это kube-proxy и сроки действия сертификатов.

В моем форке все осталось, как было раньше — куб-прокси запускается, как статик под, сертификаты выписываются на 100 лет.

В Kubeadm куб-прокси запускается, как daemonset, а сертификаты выписываются на 1 год, и их надо периодически продлевать. kubeadm наконец-то научился это делать одной командой.

Разница небольшая, и на сегодня мы используем оба варианта.

Особенности (недостатки) при промышленной эксплуатации:

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

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

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

Например у меня была проблема с кубадмом, когда он падал в момент добавления второго и третьего мастера, и после этого кубспрей делал kubeadm reset на узле, и пробовал добавить мастер еще раз.

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

Opensource как он есть.

Всё это и многое другое на бесплатном вебинаре «Обзор возможностей Kubespray» 23 сентября 20.00 МСК.

Присоединяйтесь!

Источник: habr.com

Добавить комментарий