Стремительно растущая конфигурация K8s с современными трендовыми технологиями AI продолжает видоизменять трансформацию способов управления инфраструктурой и приложениями. В этой статье мы более детально обратимся к платформе K8sGPT, которая занимает центральное место в перевороте работы контейнерных приложений, начавшемся в 2023 году.

Хотя это и не новинка технологий, это не отменяет того факта, что она остается интересной темой для обсуждения.

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

Приятного прочтения!

Всем привет! Это снова Олег. Как и обещал, публикую вторую часть текста, посвященную вопросам, которые могут быть заданы на собеседовании по Kubernetes. 

Чтобы было понятно о чем речь, коротко: я работаю исполнительным директором по разработке в Газпромбанке, собеседую инженеров DevOps и системных администраторов. Делюсь вопросами (и ответами, конечно), которые могут быть заданы на собеседовании. Первую часть можно найти здесь. Итак, поехали.

Современный мир бизнеса и разработки программного обеспечения характеризуется высокой динамикой и необходимостью быстрого реагирования на изменения в рыночных условиях. В этом контексте эффективная организация команд становится ключевым фактором успеха. 

Team Topologies - это концепция, которая предлагает рациональный и гибкий подход к организации команд внутри организации. Классические подходы к организации Agile команд, как правило, рекомендуют создавать универсальные и кроссфункциональные команды, где любая команда может сделать любую фичу из беклога.

Всем привет! На связи Сергей Гончарук, менеджер проектов компании «Флант». 30 ноября и 1 декабря 2023 года прошла конференция TeamLead++ Conf 2023. Ниже — текстовый вариант моего доклада с конференции про опыт «Фланта» в построении процессов управления задачами для Dev-части нашей DevOps-работы. 

В докладе я рассказал, как можно применить ценностную модель, чтобы построить идеальный фреймворк для команды, и как приносить изменения в компанию через создание профессионального сообщества, в нашем случае — гильдии.

Всем привет! Меня зовут Максим, я релиз-инженер Ozon, и в этой статье я расскажу про впихивание невпихуемого, или про оптимальную с точки зрения используемых ресурсов стратегию деплоя в Kubernetes, которая позволила нам сэкономить тысячи ядер CPU и терабайты RAM.

Я довольно долго прожил в Сиэтле и Калифорнии, и один из первых вопросов, который мне всегда задают: как там, в стране американской мечты? Я всегда отвечаю — это зависит. Пока что этот ответ никого не удовлетворил…

Очевидно, этот вопрос часто задаётся не из пустого любопытства, особенно если я разговариваю с человеком из IT. Многие технические специалисты думают о том, чтобы испытать удачу в США.

Итак, как там на самом деле? Мы видели много разных публичных мнений, от очень хайпового фильма «Кремниевая Долина» Юрия Дудя, изображающего идиллический и солнечный образ, до очень негативного от Артемия Лебедева.

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

Давайте посмотрим что есть что.

С момента публикации концепции Twelve-Factor App значительно изменилось то, как мы создаём, упаковываем и развёртываем приложения. Контейнеры, Kubernetes и облачные технологии стали основными технологиями, которые позволяют нам создавать переносимые, масштабируемые и надёжные приложения. Тем не менее 12 факторов, сформулированных в концепции, всё ещё актуальны в современном технологическом стеке.

Перевели статью, в которой описывается методология Twelve-Factor App и применение её концепций в контексте контейнеров и Kubernetes.

Привет, Хабр! Меня зовут Даниэла, я руковожу направлением корпоративных льгот в Росбанке. В этом посте я расскажу, что такое выгорание, как оно проходит, как уберечь себя от выгорания, отслеживать его у сотрудников и, наконец, что мы для этого делаем в компании.

О сложных системах простыми словами.

В шпаргалке на высоком уровне рассматриваются такие вещи, как протоколы коммуникации, DevOps, CI/CD, архитектурные паттерны, базы данных, кэширование, микросервисы (и монолиты), платежные системы, Git, облачные сервисы etc. Особую ценность представляют диаграммы — рекомендую уделить им пристальное внимание. Полагаю, шпаргалка будет интересна всем, кто хоть как-то связан с разработкой программного обеспечения и, прежде всего, веб-приложений. Буду признателен за помощь в уточнении/исправлении понятий, терминологии, логики/алгоритмов работы систем (в рамках того, что по этому поводу содержится в оригинале), а также в обнаружении очепяток.

