С 29 декабря по 24 февраля на Хабре прошёл сезон Kuberbetes. Вместе с партнёром, #CloudMTS, мы вдохновляли хабраавторов публиковать статьи по k8s и контейнерам в соответствующем хабе — глубокие, полезные, с техническими подробностями.
Пришло время подвести итоги и узнать, кто получит новенький MacBook и грант в 30 000 рублей на то, чтобы написать ещё одну классную статью. Награждаем не только победителя: участники конкурса получат в подарок от #CloudMTS гранты на использование сервисов компании.
О хабе
Хаб Kubernetes появился в 2017 году, и за это время в нём опубликовали уже более 1000 статей. Самые частые пересечения происходят с хабами Виртуализация, Системное администрирование, Облачные сервисы и DevOps, а топовые статьи набрали до 75 тысяч просмотров. Но мы всё-таки тут собрались не обсуждать хаб, а выяснить, кто же стал чемпионом-статьеписцем.
Итоги сезона
Под катом таблица со всеми текстами — участниками сезонов Kubernetes. Не смотрите в неё, если не хотите заспойлерить себе победившую статью:
Текст | Автор | Просмотры | Рейтинг | Закладки | Комментарии |
11k | 46 | 104 | 32 | ||
Мониторинг межсервисного взаимодействия Kubernetes с помощью протокола NetFlow | 4,5k | 44 | 42 | 8 | |
3,4k | 32 | 21 | 4 | ||
4,1k | 30 | 52 | 3 | ||
Как я клонировал Томми Версетти, или Запускаем GUI/GPU-приложения в Kubernetes | 4,2k | 29 | 34 | 5 | |
Устанавливаем Kubernetes-платформу Deckhouse в закрытом окружении. Пошаговая инструкция | 2,5k | 25 | 27 | 4 | |
Настройка LDAP-аутентификации в кластере Kubernetes под управлением Deckhouse | 2,7k | 24 | 36 | 4 | |
Создание Kubernetes-кластера на пальцах, или Почему это не сложно | 18k | 18 | 184 | 12 | |
15k | 16 | 52 | 21 | ||
6,3k | 16 | 37 | 5 | ||
1,9k | 12 | 22 | 3 | ||
2,7k | 11 | 23 | 8 | ||
5,2k | 11 | 46 | 21 | ||
5,3k | 10 | 57 | 5 | ||
4,8k | 10 | 44 | 16 | ||
5,4k | 10 | 66 | 10 | ||
Вжух — и собралось, или Как я ускорял сборку UI на базе kubernetes + jenkins и yarn + nx | 3,1k | 9 | 25 | 7 | |
4k | 8 | 22 | 4 | ||
8,9k | 7 | 60 | 0 | ||
2,5k | 6 | 21 | 9 | ||
5,1k | 6 | 39 | 7 | ||
Создаём стенд для бэкенд-разработки на Bare Metal (и не только). Часть 1 | 5,1k | 4 | 44 | 10 |
Подводя итоги, мы обнаружили, что среди статей-участников не было близнецов или клонов на уровне темы. Это были очень разные материалы о стеках и кейсах применения Kubernetes. Тут была и Rust-разработка, и геймдев, и нечто совершенно девопсовое. При этом в каждой статье был крутой набор инсайтов по узкой теме. Такие не откопать даже в самых запылённых уголках официальной доки и man pages. Познавать их до нашего сезона пришлось бы через собственные шишки, боль и тлен.
Нашим читателям явно нравится техническая душнота (в лучшем смысле этого слова), — особенно хорошо заходят гайды с примерами из личного опыта. В среднем более высокую оценку получают длинные статьи — this is the Хабр way. Например, в постах в топе-3 в среднем ~12 700 знаков.
Слово авторам
Нескольких участников сезона мы попросили порассуждать о будущем контейнеризации, поделиться самыми забавными случаями из личной практики или дать совет тем, кто только начинает работать с Kubernetes. Вот что они нам рассказали.
Какие вызовы стоят перед Kubernetes и теми, кто его администрирует?
Сергей Ермейкин aka mistikan, Junior DevOps Engineer, Lad,
автор поста «Как я клонировал Томми Версетти, или Запускаем GUI/GPU приложения в Kubernetes»
Перечислю топ вызовов, которые, на мой взгляд, стоят сейчас перед Kubernetes:
• Безопасность кластера и запускаемых в нём приложений. CRI нас спасает, но существуют различные векторы атаки для его обхода. Никто не должен забывать, что мы запускаем и как мы запускаем.• Рождение платформ DeckHouse, OpenShift. Kubernetes — оркестратор контейнеров, а отдельно от него стоят сети, политика безопасности, мониторинг и так далее. И здесь, конечно же, Kubernetes должен быть лучшим в оркестрации, а платформы сами разберутся в своих вызовах.
• Операторы. Команды применяют Kubernetes для управления своей инфраструктурой. И если раньше они просто управляли инстансом в Terraform и подготавливали виртуальные машины в Ansible, то с развитием «операторной темы» подход изменился. Теперь пишется оператор, применяется CRD, а K8S обслуживает. То есть оркестратор стал некой платформой и источником правды о сущностях в инфраструктуре.
А тем, кто работает с Kubernetes, я желаю осваивать его с новых сторон и помогать сообществу становиться лучше — например, написав статью или предложив Merge Request с новой фичей!
Самый крутой инсайт о Kubernetes за последний год
На мой взгляд, совсем немного решений в open source и вне его имеют хорошую документацию, где в полной мере можно найти то или иное описание. Когда я сталкиваюсь с проблемой неясного происхождения, отправной точкой становятся документация и гугл, но зачастую ответов там нет. Поэтому в ход вступает следующая цепочка: анализ открытых и закрытых issue в репозитории, а после — анализ кода.
Я пришёл к выводу, что очень часто для эффективного и быстрого решения проблемы достаточно поглубже посмотреть в код. Код открывает любые тонкости и нюансы работы, а также помогает выстроить цепочку, ведущую от проблемы к истинной причине её возникновения. Не бойтесь залезть в код поглубже, потому что это позволит выстроить и протестировать различные теории возникновения проблемы быстрее, а также позволит лучше понять, как работает тот или иной компонент k8s.
Пост softError особенно впечатлил наших партнёров #CloudMTS:
Иван Гулаков
техлид команды DevOps в #CloudMTS
«Из всех статей сезона мне больше всего понравилась „Стеклянная луковица dns внутри k8s“ от @softError В ней очень круто рассказано о двух видах резолверов в Golang: нативном и с трансляцией в C, — я сам не знал об этой возможности до прочтения статьи. Тот случай, когда автор плотно разобрался в теме и смог доходчиво донести информацию до читателей».
Самое сложное и самое приятное в работе с Kubernetes
Самое сложное в работе с Kubernetes — понять, как он устроен, для чего нужен и как его использовать. А самое крутое и приятное в том, что он даёт огромные возможности по гибкой настройке контейнеров: с ролевыми моделями, пространствами (неймспейсами) для каждого приложения или проекта. А главное, берёт на себя все сложности масштабирования, балансирования и позволяет очень удобно управлять приложениями в контейнерах (как дома, так и в больших высоконагруженных системах), используя один и тот же подход.
Совет тем, кто только начинает изучать Kubernetes
От блога Слёрма и Southbridge в сезоне Kubernetes участвовал пост «Собеседование мечты: как девопсу попасть на работу». Для статьи об итогах сезона редакция блога попросила комментарий у эксперта:
pauljamm, архитектор Yandex Cloud
Комментарий подготовлен при поддержке редактора Слёрма Asiiat_Gadaborsheva.
С чего начать. Для начала стоит на каком-нибудь готовом кластере K8s познакомиться с основными понятиями и абстракциями: Pod, Deployment, Service, Ingress и так далее. Я рекомендую посмотреть в сторону облачных провайдеров. Далее — читать официальную документацию, смотреть полезные обучающие видео на YouTube, читать статьи на Хабре.
Сколько времени заложить на обучение. Смотря какая у человека цель — администрировать кластеры или запускать приложения. Если берём разработчика, который хочет разобраться во всех особенностях, которые есть у Kubernetes с точки зрения запуска приложения, то базово можно заложить пару недель по два часа в день. Сроки примерные — понятно, что количество часов для каждого конкретного человека сложно измерить.
А если необходимо администрировать кластер K8s, то дополнительно нужно разобраться и с тем, как кластер работает, как он запускается, настраивается, чинится. И конечно, как обучить коллег правильно работать с кластером, — для этого важно очень хорошо представлять, что там внутри есть. Тут я заложил бы ещё пару недель с такой же интенсивностью. Вообще, чтобы вписать в резюме, что вы знакомы с K8s, потребуется месяц практики. А чтобы пройти моё собеседование для джунов — месяца четыре как минимум.
Для чего вообще кубы нужны сейчас. Kubernetes — это не только и даже не столько «запускалка» контейнеров. Он может гораздо больше. Например, крупные компании сейчас строят инфраструктурную платформу на k8s, которая решает кучу задач: от управления контейнерами до администрирования всей облачной инфраструктуры.
Слово партнёру сезона Kubernetes
Kubernetes — новый Linux. Проникновение контейнерных технологий становится всё шире, при этом порог входа в них постоянно снижается. Kubernetes превращается из инструмента для больших компаний в привычную часть IT-ландшафта.
У Gartner есть популярный график — Hype Cycle, кривая, которая отражает процесс развития, через который проходит любая инновационная технология: от стадии хайпа и завышенных ожиданий до продуктивного использования.
На мой взгляд, такие проекты, как сезон Kubernetes на Хабре, помогают этой технологии быстрее пройти этапы завышенных ожиданий и разочарования. Чем больше мы делимся друг с другом реальными проблемами и успехами при эксплуатации технологии, без маркетинговой пыли и громких заявлений, тем ближе мы становимся к получению реальной пользы от внедрения.
Предполагаю, что в ближайшем будущем всё больше внимания при работе с Kubernetes будут уделять безопасности. Чем больше компаний начинает применять K8s в продакшен-среде, тем острее встают вопросы их защиты. Речь идет как о появлении новых продуктов в области обеспечении безопасности кластеров и инфраструктуры вокруг них, так и о внимании регуляторов.
Ещё один тренд — использование managed-кластеров. По отчётам Datatog, более 90% кластеров Kubernetes были развёрнуты у облачных провайдеров. Это логичный шаг для компаний, которые не хотят инвестировать в приземление новых технологий слишком много и готовы переложить сложности управления кластерами на сервис-провайдеров.
Наконец, я думаю, что компании будут строить больше гибридных и мультиоблаков, в том числе с кластерами Kubernetes. Далеко не все готовы полностью переносить свои нагрузки к одному облачному провайдеру. Поэтому среди крупных компаний популярен подход, при котором они развёртывают кластеры и у нескольких провайдеров, и локально.
Победитель
Наконец-то самое главное — чествуем победителя. Итак, удивляйтесь, если, конечно, не стали сразу раскрывать таблицу результатов. Новенький MacBook и 30 000 рублей в качестве стимула на написание ещё одной полезной статьи уходит пользователю onegreyonewhite. В своей статье «Не куб, а кубик: kubernetes для не-highload» он рассказал, какие задачи энтерпрайзный, на первый взгляд, Kubernetes может эффективно решать в небольших компаниях. Видимо, такой кубик-масипуська показался хабровчанам очень милым пушистиком — за него отдали голоса 46 читателей. Кстати, лидирует эта статья и по количеству комментариев — тут их аж 32.
Слава Слово победителю.
Я давно работаю с k3s. Было время, когда я искал инструмент, который легко сможет освоить даже джун — так я познакомился с Rancher'ом (сейчас я, кстати, готовлю статью про его экосистему). Оттуда вышел и на k3s/rke. Недавно мы с коллегой как раз подбирали решение, на котором удобно учить разработчиков готовить свои песочницы. В связи с этой задачей снова всплыл k3s. А мне нравится вдохновлять людей на то, чтобы они использовали удобные инструменты и не боялись осваивать что-то новое. Так и родилась идея статьи, с которой я участвовал в сезоне Kubernetes.
Думаю, что узкоспециализированные версии будут появляться у Kubernetes и дальше. Да, Kubernetes — это универсальное решение, но как только выходишь за рамки общих задач, сразу появляется потребность в кастомизации.
Сейчас очень много софта пишется с расчётом на контейнеризацию. Кубер изначально создавался, чтобы облегчать боль автоматизации и поддержки. Поэтому было понятно, что должно появиться какое-то решение для небольших компаний и сетей. Кроме того, разработчикам тоже нужны песочницы, которые легко поднимать и поддерживать. Эти потребности и закрывают k3s, k0s и прочие k.
Если какая-то потребность возникает у одной или двух компаний, то новая ветка не появится. Но когда таких компаний и инженеров много, рождаются продукты, подобные k3s. Это эволюция.
Мне кажется, скоро появятся продукты, ориентированные на выполнение Job и работы с машинным обучением, потому что в этой сфере ещё очень много костылей, нет единого удобного решения.
Я люблю кубик за автоматизацию и гибкость. Сама философия очень крутая и понятная разработчику: есть решение по управлению контейнерами и сетями, а остальное крутится вокруг них. И есть интерфейс для расширения в виде CRD и событий, чтобы решить практически любую задачу автоматизации. Это прям DevOps way! И жирный аргумент в пользу любви к кубику.
Есть и другие решения для управления контейнерами и сетями, но Kubernetes захватил мир как раз за счёт возможностей плагинов. Любую узкую задачу можно решить существующим оператором, если таковой есть. А если нет, написать свой, — я как раз писал статью об этом. Большинство аналогов направлены на простое развёртывание контейнеров, а Kubernetes реализует целую философию и решает уже комплекс проблем.
Боль обычно вызывают порог входа, поддержка и чересчур богатое разнообразие решений.
Про порог входа я и в статье упомянул. Джуна научить работать в кубере осознанно, довольно сложно на практике. Я радуюсь, когда кто-то говорит про успешный успех в этом вопросе, но у меня вот не так всё круто. Поэтому без инструментов типа интуитивно понятного гуя с кнопкой «дай мне кластер» не представляю работу команды. Отчасти эта проблема решается такими штуками, как k3s, rancher, deckhouse, managed-решения.
Поддержка тоже интересный вопрос. Чем больше масштабируемость, тем больше «подвижных частей», которые могут сломаться, и надо понимать, как они работают. Поэтому кажется — а что там поддерживать? Но прилетает чёрный лебедь — и всё как у Шелдона Купера: «Why? Why?! Oh, that's why...»
Это дискуссионные вопросы, но обсуждение появляется там, где есть проблема. Не сказать, что меня что-то из этого заставляет рыдать от отчаяния, но жжение ниже поясницы вызывает довольно часто.
Выводы
Вот так и завершился наш сезон Kubernetes. Читатели Хабра получили новый набор полезных и крутых постов по узкой теме, с чем их и поздравляем. А мы продолжим развивать формат сезонов, так что держите руку на пульсе. Может быть, в следующий сезон экспертный текст напишете уже вы.