DevOps FM

Что было интересного на прошлой неделе? ⚡️

▪️День Рождения — kubeadm исполнилось 7 лет. kubeadm — это инструмент для запуска минимально жизнеспособного кластера.

▪️ClickHouse анонсировали альтернативу ZooKeeper — ClickHouse Keeper. В анонсе говорится, что новый инструмент станет полной заменой ZooKeeper с полностью совместимым клиентским протоколом и той же моделью данных.

▪️GitLab нашли несколько уязвимостей уровня «high» и выпустили для них патчи. Рекомендовано как можно скорее обновиться до последней версии.

▪️Helm 3.13 — флаг --dry-run теперь имеет несколько опций, в обработке значений были исправлены многочисленные проблемы, появилась возможность работать с реестрами OCI через HTTP, используя --plain-http, новая команда helm get metadata и другие обновления. Вся информация — в Release Notes.

▪️Docker улучшает видимость токенов личного доступа пользователей Docker Desktop и Hub. В частности, меняет способ обработки токенов в сеансах между двумя инструментами. В работе Docker Hub, Docker Desktop и Docker CLI не произойдет заметных изменений, но рекомендовано использовать последние версии Docker Desktop и Docker CLI, чтобы получить новейшие функции и обновления безопасности.

▪️Релиз KEDA v2.12.0. Kubernetes Event Driven Autoscaling (KEDA) — оператор Kubernetes с открытым исходным кодом. Полный список изменений доступен в Release Notes.

Всем DevOps! 🖖

#новости

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

Отрасль требует непрерывности деплоя и уже имеется достаточное количество инструментов для этого. Пусть не идеальных, но они есть и по большей части удовлетворяют потребностям бизнеса. Но для того, чтобы эти инструменты работали, нужна соответствующая инфраструктура. Где-то на первых этапах её обеспечивали DevOps’ы в ванильных кубах, что требовало огромных затрат. Ответом на это со стороны облачных провайдеров стали managed кубы, где затраты на обслуживание инфраструктуры и стоимость её владения стали ниже. Serverless — это дальнейшая эволюция абстракции инфраструктуры, которая делает разработку и эксплуатацию приложения ещё более простой и без дополнительных затрат на инфраструктуру.

Тем более, что сейчас уже есть несколько инструментов, которые дают возможность использовать бессерверные функции в собственном кубе (например, Knative и OpenWhisk), т.е. без использования облачного провайдера. Это может дать дополнительное ускорение внедрения этой технологии.

А поскольку наша деятельность неразрывно связана с инфраструктурой и используемыми в отрасли инструментами, то нам стоит обратить внимание на эту технологию, чтобы в прекрасный день мы обнаружили, что реалии поменялись, а мы к этому полностью готовы!

Security

На доклады этого трека я, к сожалению, попасть не смог, слушал другие темы. Но несколько наблюдений по этой теме всё же сделал.

На открытии было заявлено, что одной из стратегий развития облака будет создание простых Cloud-native решений в безопасности.

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

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

Другие сервисы

По ходу посещения докладов и общения с людьми, я делал небольшие пометки по сервисам, которые могут быть интересны в решении тех или иных вопросов.

- Yandex Cloud Apps: новый сервис от Яндекса. Это маркетплейс для размещения cloud-native приложений. Пока такое ощущение, что на текущий момент туда нельзя добавлять внешние приложения, но в будущем, я думаю, с высокой вероятностью они сделают такую возможность. В этом случае это кажется отличным вариантом для размещения nxs-backup и nxs-data-anonymizer.

- Gravity UI: библиотека компонентов для React. Возможно, облегчит создание web-интерфейсов для наших инструментов. Это open-source.

- DataLens: инструмент визуализации данных. Прежде всего он задумывался как BI-инструмент. Не знаю, будет ли он полезен именно в этом качестве, но выглядит так, что он может быть полезным для визуализации прогресса по текущим целям или технологического радара. Тут нужно дополнительное исследование. Это open-source

- YDB: часто упоминалась в докладах различных крупных компаниях-партнёров Yandex. Это open source

- GreenPlum: плюс минус то же самое, что и про YDB

Пожалуй, на этом мои основные наблюдения по поводу прошедшей конференции подошли к концу»

#лонгрид

Всем DevOps! 🖖

Хотим начать неделю с необычного поста.

Борис Ершов, CTO компании Nixys, побывал на конференции и поделился наблюдениями, которые, пожалуй, могут быть полезны и вам!

