DevOps и Kubernetes: от практик до эксплуатации кластера

Основы DevOps: культура, процессы и инфраструктура как код

Зачем нужен DevOps

DevOps — это подход к созданию и эксплуатации программных продуктов, который уменьшает разрыв между разработкой (Dev) и эксплуатацией (Ops). Цель DevOps — быстрее и безопаснее доставлять изменения пользователям, сохраняя стабильность и управляемость систем.

DevOps часто ошибочно сводят к набору инструментов (CI/CD, Kubernetes, Terraform). На практике основа — это:

культура (как люди взаимодействуют и принимают решения)

процессы (как изменения попадают в продакшен)

автоматизация (как убрать ручной труд и снизить вариативность)

измеримость (как понимать, что стало лучше)

> "SRE is what happens when you ask a software engineer to design an operations team." — из книги Site Reliability Engineering от Google (Site Reliability Engineering, O’Reilly)

В этом курсе DevOps — фундамент для последующих тем: контейнеризация, CI/CD, GitOps и эксплуатация Kubernetes-кластера.

!Классическая петля DevOps показывает непрерывный цикл доставки и улучшений

Культура DevOps: совместная ответственность и доверие

DevOps начинается с того, что команда перестаёт воспринимать эксплуатацию как «чужую зону ответственности». Ключевая идея — you build it, you run it: те, кто меняет систему, должны участвовать в её надёжной работе.

Основные культурные принципы

Совместная ответственность за результат

Прозрачность и наблюдаемость работы систем

Постмортемы без поиска виноватых (разбираем причины и улучшаем систему, а не «наказываем» людей)

Непрерывное улучшение маленькими шагами

DevOps и модель CALMS

Один из способов описать DevOps — модель CALMS:

Culture — культура сотрудничества

Automation — автоматизация

Lean — устранение потерь, маленькие партии изменений

Measurement — измеримость

Sharing — обмен знаниями

Это полезно как чек-лист: если у вас есть только автоматизация, но нет культуры и измеримости — DevOps не «взлетит».

Процессы DevOps: как изменения попадают к пользователю

Процессная часть DevOps отвечает на вопросы:

как разработчик добавляет изменение

как команда проверяет качество

как изменение попадает в продакшен

как команда понимает, что всё работает

Версионирование и Git как источник правды

Обычно изменения живут в Git-репозиториях. Важные практики:

Pull request (merge request): изменения проходят ревью

Короткоживущие ветки или trunk-based development: меньше конфликтов и проще интеграция

Код-ревью как практика управления рисками, а не «формальная галочка»

CI и CD: непрерывная интеграция и доставка

Термины:

CI (Continuous Integration) — практика, при которой изменения регулярно интегрируются в основную ветку и автоматически проверяются (сборка, тесты, статический анализ).

CD употребляется в двух смыслах:

- Continuous Delivery — система всегда готова к релизу, выкладка может быть ручным шагом. - Continuous Deployment — выкладка в продакшен происходит автоматически после прохождения проверок.

!Базовый пайплайн показывает, как автоматические проверки снижают риск релиза

Маленькие изменения и управление риском

Главная процессная идея DevOps: меньше размер изменения — меньше риск. Практики, которые помогают:

частые релизы небольшими порциями

feature flags (функциональные флаги), чтобы включать/выключать функциональность без нового деплоя

canary и blue-green деплой (подходы к выкладке, снижающие риск инцидента)

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

Инфраструктура как код (IaC): зачем и что это такое

Инфраструктура как код (Infrastructure as Code, IaC) — это подход, при котором инфраструктура (сети, виртуальные машины, кластеры, настройки) описывается декларативно или процедурно в виде файлов, которые:

хранятся в системе контроля версий (обычно Git)

проходят ревью как обычный код

применяются автоматически или полуавтоматически

Почему IaC — это основа эксплуатации

IaC решает типичные проблемы ручного управления:

Неповторяемость: «у меня на сервере настроено, но я не помню как»

Дрейф конфигурации: продакшен отличается от того, что «должно быть»

Сложность аудита: непонятно, кто и когда менял настройки

Медленные изменения из-за ручных шагов и очередей

С IaC инфраструктура становится:

воспроизводимой (можно создать заново)

проверяемой (ревью, линтеры, политики)

предсказуемой (меньше «магии руками»)

Декларативный и процедурный подход

Декларативный: вы описываете желаемое состояние (например, «должна быть сеть и 3 узла»), а инструмент сам решает как этого достичь.

Процедурный: вы описываете шаги (например, «выполни команды 1…N»).

На практике оба подхода встречаются и могут сочетаться.

Типовой стек IaC-инструментов

На уровне базового понимания:

Terraform — популярный инструмент для описания и создания инфраструктуры в облаках и не только (Terraform Introduction)

Ansible — автоматизация конфигурации и задач на серверах (Ansible Getting Started)

Позже, в контексте Kubernetes, к IaC/конфигурации добавятся:

манифесты Kubernetes

Helm-чарты

GitOps-подход к доставке конфигурации

Практика: GitOps как развитие IaC

GitOps — это подход, где Git является источником истины для желаемого состояния систем, а автоматический агент приводит реальное состояние к желаемому.

Полезный ориентир: принципы GitOps от OpenGitOps (OpenGitOps).

