Kubernetes на реальных примерах - UPROGER

Этот гайд предназначен для освоения Kubernetes — платформы для оркестрации контейнеров. Программа рассчитана на новичков и постепенно подводит слушателя к уровню опытного пользователя. Каждый урок снабжён примерами и тестовыми вопросами для проверки знаний.

🖥 На Stepik вышел курс, который учит работать с Docker на реальных проектах – лучший вход в работу с контейнерами.

Модуль 1. Знакомство с Kubernetes

Урок 1. Что такое Kubernetes

Описание:

Kubernetes — это платформа с открытым исходным кодом для управления контейнеризованными приложениями, которая автоматизирует развёртывание, масштабирование и управление контейнерами.
Она была разработана компанией Google и передана в Cloud Native Computing Foundation (CNCF). Платформа помогает запускать микросервисные приложения и упрощает администрирование.
Основные задачи: оркестрация контейнеров, управление ресурсами, самоисцеление (перезапуск упавших контейнеров) и автоматическое масштабирование.

Пример: простая веб‑служба, написанная на Python, упаковывается в образ Docker и развертывается в Kubernetes, который автоматически создаёт несколько копий контейнера и балансирует запросы между ними.

Тест:

Что такое Kubernetes?
1. Операционная система для запуска виртуальных машин.
2. Платформа для оркестрации контейнеров, автоматизирующая развёртывание и масштабирование приложений. ✅
3. Язык программирования для разработки микросервисов.
4. База данных для хранения контейнеров.
Какую задачу решает Kubernetes?
1. Управляет только сетевым трафиком.
2. Автоматизирует развёртывание, масштабирование и мониторинг контейнеризованных приложений. ✅
3. Служит для проектирования микросхем.
4. Является текстовым редактором.
Какая организация развивает Kubernetes?
1. Cloud Native Computing Foundation (CNCF). ✅
2. Apache Software Foundation.
3. Mozilla Foundation.
4. FreeBSD Foundation.

Урок 2. Архитектура кластера

Описание:

Кластер Kubernetes состоит из управляющих компонентов (control plane) и рабочих узлов (nodes). Узел — это «рабочая машина» (виртуальная или физическая), на которой запускаются подыkubernetes.io.
Управляющая плоскость включает API‑сервер, планировщик (scheduler) и controller manager — службы, которые принимают решения о размещении подов, следят за состоянием и управляют инфраструктурой.
На каждом рабочем узле работает kubelet (агент, отвечающий за связь с управляющей плоскостью), а также контейнерный runtime (например, containerd или Docker), который запускает контейнерыkubernetes.io.
Контрольная плоскость распределяет поды по узлам, следя за доступными ресурсами и состоянием компонентов. При необходимости перезапускает контейнеры или переносит их на другие узлы.

Тест:

Что такое «узел» (Node) в Kubernetes?
1. Веб‑сервер, который обслуживает пользователей.
2. Рабочая машина (физическая или виртуальная), на которой запускаются поды и которая управляется контрольной плоскостьюkubernetes.io. ✅
3. Отдельный контейнер в кластере.
4. База данных для хранения образов.
Какие компоненты обычно работают на каждом узле?
1. Только API‑сервер.
2. kubelet и контейнерный runtime (например, containerd)kubernetes.io. ✅
3. Только Git‑сервер.
4. Планировщик и controller manager.
За что отвечает планировщик (scheduler)?
1. За загрузку образов контейнеров из интернета.
2. За выбор узла, на котором будет запущен новый под, учитывая доступные ресурсы. ✅
3. За хранение данных в кластере.
4. За обновление ядра операционной системы.

Урок 3. Основные объекты Kubernetes

Описание:

