С 29 декабря 2022 до 24 февраля 2023 Хабр вместе с #CloudMTS запускает сезон Kubernetes — конкурс технических статей о K8s, оркестрации и управлении контейнерами. Это третий сезон Хабра: летом и осенью мы уже неслабо продвинули пачку крутейших хардкорных текстов о Java и Data Mining. Теперь пришла пора разобрать по косточкам Kubernetes и относящиеся к нему DevOps-практики.
UPD. Сезон закончился, итоги можно посмотреть в этой статье.
Зачем это нужно
Максимальные просмотры на Хабре традиционно набирают универсальные материалы, понятные и полезные всем. А вот узкоспециальные и технически сложные статьи как правило получают меньше внимания: просто в силу того, что интересны не всем. И тут нет заговора — чисто тервер.
Но мы всегда топим за хардкор, метровые листинги и увлекательную техническую душнину — на том и стоит Хабр. Такие статьи мы и будем дополнительно продвигать в рамках сезона: сложные, интеллектуальные, практичные, узкоспециализированные — про Kubernetes и его использование в контейнерной инфраструктуре. Победит тот, чья статья получит самый большой рейтинг.
Что по призам и славе
Зал славы рок-н-ролла. Хабр выдаст всем авторам плашку «Участник сезона Kubernetes», а победителю достанется значок «Победитель сезона Kubernetes» и дополнительный инвайт.
Грант от спонсора на 30 000 рублей для подготовки ещё одной классной статьи получит победитель сезона. Если на новую статью нет времени, грант можно передать другому участнику — так было в сезоне Java.
MacBook от спонсора. Автору самой рейтинговой статьи достанется Apple MacBook Air — вот такой, как на картинке.
Правила сезона
Почти такие же, как и раньше — но с поправкой на тему.
Побеждает пост с наивысшим рейтингом. Голосовать за лучшую статью можно на протяжении всего сезона, а после его завершения мы объявим результаты.
Один автор может прислать сколько угодно заявок. Чем больше статей, тем выше шанс привлечь внимание читателей и победить. Принимаются не только новые посты, но и старые тексты, опубликованные после 1 декабря 2022. Последний день приёма заявок — 24 февраля 2023.
Участвовать могут все — даже авторы из «Песочницы». Отличная возможность привлечь максимум внимания к вашему первому посту и сразу попасть «в основу».
Только технохардкор. Мы хотим глубокого погружения в технические, архитектурные и процессные детали, неожиданные решения и прочие межпланетные дела.
Kubernetes в центре внимания, а технологии важнее эмоций. Пост должен быть про применение Kubernetes, а не про DevOps-практики в целом или виртуализацию. Если опытный инженер или разработчик, имеющий дело с контейнерами, узнает из вашего поста что-то новое и полезное — это тот самый технохардкор.
Без лишней рекламы или антирекламы. Можно упоминать свою компанию, но не воевать с конкурентами или на всю катушку пиарить своё супер-пупер-решение. Заявки отсматриваем вручную, так что no pasaran.
Зачем продвигать именно статьи про Kubernetes
Вовремя попавшаяся статья с описанием технических подробностей системы или примерами решения сложных вопросов могут сэкономить кучу ресурсов разработки, времени и денег. Для примера мы собрали несколько кейсов из практики #CloudMTS: как ребята фиксили неполадки, творчески использовали операторы K8s и баг-репортили в Red Hat. Часть кейсов — из практики команды, которая работает над внутренней инфраструктурой, а часть — от команды внешнего продукта, Containerum Kubernetes Service (CKS).
История #1. Скрытые механики продукта, о которых лучше знать заранее
Тяжело быть первопроходцем в поиске багов распространённых на рынке решений — и конечно, статья или выступление на конференции о том, как с болью найденный тобою баг фиксил кто-то другой, могла сберечь кучу нервов.
Итак, у нас есть департамент кибербезопасности, который разрабатывает систему по комплексному засекьюриванию кластеров. Эта система сканирует образы и запущенные контейнеры, мониторит трафик — в общем, делает всё, чтобы злоумышленники не могли нанести никакого вреда.
В один прекрасный момент мы заинсталлили это решение в свою DEV-среду для пробной обкатки. Пару дней всё прекрасно работало, однако потом у нас начали жутко течь по ресурсам мастер-ноды, при этом мы не вносили никакие изменения в конфигурацию самого кластера, да и профиль нагрузки от запущенных бизнесовых приложений особо не менялся. На графиках загрузки нод в Grafana не было каких-то характерных всплесков, нагрузка росла линейно, пока CPU и RAM машины не утилизировались почти под 100%. Основным виновником торжества был kube-apiserver, он поедал какое-то совершенно неадекватное количество ресурсов для кластера подобного размера.
Мы долго не могли понять, в чём дело, и почти случайно нашли в аудит-логах кластера, что у нас постоянно валятся validation-хуки: судя по записям, один из них циклически не мог обработать обращение к ресурсу pods/attach. Потом выяснилось, что этот хук связан с вышеупомянутой системой от департамента кибербезопасности. Начав копать дальше, мы обнаружили, что проблема связана с работой Docker-in-Docker-задачи в GitLab-раннере, который использовался для интеграционных тестов. Во время работы пайплайна раннер генерировал те самые обращения к ресурсу, по которым мы видели ошибку в логах.
Теперь паззл сложился: некоторое время баг никак не проявлял себя, так как сбойный ивент никто не триггерил. Но когда запустилось большое количество интеграционных тестов, раннеру с хуком поплохело. В итоге kube-api получил очередь задач, которую никак не мог адекватно разобрать и начал течь по ресурсам, а дальше поплохело уже и его соседям на ноде. На машины, которым повезло меньше, приходил ещё и OOM, что добавляло дополнительных проблем с доступностью кластера.
В итоге мы вычислили виновника, отключили обработку сбойного ивента в манифесте хука и минут через 30 состояние кластера пришло в норму. Ну а дальше рассказали коллегам о проблеме, они смогли воспроизвести её и через некоторое время выпустили заплатку.
История #2. Для Kubernetes можно найти много интересных применений
Типовые паттерны работы с привычными инструментами — это хорошо и правильно, но всегда можно попытаться выйти за рамки привычного использования решений и задействовать их каким-то хитрым способом. Мы любим и читать про такие хаки, и придумывать их. Вот вам небольшая, но гордая история:)
Весь Kubernetes работает на событийной модели, то есть он сам автоматически постоянно приводит состояние отдельных компонентов к тому состоянию, которое описано в манифесте. На этой же модели строятся и все операторы, дополнительные контроллеры для K8s, которые используют собственные API — CRD (Custom Resource Definition) — чтобы хранить собственные спеки CR (Custom Resource) и на их основе создавать новые ресурсы в кластере или управлять жизненным циклом существующих.
И мы подумали: а почему бы не воспользоваться таким чудесным инструментом для унификации обслуживания всего и вся и перевести всё на готовые операторы? Дело в том, что у нас была проблема: часть инфраструктуры находится вне Kubernetes, и тащить её туда мы не хотим по ряду причин. Однако управлять ею с помощью K8s тоже хочется, так как это сразу даёт ряд преимуществ:
Автоматическое и непрерывное приведение инфраструктуры к необходимому виду. В отличие от стандартных IaC-подходов в таком случае нам не нужно, чтобы кто-то нажимал на кнопочку деплоя.
Единая точка правды: статусы всех интересующих нас подконтрольных сущностей мы можем посмотреть в одном месте, не бегая по куче ВМ, клиентов, Git-репозиториев.
Благодаря единой точке правды мы можем легко и быстро делать бэкапы нашего K8s (etcd-снапшоты) и так же легко восстанавливаться из них. А ещё после восстановления операторы в K8s самостоятельно настроят все необходимые сущности вовне, и нам не придётся дополнительно что-то запускать из других мест.
Подумав, мы сами написали несколько операторов для закрытия всех своих потребностей:
Создание индекс-паттернов для Kibana.
Создание записей в нашем DNS (External DNS нам не подошёл, потому что он не умеет работать с тем сервером, который используем мы).
Управление Kafka: создание пользователей, топиков, настройка ACL и так далее.
Правда, у подобного подхода есть и минус — это довольно затратно с точки зрения человеческих ресурсов, которые необходимы для написания и отладки самих операторов. Иногда лучше написать парочку условных плейбуков и на этом остановиться, если задача не требует серьёзного масштабирования.
История #3. Рассказы о рабочих моментах помогают избегать ошибок
Хорошее тестирование помогает не только проверить корректность решения, но и, эмулируя поведение клиента, попытаться выстрелить себе в ногу с помощью доступных в админке средств. Такие кейсы, конечно, редкость — в открытом доступе их практически не найти, потому что они могут касаться деталей реализации продукта. И тем выше их ценность: зная подобные нюансы, можно изначально учесть их в архитектуре своего решения. Рассказываем, как мы успешно обрушили один из кластеров в Containerum Kubernetes Service:)
В Kubernetes есть сущности, которые отвечают за проброс трафика извне внутрь. Эти сервисные сущности бывают трёх типов: кластер IP, нод-порт и load balancer — и собираются они как матрёшка, от самой маленькой до самой большой. Под них выделяются CIDR-диапазоны IP-адресов, которые не должны пересекаться с диапазонами адресов, зарезервированных для подов и сервисов K8s-кластера, сетей, в которых находятся виртуальные машины, сервера и т. п.
В процессе разработки мы решили попробовать поломать систему — и нам это удалось. Мы создали сервис, в externalIPs которого указали адрес одной из рабочих нод. На всех узлах кластера создались IPVS-маршруты, которые перенаправляли трафик с заданного пользователем IP-адреса на те ноды, где запущены поды, принимающие трафик с сервиса.
При попытке определить MAC-адрес ноды, которым воспользовался пользователь, мы периодически получали адреса с соседних нод. В итоге эта worker-нода не могла нормально взаимодействовать с kube-apiserver, а при попытке зайти на неё по SSH мы каждый раз попадали на случайную виртуальную машину, входящую в кластер.
В общем, новый сервис был благополучно растиражирован по всему кластеру с единым адресом. И кластер, естественно, начал сходить с ума: он пытается отправлять запросы, а они приходят на случайные машины (адрес-то во всех используется один). В итоге мы прибили созданный с ошибкой сервис и это подобие кольца разорвалось.
Казалось бы, Kubernetes должен такие ситуации детектировать и запрещать создание ресурсов, которые будут ломать кластер. Но нет, проверяет он не всё. А потому прямо сейчас мы проводим большую работу, чтобы выявить все подобные слепые пятна K8s и наладить за ними контроль через admission-контроллер и OPA (Open Policy Agent).
Как подать заявку
Написать текст для хаба Kubernetes. Если сомневаетесь, подойдёт ли тема — можно спросить у @mimizavr.
При публикации добавить к посту тег «сезон kubernetes». Важно: можно прикрепить тег и к старому посту, если он опубликован с 1 декабря 2022 г. по 24 февраля 2023 г.
Дождаться проверки модератором. Если пост подойдёт под критерии сезона, мы отметим его специальной плашкой под заголовком и добавим в список под постом-анонсом. О результатах модерации отпишемся в личку.
И вот вы уже контейнеризованы и заоркестрированы.
Идеи для постов
Вот вам идеи от топового автора в хабе Kubernetes. Их можно взять в работу прямо так или использовать как отправную точку для своего творчества.
Сравнение отечественных дистрибутивов Kubernetes: Deckhouse, Штурвал, NEOMSA.
Практические кейсы использования service mesh: какие задачи были решены, в чём профит для бизнеса.
WASM и Kubernetes: как это работает, есть ли тут будущее.
Kubernetes — он для Dev или Ops? Все обычно говорят только про Ops. Какие инструменты помогают сделать его всё-таки более удобным/юзабельным и для Dev?
Cloud-native-подход к CI/CD в Kubernetes (реализуем весь цикл доставки софта полностью в контейнерах).
Мне лично всегда интересно читать, когда о каких-то сложных абстракциях K8s рассказывают просто, на понятных примерах из жизни. Вот пара подобных статей:
Ещё мне интересны инструкции для начинающих по развёртыванию K8s-кластера и т. п. темам.
Посты-участники
Не только работой едины — ARK+K3S+MetalLB.
Как-то играя в Ark, я захотел играть на своём сервере вместе с друзьями, и как раз под это дело у меня есть свой домашний сервер и выделенный IP, характеристик сервера более чем достаточно, в моём случае это Ryzen 7 1700X, 32Gb RAM и 1500Gb дисковой памяти. Как основу я взял контейнеризацию LXS и настроил внутри Ark сервер по первой инструкции, что нашёл в интернете, настроил service для Ark, чтобы руками его не запускать всё время.
Релизный цикл ПО для самых маленьких.
В продолжении нашей серии для начинающих айтишников о базовых идеях современной коммерческой разработки, поговорим о моделях релизов. Это очень обширная тема, но мы пройдёмся по верхам и исключительно с позиции разработчика. Мы не будем брать экзотические случаи, когда релизы относят на флешке, закрытой в специальном контейнере, или когда релиз ровно один — в конце разработки — и на нём всё заканчивается. Поговорим о популярном CI/CD, какую роль тут играет Kubernetes и почему фичи не сразу оказываются в проде.
Создаём стенд для бэкенд-разработки на Bare Metal (и не только). Часть 1.
Многим в начале DevOps-пути доверяют только настройку CI/CD. Но потом в один прекрасный день тимлид приходит с задачей развернуть инфраструктуру для бэкенд-разработки, и возникает ступор. Я прошёл ровно этот путь: в процессе накопил много полезной информации, сформировал инструкцию и теперь делюсь ею с вами. Расскажу, с чего начать, что ставить и как ко всему подступиться.
Как переехать в облака и не остаться без штанов
Каждый год мы прогнозируем потребность в ресурсах и, при необходимости, либо модернизируем существующее оборудование, либо закупаем новое. Пару лет назад мы решили расширять инфраструктуру в облака, так как требования к скорости, доступности, надёжности инфраструктуры и сервисов достаточно сильно возросли.
Правда, без предварительной аналитики и оценки возможных проблем можно довольно больно выстрелить себе в колено и потратить кучу времени, нервов и денег. Разберёмся, как переехать в облака и не остаться без штанов, на примере наших ошибок.
Как создать cloud-init шаблон ОС Astra Linux в Proxmox
Сloud-init — это программа для инициализации виртуальных машин, обычно применяющаяся в облачных платформах. Но использовать cloud-init можно и локально, например в Proxmox, который успешно поддерживает данную технологию.
Всё, что нам надо — cloud-init-образ нужной ОС. Данная статья применима для любого cloud-init-образа. Я покажу, как это делать на примере Astra Linux 1.7.
Вжух и собралось или как я ускорял сборку UI на базе kubernetes + jenkins и yarn + nx
С распространением практики доставки непрерывных обновлений время сборки приложений стало критически важным параметром как для разработчиков, так и для бизнеса компании в целом. В данной статье описан мой опыт ускорения Frontend пайплайна Jenkins в Kubernetes на базе yarn и nx.
Вам не нужен свой Kubernetes
Как DevOps инженер я имею опыт установки и поддержки vanilla kubernetes(k8s) на bare metal, опыт построения private cloud вокруг такого k8s, а также опыт использования различных public cloud таких как EKS (Amazon Managed Kubernetes), GKE (Google Managed Kubernetes), AKS (Azure Kubernetes Service). На данном этапе карьеры я очень часто тыкаю k8s, который развернут с помощью kops внутри AWS инфраструктуры.
Мониторинг межсервисного взаимодействия Kubernetes с помощью протокола NetFlow
Часто возникает ситуация, когда в кластере работает много взаимодействующих между собой сервисов, но из-за спонтанности разработки эти взаимодействия могут быть нигде не документированы. То есть ни команды разработки, ни команды эксплуатации доподлинно не знают, какие приложения куда обращаются, как часто, и какую нагрузку создают эти обращения. И когда возникает проблема с производительностью какого-то сервиса, не совсем понятно, на что нужно обратить внимание. В идеале хотелось бы иметь какую-то карту взаимодействия сервисов в Kubernetes, которая сама автоматически обновляется. Такую карту можно построить с помощью инструментов типа Istio и Cilium. Но иногда можно обойтись и более простыми решениями — например, NetFlow.
Когда хочется больше: пишем кубовый оператор
Итак, некоторое время назад я писал статью о том, как мы переехали на werf со скрипта. По большому счёту, это продолжение той истории. Задача встала такая: нужно максимально автоматизировано разворачивать свежее приложение на нескольких кластерах kubernetes, которое уже имеет обвязку для деплоя в виде werf. После некоторых изысканий и попыток использовать "коробочные" решения самой верфи и куба, я понял, что придётся написать собственный оператор, чтобы получить прям 100% покрытия всех "хотелок".
Настройка LDAP-аутентификации в кластере Kubernetes под управлением Deckhouse
Deckhouse — Kubernetes-платформа с открытым кодом, с помощью которой можно создавать идентичные Kubernetes-кластеры в любой инфраструктуре и автоматически управлять ими. Для проверки подлинности в Deckhouse используется модуль user-authn. Он настраивает единую систему аутентификации, интегрированную с Kubernetes и веб-интерфейсами других модулей — например, с Grafana. User-authn поддерживает несколько внешних провайдеров и протоколов аутентификации: GitHub, GitLab, Bitbucket Cloud, Crowd, LDAP и OIDC. В статье расскажу, как развернуть сервер LDAP и настроить через него доступ к приложению.
Разбираемся в нюансах создания оператора на golang
В данной статье я постарался изложить на что обратить внимание при написании оператора на golang и на нюансы, которые описываются вскользь или вовсе не описываются в официальном туториале или других статьях подобного вида.
Kubernetes через грабли или внедрение в университете
К Kubernetes мы присматривались два года. Изучали различные статьи, пытались его разворачивать, но после развертывания не понимали что делать дальше. Пока однажды мы не решили попробовать завернуть одну из систем в контейнер. Для оркестрации контейнера была выбрана система Docker Swarm, так как она проще, и тут возникла первая проблема – в выбранной системе была авторизация, а Docker Swarm проблема с сохранением сессии пользователя если контейнеров больше одного (мы использовали ADFS для авторизации в системе) – т.е. текущая сессия пользователя не сохранялась и при обновлении страницы выходила стартовая. Поиск различных решений сводил к одному – нужен Kubernetes с его Ingress контроллером, где есть «липкие сессии» (sticky session). При выборе дистрибутива было принято решение использовать «ванильный» k8s.
Kyverno — замена PodSecurityPolicy или нечто большее?
Меня зовут Макарий Балашов, я SRE в Ak Bars Digital. Наша команда занимается подготовкой и развитием инфраструктуры для команд разработки. В этой статье расскажу и покажу на примерах, как мы используем Kyverno — policy engine разработанный специально для Kubernetes.
Не куб, а кубик: kubernetes для не-highload
Может ли kubernetes сделать жизнь админов небольших и средних компаний проще или же это шайтан-машина для кровавого enterprise и оголтелых стартапов?Сейчас Kubernetes раскатывают все, кому не лень, для всего, что только может прийти в голову. Чаще всего там, где ему не место, но он развёрнут и используется, причина довольно прозаичная: обучение за счёт работадателя проектов. Все хотят получать больше, а для этого нужно соответствовать критериям из вакансий, где практически везде написаны эти 3 волшебных символа: K-8-S.
Создание Kubernetes-кластера на пальцах или почему это не сложно
Привет, меня зовут Руслан, я энтузиаст одного отдела искусственного интеллекта, занимаюсь автоматизацией процесса разработки и контролем за инфраструктурой внутри Kubernetes. Хочу детально рассмотреть развёртку Kubernetes-кластера, показать решения на возможные ошибки, ответы на которые пришлось довольно долго поискать. После окончания статьи вы будете знать, как создать кластер, который подойдет почти под любые задачи.
KubEnv — простое управление конфигами Kubernetes
На моей работе мы пользуемся Kubernetes, для наших задач это очень полезный инструмент, который снимает с DevOps-ов и разработчиков много головной боли (хотя про DevOps-ов не уверен, но в любом случае, мне с ним жить точно проще). Как и многие, мы используем микросерверный подход, наш продукт состоит из большого количества компонентов, и Kubernetes позволяет ими удобно управлять. К сожалению, специфика нашего продукта такова, что разворачивать приложение только на одном кластере не предоставляется возможным (данные пользователей обрабатываются на другом кластере). Я не уверен, насколько сильно я могу распространяться про нюансы, поэтому оставлю описание на этом уровне, хотя, конечно, хочу рассказать больше.
Раскатка k8s 1.26 ansible+jenkins
И вообще managed cluster своими руками за 1000 и один человеко-час. Недавнее масштабное обновление github (когда там часами не работало ничто) побудило меня поделиться своим опытом автоматизации установки k8s на bare metal. Итак. Задача: развернуть кластер kubernetes последней на данный момент версии 1.26 средствами CI/CD за минимальное время (на моем оборудовании около 3 минут), и вообще, начать с этого построение своих инструментов управления кластером.
Как я клонировал Томми Версетти, или запускаем GUI/GPU приложения в Kubernetes
Привет! Меня зовут Сергей Ермейкин, я Junior DevOps engineer в центре разработки IT-компании Lad. В моей первой статье на Хабре я расскажу про сборку своих GUI/GPU образов и покажу, как настроить хостовую и Kubernetes системы на примере игры GTA:VC. В детстве мне очень нравилось играть в неё: рассекать на PCJ-600, вновь и вновь повторять "миссию с вертолетиком", "летать" на Panzer. Сейчас я выступаю всего лишь в роли зрителя, наблюдая за скоростными прохождениями игры. В один из таких просмотров я задался вопросом: можно ли автоматизировать процесс прохождения и направить искусственный интеллект на игру для выполнения этой задачи? Или как запустить в кластере графическое приложение, которое использует ресурсы видеокарты? Поэтому в данной статье я подготовлю среду для обучения искусственному интеллекту.
Миграция приложения из OpenShift в «ванильный» Kubernetes
OpenShift, Rancher и другие зарубежные Kubernetes-платформы официально больше не поддерживаются в России. Многим компаниям приходится искать альтернативные решения для управления контейнеризированными приложениями — например, «ванильный» Kubernetes или российские платформы. Хотя у Kubernetes-платформ одинаковая технологическая база, перейти с одной на другую непросто: миграция неизбежно сопряжена с различными трудностями, связанными с особенностями реализации компонентов. В этой статье рассмотрен пример переезда приложения из OpenShift в «ванильный» кластер Kubernetes. В конце статьи приведена таблица соответствия примитивов OpenShift и Kubernetes — с информацией о том, какие из этих примитивов требуют замены, а какие нет.
Собеседование мечты: как девопсу попасть на работу
Каждый начинающий девопс мечтает об этом — о долгожданном оффере. Но перед тем, как его получить, придется пройти ряд интересных квестов, и среди них — собеседование. Учебный центр Слёрм собрали круглый стол из спикеров курса DevOps Upgrade и практикующих DevOps-инженеров и задали самые горячие вопросы от начинающих специалистов.
Стеклянная луковица dns внутри k8s
Бесспорно, тема резолвинга dns запросов внутри k8s неоднократно поднималась на хабре и вставала ребром перед многими инженерами поддерживающими k8s кластера. Снимая слой за слоем, попытаемся разобраться как резолвятся dns записи внутри k8s. Бонусом бегло взглянем на устройство механизма резолвинга dns для Go.
Устанавливаем Kubernetes-платформу Deckhouse в закрытом окружении.
Установка Deckhouse в закрытое окружение почти не отличается от установки на bare metal. Главные особенности:
- Чтобы предоставить приложениям доступ в Интернет в закрытом контуре, нужно явно указать параметры прокси-сервера в конфигурации кластера.
- Для обновлений или подключения дополнительных компонентов кластера необходимо указать адрес развернутого хранилища с образами контейнеров Deckhouse, прописав в случае необходимости параметры прав доступа.
В статье рассматриваются все необходимые этапы по порядку.