Мы вернёмся к GitOps, когда начнём эксплуатацию Kubernetes-кластера.

Наблюдаемость и эксплуатационная готовность

DevOps невозможен без понимания того, что происходит в системе после релиза.

Мониторинг, логирование, трассировка

Три базовых источника сигналов:

Метрики: числовые ряды (нагрузка, задержки, ошибки)

Логи: события и сообщения приложений/систем

Трейсы: путь запроса через микросервисы (распределённая трассировка)

Вместе это часто называют observability (наблюдаемость) — способность понять состояние системы по её внешним сигналам.

Инциденты и постмортемы

Инциденты будут. DevOps-подход — снижать их частоту и влияние:

алерты должны быть полезными (сигнал, а не шум)

реакции должны быть задокументированы (runbooks)

разборы после инцидентов должны улучшать систему (постмортем без обвинений)

DevSecOps: безопасность как часть процесса

Если безопасность появляется «в конце», она становится тормозом. DevSecOps — это идея, что безопасность встраивается в процесс:

ранние проверки зависимостей и уязвимостей

минимальные права доступа (principle of least privilege)

управление секретами (не хранить пароли в репозитории)

повторяемые и проверяемые изменения инфраструктуры через IaC

Как измерять успех: метрики поставки и надёжности

Чтобы улучшать процесс, нужно измерять.

Часто используют метрики исследования DORA:

частота деплоев

время выполнения изменения (lead time)

доля неуспешных изменений

время восстановления после инцидента

Ориентир по теме: материалы Google Cloud о DORA и DevOps-исследованиях (State of DevOps).

Типичные анти-паттерны DevOps

«DevOps — это один человек/команда, которая всё деплоит»

«Сначала купим Kubernetes, потом появится DevOps»

«Автоматизировали хаос» (когда плохой процесс просто запускается быстрее)

«Нет владельцев сервисов» (непонятно, кто отвечает за работу продукта в продакшене)

Что дальше по курсу

Эта статья задала базу: культура, процесс доставки и идея IaC. Дальше мы будем превращать это в практику:

собирать пайплайны CI/CD

упаковывать приложения в контейнеры

разворачивать и эксплуатировать Kubernetes

внедрять GitOps и наблюдаемость

Официальная точка входа в Kubernetes, к которой мы ещё вернёмся: документация проекта (Kubernetes Documentation).

CI/CD: сборка, тестирование и доставка приложений

Как CI/CD продолжает идеи DevOps

В прошлой статье мы разобрали DevOps как сочетание культуры, процессов, автоматизации и измеримости, а также идею инфраструктуры как кода. CI/CD — это практическая реализация этих принципов в процессе доставки изменений: мы превращаем изменения в Git в проверенный, воспроизводимый и доставляемый результат.

CI/CD отвечает на ключевые вопросы:

как автоматически проверить изменение

как собрать и версионировать результат

как безопасно доставить его в нужную среду

как быстро откатиться при проблемах

Термины и базовые понятия

CI: Continuous Integration

CI (непрерывная интеграция) — это практика, при которой каждое изменение:

попадает в общий репозиторий (обычно через pull request или merge request)

автоматически собирается

автоматически проверяется тестами и статическими проверками

Цель CI — рано находить ошибки и снижать риск интеграции.

CD: Continuous Delivery и Continuous Deployment

CD используют в двух смыслах:

Continuous Delivery (непрерывная доставка): после успешных проверок система готова к релизу, а выкладка в продакшен — отдельный управляемый шаг (часто с ручным подтверждением).

Continuous Deployment (непрерывное развертывание): после успешных проверок выкладка в продакшен происходит автоматически.

Оба подхода нормальны. Выбор зависит от рисков, требований бизнеса, зрелости тестов и наблюдаемости.

Пайплайн и этапы

Пайплайн — это описанная в коде последовательность шагов, которая запускается по событию (коммит, merge, тег релиза) и приводит к результату.

Обычно пайплайн делят на этапы:

сборка

тестирование

проверка качества и безопасности

упаковка артефакта

доставка (деплой) в среду

Артефакт

Артефакт — это результат сборки, который можно развернуть или использовать дальше:

пакет приложения

Docker-образ

архив со статикой

Helm-чарт

Ключевой принцип: один и тот же артефакт должен продвигаться по средам (dev → staging → production), чтобы не получилось “в проде собралось иначе”.

Среды

Среда — это окружение, в которое разворачивают систему:

dev (для разработки)

staging (похоже на прод, для проверки релиза)

production (продакшен)

Важно договориться, чем среды отличаются и кто принимает решение о продвижении.

!Общая схема типового CI/CD пайплайна от коммита до продакшена

Из чего состоит хороший CI

Триггеры: когда запускать проверки

Типовые события запуска:

каждый push в ветку

создание или обновление pull request

мердж в основную ветку

создание тега версии (релиз)

Практика, которая почти всегда окупается: в pull request запускать быстрые проверки, а “тяжёлые” (длинные интеграционные тесты) — по мерджу или по кнопке.

Сборка: воспроизводимость и скорость

Цель сборки — получить одинаковый результат при одинаковом исходном коде.

Чтобы сборка была предсказуемой:

фиксируйте версии зависимостей (lock-файлы)

избегайте скрытых зависимостей от окружения агента

используйте контейнеризацию сборки, если команды зависят от системных библиотек