***

«В самом начале той недели я побывал на конференции Yandex Scale, увидел и услышал там много любопытного и хотел бы поделиться с вами своими наблюдениями и мыслями.

Интересные заметки на открытии:

- Хоть это явно и не обозначалось, но тем не менее озвучивалось — стратегическими направлениям для развития Яндекс Облака будут Serverless и Security;

- Ребята показали интересный график внедрения новых сервисов и технологий, согласно которому разделили жизненный цикл на 5 этапов: триггер технологии, пик завышенных ожиданий, дно разочарования, склон просветления, плато продуктивности;

- 7 из 10 их клиентов в том или ином виде использует бессерверные вычисления.

Во-вторых, вся конфа была разделена по шести секциям:

- Infra + K8s
- Serverless
- Digital Workplace
- ML
- Data Platform
- Security

Поскольку у меня с собой была только одна пара глаз и ушей, то освещение получат не все имеющиеся треки, но я постарался захватить самые массовые, а именно те, которые собирали максимальное число зрителей на докладах и стендах. По моим наблюдениям, такими были:
- ML
- Serverless
- Security

ML

Это в принципе очень хайповая тема сейчас. Бизнес видит в ней надежду и опору в вопросах оптимизации части своих процессов и сокращение расходов. Самый крутой доклад этого трека — это YandexGPT. Где рассказывалось о истории его создания, возможностях и применении. Очень интересный доклад! И интересен он был настолько, что зал едва вместил всех желающих его послушать. Мне повезло найти себе место и слушать доклад сидя. Тут же были анонсированы новые возможности на базе объединения DataSphere и YandexGPT.

Serverless

Сразу стоит отметить, что в Яндекс Serverless представлена по двум направлениями:

- Cloud Functions: это аналог Lambda AWS, когда программа выполняется, не как результат привычного процесса сборки, деплоя и работы контейнера с бинарником типа API-сервера или кэширующего сервера. А прям в виде кода, который чихать хотел и на сборку, и на деплой и на сам сервер;

- Serverless Containers: если описать в нашем понимании, то это почти привычный нам контейнер, который ничего не знает не только про сам физический или виртуальный сервер, но и про Kubernetes со всеми его сущностями. В Яндексе верхнеуровнево деплой устроен так: закидывает код (в виде архива) и Dockerfile. Далее он там сам билдится и где-то сохраняется и уже потом пользователь оперирует нужной ревизией при запуске.

Из моего общения с участниками было видно, что интерес к этой технологии, был обусловлен основными моментами:

- Возможностью сокращения затрат на облако за счёт оплаты только тех ресурсов, которые используются во время выполнения;

- Снижением зависимости от инфраструктуры и её обслуживания (это я про дефицит в DevOps)

При всём при этом, клиенты видят в ней и существенные для себя минусы. Основные из которых это:

- Необходимость менять архитектуру и переписывать приложения. Сам принцип работы Serverless накладывает на запускающийся в нём код ряд архитектурных ограничений, поэтому в некоторых случаях программу придётся переписывать весьма и весьма существенно;

- Vendor lock-in. Каждый провайдер имеет свою реализацию, у всех разные эндпоинты и даже список поддерживаемых языков, поэтому просто перетащить имеющийся код из одного облака в другое не получится, нужна будет его переработка. И на этом все приглашённые спикеры делали акцент;

⬇️

#лонгрид

Дисклеймер! Статья скорее для тех, кто только погружается в тему :)

***

«Понятие DevOps знакомо многим, но все-таки ответить на вопрос "Что же такое DevOps?" непросто.

В статье мы постарались это сделать: упорядочили знания, определили основные понятия DevOps, ещё раз обозначили какие процессы существуют в этой методологии, какую роль они играют и с чего начать внедрение DevOps.»

➡️ Приятного чтения!

#статья_Nixys

+1 полезный open-source инструмент — KubeLinter 💻

Он анализирует YAML-файлы Kubernetes и Helm-чарты и проверяет их на соответствие различным best practices, уделяя особое внимание готовности к работе и безопасности.

Некоторые распространенные проблемы, которые выявляет KubeLinter — запуск контейнеров от имени non-root user, соблюдение минимальных привилегий и хранение конфиденциальной информации только в секретах.

Лицензия Apache License 2.0, 2.5k звездочек на GitHub ⭐️

