company_banner

Запись вебинара «Нужен ли вам Kubernetes»


    Павел Селиванов — основной спикер на интенсивах по Кубернетес (Слёрм-2 для тех, кто только знакомится с технологией и МегаСлёрм для тех, кто уже работает с Кубернетес).
    25–27 октября — Слёрм-2
    29–31 октября — МегаСлёрм


    Если вы зарегистрируетесь до 18 октября, скажите менеджеру «я с вебинара», и вам сделают скидку 10%.


    Слёрм-3 намечен на июнь '19.


    TL;DR вебинара:


    1. Если вы рассчитываете на волшебную таблетку, которая сама по себе решит ваши проблемы, то Kubernetes вам не нужен. На этом можно закончить просмотр/чтение.


    2. Мой первый опыт с k8s
    Было 50 микросервисов, хаос в эксплуатации, Docker, отсутствие оркестрации, выкатка сервисов в духе «сегодня релиз, даунтайм 2 часа».



    Внедрили Kubernetes (параллельно внедряли Docker Swarm и Nomad, Docker Swarm не прижился):



    Мы строили инфраструктуру, а не Кубернетес.


    3. Плюсы и минусы Кубернетес относительны: то, что для одного — плюс, для другого — минус. Поэтому холивар о них никогда не утихнет.


    4. «Минусы» Кубернетес


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


    — Кубернетес покрывает огромное количество аспектов инфраструктуры. Придется изучить, как они работают и как их чинить. Узкий специалист (сетевик, SRE инженер) вынужден превращаться в специалиста по Кубернетес.


    — Кубернетес из-за внутренней подвижности требует особенного отношения к мониторингу и хранению логов.


    5. Приложения должны разрабатываться под Kubernetes или по крайней мере под Docker. Кубернетес рассчитан на микросервисы. Запускать в кластере монолиты проблематично.


    6. Кубернетес позволяет контролировать огромное количество аспектов жизненного цикла приложений. Мое мнение: хорошо бы этот контроль передать разработке. Самое страшное, что я слышал от разработчика: «Почему я должен думать о ресурсах, я хочу просто писать код».


    7. Вам не нужен Кубернетес, если вы думаете:
    — Кубернетес изменит мой бизнес (или как минимум IT-департамент) и все заработает.
    — Я читал о Кубернетес на хабре, интересная тема.
    — Хочу как у Google…


    8. Есть пессимисты Кубернетес, которые им попользовались, сказали «говно» и выкинули.
    Есть оптимисты Кубернетес, готовые бороться с чем угодно, лишь бы у них был Кубернетес.
    И есть реалисты Кубернетес, готовые к тому, что огромное количество вещей нужно будет контролировать через Кубернетес, нужно будет его глубоко изучать и допиливать. Реалисты получают:
    — встроенные решения для многих задач;
    — единообразие (например, больше нет проблемы, что staging разошелся с production);
    — self-healing и как следствие 99,9% SLA.


    9. О наболевшем: об ожидании от курсов
    Я постоянно сталкиваюсь с тем, что люди рассчитывают на выходе с курсов получить специалиста. Так это не работает.
    Курсы (в частности Слёрм) — это хороший старт в технологии. Сам я курсы не люблю, был на них два раза в жизни, но именно после курсов заинтересовался Docker и начал с ним разбираться. После курсов у вас появляются вопросы, по которым вы занимаетесь саморазвитием.


    Курсы — это опыт лекторов, уже сделавших свои ошибки и собравших свои шишки.


    Курсы — это возможность задавать вопросы и получать ответы. В отличие от комьюнити, я как лектор вынужден отвечать на вопросы и нести ответственность за свои слова.


    Приятный бонус — общение с коллегами.


    10. 3 дня обучения на Слёрме заменяют 3 дня чтения документации + 1 месяц практических экспериментов + полгода эксплуатации. То есть экономят время. Но Слёрм (как и самостоятельное изучение) не гарантирует, что вы станете специалистом по Кубернетес.


    На 37 минуте начинаются ответы на вопросы участников.

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

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

      +1
      Резюме вебинара прекрасная (во всех смыслах и без шуток).
      Покажу-ка я его коллегам ;) Вдруг начнут работать.

      Еще очень интересная тема (и не затронутая) — использование minikube/minishift и OKD именно ТОЛЬКО для разработки. Потому что одно дело production, а другое — скорость тестирования. К тому же, иногда можно пожертвовать однообразностью production/dev/staging.
        0
        За сольт — тоже палец вверх.
        0
        Кубернетес рассчитан на микросервисы. Запускать в кластере монолиты проблематично.


        Вы про заморочки со stateful?
          0
          Павел пишет:
          Я про очень большое количество заморочек.
          Взять тот же вордпресс — очень много модулей просто ломается когда приложение запущено в несколько инстансов (что очень желательно для k8s).
          Ну или то же потребление ресурсов. Согласитесь что распихать по нодам пяток небольших микросервисов проще чем один жирный монолит.
            0
            Вообще я не очень уверен, что это правильная идея. Объясню — запускать куб на маленьких нодах изначально гиблая идея. Для теста = ок. Для прода — такое себе. Получается — либо куб будет на жирном bare-metal, либо куб будет на (относительно) жирных VMках. Иначе смысл какой?

            И понятия «жирный монолит» у всех свои. Одно дело — 4 ядра/8ГиБ ОЗУ (средненько так по нынешним меркам) или нечто, что ест процессоры и ОЗУ не в себя (>32ГиБ).
              0
              Взять тот же вордпресс — очень много модулей просто ломается когда приложение запущено в несколько инстансов (что очень желательно для k8s).


              Дык это о другом, вовсе не о
              Кубернетес рассчитан на микросервисы. Запускать в кластере монолиты проблематично.


              А о том, что монолит некий не предназначен для запуска на нескольких инстансах.
              Вполне себе гоняем монолиты под Kubernetes не первый год. В нескольких инстантсах. Полет нормальный. Разумеется, при их создании учтена возможность работы таковой.
            0
            Внедрили Kubernetes (параллельно внедряли Docker Swarm и Nomad, Docker Swarm не прижился)

            Зачем параллельно Kubernetes'у Consul — еще могу понять.
            Но зачем ему «параллельный Nomad»?

            Можно пояснить, — что вы имели ввиду?
              +1
              Я так понимаю, что пробовали разные, альтернативные варианты оркестратора. Куб победил (это данность, но я не могу сказать, что я, например, в восторге от его кода — реально индусы писали )))

              На самом деле я открою Америку: кубернетес — это не просто оркестратор. По сути — это менеджер ресурсов. Также как и Yarn, Nomad, Mesos, Consul Connect и пр. Просто в случае того же Yarn — нагрузкой выступают java-приложения. А k8s — распределенный менеджер ресурсов, который принимает нагрузку в виде докер-образов, т.е можно писать на своем любимом языке программирования
                0
                Зачем параллельно Kubernetes'у Consul — еще могу понять.
                Но зачем ему «параллельный Nomad»?

                Я так понимаю, что пробовали разные, альтернативные варианты оркестратора.

                Именно так. Параллельно с кубом (причем это решение в том числе перешло и в продакшен тестирование) использовался Nomad. На тот момент (2 года назад) для нас не было очевидно какое из двух решений лучше себя покажет и больше нам подойдет.
                © Павел Селиванов

              0
              отталкиваться, в любом случае, нужно от амбиций бизнеса (в контексте клиент\потребитель\etc), и если приложение изначально не подразумевает масштабирование (горизонтальное\вертикальное), особенно если оно впихнуто в докер (компосер) и запускает инстанс бд в докере и приложение в докере — всеравно k8s не решит задачу масштабирования из коробки.

              технологии, конечно, прекрасны (без сарказма, искренне), но тем не менее с несколькими миллионами очень активных клиентов вполне справится VDS в количестве менее десяти (ессно в зависимости от сложности приложения и его архитектуры)… так как гляда на цены aws, gc, etc — раскошелиться на это может себе реально крупная компания… выгднее при большой активности — несколько vds, чем тот же aws, который, к слову, может вдруг взять и регион отрубить от www (были приценденты).

              оттого с любопытством и читаю публикации от мейл груп, баду, убер (хоть 95% перевод), етс.

              PS: у меня локально, с debian 9, с трудом еле еле получалось заставлять работать k8s, устаканилось страшное впечатление как ЭТО использовать в проде, так как на сранном, хоть и топовом (i7 8700k, 32gb 3600Mhz ram) ПК это удавалось с большим трудом (собсна из-за докеров и т.п. на 100% перешел на линукс)…

              PS^ а дота и из под линукса норм канает… больше от винды и не надо
              PS^^ а фоношоп, коль макет прилетит рас в тыщу лет — так виртуалка с вин10 есть из под VMware

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

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