Чтобы сборка была быстрой:

применяйте кеширование зависимостей

разделяйте пайплайн на независимые задачи (параллелизм)

не запускайте “дорогие” шаги без необходимости

Тестирование: пирамидa тестов и “quality gates”

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

юнит-тесты: быстрые, проверяют отдельные функции и модули

интеграционные тесты: проверяют взаимодействие компонентов (например, приложение + база)

end-to-end тесты: проверяют пользовательские сценарии через интерфейсы системы

Практический ориентир: чем выше уровень теста, тем он медленнее и сложнее в поддержке. Поэтому основу обычно составляют юнит-тесты, а более высокие уровни покрывают критичные сценарии.

Quality gate — это правило “не пропускаем дальше, пока не выполнено условие”. Примеры:

тесты прошли

линтер не нашёл критических ошибок

статический анализ не обнаружил проблем определённого уровня

Статические проверки

Даже без запуска приложения можно выявлять проблемы:

линтеры (стиль, потенциальные ошибки)

статический анализ кода (поиск дефектов)

проверка лицензий и зависимостей

Подход “сломай сборку при нарушении правил” дисциплинирует, но важно не превращать CI в источник постоянных ложных срабатываний.

Безопасность в пайплайне: DevSecOps на практике

DevSecOps в контексте CI/CD означает: проверки безопасности запускаются автоматически и как можно раньше.

Что часто добавляют в пайплайн:

SAST: статический анализ исходного кода на уязвимости

проверка зависимостей: поиск известных уязвимостей в библиотеках

container image scanning: проверка Docker-образов на уязвимости

secret scanning: поиск случайно закоммиченных токенов и паролей

Важно правильно работать с секретами:

не хранить секреты в репозитории

использовать секрет-хранилища CI-системы

ограничивать доступы по принципу минимальных прав

Ориентиры по теме:

OWASP DevSecOps Guideline

OpenSSF Scorecard

CD: доставка и развёртывание как управляемый процесс

Стратегии доставки

Доставка — это продвижение артефакта по средам и применение конфигурации.

Типовые стратегии деплоя:

rolling update: постепенная замена экземпляров сервиса

blue-green: есть две версии окружения, переключение происходит быстро

canary: новая версия получает малую долю трафика, затем доля увеличивается

Мы вернёмся к этим стратегиям в Kubernetes, потому что там они реализуются особенно удобно.

Продвижение артефакта

Хорошая практика CD:

собрали артефакт один раз

опубликовали его в хранилище (например, registry для Docker-образов)

дальше разворачиваем тот же артефакт, меняя только конфигурацию среды

Откат и “break glass”

Откат должен быть предусмотрен заранее:

храните предыдущие версии артефактов

имейте простой способ вернуться на предыдущую версию

документируйте аварийный сценарий “break glass” (когда допускается ручное вмешательство)

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

Git как источник правды и варианты ветвления

CI/CD почти всегда строится вокруг Git. Есть два популярных подхода:

trunk-based development: короткие ветки, частые мерджи в основную ветку, минимизация “долгоживущих” веток

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

Для DevOps-целей часто предпочтителен trunk-based подход, потому что он уменьшает размер изменений и ускоряет обратную связь.

Пример: минимальный CI пайплайн

Ниже пример простого пайплайна, который:

собирает проект

запускает тесты

публикует артефакт (условно)

Пример в стиле GitHub Actions:

Что важно в этом примере:

пайплайн запускается на pull request и на push в main

зависимости ставятся воспроизводимо через npm ci

проверки отделены по шагам, чтобы быстрее локализовать проблему

Официальные справочники по CI-системам, которые часто встречаются в индустрии:

GitHub Actions Documentation

GitLab CI/CD Documentation

Jenkins User Documentation

Типичные ошибки и анти-паттерны CI/CD

“зелёный пайплайн ничего не гарантирует”: тесты слабые, нет проверок критичных сценариев.

слишком долгий CI: разработчики начинают избегать пайплайна, копят изменения.

пайплайн не в репозитории: настройки живут “в интерфейсе”, теряется контроль версий.

разные способы доставки: часть деплоев через пайплайн, часть вручную.

секреты в коде: токены попадают в Git и остаются в истории.

Как понять, что CI/CD работает

CI/CD нужно измерять так же, как и DevOps-процессы. Полезные метрики:

время выполнения пайплайна

доля “красных” сборок и причины падений

среднее время от коммита до деплоя

частота релизов и доля откатов

Эти показатели связаны с метриками DORA, о которых мы говорили в контексте DevOps.

Что дальше по курсу

Следующий практический шаг после CI/CD — научиться упаковывать приложения в контейнеры и доставлять их в Kubernetes. CI будет собирать и проверять код, а CD — продвигать артефакты и применять конфигурацию.

В дальнейших темах мы свяжем CI/CD с:

контейнеризацией и сборкой Docker-образов

registry (хранилищем образов)

стратегиями деплоя в Kubernetes

GitOps-подходом, где Git хранит желаемое состояние кластера

Контейнеризация: Docker, образы, реестры и лучшие практики

Как контейнеризация связывает DevOps и CI/CD

В предыдущих темах мы разобрали, как DevOps-практики и CI/CD превращают изменения в Git в проверенный результат: сборка, тесты, контроль качества, доставка. Следующий логичный шаг — сделать результат воспроизводимым и переносимым между средами.