Под (Pod) — наименьшая единица развертывания в Kubernetes. Под представляет собой группу из одного или нескольких контейнеров с общей сетью и дисковым пространством. Поды предназначены для совместного запуска тесно связанных контейнеровkubernetes.io.
Сервис (Service) — абстракция, позволяющая объединить набор подов и предоставить им стабильную точку доступа в сети. Сервис решает проблему обнаружения подов и балансировки нагрузкиkubernetes.io.
Deployment — контроллер, который управляет набором подов и обеспечивает декларативные обновления. Позволяет описать желаемое количество реплик и обновлять приложения без простоевkubernetes.io.
ReplicaSet, StatefulSet, DaemonSet — другие контроллеры для управления подами (со статическим именованием, состоянием или запуском по одному экземпляру на каждом узле).
ConfigMap и Secret — хранилища для конфигурации и секретов, монтируемые в контейнеры.

Тест:

Что такое Pod?
1. Группа из одного или более контейнеров с общим сетевым и дисковым пространствомkubernetes.io. ✅
2. Система для управления дисками.
3. Отдельная виртуальная машина.
4. Скрипт для развертывания приложений.
Для чего используется Service?
1. Для установки операционной системы.
2. Для экспонирования набора подов через единый сетевой адрес и балансировку нагрузкиkubernetes.io. ✅
3. Для хранения секретов.
4. Для управления версиями контейнеров.
Что делает Deployment?
1. Управляет обновлениями и количеством реплик подов в декларативном стилеkubernetes.io. ✅
2. Создаёт базы данных.
3. Настраивает сетевые правила.
4. Изолирует сеть контейнеров.

Модуль 2. Поды и контейнеры

Урок 1. Поды и контейнеры в Kubernetes

Описание:

Под — это оболочка вокруг контейнера(ов). В Kubernetes принято помещать один контейнер в под, но иногда требуется несколько контейнеров, которые должны быть совместно запущены (sidecar‑контейнеры). Поды имеют общий IP‑адрес и точки монтирования.
Создание пода с помощью YAML‑манифеста: в секции apiVersion: v1, kind: Pod указываются метаданные и описание контейнеров. Пример nginx‑пода:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

Поды обычно создаются через контроллеры (Deployment, Job и др.), а не напрямую. Контроллеры обеспечивают управление жизненным циклом и масштабированиеkubernetes.io.

Тест:

Что является основной единицей развертывания в Kubernetes?
1. Контейнер Docker.
2. Под (Pod). ✅
3. Узел (Node).
4. ClusterIP.
Сколько контейнеров может содержать под?
1. Всегда один.
2. Один или несколько, которые должны быть совместно запущены. ✅
3. Не более двух.
4. Столько же, сколько узлов в кластере.
Что рекомендуется использовать для создания подов в большинстве случаев?
1. Контроллеры (например, Deployment), обеспечивающие управление и масштабированиеkubernetes.io. ✅
2. Ручное создание командой kubectl create pod.
3. Запуск подов через cron.
4. Использование внешних скриптов.

Урок 2. Жизненный цикл и управление подами

Описание:

Поды считаются эфемерными объектами: при удалении пода его данные исчезают (если они не вынесены в постоянное хранилище). Контроллеры (Deployment, ReplicaSet) отвечают за создание и удаление подов при изменении состояния.
Каждому поду назначается уникальный IP‑адрес; при перезапуске будет назначен новый IP. Поэтому для обращения к подам используется сервис.
Статус пода можно просмотреть командой kubectl get pods и kubectl describe pods.
kubectl logs выводит логи контейнеров, а kubectl exec позволяет выполнять команды внутри контейнера.

Тест:

Почему поды считаются эфемерными?
1. Потому что они навсегда сохраняют данные при перезапуске.
2. Потому что при удалении пода его данные исчезают, если они не вынесены в постоянное хранилище. ✅
3. Потому что они работают только на Windows.
4. Потому что к ним нельзя подключиться.
Какая команда показывает список подов в текущем пространстве имён?
1. kubectl logs.
2. kubectl get pods. ✅
3. kubectl apply.
4. kubectl scale.
Для чего используется команда kubectl exec?
1. Для вывода списка подов.
2. Для запуска команды внутри контейнера пода. ✅
3. Для удаления пода.
4. Для создания сервиса.

