DevOps *

Паттерн feature-окружений называют по-разному: ondemand, review- или preview-окружения. Он нужен, чтобы приблизить среду разработки к продакшену, и позволяет разом избавиться от множества проблем, связанных с организацией разработки и переносом кода.
Но для создания feature-окружений и работы с ними ваш технологический стек должен быть достаточно мощным, чтобы обеспечить необходимую гибкость и динамичность. В этой статье я расскажу, как реализовать некоторые механизмы, необходимые для эксплуатации feature-окружений.

Всем привет. Меня зовут Путилин Дмитрий (Добрый Кот) Telegram.

От коллектива FR-Solutions и при поддержке @irbgeo Telegram : Продолжаем серию статей о K8S.

В этой статье мы поделимся своим опытом разработки Managed K8S под Yandex Cloud и расскажем, как мы создали конфигурацию, которую можно легко адаптировать для запуска в любом облаке или on-premises решении, изменяя только некоторые настройки. Если вы заинтересованы в построении гибких и масштабируемых Kubernetes-кластеров, то этот материал обязательно для вас.

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

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

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

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

Далее речь пойдет о системе, которая работает на основе стека prometheus alertmanager + с учетом того, что микросервисы развернуты в кубере. Итак, приступим.

В незапамятные времена, когда еще не вышла последняя серия «Во все тяжкие», алерты чаще всего хранились в одном месте — будь то icinga, zabbix, TICK stack или тот же самый Prometheus. В этом есть свои плюсы — можно легко отслеживать изменения, грепнуть нужный алерт, накидать CI и так далее. Но когда речь заходит о микросервисной архитектура, где бизнес логика представлена отдельными сервисами, было бы логичным держать бизнес алертинг рядом с микросервисов.

Что ж, давайте попробуем реализовать такой подход.

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

Привет! Меня зовут Игорь, я управляющий партнёр и системный архитектор в KTS.

В этой статье, подготовленной по мотивам моего доклада в «Школе мониторинга» Slurm, хочу поделиться своим набором best practice «Как лучше всего настроить Grafana Loki для сбора логов в инфраструктуре». 

На мой взгляд, порог входа в систему достаточно низкий, и в Интернете много туториалов. Поэтому я расскажу о более сложных и не совсем очевидных вещах, с которыми не раз сталкивался при работе с Grafana Loki. 

Этой ночью вышла новая версия Kubernetes — 1.27. Среди главных изменений — переход на собственный полноценный реестр registry.k8s.io, обновление запросов и лимитов Пода «на месте» — т.е. без необходимости перезапускать Под или его контейнеры и ряд усовершенствований в области безопасности (stable-статус фичи seccomp by default, in-process-валидация запросов к API-серверу и др.).

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

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

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

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

Надоело, что одни пороги метрик настроены в Prometheus, другие в Zabbix, третьи еще в каком‑то Zabbix? А когда трясет инфру и vCenter, то с vROps летят оповещения, причем те же самые о виртуалках, что поставлены на мониторинг в первом и втором Zabbix?!

Тут можно менять названия уровней вашего ИТ‑окружения, можно менять названия систем мониторинга. Дубли, штормы, алярмы и алармы. Проблема будет знакома всем, кто работает с большими инфраструктурами. А еще не забываем о проблеме «сложить все в одну банку»: все метрики с разных прометеев, например; ну и, конечно же, совсем было бы здорово в одной системе увидеть все метрики и логи и настроить по ним корреляции и автоматизацию.

А так можно было? Конечно!

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

Это можно оспорить, ведь Cacher также может быть технической реализацией, хотя ему и требуется базовая реализация. Подробно рассмотрим кэширование в одном из будущих постов. А сейчас подробно изучим кэширование и его возможности. 

Когда появляется потребность в DevOps-команде, перед бизнесом всегда встают конкретные вопросы: “А всё-таки, как решить мою проблему — нанять DevOps-специалиста в штат, использовать аутстафф или отдать проект на аутсорс? Есть ли четкие критерии для выбора? Что будет эффективнее?”

На конференции DevOps Conf 2023 я как раз рассказываю об этом, а в качестве основного критерия для выбора модели взаимодействия предлагаю использовать этап жизненного цикла вашего продукта. 

Всем доброе утро!
Сегодня мы поднимем такую интересную тему, как DevOps Governance в Enterprise.

В современных реалиях не так просто прийти к бизнесу и сказать: "Давайте всё автоматизируем, и всё будет хорошо!" Нет, это так не работает, особенно в крупных компаниях. А если у Вас ещё и нет единого процесса внесения изменений, то каждый будет кто в лес по грибы, кто домой за скатертью-самобранкой приходить и навязывать свои идеи.

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

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

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

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

В докладе я препарирую Istio, дабы понять, как он работает, какие у него подводные камни и как им правильно пользоваться.

Это мой второй доклад про Istio и Service Mesh. Первый я сделал на конференции Kuber Conf 2021: «Что ждать от внедрения Istio?». Рекомендую ознакомиться сначала с ним, будет несколько проще.

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

В статье мы рассмотрим, как в Kubernetes-кластере под управлением Deckhouse удобно и быстро настраивать мониторинг с уведомлениями в Telegram. Воспользуемся VictoriaMetrics для хранения метрик, добавим дашборд в Grafana, создадим алерт и настроим оповещение.

В наши дни весь современный бизнес имеет взлеты и падения - если мы говорим о команде, разрабатывающей свой продукт. Мы можем стать либо свидетелями рождения истории, либо её участниками. Именно так в 1987 году бывший офицер Шэньчжэнь создал свою компанию с капиталом в 20 000 юаней. Её название знает сейчас каждый инженер, но многие не задумываются в смысловом содержании этого названия Hua - “Китай” и Wei - “Достижение”.

“Так, стоп”, - мысленно подумал сейчас про себя каждый, - “Зачем я сейчас читаю про это? Я хочу узнать что-то про SberCloud, и как там обстоят дела с k8s”. А вот нельзя говорить о SberCloud и не говорить о Huawei Cloud, ведь по своей сути это один и тот же продукт, который предоставляется нам сейчас на рынке. Но не хотелось бы впадать в полемику и говорить о том, почему так и никак иначе. Лучше обсудим ряд вопросов, которые действительно интересуют любого инженера, решившего связать свою проектную деятельность со SberCloud.