Контейнеризация решает классическую проблему: «на моём ноутбуке работает, а в staging/production — нет». Вместо того чтобы надеяться на одинаковые версии библиотек и настроек ОС на всех серверах, мы упаковываем приложение вместе с его зависимостями в контейнерный образ, который:

одинаково запускается на разных машинах

удобно версионируется

легко доставляется через реестр образов

естественно встраивается в CI/CD

В Kubernetes именно контейнерные образы становятся базовой единицей доставки приложения в кластер.

!Цепочка от кода до запущенного контейнера через CI/CD и реестр

Базовые термины

Контейнер

Контейнер — это запущенный из образа изолированный процесс (или набор процессов) в ОС, который использует:

изоляцию ресурсов (пространства имён, cgroups)

файловую систему, собранную из слоёв образа

конфигурацию запуска (команда, переменные окружения, порты)

Важно: контейнер — это не виртуальная машина. Он разделяет ядро ОС с хостом.

Образ

Образ (image) — это неизменяемый шаблон, из которого создаются контейнеры. Внутри образа:

файловая система приложения и зависимостей

метаданные (какая команда запускается, рабочая директория, переменные)

Образ можно:

собрать из Dockerfile

пронумеровать версией (тегом)

загрузить в реестр

Реестр образов

Реестр (registry) — это хранилище контейнерных образов, откуда их можно скачивать (pull) и куда можно публиковать (push). Примеры:

Docker Hub

GitHub Container Registry

Docker

Docker — популярный набор инструментов для сборки и запуска контейнеров: docker build, docker run, docker push/pull.

Документация:

Docker documentation

OCI и совместимость

Чтобы контейнерные образы были переносимыми между инструментами и реестрами, существует стандарт OCI:

Open Container Initiative

Практический смысл: образ, собранный «в докер-стиле», обычно можно использовать и без Docker (например, через containerd в Kubernetes).

Как устроен контейнерный образ: слои и кеш

Слои образа

Обычно образ состоит из слоёв (layers). Каждый слой — результат шага сборки (например, RUN apt-get ... или COPY ...). Это даёт два важных эффекта:

ускорение сборки за счёт кеширования

экономия места и трафика (переиспользуются одинаковые слои)

!Наглядно показывает, почему порядок команд в Dockerfile влияет на скорость сборки

Контекст сборки и .dockerignore

docker build отправляет в сборщик контекст — файлы из директории сборки. Если контекст большой (например, вы отправляете node_modules, логи, артефакты), сборка становится медленнее и может случайно утащить лишнее в образ.

Файл .dockerignore исключает ненужные файлы из контекста.

Dockerfile: минимальная база

Dockerfile — текстовый рецепт сборки образа. Часто используемые инструкции:

FROM — базовый образ

WORKDIR — рабочая директория

COPY — копирование файлов в образ

RUN — команды сборки (установка зависимостей)

ENV и ARG — переменные окружения и аргументы сборки

EXPOSE — документирование порта

USER — пользователь, от которого работает процесс

CMD и ENTRYPOINT — команда запуска

Официальная справка:

Dockerfile reference

Пример: простой Dockerfile для веб-приложения

Что важно в примере:

сначала копируются файлы зависимостей, затем выполняется npm ci — это помогает кешированию

только после этого копируется остальной код — изменение кода не ломает кеш установки зависимостей

Теги, версии и digest: как правильно ссылаться на образ

Тег

Тег (tag) — это человекочитаемая метка, например:

myapp:1.4.2

myapp:latest

Тег — подвижная ссылка: сегодня latest может указывать на один образ, завтра — на другой.

Digest

Digest — это контент-идентификатор образа (хэш), например sha256:.... Он:

однозначно указывает на конкретный образ

полезен для воспроизводимости и безопасности

Практика для production:

в деплоях фиксировать версии (теги)

для максимальной неизменяемости — фиксировать digest (часто уже на уровне GitOps/манифестов)

Реестры образов: публикация и скачивание

Базовые команды

Сборка:

Публикация в реестр:

Скачивание:

Запуск:

Аутентификация

Для приватных реестров обычно нужно выполнить вход:

В CI/CD это делается через секреты (токены/пароли), которые хранит CI-система, а не репозиторий.

Встраивание контейнеров в CI/CD

Контейнерная сборка — типичный этап пайплайна:

собрать образ

прогнать тесты (часто до сборки или внутри сборки)

просканировать образ на уязвимости

запушить образ в реестр

передать версию дальше в CD

Пример: сборка и публикация образа в GitHub Actions

Идея, которую важно унести:

CI публикует версионированный артефакт (образ)

CD разворачивает в окружения один и тот же образ, меняя только конфигурацию

Документация используемых action-ов:

docker/login-action

docker/build-push-action

Лучшие практики Docker-образов

Минимизируйте размер и поверхность атаки

используйте небольшие базовые образы (например, alpine там, где это уместно)

удаляйте временные файлы и кеши пакетных менеджеров

устанавливайте только нужные зависимости

Фиксируйте версии и делайте сборку воспроизводимой

избегайте плавающих версий базовых образов без необходимости

используйте lock-файлы зависимостей (package-lock.json, poetry.lock)

по возможности фиксируйте базовый образ по digest

Используйте multi-stage build