Урок 3. Контроллеры: ReplicaSet, Deployment и StatefulSet

Описание:

ReplicaSet гарантирует наличие заданного количества реплик подов. Контроллер следит за количеством живых подов и создаёт/удаляет их при отклонении от желаемого состояния.
Deployment предоставляет декларативные обновления ReplicaSet и подов. Он позволяет задать желаемое состояние приложения, а контроллер плавно обновит поды, создавая новые и удаляя старыеkubernetes.io.
StatefulSet используется для приложений, которым требуется сохранение идентичности подов (имена, упорядоченный запуск/остановка) и стабильное хранилище. Применяется для баз данных, распределённых систем.
DaemonSet гарантирует, что на каждом узле будет запущен один экземпляр пода (например, системный агент или мониторинг).

Тест:

Что обеспечивает ReplicaSet?
1. Управление конфигурацией контейнеров.
2. Поддержание заданного количества реплик подов, автоматическое создание/удаление. ✅
3. Управление секретами.
4. Создание ingress‑контроллеров.
Какие преимущества даёт Deployment по сравнению с прямым использованием ReplicaSet?
1. Deployment позволяет описывать желаемое состояние и обеспечивает атомарные обновления и откаты версий без простоя приложенияkubernetes.io. ✅
2. Он служит для хранения секретов.
3. Он предоставляет доступ по постоянному IP‑адресу.
4. Он автоматически монтирует тома.
Для чего нужен StatefulSet?
1. Для приложений с хранимым состоянием и требованием уникальных имён подов (например, базы данных). ✅
2. Для балансировки сетевого трафика.
3. Для управления конфигурационными файлами.
4. Для сборки Docker‑образов.
Что делает DaemonSet?
1. Запускает поды только на одном узле.
2. Гарантирует, что на каждом узле кластера будет запущен один экземпляр пода (например, для мониторинга). ✅
3. Создаёт секреты.
4. Управляет масштабированием.

Модуль 3. Развёртывание и управление рабочими нагрузками

Урок 1. Создание и обновление Deployment

Описание:

Deployment управляет ReplicaSet и подами. Он позволяет описать желаемое количество копий приложения и автоматизировать процесс обновления. Чтобы создать Deployment, используется манифест apiVersion: apps/v1, kind: Deployment. В нём указывают имя, количество реплик и шаблон пода.
Обновление Deployment происходит постепенно: создаётся новый ReplicaSet, а старые поды удаляются по мере появления новыхkubernetes.io. Это обеспечивает непрерывность работы приложения.
Команды kubectl apply -f deployment.yaml создают/обновляют Deployment, а kubectl rollout status deployment/<name> показывает статус развёртывания.

Тест:

Что описывается в Deployment?
1. Только конфигурация узлов.
2. Декларативное состояние приложения (количество реплик, образ контейнера), которое должен поддерживать контроллер. ✅
3. Состояние сети кластера.
4. Правила firewall.
Как происходит обновление Deployment?
1. Старые поды удаляются сразу, а новые запускаются после удаления.
2. Создаётся новый ReplicaSet с обновлённым шаблоном, затем постепенно масштабируется новый и уменьшается старый, что обеспечивает непрерывную работу приложенияkubernetes.io. ✅
3. Контейнеры обновляются внутри существующих подов.
4. Выполняется обновление ядра операционной системы.
Какая команда позволяет следить за состоянием развертывания?
1. kubectl get pods.
2. kubectl rollout status deployment/<имя> ✅
3. kubectl delete deployment.
4. kubectl proxy.

Урок 2. Управление ReplicaSet и масштабирование

Описание:

ReplicaSet обеспечивает поддержание определённого количества подов. Масштабирование можно выполнить вручную (kubectl scale deployment <имя> --replicas=<число>), указав желаемое число реплик.
Автоматическое масштабирование реализуется при помощи Horizontal Pod Autoscaler (HPA), который увеличивает или уменьшает количество реплик на основе метрик (например, загрузки CPU). Для работы HPA требуется компонент metrics‑server и объект HorizontalPodAutoscaler.
Масштабирование вниз может происходить постепенно для экономии ресурсов. Следует следить за пределами ресурсов (requests/limits) в манифестах контейнеров.

Тест:

Что делает ReplicaSet при падении одного из подов?
1. Ничего не делает.
2. Перезапускает контейнер внутри пода.
3. Создаёт новый под, чтобы поддерживать заданное количество реплик. ✅
4. Останавливает все поды.
Как называется объект для горизонтального автоматического масштабирования подов?
1. VerticalPodAutoscaler.
2. HorizontalPodAutoscaler. ✅
3. Deployment.
4. ConfigMap.
Какая команда масштабирует Deployment до указанного количества реплик?
1. kubectl delete.
2. kubectl scale deployment <имя> --replicas=<N> ✅
3. kubectl logs.
4. kubectl run.

Урок 3. StatefulSet и DaemonSet

Описание:

StatefulSet используется для приложений, которым требуются стабильные идентификаторы подов и сохранение состояния. Каждый под имеет уникальное имя (например, app-0, app-1) и может иметь привязанный PersistentVolume, который сохраняет данные при перезапуске.
DaemonSet гарантирует, что на каждом узле будет запущена одна копия пода. Это полезно для агентов мониторинга (Prometheus Node Exporter), журналирования или сетевых плагинов.
Удаляя DaemonSet, можно остановить все запущенные экземпляры на узлах. Масштабирование осуществляется автоматически при добавлении или удалении узлов.

Тест:

Для чего предназначен StatefulSet?
1. Для бессостоящих приложений.
2. Для приложений, где требуется сохранение состояния и уникальные имена подов (например, базы данных). ✅
3. Для динамического масштабирования CPU.
4. Для управления секретами.
Какое свойство отличает DaemonSet от ReplicaSet?
1. DaemonSet разворачивает поды только на одном узле.
2. DaemonSet гарантирует одну копию пода на каждом узле кластера, независимо от количества узлов. ✅
3. ReplicaSet предназначен для приложений со статусом.
4. DaemonSet обновляет контейнеры без перерыва.
Для чего пригодится DaemonSet?
1. Для развертывания сервисов балансировки.
2. Для запуска агентов мониторинга или сетевых компонентов на всех узлах. ✅
3. Для создания ConfigMap.
4. Для обновления ядер ОС.

Модуль 4. Сервисы и сетевое взаимодействие

Урок 1. Сервисы и балансировка нагрузки

Описание:

Service позволяет экспонировать набор подов через единый сетевой адрес. Он решает проблему обнаружения подов, которые могут динамически появляться и исчезать. Сервис создаётся объектом Service, где указывается селектор для выбора нужных подовkubernetes.io.
Поддерживаются типы сервисов: ClusterIP (доступ внутри кластера), NodePort (открытие порта на каждом узле), LoadBalancer (создаёт балансировщик в облаке) и ExternalName (псевдоним DNS).
Сервис работает совместно с DNS: каждому сервису назначается DNS‑имя, по которому другие поды могут обращаться к нему.
Пример простого сервиса:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  type: ClusterIP

Тест:

Какую проблему решает Service?
1. Настройку дисков.
2. Обеспечивает обнаружение подов и балансировку нагрузки между нимиkubernetes.io. ✅
3. Установку обновлений ядра.
4. Настройку логирования.
Какой тип сервиса используется для внутреннего доступа в кластере?
1. NodePort.
2. ClusterIP. ✅
3. LoadBalancer.
4. ExternalName.
Что делает Service с типом LoadBalancer?
1. Ничего не делает.
2. Создаёт внешний балансировщик нагрузки в облаке и направляет трафик на узлы кластера. ✅
3. Удаляет поды.
4. Создаёт ConfigMap.

Урок 2. Ingress и маршрут трафика

