С 29 декабря по 24 февраля на Хабре прошёл сезон Kuberbetes. Вместе с партнёром, #CloudMTS, мы вдохновляли хабраавторов публиковать статьи по k8s и контейнерам в соответствующем хабе — глубокие, полезные, с техническими подробностями.  Пришло время подвести итоги и узнать, кто получит новенький MacBook и грант в 30 000 рублей на то, чтобы написать ещё одну классную статью. Награждаем не только победителя: участники конкурса получат в подарок от #CloudMTS гранты на использование сервисов компании.  Хаб Kubernetes появился в 2017 году, и за это время в нём опубликовали уже более 1000 статей. Самые частые пересечения происходят с хабами Виртуализация, Системное администрирование, Облачные сервисы и DevOps, а топовые статьи набрали до 75 тысяч просмотров. Но мы всё-таки тут собрались не обсуждать хаб, а выяснить, кто же стал чемпионом-статьеписцем.  Текст Автор Просмотры Рейтинг Закладки Комментарии Не куб, а кубик: kubernetes для не-highload onegreyonewhite 11k 46 104 32 Мониторинг межсервисного взаимодействия Kubernetes с помощью протокола NetFlow trublast 4,5k 44 42 8 Миграция приложения из OpenShift в «ванильный» Kubernetes djerohn 3,4k 32 21 4 Стеклянная луковица dns внутри k8s softError 4,1k 30 52 3 Как я клонировал Томми Версетти, или Запускаем GUI/GPU-приложения в Kubernetes mistikan 4,2k 29 34 5 Устанавливаем Kubernetes-платформу Deckhouse в закрытом окружении. Пошаговая инструкция Zhbert 2,5k 25 27 4 Настройка LDAP-аутентификации в кластере Kubernetes под управлением Deckhouse zimmermann 2,7k 24 36 4 Создание Kubernetes-кластера на пальцах, или Почему это не сложно haoshand 18k 18 184 12 Вам не нужен свой Kubernetes softError 15k 16 52 21 Когда хочется больше: пишем кубовый оператор onegreyonewhite 6,3k 16 37 5 Kyverno — замена PodSecurityPolicy или нечто большее? ya-makariy 1,9k 12 22 3 Не только работой едины: ARK+K3S+MetalLB General_RJ-45 2,7k 11 23 8 Kubernetes через грабли, или Внедрение в университете Fitrager 5,2k 11 46 21 Разбираемся в нюансах создания оператора на golang deepdive 5,3k 10 57 5 KubEnv — простое управление конфигами Kubernetes Ryder95 4,8k 10 44 16 Раскатка k8s 1.26 ansible+jenkins itoracle 5,4k 10 66 10 Вжух — и собралось, или Как я ускорял сборку UI на базе kubernetes + jenkins и yarn + nx softError 3,1k 9 25 7 Собеседование мечты: как девопсу попасть на работу Lika_Chernigo 4k 8 22 4 Релизный цикл ПО для самых маленьких Maxilect 8,9k 7 60 0 Как переехать в облака и не остаться без штанов blognaumen 2,5k 6 21 9 Как создать cloud-init-шаблон ОС Astra Linux в Proxmox toxella 5,1k 6 39 7 Создаём стенд для бэкенд-разработки на Bare Metal (и не только). Часть 1 Surf_Studio 5,1k 4 44 10  Подводя итоги, мы обнаружили, что среди статей-участников не было близнецов или клонов на уровне темы. Это были очень разные материалы о  стеках и кейсах применения Kubernetes. Тут была и Rust-разработка, и геймдев, и нечто совершенно девопсовое. При этом в каждой статье был крутой набор инсайтов по узкой теме. Такие не откопать даже в самых запылённых уголках официальной доки и man pages. Познавать их до нашего сезона пришлось бы через собственные шишки, боль и тлен. Нашим читателям явно нравится техническая душнота (в лучшем смысле этого слова), — особенно хорошо заходят гайды с примерами из личного опыта. В среднем более высокую оценку получают длинные статьи — this is the Хабр way. Например, в постах в топе-3 в среднем ~12 700 знаков. Нескольких участников сезона мы попросили порассуждать о будущем контейнеризации, поделиться самыми забавными случаями из личной практики или дать совет тем, кто только начинает работать с Kubernetes. Вот что они нам рассказали. автор поста «Как я клонировал Томми Версетти, или Запускаем 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, — я сам не знал об этой возможности до прочтения статьи. Тот случай, когда автор плотно разобрался в теме и смог доходчиво донести информацию до читателей». автор поста «Не только работой едины: ARK+K3S+MetalLB» Самое сложное в работе с Kubernetes — понять, как он устроен, для чего нужен и как его использовать. А самое крутое и приятное в том, что он даёт огромные возможности по гибкой настройке контейнеров: с ролевыми моделями, пространствами (неймспейсами) для каждого приложения или проекта. А главное, берёт на себя все сложности масштабирования, балансирования и позволяет очень удобно управлять приложениями в контейнерах (как дома, так и в больших высоконагруженных системах), используя один и тот же подход. От блога Слёрма и Southbridge в сезоне Kubernetes участвовал пост «Собеседование мечты: как девопсу попасть на работу». Для статьи об итогах сезона редакция блога попросила комментарий у эксперта: Комментарий подготовлен при поддержке редактора Слёрма Asiiat_Gadaborsheva.  С чего начать. Для начала стоит на каком-нибудь готовом кластере K8s познакомиться с основными понятиями и абстракциями: Pod, Deployment, Service, Ingress и так далее. Я рекомендую посмотреть в сторону облачных провайдеров. Далее — читать официальную документацию, смотреть полезные обучающие видео на YouTube, читать статьи на Хабре. Сколько времени заложить на обучение. Смотря какая у человека цель — администрировать кластеры или запускать приложения. Если берём разработчика, который хочет разобраться во всех особенностях, которые есть у Kubernetes с точки зрения запуска приложения, то базово можно заложить пару недель по два часа в день. Сроки примерные — понятно, что количество часов для каждого конкретного человека сложно измерить. А если необходимо администрировать кластер K8s, то дополнительно нужно разобраться и с тем, как кластер работает, как он запускается, настраивается, чинится. И конечно, как обучить коллег правильно работать с кластером, — для этого важно очень хорошо представлять, что там внутри есть. Тут я заложил бы ещё пару недель с такой же интенсивностью. Вообще, чтобы вписать в резюме, что вы знакомы с K8s, потребуется месяц практики. А чтобы пройти моё собеседование для джунов — месяца четыре как минимум. Для чего вообще кубы нужны сейчас. Kubernetes — это не только и даже не столько «запускалка» контейнеров. Он может гораздо больше. Например, крупные компании сейчас строят инфраструктурную платформу на k8s, которая решает кучу задач: от управления контейнерами до администрирования всей облачной инфраструктуры. ведущий менеджер по продукту 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.  Слава Слово победителю.  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. Читатели Хабра получили новый набор полезных и крутых постов по узкой теме, с чем их и поздравляем. А мы продолжим развивать формат сезонов, так что держите руку на пульсе. Может быть, в следующий сезон экспертный текст напишете уже вы.