Multi-stage build позволяет разделить:

стадию сборки (компиляторы, dev-зависимости)

стадию runtime (только то, что нужно для запуска)

Пример:

Польза:

итоговый образ меньше

меньше лишних утилит внутри контейнера

Справка:

Multi-stage builds

Запускайте процесс не от root

Запуск от root внутри контейнера повышает риск при уязвимостях приложения. Практика:

создавайте пользователя

используйте USER в Dockerfile

выставляйте корректные права на директории

Справка по рискам и рекомендациям:

Docker security

Не кладите секреты в образ

Анти-паттерны:

COPY .env .

ENV DB_PASSWORD=...

скачивание приватных ключей на этапе сборки без контроля

Вместо этого:

передавайте секреты на этапе запуска (переменные окружения/secret store)

используйте секреты CI для доступа к реестрам и приватным зависимостям

Оптимизируйте кеш Dockerfile

выносите установку зависимостей выше, чем копирование исходников

держите редко меняющиеся шаги ближе к началу Dockerfile

используйте .dockerignore, чтобы не ломать кеш случайными файлами

Добавляйте метаданные и проверяйте образ

Полезные практики для зрелого процесса:

добавлять метки (labels) с версией, ссылкой на репозиторий, commit SHA

сканировать образы на уязвимости до публикации

Одна из популярных категорий инструментов для сканирования — Trivy:

Trivy documentation

Частые ошибки и анти-паттерны

сборка образа на production-сервере вручную

использование latest для production без контроля

огромный контекст сборки и отсутствие .dockerignore

хранение секретов в образе или в репозитории

отсутствие версионирования образов (невозможно откатиться)

запуск контейнера от root без необходимости

Что дальше в курсе

Контейнеризация завершает цепочку «код → проверка → артефакт». Дальше мы перейдём к тому, как этот артефакт (контейнерный образ) запускается и управляется в Kubernetes:

как Kubernetes скачивает образы из реестров

как описывать деплой приложения декларативно

как реализуются стратегии rolling/canary/blue-green на практике

как GitOps связывает версию образа и конфигурацию кластера

Kubernetes: архитектура и базовые объекты для деплоя

Зачем Kubernetes после CI/CD и контейнеров

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

Kubernetes решает эту задачу как платформа оркестрации контейнеров: вы описываете желаемое состояние (сколько экземпляров сервиса должно работать, какие порты открыть, какие переменные окружения использовать), а Kubernetes непрерывно приводит фактическое состояние к желаемому.

Официальная документация: Kubernetes Documentation.

Ментальная модель Kubernetes

Декларативность и цикл согласования

Kubernetes работает по принципу:

вы отправляете в кластер декларативное описание объектов (обычно YAML-манифесты)

кластер сохраняет это описание как желаемое состояние

контроллеры Kubernetes постоянно сравнивают желаемое состояние с реальностью и исправляют расхождения

Эта идея тесно связана с DevOps и IaC: манифесты можно хранить в Git, ревьюить и доставлять через CD или GitOps.

Что такое кластер

Кластер Kubernetes состоит из:

control plane: компоненты управления, принимающие решения и хранящие состояние

worker nodes: узлы, где реально запускаются контейнеры

!Общая архитектура кластера и роли основных компонентов

Архитектура: основные компоненты

Control plane

kube-apiserver

- центральная точка входа: все изменения (kubectl, CI/CD, операторы) идут через API - проверяет права доступа, валидирует запросы и записывает состояние - документация: kube-apiserver

etcd

- распределенное хранилище, где лежит состояние кластера (какие объекты созданы и какие у них спецификации) - документация: etcd

kube-scheduler

- выбирает подходящий узел, куда поставить новый Pod, учитывая ресурсы и ограничения - документация: kube-scheduler

kube-controller-manager

- запускает контроллеры, которые “дожимают” состояние до желаемого (например, чтобы было ровно 3 реплики) - документация: kube-controller-manager

Worker node

kubelet

- агент на узле: получает от control plane описание Pod и обеспечивает их запуск - следит за состоянием контейнеров и сообщает его обратно - документация: kubelet

container runtime

- компонент, который реально запускает контейнеры (часто containerd) - Kubernetes использует стандарт CRI - справка: Container Runtimes

kube-proxy

- реализует сетевую “обвязку” для Service (маршрутизация трафика к Pod) - документация: kube-proxy

Сеть и хранилище как плагины

CNI (Container Network Interface): сетевой плагин, который обеспечивает сетевую связность Pod

- справка: Networking and Network Policy

CSI (Container Storage Interface): подключение хранилищ (диски, сетевые тома)

- справка: Volumes

Базовые объекты Kubernetes для деплоя

Ниже объекты, с которыми вы будете сталкиваться чаще всего при доставке приложений.

Namespace

Namespace — логическая “папка” внутри кластера для изоляции:

имен объектов

квот (ресурсы)

политик доступа

Документация: Namespaces.

Pod

Pod — минимальная единица запуска в Kubernetes.

Pod может включать один или несколько контейнеров

контейнеры внутри Pod разделяют сеть (один IP на Pod) и могут разделять тома

Pod считается “одноразовым”: если он умер, Kubernetes чаще создаст новый Pod, а не “починит” старый

Документация: Pods.

ReplicaSet