Описание:

Ingress — объект, позволяющий управлять входящим HTTP/HTTPS‑трафиком и маршрутизировать его к различным сервисам на основе правил (URL‑путь, хост). Ingress работает совместно с контроллером Ingress, который реализует фактическое перенаправление.
С помощью Ingress можно настроить SSL‑терминацию, переписывание путей и базовую аутентификацию. Это позволяет иметь один внешний IP‑адрес и обслуживать множество приложений.
Пример Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

Тест:

Что такое Ingress?
1. Объект хранения конфигураций.
2. Объект для маршрутизации входящих HTTP/HTTPS‑запросов к сервисам внутри кластера. ✅
3. Система логирования.
4. Система управления узлами.
Для чего нужен Ingress‑контроллер?
1. Для автоматизации развёртывания баз данных.
2. Для реализации правил Ingress на уровне сети и балансировщика. ✅
3. Для создания PersistentVolume.
4. Для управления секретами.
Какой тип трафика обычно обрабатывает Ingress?
1. TCP пакеты для базы данных.
2. HTTP/HTTPS‑запросы. ✅
3. ICMP‑пакеты.
4. Системные журналы.

Урок 3. Сетевые политики и безопасность

Описание:

NetworkPolicy — объект, который определяет правила сетевого взаимодействия между подами. По умолчанию, если в кластере включён сетевой плагин с поддержкой NetworkPolicy, трафик между подами разрешён. Сетевые политики могут ограничивать входящий и исходящий трафик по IP‑адресам, пространствам имён и меткам.
Пример политики, разрешающей входящий трафик только от подов с меткой access: granted:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-access
spec:
  podSelector:
    matchLabels:
      app: my-app
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: granted
    ports:
    - protocol: TCP
      port: 80

Сетевые политики важны для обеспечения безопасности приложений, особенно в многопользовательских кластерах.

Тест:

Для чего используется NetworkPolicy?
1. Для настройки ядра Linux.
2. Для ограничения сетевого трафика между подами согласно заданным правилам. ✅
3. Для обновления контейнеров.
4. Для управления хранилищем.
Что происходит, если не настроены сетевые политики и плагин поддерживает их?
1. Весь трафик блокируется.
2. Весь трафик разрешён. ✅
3. Сеть перезапускается.
4. Настраиваются только исходящие соединения.
Какие параметры используются в правилах NetworkPolicy?
1. Подсети и версии ядра.
2. IP‑диапазоны, метки подов, пространства имён и порты. ✅
3. Только имена сервисов.
4. Количество реплик Deployment.

Модуль 5. Хранение данных и конфигурация

Урок 1. Томa и постоянные тома

Описание:

В Kubernetes том (Volume) — это каталог, доступный контейнерам внутри подаkubernetes.io. Типы томов определяют, где и как хранится информация: emptyDir (файлы удаляются при удалении пода), hostPath (монтирование каталога хоста), configMap (файлы конфигурации) и др.
Чтобы использовать том, его описывают в разделе volumes манифеста пода и монтируют в контейнер через volumeMountskubernetes.io.
PersistentVolume (PV) и PersistentVolumeClaim (PVC) — ресурсы, которые позволяют выделить долговременное хранилище. PV представляют физическое хранилище (EBS, NFS), а PVC — запрос приложения на дисковое пространство. Связывание PV и PVC обеспечивает сохранность данных при удалении подов.

Тест:

Что представляет собой том (Volume) в Kubernetes?
1. Файл конфигурации.
2. Каталог, который может содержать данные и доступен контейнерам в подеkubernetes.io. ✅
3. Объект для маршрутизации трафика.
4. Таблица в базе данных.
Для чего используются PersistentVolume и PersistentVolumeClaim?
1. Для автоматического масштабирования.
2. Для организации долгосрочного хранения данных, независимого от жизненного цикла подов. ✅
3. Для управления сетевыми политиками.
4. Для обновления подов.
Как подключить том к контейнеру?
1. Монтировать его через volumeMounts в описании контейнера и описать сам том в секции volumeskubernetes.io. ✅
2. Указать его в ports.
3. Создать ConfigMap.
4. Использовать команду kubectl logs.