P.S. Статьи про работу с этим инструментом:

• «Ensuring YAML best practices using KubeLinter»

• «Analyze Kubernetes files for errors with KubeLinter»

• «How to add a new check in KubeLinter?»

• «Extending kube-linter To Build A Custom Template»

#open_source

Всем DevOps! 🖖

Еще немного про OpenTofu. Вышла вот такая заметка в блоге — «Why should I care about OpenTofu?»

Авторы проекта отвечают на в общем-то вполне логичный вопрос: «Смена лицензии меня не затрагивает, так почему меня это должно волновать?»

TL;DR: иметь альтернативы — это всегда хорошая стратегия, конкуренция важна, появление проектов типа OpenTofu снижает вероятность дальнейшего ужесточения лицензионных ограничений.

#новости

k3s: легковесный дистрибутив Kubernetes

Часть 1: из истории k3s

Часть 2: отличия от k8s

Часть 3: архитектура

Часть 4: как можно развернуть k3s и Fun facts

▪️ Ссылка на репозиторий k3s

▪️ Ссылка на документацию k3s

▪️ Полезная ссылка из комментариев: «k3d — легкая оболочка для запуска k3s в докере»

#лонгрид #open_source

Как можно развернуть k3s

Кластер из одной ноды (изображение 1)

Этот самый упрощенный метод для разворачивания кластера k3s, который оптимизирован для пограничных устройств. Вы просто запускаете команду установки при помощи команды curl, и она разворачивает полноценный кластер Kubernetes. Но стоит сразу обратить внимание, что данная архитектура развертывания не сможет обеспечить вам отказоустойчивость.

Один кластер с несколькими агентами (изображение 2)

Этот метод также использует один сервер к которому вы можете добавить агентов в кластер. Агенты безопасно подключаются с помощью токена, который сервер создает при запуске. В этой конфигурации каждый узел агента регистрируется на одном и том же узле сервера. Пользователь k3s может управлять ресурсами Kubernetes, вызывая API k3s на узле сервера.

Высокодоступный сервер k3s с внешней БД (изображение 3)

Этот метод можно использовать, если вам важно настроить отказоустойчивый кластер. Данный кластер k3s состоит из:

• Двух или более серверных узлов, которые будут обслуживать API Kubernetes и запускать другие службы плоскости управления.

• Внешнего хранилища данных (вместо встроенного хранилища данных SQLite, которое используется в конфигурациях с одним сервером по умолчанию).

Fun facts про k3s

• Более 1 миллиона загрузок. С февраля 2019 года k3s скачали более 1 миллиона раз, в среднем 20 000 установок в неделю.

• На момент 2023 года имеет на гитхабе более 24 тысяч звезд, что говорит о заинтересованности сообщества в данном проекте.

• Не существует ни полной формы названия k3s, ни официального произношения. Разработчики хотели, чтобы установка Kubernetes была вдвое меньше с точки зрения занимаемой памяти. А так как Kubernetes состоит из 10 букв, которое сообщество стилизовали под k8s, ребята из Rancher Labs просто уменьшили вдвое количество букв в Kubernetes и стилизовали под k3s.

*️⃣4/4

#лонгрид #open_source

Архитектура

На приведенном выше рисунке показана разница между сервером k3s и узлами агента k3s. (Источник здесь)

Если копнуть глубже, то k3s упакован и развернут в виде одного бинарного файла размером приблизительно 60 МБ, представляющего из себя самодостаточный инкапсулированный объект, который запускает почти все компоненты кластера Kubernetes.

На рисунке мы наблюдаем две ноды, на одной из которых работает k3s service, а на второй агент k3s. API server проверяет и настраивает данные для объектов API — например pods, services и т.д. Controller Manager наблюдает за общим состоянием кластера через API-сервер, вносит в него изменения и переводит из текущего состояния в желаемое. Scheduler назначает модули узлам в соответствии с их текущим состоянием, ограничениями и доступными ресурсами. Kubelet как основной агент узла в кластере, работающий на каждой ноде. Kine, где в качестве хранилища по умолчанию используется SQLite. Containerd как исполняемая среда для запуска контейнеров. Связь между агентом и сервером осуществляется через туннельный прокси.

*️⃣3/4: продолжение следует :)

#лонгрид #open_source

Отличия от k8s

• В k3s нет четкого различия между мастер и воркер нодами. Управление подами происходит на любой ноде, независимо от роли, которую они играют. Таким образом, понятия мастер и воркер нод не применимы к кластеру k3s