ReplicaSet поддерживает заданное количество одинаковых Pod.

если Pod исчез — создаст новый

обычно вы не создаете ReplicaSet вручную: это делает Deployment

Документация: ReplicaSet.

Deployment

Deployment — главный объект для деплоя stateless-приложений.

Deployment обеспечивает:

управление ReplicaSet и Pod

rolling update (постепенное обновление версии)

откат на прошлую ревизию

Документация: Deployments.

Service

Service дает стабильную точку доступа к группе Pod.

Проблема, которую решает Service:

Pod создаются и удаляются, их IP меняются

клиентам нужен стабильный адрес и балансировка

Типовые варианты Service:

ClusterIP: доступен только внутри кластера

NodePort: открывает порт на каждом узле (простая публикация наружу)

LoadBalancer: просит облако создать внешний балансировщик (если кластер в облаке)

Документация: Service.

Ingress

Ingress описывает правила HTTP/HTTPS-доступа извне к сервисам внутри кластера.

Важно:

Ingress — это только правила

чтобы они работали, нужен Ingress Controller (например, NGINX Ingress Controller или другой)

Документация: Ingress.

ConfigMap и Secret

Эти объекты отделяют конфигурацию от контейнерного образа, что напрямую продолжает практики из CI/CD и контейнеризации.

ConfigMap: несекретная конфигурация (строки, файлы конфигов)

Secret: секретные данные (токены, пароли, ключи)

Важно: Secret в Kubernetes по умолчанию не является полноценным секрет-хранилищем, а механизмом доставки секретов в Pod. Для серьезной модели безопасности часто подключают внешние системы (например, Vault) и политики.

Документация:

ConfigMaps

Secrets

Labels и selectors

Label — это пара ключ=значение, которую вы назначаете объектам.

Labels нужны, чтобы “связывать” объекты:

Service находит нужные Pod через selector

Deployment управляет Pod по меткам

Документация: Labels and Selectors.

Как эти объекты связаны при деплое

!Связи объектов Kubernetes в типовом веб-деплое

Минимальный пример деплоя: Deployment + Service

Ниже пример “скелета”, который отражает базовую практику: один и тот же контейнерный образ (результат CI) запускается в Kubernetes, а доступ обеспечивается Service.

Deployment

Что здесь важно:

replicas: 3 задает желаемое количество Pod

selector.matchLabels и template.metadata.labels должны соответствовать, иначе Deployment не сможет управлять своими Pod

image — ссылка на контейнерный образ из реестра (то, что вы научились собирать и публиковать ранее)

Service

Смысл полей:

selector.app: web находит Pod с меткой app=web

port: 80 — порт Service (как к нему обращаются клиенты внутри кластера)

targetPort: 3000 — порт контейнера

Применение манифестов

Обычно манифесты применяют командой:

Справка по kubectl: kubectl Overview.

Обновления и откаты: почему Deployment удобен для CD

Deployment хранит историю ревизий и умеет обновляться постепенно.

Типовой жизненный цикл версии:

CI собирает новый образ и публикует его в реестр

CD меняет image в манифесте Deployment (например, с 1.0.0 на 1.0.1)

Kubernetes выполняет rolling update, заменяя Pod постепенно

если метрики и наблюдаемость показывают проблему, можно откатить Deployment

Документация: Rolling Update Deployment.

Конфигурация и секреты: отделяем образ от среды

Контейнерный образ должен быть одинаковым для dev, staging и production, а отличаться должна конфигурация.

Типовые способы доставить конфигурацию в Pod:

переменные окружения из ConfigMap/Secret

файлы конфигурации через volume, созданный из ConfigMap/Secret

Пример фрагмента контейнера с переменными окружения:

Здесь:

configMapKeyRef берет значение из ConfigMap

secretKeyRef берет значение из Secret

Таблица: какой объект за что отвечает

| Объект | Задача | Типичное применение | |---|---|---| | Namespace | Логическая изоляция | Разделение сред и команд | | Pod | Запуск контейнеров | Базовая единица выполнения | | ReplicaSet | Количество Pod | Почти всегда через Deployment | | Deployment | Обновления и реплики | Stateless-сервисы, API, веб | | Service | Стабильный доступ к Pod | Внутрикластерный доступ и балансировка | | Ingress | HTTP/HTTPS маршрутизация | Публичный вход в кластер | | ConfigMap | Несекретная конфигурация | Настройки приложений | | Secret | Секреты | Пароли, токены, ключи |

Практические замечания для реальной эксплуатации

Не рассчитывайте на “вечность” Pod: проектируйте сервис так, чтобы Pod можно было безопасно пересоздать.

Не используйте latest для production-образов: версионируйте образы и делайте откаты воспроизводимыми.

Разделяйте ответственность:

- образ и код поставляет CI - манифесты и конфигурацию продвигает CD или GitOps

Сразу продумывайте наблюдаемость: обновления без сигналов (метрики, логи) превращаются в риск.

Что дальше по курсу

Эта статья дала архитектурную базу и минимальный набор объектов для деплоя. Далее логично углубляться в эксплуатационные аспекты Kubernetes:

стратегии деплоя на практике (rolling, canary, blue-green)

health checks (liveness/readiness), requests/limits и autoscaling

хранение данных (PersistentVolume) и сетевые политики

GitOps для доставки манифестов и управления версиями в кластере