Урок 2. ConfigMap и Secret

Описание:

ConfigMap — объект, позволяющий хранить неконфиденциальные данные конфигурации в формате ключ‑значение. Эти данные можно монтировать как том или передавать в контейнер через переменные окружения.
Secret — объект для хранения конфиденциальной информации (пароли, токены). В отличие от ConfigMap, данные в Secret кодируются (base64) и могут быть ограничены по доступу.
Пример использования ConfigMap и Secret в поде:

apiVersion: v1
kind: Pod
metadata:
  name: secret-example
spec:
  containers:
  - name: app
    image: alpine
    env:
    - name: DB_USER
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: username
    - name: CONFIG_VALUE
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: my_key
    volumeMounts:
    - name: config-vol
      mountPath: /etc/config
  volumes:
  - name: config-vol
    configMap:
      name: app-config

Для создания ConfigMap используется kubectl create configmap, а для Secret — kubectl create secret generic.

Тест:

Какой объект следует использовать для хранения паролей в Kubernetes?
1. ConfigMap.
2. Secret. ✅
3. Deployment.
4. Ingress.
Чем отличаются ConfigMap и Secret?
1. Secret хранит конфиденциальные данные и кодируется, ConfigMap — неконфиденциальные данные. ✅
2. Secret используется только для сетевых политик.
3. ConfigMap предназначен для баз данных.
4. Ничем не отличаются.
Каким способом можно подставить значение из Secret в контейнер?
1. Через valueFrom.secretKeyRef в разделе env. ✅
2. Через ports.
3. Через args.
4. Через ingress.

Урок 3. StorageClass и динамическое выделение хранилища

Описание:

StorageClass определяет класс хранилища, который позволяет динамически создавать PersistentVolume. В нём описываются параметры провайдера (например, тип диска в облаке, режим доступа).
При создании PVC, в котором указан StorageClass, Kubernetes автоматически создаёт PV с нужными характеристиками.
К примеру, в AWS можно создать StorageClass с использованием EBS GP3 дисков:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  fsType: ext4
allowVolumeExpansion: true
reclaimPolicy: Delete

Тест:

Для чего используется StorageClass?
1. Для описания динамических параметров выделения дисков (например, тип диска, репликация). ✅
2. Для управления Ingress.
3. Для настройки сетевой политики.
4. Для обновления контейнеров.
Что происходит при создании PVC, если указан StorageClass?
1. PVC остаётся без хранилища.
2. Kubernetes автоматически создаёт PersistentVolume соответствующего класса. ✅
3. Ничего не происходит.
4. Создаётся ReplicaSet.
Что такое параметр allowVolumeExpansion в StorageClass?
1. Разрешает изменение размера тома после его создания. ✅
2. Задаёт тип сети.
3. Управляет сетевыми правилами.
4. Определяет количество реплик.

Модуль 6. Масштабирование, мониторинг и реальные примеры

Урок 1. Автоматическое масштабирование и ресурсы

Описание:

Horizontal Pod Autoscaler (HPA) — контроллер, который автоматически увеличивает или уменьшает количество реплик подов на основе метрик (загрузка CPU, пользовательские метрики). Для работы HPA необходимо установить metrics-server или Prometheus Adapter.
Vertical Pod Autoscaler (VPA) — контроллер, который автоматически подбирает значения ресурсов (requests/limits) для контейнеров. VPA рекомендуется использовать для фоновых или batch‑нагрузок, но реже для веб‑сервисов.
Чтобы правильно настроить автоскейлинг, в манифестах контейнеров необходимо указать resources.requests и resources.limits.

Тест:

