С 29 декабря 2022 до 24 февраля 2023 Хабр вместе с #CloudMTS запускает сезон Kubernetes — конкурс технических статей о K8s, оркестрации и управлении контейнерами. Это третий сезон Хабра: летом и осенью мы уже неслабо продвинули пачку крутейших хардкорных текстов о Java и Data Mining. Теперь пришла пора разобрать по косточкам Kubernetes и относящиеся к нему DevOps-практики.
Зачем это нужно
Максимальные просмотры на Хабре традиционно набирают универсальные материалы, понятные и полезные всем. А вот узкоспециальные и технически сложные статьи как правило получают меньше внимания: просто в силу того, что интересны не всем. И тут нет заговора — чисто тервер.
Но мы всегда топим за хардкор, метровые листинги и увлекательную техническую душнину — на том и стоит Хабр. Такие статьи мы и будем дополнительно продвигать в рамках сезона: сложные, интеллектуальные, практичные, узкоспециализированные — про 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.
При публикации добавить к посту тег «cезон 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.
С 29 декабря 2022 до 24 февраля 2023 Хабр вместе с #CloudMTS запускает сезон Kubernetes — конкурс технических статей о K8s, оркестрации и управлении контейнерами. Это третий сезон Хабра: летом и осенью мы уже неслабо продвинули пачку крутейших хардкорных текстов о Java и Data Mining. Теперь пришла пора разобрать по косточкам Kubernetes и относящиеся к нему DevOps-практики.
Зачем это нужно
Максимальные просмотры на Хабре традиционно набирают универсальные материалы, понятные и полезные всем. А вот узкоспециальные и технически сложные статьи как правило получают меньше внимания: просто в силу того, что интересны не всем. И тут нет заговора — чисто тервер.
Но мы всегда топим за хардкор, метровые листинги и увлекательную техническую душнину — на том и стоит Хабр. Такие статьи мы и будем дополнительно продвигать в рамках сезона: сложные, интеллектуальные, практичные, узкоспециализированные — про 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.
При публикации добавить к посту тег «cезон 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.