company_banner

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

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


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



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


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


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


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

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


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


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


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


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


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


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


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


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


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


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


    Opensource как он есть.


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


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

    Southbridge
    Обеспечиваем стабильную работу highload-проектов

    Комментарии 4

      +2

      Спасибо за напоминание, но мы и так знаем:
      https://habr.com/ru/company/southbridge/blog/519580/
      Или… что-то поменялось? :-)

        +2

        Есть ли у сабжа преимущества
        перед RKE, кроме «я привык все делать Ansible’ом»?

          +1

          еще один фанат rke, приветствую!

            0
            Есть и много.
            Как минимум кубспрей умеет не только в докер, но и containerd и crio, причем сам ставит, а не требует готовый.
            Плюс более удобный подход к запуску контрол-плейна.
            kubectl get pod -n kube-system покажет api, cm, scheduler… и логи их так же можно посмотреть. Плюс у кублетов можно динамические конфиги использовать.

            ну и там еще много всего, но это уже относится к косякам rke, типа хранения приватного ключа от корневого сертификата кластера в конфигмапе.
            в kubeadm народ заморачивался, писал специальный код, который генерил секреты с TTL 1 час, клал в эти секреты сертификаты, дополнительно их шифровал… и все это для того, чтобы передать серты на второй и третий мастера при HA-сетапе…
            а в rke ребята простые…

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

          Самое читаемое