Какая разница между HPA и VPA?
1. HPA масштабирует количество подов, VPA корректирует запрашиваемые ресурсы контейнеров. ✅
2. VPA масштабирует только сетевые политики.
3. HPA управляет секретами.
4. Они не отличаются.
Какие метрики обычно используются HPA?
1. Загрузка CPU и пользовательские метрики. ✅
2. Число Ingress.
3. Параметры ядра Linux.
4. Кольцевой буфер.
Что необходимо установить для работы HPA?
1. metrics‑server или другой источник метрик. ✅
2. Secret Controller.
3. ConfigMap.
4. Ingress Controller.

Урок 2. Мониторинг и логирование

Описание:

Для наблюдения за состоянием приложений используются инструменты мониторинга: Prometheus (сбор метрик), Grafana (визуализация), Alertmanager (оповещения). Они могут быть развернуты в виде подов внутри кластера.
Логирование осуществляется через системы, такие как ELK (Elasticsearch, Logstash, Kibana) или Loki, которые собирают и хранят логи контейнеров. Чтобы отправлять логи, часто используются Fluentd или Vector, настроенные через DaemonSet.
В Kubernetes предусмотрены события (kubectl get events) и логи (kubectl logs) для отладки.

Тест:

Какой инструмент используют для сбора и хранения метрик?
1. Prometheus. ✅
2. Kibana.
3. Fluentd.
4. Ceph.
Для чего служит Grafana?
1. Для хранения секретов.
2. Для визуализации метрик, полученных от Prometheus. ✅
3. Для создания подов.
4. Для маршрутизации HTTP‑запросов.
Что такое DaemonSet в контексте логирования?
1. Контроллер, который запускает по одному экземпляру пода на каждом узле, например, для сбора логов. ✅
2. Контроллер, который управляет ConfigMap.
3. Репликация подов.
4. Обновление ядра ОС.

Урок 3. Реальный пример: деплой WordPress с MySQL

Описание:

В качестве практики развернём веб‑приложение WordPress, использующее базу данных MySQL. Каждое приложение будет выполнено в отдельном поде или наборе подов, управляющихся Deployment.
Создадим PersistentVolumeClaims для хранения данных базы данных и загрузок WordPress. Будет создан Service для базы данных и сервис типа LoadBalancer или NodePort для WordPress.
Пример файлов:

1. Манифест базы данных (mysql-deployment.yaml):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: password
        volumeMounts:
        - name: mysql-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-storage
        persistentVolumeClaim:
          claimName: mysql-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  ports:
  - port: 3306
  selector:
    app: mysql

2. Манифест WordPress (wordpress-deployment.yaml):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: wp-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
spec:
  selector:
    matchLabels:
      app: wordpress
  template:
    metadata:
      labels:
        app: wordpress
    spec:
      containers:
      - name: wordpress
        image: wordpress:6
        env:
        - name: WORDPRESS_DB_HOST
          value: mysql
        - name: WORDPRESS_DB_PASSWORD
          value: password
        volumeMounts:
        - name: wordpress-storage
          mountPath: /var/www/html
      volumes:
      - name: wordpress-storage
        persistentVolumeClaim:
          claimName: wp-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: wordpress
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30080
  selector:
    app: wordpress

Развернув эти манифесты, мы получим работающий блог. Для доступа используйте kubectl port-forward или сервис типа LoadBalancer. Трафик между WordPress и базой данных осуществляется через сервис mysql.

Тест:

Какие PersistentVolumeClaim используются в этом примере?
1. mysql-pvc и wp-pvc для хранения данных MySQL и WordPress. ✅
2. Только mysql-pvc.
3. Только wp-pvc.
4. PVC не используются.
Для чего используется сервис mysql?
1. Для предоставления постоянного IP‑адреса и порта для базы данных MySQL. ✅
2. Для обновления WordPress.
3. Для логирования.
4. Для настройки Ingress.
Какой тип сервиса выбран для WordPress в примере?
1. ClusterIP.
2. NodePort (порт 30080). ✅
3. LoadBalancer.
4. ExternalName.