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

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

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

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

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

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

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

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

#лонгрид #open_source

Всем DevOps! 🖖

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

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

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

#новости

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

***

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

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

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

#статья_Nixys

Всем 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’ы в ванильных кубах, что требовало огромных затрат. Ответом на это со стороны облачных провайдеров стали 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

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

#лонгрид

В команду Nixys требуются DevOps-инженеры — от Junior до Senior

Nixys — профессионалы в поддержке HighLoad / HA web-проектов с более чем 13-летним опытом. На постоянном обслуживании компании находится более 300 крупных известных брендов.

⚙️ Стек: Linux (ubuntu/debian, centos), Kubernetes (k8s, k3s, OKD), Prometheus/Grafana/Zabbix, ELK/EFK, CI/CD (GitLab, Jenkins), Docker, Docker Compose, Nginx, Apache, PHP-FPM, MySQL, PostgreSQL, MariaDB, MongoDB, Redis, Clickhouse, Minio, IaC (Terraform, Ansible), Yandex Cloud, GCP, AWS

📌 Основные задачи:

• проектирование архитектуры инфраструктурной части проекта и процессов по запросу клиента;

• мониторинг и контроль работоспособности сервисов;

• разработка и поддержка процессов CI/CD;

• подготовка и администрирование тестовых и промышленных сред, предоставление сервиса, соответствующего SLA;

• автоматизация рутины с помощью python/bash/golang;

• администрирование и настройка систем контейнеризации, Linux-систем (CentOS, Debian, Ubuntu), различных сервисов БД, очередей и т.д.

➡️ Полную информацию по вакансиям (условия, контакты и т.д.) можно найти на сайте или на hh.ru

Всем DevOps! 🖖
Сегодня — про Helm и инструменты для работы с ним.

Немного теории

Для начала вспомним, что это вообще такое.

Helm — это пакетный менеджер, который позволяет вам работать с приложениями в K8s так-же просто и удобно, как с привычным пакетным менеджером, например apt или yum, помогает доставлять одно и то же приложение в разные окружения с различными параметрами и позволяет легко и удобно управлять жизненным циклом приложения. На практике является одним из самых распространённых и простых способов релиза приложений в куб.

Для получения манифестов k8s в Helm используется go-templates. Это мощный и удобный инструмент, позволяющий реализовывать очень много интересных вещей и обладающий гибкой логикой.

Для работы с чартами используются артефакт хабы. Осуществлять поиск и установку нужной версии очень легко. Если публичные чарты вам не подходят, вы можете использовать свой собственный регистри хаб или чей то ещё. Некоторые дистрибутивы k8s (OS, OKD, Rancher) вообще предоставляют для данного функционала GUI из коробки, позволяя работать с Helm максимально удобным способом.

При установке приложения через Helm создаётся релиз. Релиз Helm — это полноценное состояние приложения, включая его конфигурации и переменные окружения (если они хранятся в k8s). Переключаясь между релизами Helm, например, откатывая релиз, вы также получаете именно те параметры, с которыми было запущено приложение, в отличие, например, от переключения между версиями репликасетов в деплойменте.

В Helm есть хуки. Это очень удобный инструмент, который позволяет вам выполнить какой-либо джоб до того, как будет выполнено обновление других манифестов k8s. Например, если у вас приложение состоит из деплоймента и кронджобов, а миграция БД выполняется в init-контейнере, вы не застрахованы от ситуации, когда миграция ещё не завершилась, а кроны с новым кодом уже падают, из-за того, что версия БД еще старая. Хук в данном случае решает задачу.

Удобно реализована работа с зависимостями. Параметры запуска зависимости настраиваются точно так же, как и само приложение: всё что вам нужно — добавить зависимость в описание чарта, а её параметры — в файл values.

У Helm большое комьюнити, и практически все open-source проекты имеют свой собственный чарт. Вам ничто не помешает скачать любой чарт, и локально поменять в нём всё что угодно.

Если для деплоя вы используете манифесты k8s без шаблонизации, то вам потребуется поработать с существенно большим объёмом данных, чтобы настроить ваше приложение в нескольких окружениях.

Недостатки:

• При использовании публичных чартов есть шанс столкнуться с багами.

• Тяжело реализуется сложная логика, есть ограничения.

• Для создания минималистичного values файла чарт должен быть заточен под приложение.

1/2

#лонгрид