Эксплуатация Kubernetes: безопасность, наблюдаемость и масштабирование

Как эта тема продолжает курс

Ранее мы выстроили цепочку код → CI/CD проверки → контейнерный образ → деплой через базовые объекты Kubernetes (Deployment/Service/Ingress/ConfigMap/Secret). Эксплуатация кластера начинается там, где заканчивается «просто запустить Pod»: нужно обеспечить безопасность, наблюдаемость и масштабирование так, чтобы система оставалась управляемой при росте нагрузки и команды.

Эта статья даёт практическую опору для работы production-кластера:

безопасность на уровнях доступа, Pod и сети

наблюдаемость через метрики, логи, трассировки и алерты

масштабирование приложений и кластера, а также управление ресурсами

!Три эксплуатационных контура вокруг кластера

Безопасность Kubernetes

Безопасность в Kubernetes всегда многослойна: если вы полагаетесь на один механизм (например, только на Secret), система остаётся уязвимой.

Аутентификация и авторизация: кто может что делать

Аутентификация отвечает на вопрос: кто ты? (пользователь, сервисный аккаунт, CI/CD-бот). Авторизация отвечает: что тебе можно?.

В Kubernetes чаще всего используется модель:

доступ к API кластера

проверка прав через RBAC

RBAC (Role-Based Access Control) связывает субъект (пользователь или ServiceAccount) с набором разрешений.

Ключевые объекты RBAC:

Role и RoleBinding действуют в пределах Namespace

ClusterRole и ClusterRoleBinding действуют на весь кластер

Документация: Using RBAC Authorization.

Практические принципы:

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

разделение сред через Namespace и разные наборы ролей

отдельные ServiceAccount для приложений, для CI/CD и для операторов

Admission-контроль: как не пустить опасные манифесты в кластер

Даже если пользователь имеет право создавать Pod, кластер может дополнительно проверять «качество» и безопасность объекта на входе.

В Kubernetes это делает admission control.

Из практических механизмов, которые стоит знать:

Pod Security Standards и режимы Pod Security Admission

ValidatingAdmissionPolicy (валидирующие политики)

Документация:

Pod Security Standards

Pod Security Admission

Validating Admission Policy

Смысл для эксплуатации: вы формализуете правила вроде «запрещены привилегированные контейнеры» или «нельзя запускать от root», и кластер сам блокирует нарушения.

SecurityContext: как запускать контейнер безопаснее

SecurityContext задаёт параметры безопасности для Pod или контейнера.

Что обычно фиксируют в production:

запрет привилегированного режима

запрет повышения привилегий

запуск не от root

ограничение Linux capabilities

read-only файловая система там, где возможно

Документация: Configure a Security Context for a Pod or Container.

Пример фрагмента манифеста:

Важно: это не «магическая защита», а снижение последствий, если в приложении есть уязвимость.

Secrets: доставка секретов и типичные ошибки

Secret в Kubernetes — это объект для доставки секретов в Pod (например, через переменные окружения или volume). Это не полноценное секрет-хранилище «само по себе».

Документация: Secrets.

Практики:

не хранить секреты в Git в открытом виде

ограничивать доступ к Secret через RBAC

не печатать секреты в логах

рассмотреть шифрование secret-данных в etcd

Про шифрование: Encrypting Secret Data at Rest.

Сетевая безопасность: NetworkPolicy

По умолчанию сеть между Pod часто устроена так, что «всё со всем может общаться» внутри кластера. Для production обычно нужен принцип default deny и явные разрешения.

NetworkPolicy позволяет определить, какие Pod могут принимать и устанавливать соединения.

Документация: Network Policies.

Важное уточнение: NetworkPolicy работает только если ваш CNI-плагин поддерживает политики.

Безопасность цепочки поставки: образы и реестры

Из прошлой статьи про контейнеризацию следует эксплуатационный вывод: образ — ваш главный артефакт, и его нужно контролировать.

Что обычно вводят:

запрет :latest в production

сканирование образов на уязвимости в CI

контроль того, откуда можно скачивать образы (разрешённые реестры)

подпись образов и проверка подписи на деплое (в зрелых процессах)

Базовая отправная точка по теме безопасности образов в Kubernetes: Container image security.

Наблюдаемость: метрики, логи, трассировка

Наблюдаемость отвечает на вопрос: что происходит с приложением и кластером прямо сейчас, и почему? В DevOps-процессе это основа безопасных релизов, canary/rolling-обновлений и быстрого восстановления.

Классическая «тройка сигналов»:

метрики: численные показатели во времени (latency, RPS, ошибки, ресурсы)

логи: события и сообщения

трейсы: путь запроса через компоненты

Health checks: readiness и liveness

В Kubernetes критично правильно настроить проверки контейнеров, иначе вы получаете:

трафик на Pod, который ещё не готов

бесконечные рестарты при временной деградации

Основные probes:

readinessProbe: можно ли направлять трафик в Pod

livenessProbe: жив ли процесс, нужно ли перезапускать

startupProbe: отделяет «долгий старт» от «подвисшего старта»

Документация: Configure Liveness, Readiness and Startup Probes.

Мини-пример:

Метрики: что измерять в первую очередь

На старте важно не пытаться измерить всё. Полезный минимальный набор:

метрики приложения: ошибки, задержки, количество запросов