• Отсутствуют необязательные компоненты Kubernetes, например, плагины объема хранилища и API-интерфейсы облачных провайдеров.

• Добавлены некоторые элементы, включая containerd, Flannel, CoreDNS, CNI, ingress controller Traefik, локальное хранилище данных, встроенный сервис Load Balancer. Все эти элементы упакованы в один бинарный файл и выполняются в рамках одного процесса. Дистрибутив также поддерживает Helm-charts из коробки.

• K3s не имеет внешних зависимостей. Это означает, что вам не нужно ничего устанавливать, чтобы запустить его.

• Автоматическое развертывание. Оно позволяет развертывать манифесты Kubernetes и Helm-чарты, помещая их в определенный каталог. То есть k3s отслеживает изменения и заботится об их применении без дальнейшего взаимодействия. Просто создайте/обновите свою конфигурацию, и k3s обеспечит актуальность ваших deployments.

*️⃣2/4: продолжение следует :)

#лонгрид #open_source

Всем DevOps! 🖖

Уверены, что вы знакомы с Kubernetes (его еще называют k8s). У Kubernetes много плюсов, но есть один существенный минус — кластер Kubernetes немного сложен в настройке и требует значительных ресурсов, что затрудняет развертывание на локальной машине для обучения или разработки. В общем, не всегда возможно перейти на полноценный k8s. К счастью, на этот случай есть более легкое решение в виде k3s.

Про него и пойдет речь в сегодняшних постах. Разумеется, потом оформим все части в одну подборку 😉

Из истории k3s

Во время создания Rio (одна из разработок для kubernetes от Rancher Labs), разработчик Даррен Шепард был разочарован, что для тестирования постоянно требовалось запускать новый кластер Kubernetes. Он знал, что это занимает много времени и, если он сможет запускать кластер быстрее, то сможет выделять больше времени на написание кода и новые фичи. Даррен был хорошо знаком с исходным кодом Kubernetes и начал его разбирать, удаляя все ненужные компоненты, чтобы обеспечить быстрый запуск.

В 2019 году компания Rancher Labs объявила о запуске нового open source-проекта k3s, который представлял собой легкий и простой в установке дистрибутив k8s, предназначенный для разработчиков, ищущих способ запуска Kubernetes на платформах с ограниченными ресурсами.

Чтобы адаптировать Kubernetes к слабому железу, Rancher Labs:

• Удалили старый и неиспользуемый код. По словам разработчиков из кода было вырезано порядка 1000 строк;

• Вместо Docker использовали conteinerd;

• Добавили поддержку Kine, в качестве хранилища по умолчанию;

• Удалили драйвера облачных провайдеров.

*️⃣1/4: продолжение следует :)

#лонгрид #open_source

Маленькая шпаргалка 💻

Как узнать актуальные CVE в k8s? Обратиться к Official CVE Feed.

Эту же информацию можно извлечь в формате JSON:

curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json

Или XML:

curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/feed.xml

Приятно, что для каждой CVE указывается ссылка на GitHub Issue и можно посмотреть как не идут дела.

#интересное

Всем DevOps! 🖖
Давайте посмотрим, что было интересного на прошлой неделе.

▪️+ 1 open-source инструмент с забавным названием. Разумеется, речь о проекте OpenTofu — который переименовали из OpenTF и который стал проектом The Linux Foundation 🎉 А это значит, что теперь OpenTofu будет всегда Open Source.

▪️Релиз GitLab 16.4. Настраиваемые роли, список зависимостей на уровне группы/подгруппы, локальный доступ к кластерам с использованием идентификатора пользователя GitLab и многое другое.

И небольшая полезная инфа (ну мало ли): у GitLab есть весьма удобная площадка, на которой описана поэтапность обновления c вашей версии до последней актуальной.

▪️Релиз Angie 1.3.0. Поддержка нескольких паттернов сопоставления URI запроса для одного и того же контекста конфигурации (директива «location»), статистика в формате Prometheus, которая упрощает построение систем мониторинга в современной инфраструктуре, версионирование конфигураций отдельных процессов веб-сервера и возможность получения текущей конфигурации сервера через HTTP API. Все изменения — вот здесь.

Если мы пропустили что-то важное, обязательно дополняйте в комментариях :)

Желаем отличной недели! 🔥

#новости

