company_banner

Бесплатный вебинар «Обзор возможностей Kubespray»

    Почему именно Kubespray?


    С Kubernetes мы столкнулись чуть более двух лет назад — до этого у нас был опыт работы с Apache Mesos и мы успешно отказались от docker swarm. Поэтому освоение k8s сразу пошло по бразильской системе. Никаких миникубов или менеджед решений от гугла.


    Kubeadm в тот момент не умел собрать кластер etcd, а из остальных вариантов kubespray был в топе выдачи гугла.


    Мы его посмотрели и поняли — надо брать.


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



    На вебинаре Сергей Бондарев расскажет, как устроен kubespray, в чем отличие от kubeadm, kops, rke. Поделится уникальными фишками kubespray и алгоритмом установки кластера. Разберёт особенности (недостатки) при промышленной эксплуатации.


    Так почему же мы ухватились за kubespray всеми тремя руками?


    • Это ансибль и opensource. Всегда можно допилить какие то моменты под себя.
    • Можно ставить на Centos, ну и на другие дистрибутивы ;)
    • HA-setup. Отказоустойчивый etcd-кластер из 3 мастеров.
    • Возможность добавлять узлы и обновлять кластер.
    • Установка дополнительного софта типа dashboard, metrics server, ingress controller и т.п.

    Также ансибль сценарий работает с митогеном. Что дает ускорение на 10-15%, не больше, потому что основное время занимает выкачивание образов и установка.


    Объективно говоря, на сегодняшний момент выбор kubespray для установки кластера далеко не так очевиден, как это было два года назад.


    Если кратко...


    Например, kops — вроде бы как и кубспрей позволяет установить кластер с нуля, даже виртуалки сам создаст. Но работает только AWS, GCE и опенстек. Что как бы вызывает вопрос — зачем он нужен, если в этих облаках есть менеджед решения, даже в опенстеке, например selectel и или mail.ru. rke — кому-то нравится, но у них свой собственный подход к структуре создаваемого кластера и не очень большие возможности по кастомизации компонентов кластера. Плюс требуется уже настроенный узел с установленным докером. kubeadm — также требуется докер, утилита от разработчиков кубернетес, наконец-то научилась создавать отказоустойчивые сетапы, хранить конфиг и сертификат внутри кластера и теперь не надо синкать эти файлы вручную между узлами. Хороший инструмент, но ориентирован только на поднятие контрол-плейна. Даже сеть в кластере не устанавливает, а документация предлагает применить манифесты с CNI вручную.


    Ну и немаловажным фактом является то, что все эти три утилиты написаны на go, и если вам потребуется что-то свое, уникальное, надо знать go, чтобы подправить код и создать pull request.
    Кубспрей — это ансибл, который явно проще изучить, чем go.


    Ну, и конечно же на том же ансибль можно написать собственные сценарии для установки докера и кластера с помошью rke или kubeadm. И эти сценарии, за счет своей узкой специализированности конкретно под ваши требования, будут работать намного быстрее кубспрея. И это отличный, рабочий вариант. Если у вас есть компетенции и время.


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


    И это только часть того, о чём мы поговорим. Скучно не будет. Приходите и регистрируйтесь на вебинар. Или регистрируйтесь и приходите. Как вам больше нравится.

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

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

      0
        –3
        Нет. Далеко не повторение. Больше глубины данных и примеров. Как говорится, Сергея ничто не будет сдерживать — это будет его звёздный час во всех смыслах.
        0
        А если вы только начинаете знакомиться с Kubernetes, то освоить кубспрей будет намного легче и быстрее.

        нет, нет и нет. Самое быстрое — "rke up", плавали знаем. 10 минут и кластер готов.
        Да, могут быть вопросы по "расширяемости", но если уж так копать, то нужно проходить hard way от Келси Хайтауэра — реально нестареющая классика
        По митогену тоже есть особое мнение:
        https://habr.com/ru/post/516028/


        про митоген
        — А где здесь про Mitogen? — вправе спросить ты, уважаемый читатель. В этой статье — нигде. Но если ты реально готов читать его код и разбираться, почему твой плейбук падает с Mitogen, а с ванильным Ansible нормально работает, или почему этот же плейбук доселе исправно работал, а после обновления стал делать странное — что ж, Mitogen потенциально может быть твоим инструментом. Применяй, разбирайся, пиши статьи — прочитаю с интересом.

        Почему лично я не использую Mitogen? Потому что гладиолус он работает, только пока таски реально простые и всё хорошо. Однако стоит свернуть чуть влево или вправо — всё, приехали: в ответ в тебя летит горсть невнятных исключений, и для завершения картины не хватает только расхожей фразы «всем спасибо, все свободны». В общем, я просто не желаю тратить время на выяснение причин очередного «подземного стука».

        kubeadm — также требуется докер,

        srsly? А им же вроде можно сетапить и бездокерные кластера, на cri-o и containerd.


        все IMHO

          +1
          minikube start еще быстрее…

          Речь о самом простом способе поднять production-ready кластер. Чтобы человек сразу привыкал к хорошему, а не решал вопросы по «расширяемости»…

          Про митоген… Помню эту статью на хабре. Там автор предлагал на каждый чих писать свои модули под ансибль. В итоге вместо описания сценариев на ямле, процесс создания IaC превращался в программирование на питоне. и я предполагаю, что его проблемы были как раз между митогеном и его модулями…
          Это я к тому, что запуск кубспрея с митогеном я отлаживал и добавлял. И из всего, что пришлось переделывать — это таски с настройкой coreos-like дистров (использовался модуль raw, чтобы питон туда поставить) и пара тасков с хитрыми delegate_to: внутри циклов с include:

          «докер» == «среда контейнеризации» — для краткости речи
            0

            спасибо


            Речь о самом простом способе поднять production-ready кластер.

            rke не продакшн реди? Та ну.


            «докер» == «среда контейнеризации» — для краткости речи

            принято, но это только запутывает новичков )

          0
          ну скажем так — с rke есть нюансы…
          Лично я думаю, что версия 3.0 будет не совместима с 2.X ;)

          Человек, который знает про cri-o и containerd и чем они отличаются от докера — сложно назвать новичком.
            0
            ну скажем так — с rke есть нюансы…

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


            Лично я думаю, что версия 3.0 будет не совместима с 2.X ;)

            и? :-) Я не берусь утверждать гарантированно, но с кьюб спрей, как и с любым другим сложным инструментом, тоже масса нюансов и поэтому коллеги из чатиков натыкались на какие-то ситуации, когда его прогон все ломал (или хотя бы не чинил). Но я не дам точной фактуры, потому что мне это сейчас не интересно искать, а, во-вторых, я допускаю, что коллеги ССЗБ и попросту что-то сделали не так (см. предыдущий тезис про сложность).

            +1
            попробовал я давечА этот форк. Нус, скажем так из первых впечатлений:
            1) использование hostname, а не hostnamectl — на centos8 cloud пришлось доставлять условными ручками (через cloud-init, конечно, хотя иные пакеты «инсталер» ставит). Ну и не забыть поставить iptables если вам оно надо будет «потом» (в процессе инсталяции иных компонент)…
            2) использование (отключаемое, но всё же) запуска ionice внутри etcd офиц. (если не переопределён, конечно) образа, хотя его там уже давно выпилили. Как следствие etcd не поднимается, что как бы печально.

            Короче как итог: если вы думаете что большие дядьки за вас все сделали и вы по трём командам развернете k8s в проде — врядли.

            Мне так и осталось непонятным итоговая аудитория этого kubespray (и форка в частности): для «поиграться» есть более простые решения, для реально здоровых инсталяций (хотя бы в 100 нод) — в 90% придётся допиливать хотя бы это решение или рисовать своё (и не факт что рисовать своё будет быстрее чем допиливать и потом поддерживать в актуальности).

            JohnRico — попросите спикера освятить вопрос «кому это надо»?

            Note: я ниразу не ops, я с другой стороны.
              –2
              Сейчас попрошу. :)
                0
                Про хостнейм я не понял про какой таск вы говорите. Если вот про этот из роли bootstrap-os, то это не команда, а модуль ансибль.

                - name: Assign inventory name to unconfigured hostnames (non-CoreOS, non-Flatcar, Suse and ClearLinux)
                  hostname:
                    name: "{{ inventory_hostname }}"
                  when:
                    - override_system_hostname
                    - ansible_os_family not in ['Suse', 'Flatcar Container Linux by Kinvolk', 'ClearLinux'] and not is_fedora_coreos
                


                По поводу etcd_ionice. Тут да, мой косяк, не уследил за тем, что в контейнерах etcd v3.4.x выпилили бинариник ionice, и я уже убрал эту опцию из своего форка и готовлю PR в основной кубспрей.

                Насчет целевой аудитории — Вы как-то резковато обратились только к граничным случаям:
                — для поиграться
                — и для реально здоровых в хотя бы 100 узлов…
                А как же остальные 90% реальных пользователей кубернетес? У которых кластера от 5 до 20 узлов, и нет денег на специалистов, готовых не только написать IaC сценарий для развертывания кластера, но и регулярно изучать, что новенького появилось в кубе, что изменилось, а что и удалили. И согласно всем этим изменениям поддерживать свой сценарий в актуальном состоянии.
                  +1
                  то это не команда, а модуль ансибль.
                  уже не вспомню, но вероятно это — как раз вероятно не хватает ещё одного условия исключения…

                  А как же остальные 90% реальных пользователей кубернетес? У которых кластера от 5 до 20 узлов, и нет денег на специалистов, готовых не только написать IaC сценарий для развертывания кластера, но и регулярно изучать, что новенького появилось в кубе, что изменилось, а что и удалили. И согласно всем этим изменениям поддерживать свой сценарий в актуальном состоянии.

                  такие люди не справятся и с kubespray — столкнуться как например я с первой ошибкой и уйдут в rke/иное «k8s в два клика»/k8s as service. «Платишь орехами — получаешь обезъян».

                  Что дейсвительно таким нужно, так это не «ansible макороны» — а готовые образа мастеров, нод и т.д. (где уже всё стоит, настроено + cloud-init «инструкция» как их «запустить» чтобы при старте стать «кластером»). Все кто хочет «не стандарт» — идут на рынок за админами (ops-ами или как вы их хотите назвать — не так важно). Либо сервис (вот вам идея), который позволит натыкать что вы хотите (на там выбрать сеть, формат образов и т.п.), заплатить мини денюжку для подписки на выбранную конфигурацию и получать эти образа «по-подписке» для обновления свого кластера. И пусть эти ansible программы (kubespray) (да, это ведь эта конфа по слоности уже похожа на «взрослый» язык программирования) будет не их головной болью.

                  В эту степь сейчас идёт вся индустрия — immutable образа и это относится не только к контейнерам, но и к виртуалкам.
                    –1
                    Нет необходимости, ресурсов или желания самостоятельно управлять своими кластерами — выбирайте любое менеджед решение от крупного поставщика. GKE, EKS, AKS.

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

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