Выражаю благодарность Анне Неустроевой за помощь в редактировании материала.

Возможно, немного другой формат шпаргалки покажется вам более удобным.

System Design (сборник на английском языке).

При использовании дополнительных контейнеров в Kubernetes важно развернуть их так, чтобы сократить количество YAML-кода и при этом не лишить платформенные команды возможности публиковать sidecar'ы без запроса на обновление приложение. Для этого подходят Sidecar Injector'ы — решения, которые позволяют писать свою логику изменения создаваемых ресурсов «на лету».

Меня зовут Максим Чудновский, я развиваю Platform V Synapse Service Mesh в СберТехе. Продолжаю свой рассказ о паттернах использования дополнительных контейнеров в Kubernetes. В этот раз поговорим, как устроены Sidecar Injector'ы, как перейти к управлению кластером через политики и какие готовые решения для этого существуют.

Соглашение об уровне обслуживания (SLA) – это соглашение с клиентами или пользователями, где описывается уровень обслуживания, который поставщик обещает предоставить клиенту. SLA можно представить в виде измеряемой метрики, например, как время безотказной работы или суммарное количество ошибок. Перевели статью, где рассматривается простой способ расчета SLA на примере Nginx-сервера.

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

От автора перевода: в Google вместо PR (Pull Request) принято использовать аббревиатуру CL (ChangeList — список изменений). Остальные термины, на мой взгляд, понятны и без пояснений. Чтобы разбавить кучу текста, в качестве разделителей разделов использованы генерации на тему "код-ревью от разных мультипликаторов" от нейросети Kandinsky.

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

В новой серии статей «Мир приключений по API-серверу Kubernetes» («k8s ASA») мы погрузимся во все детали работы API-сервера, получим представление о том, как они работают, а также с какими компонентами взаимодействуют. Параллельно поэкспериментируем с заменой пользовательских компонентов, создадим инструментарий и рассмотрим, как другие пользователи модифицировали его в соответствии с пользовательскими кейсами. Кто знает, возможно, даже построим наш собственный. ?

Привет! Меня зовут Сергей — я руководитель DevOps-направления в KTS.

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

Это финальная часть нашего доклада, в которой вы узнаете, как управлять инфраструктурой в GitOps с помощью Crossplane. Новый подход к IaC и как его можно объединить с ArgoCD.

Публичный Open Source-релиз Deckhouse состоялся в 2021 году. С тех пор мы много и подробно рассказываем о платформе — на Хабре, на конференциях, в СМИ. Однако когда мы проводим презентации Deckhouse потенциальным клиентам, по-прежнему нередко слышим примерно один и тот же вопрос: «А что вы, вообще, сделали? Взяли Kubernetes и засунули в него разные Open Source-компоненты?»

Я понял, что есть проблема с пониманием продукта и решил рассказать на HighLoad++ 2022, что мы сделали на самом деле.

Привет, меня зовут Сергей — я руководитель DevOps-направления KTS. 

Рассмотрим относительно новый виток в развитии деплоя приложений и посмотрим, какие вопросы можно закрыть с помощью инструмента Argo CD.

GitOps — это одна из реализаций Pull-модели, в которой Git является хранилищем всех конфигураций. Источник правды — Git, все изменения в инфраструктуре проходят только через него. Все изменения по Pull-модели проводит специальный агент, который затем поддерживает заданное состояние. То есть если внести в инфраструктуру изменения вручную, агент увидит несоответствие с тем, что есть в Git, и вернёт все к нужному состоянию, идентичному источнику правды. 

Argo CD — один из самых популярных GitOps-инструментов. Он живет внутри Kubernetes и там же развертывает сущности. Argo CD предоставляет удобный RBAC, то есть управление правами и доступами. В интерфейсе можно посмотреть свои действия, управлять приложениями и  принудительно синхронизировать их. Argo CD входит в CNCF, что вызывает к нему большое доверие.

Это первая часть топика, где мы поговорим о Reliability в рамках практик SRE.

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