С 29 декабря по 24 февраля на Хабре прошёл сезон Kuberbetes. Вместе с партнёром, #CloudMTS, мы вдохновляли хабраавторов публиковать статьи по k8s и контейнерам в соответствующем хабе — глубокие, полезные, с техническими подробностями. 

Пришло время подвести итоги и узнать, кто получит новенький MacBook и грант в 30 000 рублей на то, чтобы написать ещё одну классную статью. Награждаем не только победителя: участники конкурса получат в подарок от #CloudMTS гранты на использование сервисов компании.

О хабе 

Хаб Kubernetes появился в 2017 году, и за это время в нём опубликовали уже более 1000 статей. Самые частые пересечения происходят с хабами Виртуализация, Системное администрирование, Облачные сервисы и DevOps, а топовые статьи набрали до 75 тысяч просмотров. Но мы всё-таки тут собрались не обсуждать хаб, а выяснить, кто же стал чемпионом-статьеписцем. 

Итоги сезона

Подводя итоги, мы обнаружили, что среди статей-участников не было близнецов или клонов на уровне темы. Это были очень разные материалы о  стеках и кейсах применения 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 за последний год

arkashaErema, DevOps-инженер

автор поста «Вам не нужен свой Kubernetes»

На мой взгляд, совсем немного решений в open source и вне его имеют хорошую документацию, где в полной мере можно найти то или иное описание. Когда я сталкиваюсь с проблемой неясного происхождения, отправной точкой становятся документация и гугл, но зачастую ответов там нет. Поэтому в ход вступает следующая цепочка: анализ открытых и закрытых issue в репозитории, а после — анализ кода.

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

Пост arkashaErema особенно впечатлил наших партнёров #CloudMTS:

Иван Гулаков

техлид команды DevOps в #CloudMTS

«Из всех статей сезона мне больше всего понравилась „Стеклянная луковица dns внутри k8s“ от arkashaErema. В ней очень круто рассказано о двух видах резолверов в Golang: нативном и с трансляцией в C, — я сам не знал об этой возможности до прочтения статьи. Тот случай, когда автор плотно разобрался в теме и смог доходчиво донести информацию до читателей».

Самое сложное и самое приятное в работе с Kubernetes

General_RJ-45, DevOps-MLOps-инженер

автор поста «Не только работой едины: ARK+K3S+MetalLB»

Самое сложное в работе с Kubernetes — понять, как он устроен, для чего нужен и как его использовать. А самое крутое и приятное в том, что он даёт огромные возможности по гибкой настройке контейнеров: с ролевыми моделями, пространствами (неймспейсами) для каждого приложения или проекта. А главное, берёт на себя все сложности масштабирования, балансирования и позволяет очень удобно управлять приложениями в контейнерах (как дома, так и в больших высоконагруженных системах), используя один и тот же подход.

Совет тем, кто только начинает изучать Kubernetes

От блога Слёрма и Southbridge в сезоне Kubernetes участвовал пост «Собеседование мечты: как девопсу попасть на работу». Для статьи об итогах сезона редакция блога попросила комментарий у эксперта:

pauljamm, архитектор Yandex Cloud

Комментарий подготовлен при поддержке редактора Слёрма Asiiat_Gadaborsheva.

С чего начать. Для начала стоит на каком-нибудь готовом кластере K8s познакомиться с основными понятиями и абстракциями: Pod, Deployment, Service, Ingress и так далее. Я рекомендую посмотреть в сторону облачных провайдеров. Далее — читать официальную документацию, смотреть полезные обучающие видео на YouTube, читать статьи на Хабре.

Сколько времени заложить на обучение. Смотря какая у человека цель — администрировать кластеры или запускать приложения. Если берём разработчика, который хочет разобраться во всех особенностях, которые есть у Kubernetes с точки зрения запуска приложения, то базово можно заложить пару недель по два часа в день. Сроки примерные — понятно, что количество часов для каждого конкретного человека сложно измерить.

А если необходимо администрировать кластер K8s, то дополнительно нужно разобраться и с тем, как кластер работает, как он запускается, настраивается, чинится. И конечно, как обучить коллег правильно работать с кластером, — для этого важно очень хорошо представлять, что там внутри есть. Тут я заложил бы ещё пару недель с такой же интенсивностью. Вообще, чтобы вписать в резюме, что вы знакомы с K8s, потребуется месяц практики. А чтобы пройти моё собеседование для джунов — месяца четыре как минимум.

Для чего вообще кубы нужны сейчас. Kubernetes — это не только и даже не столько «запускалка» контейнеров. Он может гораздо больше. Например, крупные компании сейчас строят инфраструктурную платформу на k8s, которая решает кучу задач: от управления контейнерами до администрирования всей облачной инфраструктуры.

Слово партнёру сезона Kubernetes

Родион Цалкин,

ведущий менеджер по продукту Containerum Kubernetes Service

Kubernetes — новый Linux. Проникновение контейнерных технологий становится всё шире, при этом порог входа в них постоянно снижается. Kubernetes превращается из инструмента для больших компаний в привычную часть IT-ландшафта. 

У Gartner есть популярный график — Hype Cycle, кривая, которая отражает процесс развития, через который проходит любая инновационная технология: от стадии хайпа и завышенных ожиданий до продуктивного использования.

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

Предполагаю, что в ближайшем будущем всё больше внимания при работе с Kubernetes будут уделять безопасности. Чем больше компаний начинает применять K8s в продакшен-среде, тем острее встают вопросы их защиты. Речь идет как о появлении новых продуктов в области обеспечении безопасности кластеров и инфраструктуры вокруг них, так и о внимании регуляторов. 

Ещё один тренд — использование managed-кластеров. По отчётам Datatog, более 90% кластеров Kubernetes были развёрнуты у облачных провайдеров. Это логичный шаг для компаний, которые не хотят инвестировать в приземление новых технологий слишком много и готовы переложить сложности управления кластерами на сервис-провайдеров. 

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

Победитель

Наконец-то самое главное — чествуем победителя. Итак, удивляйтесь, если, конечно, не стали сразу раскрывать таблицу результатов. Новенький MacBook и 30 000 рублей в качестве стимула на написание ещё одной полезной статьи уходит пользователю onegreyonewhite. В своей статье «Не куб, а кубик: kubernetes для не-highload» он рассказал, какие задачи энтерпрайзный, на первый взгляд, Kubernetes может эффективно решать в небольших компаниях. Видимо, такой кубик-масипуська показался хабровчанам очень милым пушистиком — за него отдали голоса 46 читателей. Кстати, лидирует эта статья и по количеству комментариев — тут их аж 32. 

Слава Слово победителю.

onegreyonewhite

devops-евангелист и специалист широкого профиля в ВСТ Консалтинг

Я давно работаю с 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. Читатели Хабра получили новый набор полезных и крутых постов по узкой теме, с чем их и поздравляем. А мы продолжим развивать формат сезонов, так что держите руку на пульсе. Может быть, в следующий сезон экспертный текст напишете уже вы.