метрики ресурсов Pod: CPU/память

метрики состояния: количество реплик, рестарты, падения

Де-факто стандарт в экосистеме Kubernetes — Prometheus для сбора метрик.

Prometheus Documentation

Для метрик состояния объектов Kubernetes часто используют kube-state-metrics:

kube-state-metrics

Логи: централизованный сбор и структура

Базовая практика для контейнеров: приложение пишет логи в stdout/stderr, а платформа собирает их централизованно.

С точки зрения Kubernetes полезно понимать:

как смотреть логи конкретного Pod: kubectl logs

что логи на узле — это не централизованное хранение, и Pod может исчезнуть

почему стоит писать структурированные логи (например, JSON), чтобы проще фильтровать

Документация по логированию: Logging Architecture.

Трейсы: почему без них сложно в микросервисах

Если запрос проходит через несколько сервисов, логи и метрики часто не отвечают на вопрос «где именно потеряли время». Для этого нужна распределённая трассировка.

Стандарт для инструментирования — OpenTelemetry:

OpenTelemetry Documentation

Алертинг: сигнал, а не шум

Алертинг нужен не «на все метрики», а на симптомы, влияющие на пользователя.

Практические ориентиры:

алерт на ошибки и недоступность важнее алерта на высокую CPU

алерт должен вести к действию: что проверить, как смягчить проблему

фиксируйте действия в runbook

Полезная концепция, если вы строите зрелую эксплуатацию: SRE-подход к сигналам и ошибкам.

Site Reliability Engineering (книга)

!Поток метрик, логов и трассировок от Pod до дашбордов и алертов

Масштабирование и управление ресурсами

Масштабирование в Kubernetes — это не только «добавить реплики». Нужно управлять ресурсами и доступностью так, чтобы масштабирование не ломало соседей по кластеру.

Requests и limits: база для планирования и стабильности

Для каждого контейнера можно указать:

requests: сколько ресурсов контейнеру гарантируют для планирования

limits: сколько контейнер максимум может потреблять

Почему это важно:

scheduler размещает Pod, исходя из requests

без requests кластер сложно «упаковывать», возникают неожиданные просадки

limits помогают не дать одному сервису «съесть» узел

Документация: Resource Management for Pods and Containers.

Мини-пример:

Упрощённое чтение значений:

200m CPU — это 0.2 ядра

256Mi — 256 мебибайт памяти

Автоскейлинг приложений: HPA

Horizontal Pod Autoscaler (HPA) увеличивает или уменьшает число реплик в Deployment (или другом контроллере) в зависимости от метрик.

Самый частый вариант — масштабирование по CPU, но в зрелых системах масштабируют по прикладным метрикам (например, RPS или длине очереди).

Документация: Horizontal Pod Autoscaler.

Важно понимать зависимость:

чтобы HPA работал по CPU/памяти, нужен компонент метрик (часто metrics-server)

HPA не заменяет правильные requests/limits: они делают масштабирование предсказуемым

Масштабирование кластера: Cluster Autoscaler

Если HPA увеличил число Pod, но узлам не хватает ресурсов, вам нужно масштабирование самого кластера.

Cluster Autoscaler добавляет или убирает worker-ноды в зависимости от того, есть ли неразмещённые Pod.

Cluster Autoscaler

Практическая модель:

HPA масштабирует приложение

Cluster Autoscaler масштабирует инфраструктуру

Доступность во время обновлений и сбоев: PDB

Во время rolling update, ремонта ноды или аварийного выселения Pod можно случайно потерять слишком много реплик.

PodDisruptionBudget (PDB) позволяет задать, сколько Pod может быть недоступно при добровольных прерываниях.

Документация: Pod Disruption Budgets.

Польза:

повышает доступность при обслуживании

делает поведение кластера более предсказуемым

Квоты и лимиты на Namespace: защита от «соседей»

В многокомандном кластере важно, чтобы одна команда не «съела» все ресурсы.

Инструменты:

ResourceQuota: ограничивает суммарные ресурсы в Namespace

LimitRange: задаёт дефолты и границы requests/limits

Документация:

Resource Quotas

Limit Ranges

Типичные ошибки эксплуатации

слишком широкие права в RBAC (например, cluster-admin для CI/CD без необходимости)

отсутствие NetworkPolicy в кластере с несколькими командами

секреты попадают в логи или в Git

нет readinessProbe, из-за чего трафик идёт в неготовые Pod

HPA включили, но requests не задали, и кластер ведёт себя непредсказуемо

нет PDB, и при обслуживании падает доступность

Как собрать это в единую практику

Один из рабочих путей внедрения по шагам:

Ввести базовую модель доступа: Namespace, RBAC, отдельные ServiceAccount.

Зафиксировать минимальные требования к Pod: Pod Security Admission, SecurityContext.

Определить сетевую модель: начать с NetworkPolicy для критичных сервисов.

Включить наблюдаемость: probes, метрики, централизованные логи, базовые алерты.

Настроить управление ресурсами: requests/limits, затем HPA.

Дорастить инфраструктуру: Cluster Autoscaler, PDB, квоты.

Эта последовательность связывает темы курса: CI/CD и контейнеры дают воспроизводимый артефакт, Kubernetes-объекты дают декларативный деплой, а эксплуатационные практики делают систему безопасной и устойчивой.