«Kube FM» — подкаст, позволяющий расширить знания о Kubernetes, следить за новейшими инструментами и тенденциями.

Подкаст ведет амбассадор CNCF Барт Фаррелл. Есть текстовая расшифровка и много полезных ссылок к выпуску.

В первом (и пока единственном 😢) выпуске рассматриваются новые функции Kubernetes 1.28 и рассказывается о том, что требуется для выпуска новой версии Kubernetes. В гостях Грейс Нгуен (Grace Nguyen) — Kubernetes 1.28 release lead.

#подкаст

☄️ «Возможно, отключение всего — более эффективное средство устранения неполадок. И именно устранение неполадок должно быть вашей главной заботой. Так вы выигрываете время для понимания проблемы. Это возможно не во всех случаях, но даже если вы сместите фокус с проблемы, вы сможете выиграть немного времени»

Это слова SRE-инженера Рикардо Кастро. Категорично настолько, будто это сказал его однофамилец Фидель 😜 Но смысл в этом есть.

👉 Читайте об опыте SRE-инженера в нашей новой статье.

#devops #sre

@DevOpsKaz

Всем DevOps! 🖖

Очень вероятно, что вам знаком этот инструмент (все-таки 38k звездочек на GitHub), но кажется не лишним рассказать про него еще раз :)

dive — open-source инструмент для изучения образа Docker, содержимого слоев и поиска способов уменьшить размер образа Docker/OCI.

Чтобы проанализировать образ Docker, просто запустите dive с тегом / id / digest образа:

dive <your-image-tag>

Или вы можете использовать dive напрямую с помощью команды docker:

alias dive="docker run -ti --rm -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive"
dive <your-image-tag>

# for example
dive nginx:latest

Или вы можете создать свой образ и сразу приступить к его анализу:

dive build -t <some-tag>

💻 Ссылка на GitHub

#open_source

Наглядное объяснение работы «native sidecar-контейнеров». Лучше, конечно, прочитать и оригинал текста :)

Kubernetes Native Sidecars

Fun Fact: объекта поля Sidecar нет даже в Kubernetes 1.28. Встроенные sidecar-контейнеры — это просто старые добрые init-контейнеры, но с некоторыми новыми свойствами:

▪️ Чтобы сделать init-контейнер sidecar-контейнером, необходимо добавить атрибут «restartPolicy: Always» в его спецификацию.

▪️ Поскольку сайдкары являются init-контейнерами, они соблюдают порядок запуска в списке Pod.initContainers.

▪️ Однако они не блокируют следующий запуск контейнера (init или обычного).

▪️ В отличие от init-контейнеров, в случае сбоя сайдкары будут перезапущены.

▪️ В отличие от не встроенных сайдкаров (исторически имитируемых обычными контейнерами), встроенные sidecar-контейнеры не блокируют завершение пода.

▪️startup|readiness|liveness пробы теперь можно настроить для init-контейнеров, но только для тех, у которых для параметра restartPolicy установлено значение «Always».

Другими словами, единственная «true init» особенность новых встроенных Sidecars, заключается в том, что они следуют порядку запуска инициализации. В остальном их поведение сильно отличается от init-контейнеров.

Эта конструкция открывает путь к более продвинутому типу init-контейнера. В Sidecar PEP даже упоминается новый тип, называемый «infra containers», который может быть использован для унификации поведения старых init и новых контейнеров Sidecar.

Вот как новое поведение можно визуализировать с помощью одного пода:

• Два обычных контейнера работают до завершения
• Два init-контейнера ic1 и ic2 работают до завершения.
• ... и смешанный с двумя сайдкарами sc1 (периодически выходит из строя и перезапускается) и sc2 (работает до завершения)

Обратите внимание, как:

• Первый сайдкар постоянно перезапускается.
• Оба сайдкара принудительно уничтожаются после завершения работы обоих обычных контейнеров.
• Окончательный статус пода — «Succeeded», несмотря на то, что оба сайдкара сообщают о non-zero exit codes.

#лонгрид

GitLab Critical Security Release: 16.3.4 (Community Edition) и 16.2.7 (Enterprise Edition)

Злоумышленник мог запустить пайплайн от имени произвольного пользователя с помощью scheduled security scan policies. Уровень опасности — critical (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N, 9.6).

Сообщение от GitLab c инструкцией (в том числе есть информация, что делать с версиями до 16.2)

#новости