Перейти к основному содержимому

7.06. Справочник по Kubernetes

В РАЗРАБОТКЕНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНО
Разработчику Архитектору Инженеру

Справочник по Kubernetes​

Общая архитектура Kubernetes​

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

Компоненты Control Plane (управляющей плоскости)​

Control Plane управляет состоянием кластера и принимает решения о его работе.

  • kube-apiserver
    Центральный компонент, предоставляющий REST API для взаимодействия с кластером. Все операции чтения и записи проходят через него. Поддерживает аутентификацию, авторизацию и валидацию запросов.

  • etcd
    Распределённое хранилище ключ-значение, используемое для хранения всего состояния кластера. Является единственным источником правды для Kubernetes.

  • kube-scheduler
    Отвечает за назначение Pod’ов на подходящие Node’ы на основе доступных ресурсов, политик размещения, толерантности к taint’ам и других ограничений.

  • kube-controller-manager
    Запускает контроллеры, которые наблюдают за состоянием кластера и стремятся привести его к желаемому. Включает:

    • Node Controller
    • Replication Controller
    • Endpoints Controller
    • Service Account & Token Controllers

  • cloud-controller-manager (опционально)
    Изолирует облачно-зависимую логику от основного control plane. Управляет взаимодействием с облачными провайдерами (например, AWS, GCP, Azure).

Компоненты Data Plane (рабочей плоскости)​

Data Plane состоит из узлов (Node), на которых выполняются рабочие нагрузки.

  • kubelet
    Агент, работающий на каждом Node. Отвечает за запуск Pod’ов, мониторинг их состояния и взаимодействие с container runtime.

  • kube-proxy
    Сетевой прокси, управляющий сетевыми правилами на Node для обеспечения сетевой связи с Service’ами внутри и вне кластера. Поддерживает режимы:

    • iptables
    • IPVS
    • userspace (устаревший)

  • Container Runtime
    Программное обеспечение, отвечающее за выполнение контейнеров. Поддерживаемые runtimes:

    • containerd
    • CRI-O
    • Docker Engine (через dockershim до версии 1.20, далее не поддерживается напрямую)

Основные понятия Kubernetes​

Кластер (Cluster)​

Набор машин (физических или виртуальных), объединённых в единую систему управления контейнерами. Состоит из Control Plane и одного или нескольких Node.

Node (Узел)​

Рабочая машина в кластере. Может быть физическим сервером или виртуальной машиной. Выполняет Pod’ы.

Pod​

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

  • Сеть (один IP-адрес)
  • Хранилище (Volumes)
  • Спецификацию жизненного цикла

Pod’ы создаются и управляются контроллерами (например, Deployment, StatefulSet).

Namespace​

Механизм изоляции ресурсов внутри одного кластера. Позволяет разделить кластер на логические зоны (например, dev, staging, prod).

Системные Namespace:

  • default — используется по умолчанию
  • kube-system — системные компоненты
  • kube-public — общедоступные ресурсы
  • kube-node-lease — информация о состоянии Node

Label и Selector​

  • Label — пары ключ-значение, прикрепляемые к объектам (Pod, Service и др.) для организации и выбора подмножеств.
  • Selector — выражение, используемое для фильтрации объектов по Label’ам.

Пример Label:

labels:
  app: nginx
  environment: production
  tier: frontend

Типы Selector’ов:

  • Equality-based: environment = production
  • Set-based: environment in (production, staging)

Annotation​

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

Структура объекта Kubernetes​

Каждый объект Kubernetes описывается в YAML или JSON и содержит следующие обязательные поля:

apiVersion: <строка>
kind: <строка>
metadata:
  name: <строка>
  namespace: <строка>
  labels: <карта>
  annotations: <карта>
spec: <спецификация объекта>
status: <состояние объекта> # управляется системой

  • apiVersion — указывает версию API, необходимую для создания объекта. Примеры:

    • v1 — для Pod, Service, Namespace
    • apps/v1 — для Deployment, StatefulSet, DaemonSet
    • batch/v1 — для Job, CronJob
    • networking.k8s.io/v1 — для Ingress

  • kind — тип объекта. Примеры: Pod, Service, Deployment, ConfigMap.

  • metadata.name — уникальное имя объекта в пределах Namespace.

  • metadata.namespace — пространство имён, в котором создаётся объект.

  • spec — желаемое состояние объекта. Определяется пользователем.

  • status — текущее состояние объекта. Обновляется системой автоматически.

Core API Resources​

Pod​

Структура spec​

spec:
  containers:
    - name: <строка>
      image: <строка>
      command: [<строка>, ...]
      args: [<строка>, ...]
      ports:
        - containerPort: <целое>
          protocol: TCP|UDP|SCTP
      env:
        - name: <строка>
          value: <строка>
        - name: <строка>
          valueFrom:
            configMapKeyRef: ...
            secretKeyRef: ...
      resources:
        requests:
          cpu: <строка>
          memory: <строка>
        limits:
          cpu: <строка>
          memory: <строка>
      volumeMounts:
        - name: <строка>
          mountPath: <путь>
      livenessProbe: <Probe>
      readinessProbe: <Probe>
      startupProbe: <Probe>
      lifecycle: <Lifecycle>
  initContainers: [...] # аналогично containers, но запускаются до основных
  volumes:
    - name: <строка>
      emptyDir: {}
      hostPath:
        path: <путь>
      configMap:
        name: <строка>
      secret:
        secretName: <строка>
      persistentVolumeClaim:
        claimName: <строка>
  restartPolicy: Always|OnFailure|Never
  nodeName: <строка> # прямое назначение на Node
  nodeSelector: <карта> # выбор Node по Label’ам
  tolerations: [...] # допуск к taint’ам
  affinity: <Affinity> # продвинутые правила размещения

Важные параметры контейнера​

  • image: URI образа (например, nginx:1.25, registry.example.com/app:v1)
  • command и args: переопределяют ENTRYPOINT и CMD из Dockerfile
  • ports: информационное поле; не публикует порты наружу
  • resources.requests/limits:
    • CPU: значения в миллиядрах (100m = 0.1 ядра) или ядрах (2)
    • Memory: в байтах с суффиксами (64Mi, 1Gi)
  • livenessProbe: проверяет, жив ли контейнер. При провале — перезапуск.
  • readinessProbe: проверяет, готов ли контейнер принимать трафик. При провале — исключение из Service.
  • startupProbe: отключает liveness/readiness до успешного завершения. Полезен для медленно стартующих приложений.

Типы Volume​

  • emptyDir: временный том, существует пока Pod жив
  • hostPath: монтирует файл/директорию с Node (опасно, только для одиночных нод)
  • configMap, secret: монтирует данные как файлы или переменные окружения
  • persistentVolumeClaim: запрос на постоянное хранилище

Service​

Абстракция, определяющая логический набор Pod’ов и политику доступа к ним.

Типы Service​

  • ClusterIP (по умолчанию): внутренний IP, доступен только внутри кластера
  • NodePort: открывает статический порт на всех Node, перенаправляет на ClusterIP
  • LoadBalancer: создаёт внешний балансировщик (в облаке)
  • ExternalName: возвращает CNAME записи вместо IP (редко используется)

Структура spec​

spec:
  type: ClusterIP|NodePort|LoadBalancer|ExternalName
  selector:
    app: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
      nodePort: 30007 # только для NodePort/LoadBalancer
  clusterIP: <авто или задано>
  externalIPs: [<IP>, ...]
  sessionAffinity: None|ClientIP
  • selector — выбирает Pod’ы по Label’ам
  • port — порт Service’а
  • targetPort — порт контейнера (может быть числом или именем порта из Pod spec)
  • nodePort — диапазон по умолчанию: 30000–32767

Namespace​

Простой объект:

apiVersion: v1
kind: Namespace
metadata:
  name: my-namespace
  labels:
    team: backend
  annotations:
    owner: "devops@example.com"

Используется для изоляции ресурсов, квот и политик.

Node​

Объект, представляющий физическую или виртуальную машину.

spec:
  podCIDR: <подсеть>
  taints:
    - key: dedicated
      value: gpu
      effect: NoSchedule
  unschedulable: true|false
status:
  capacity:
    cpu: "4"
    memory: "16Gi"
    pods: "110"
  allocatable:
    cpu: "3900m"
    memory: "15Gi"
  conditions:
    - type: Ready
      status: "True"
  • taints — помечает Node, чтобы на него не назначались Pod’ы без соответствующих tolerations
  • unschedulable — запрещает планировщику назначать новые Pod’ы на этот Node

Workload Controllers​

Контроллеры управляют жизненным циклом Pod’ов, обеспечивая соответствие текущего состояния желаемому.

Deployment​

Используется для управления бессостоятельными приложениями. Обеспечивает декларативные обновления, откаты и масштабирование.

Структура spec​

spec:
  replicas: <целое> # количество желаемых Pod’ов
  selector:
    matchLabels:
      app: my-app
  strategy:
    type: RollingUpdate|Recreate
    rollingUpdate:
      maxUnavailable: <целое или процент>
      maxSurge: <целое или процент>
  minReadySeconds: <целое> # сколько секунд Pod должен быть ready перед учётом
  revisionHistoryLimit: <целое> # сколько старых ReplicaSet хранить
  progressDeadlineSeconds: <целое> # таймаут для прогресса обновления
  paused: true|false
  template: # шаблон Pod
    metadata:
      labels:
        app: my-app
    spec:
      containers: [...]

Параметры стратегии обновления​

  • RollingUpdate (по умолчанию): постепенно заменяет старые Pod’ы новыми.

    • maxUnavailable: максимальное количество Pod’ов, которые могут быть недоступны во время обновления. Значение по умолчанию — 25%.
    • maxSurge: максимальное количество Pod’ов сверх желаемого числа. Значение по умолчанию — 25%.

  • Recreate: сначала удаляет все старые Pod’ы, затем создаёт новые. Приводит к downtime.

Полезные команды​

  • kubectl rollout status deployment/<name> — отслеживание прогресса
  • kubectl rollout history deployment/<name> — история ревизий
  • kubectl rollout undo deployment/<name> — откат к предыдущей версии

StatefulSet​

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

Обеспечивает:

  • Уникальные, стабильные имена Pod’ов (web-0, web-1, ...)
  • Упорядоченный запуск и завершение
  • Постоянное хранилище, привязанное к каждому Pod’у

Структура spec​

spec:
  replicas: <целое>
  serviceName: <строка> # Headless Service для DNS
  selector:
    matchLabels:
      app: mysql
  template: # шаблон Pod
    metadata:
      labels:
        app: mysql
    spec:
      containers: [...]
  volumeClaimTemplates: # список PVC, создаваемых для каждого Pod’а
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 10Gi
        storageClassName: fast-ssd
  podManagementPolicy: OrderedReady|Parallel
  updateStrategy:
    type: RollingUpdate|OnDelete
    rollingUpdate:
      partition: <целое> # для канареечных обновлений

Особенности​

  • serviceName должен ссылаться на Headless Service (clusterIP: None)
  • volumeClaimTemplates автоматически создаёт PersistentVolumeClaim для каждого Pod’а
  • podManagementPolicy:
    • OrderedReady (по умолчанию): строгий порядок запуска/удаления
    • Parallel: все Pod’ы управляются одновременно

DaemonSet​

Запускает по одному Pod’у на каждом подходящем Node. Используется для системных агентов: log collectors, monitoring agents, network plugins.

Структура spec​

spec:
  selector:
    matchLabels:
      app: fluentd
  template: # шаблон Pod
    metadata:
      labels:
        app: fluentd
    spec:
      containers: [...]
  updateStrategy:
    type: RollingUpdate|OnDelete
    rollingUpdate:
      maxUnavailable: <целое или процент>
  minReadySeconds: <целое>

DaemonSet игнорирует replicas. Число Pod’ов равно числу подходящих Node’ов.

Job​

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

Структура spec​

spec:
  parallelism: <целое> # сколько Pod’ов запускать одновременно
  completions: <целое> # сколько успешных завершений требуется
  backoffLimit: <целое> # максимум попыток после неудачи
  activeDeadlineSeconds: <целое> # максимальное время выполнения
  ttlSecondsAfterFinished: <целое> # через сколько удалять завершённый Job
  template: # шаблон Pod
    spec:
      restartPolicy: OnFailure|Never # Always запрещён
      containers: [...]
  • Если completions не указано, Job завершается после первого успешного Pod’а.
  • restartPolicy не может быть Always.

CronJob​

Запускает Job по расписанию в формате cron.

Структура spec​

spec:
  schedule: "0 */6 * * *" # каждые 6 часов
  timeZone: "Europe/Moscow" # опционально, начиная с v1.29
  startingDeadlineSeconds: <целое> # макс. задержка запуска
  concurrencyPolicy: Allow|Forbid|Replace
  suspend: true|false
  successfulJobsHistoryLimit: <целое> # сколько успешных Job хранить
  failedJobsHistoryLimit: <целое> # сколько неудачных Job хранить
  jobTemplate:
    spec:
      template:
        spec:
          containers: [...]
  • concurrencyPolicy:
    • Allow (по умолчанию): разрешает параллельные запуски
    • Forbid: пропускает новый запуск, если предыдущий ещё работает
    • Replace: завершает текущий Job и запускает новый

Конфигурация и секреты​

ConfigMap​

Хранит нечувствительные конфигурационные данные в виде пар ключ-значение.

Способы использования​

  1. Как переменные окружения:

    envFrom:
      - configMapRef:
          name: app-config

  2. Как отдельные переменные:

    env:
      - name: DB_HOST
        valueFrom:
          configMapKeyRef:
            name: app-config
            key: database.host

  3. Как Volume (файлы в директории):

    volumes:
      - name: config-volume
        configMap:
          name: app-config

Структура объекта​

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database.host: "postgres"
  log.level: "info"
binaryData:
  cert.pem: <base64>
  • data — текстовые значения (UTF-8)
  • binaryData — двоичные данные в base64

Secret​

Хранит чувствительные данные: пароли, токены, TLS-ключи.

Типы Secret:

  • Opaque (по умолчанию) — произвольные данные
  • kubernetes.io/tls — сертификат и приватный ключ
  • kubernetes.io/dockerconfigjson — для доступа к приватным registry
  • kubernetes.io/service-account-token — токены сервисных аккаунтов

Пример TLS Secret​

apiVersion: v1
kind: Secret
metadata:
  name: tls-secret
type: kubernetes.io/tls
data:
  tls.crt: <base64>
  tls.key: <base64>

Использование​

Аналогично ConfigMap: через envFrom, valueFrom.secretKeyRef, или как Volume.

Сетевые ресурсы​

Ingress​

Управляет входящим HTTP/HTTPS-трафиком на уровне кластера. Требует установленного Ingress Controller (NGINX, Traefik, HAProxy).

Структура spec​

spec:
  ingressClassName: nginx # указывает класс контроллера
  tls:
    - hosts:
        - example.com
      secretName: tls-secret
  rules:
    - host: example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend-service
                port:
                  number: 80

Типы путей (pathType)​

  • Exact — точное совпадение
  • Prefix — префиксное совпадение
  • ImplementationSpecific — зависит от контроллера

Аннотации (часто используются)​

  • nginx.ingress.kubernetes.io/rewrite-target
  • traefik.ingress.kubernetes.io/router.entrypoints: websecure

NetworkPolicy​

Определяет правила сетевого трафика между Pod’ами. Требует CNI с поддержкой политик (Calico, Cilium, kube-router).

Пример: разрешить вход только из frontend​

spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              name: monitoring
      ports:
        - protocol: TCP
          port: 9090
  • Без NetworkPolicy весь трафик разрешён.
  • policyTypes явно указывает, применяются ли правила к входящему, исходящему или обоим типам трафика.

Хранилище​

PersistentVolume (PV)​

Ресурс кластера, представляющий физическую или облачную единицу хранения.

Типы провайдеров​

  • hostPath — локальная директория (только для одиночных нод)
  • nfs, iscsi, cephfs — сетевые файловые системы
  • awsElasticBlockStore, gcePersistentDisk, azureDisk — облачные диски
  • CSI-драйверы — универсальный интерфейс для любых хранилищ

Структура PV​

spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteOnce
    - ReadOnlyMany
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain|Recycle|Delete
  storageClassName: fast-ssd
  hostPath:
    path: /mnt/data

Access Modes​

  • ReadWriteOnce (RWO) — один Node, чтение и запись
  • ReadOnlyMany (ROX) — много Node, только чтение
  • ReadWriteMany (RWX) — много Node, чтение и запись

Reclaim Policy​

  • Retain — сохраняет данные после удаления PVC
  • Delete — удаляет PV и физическое хранилище
  • Recycle — устаревший, не рекомендуется

PersistentVolumeClaim (PVC)​

Запрос на использование PV от имени Pod’а.

spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
  storageClassName: fast-ssd
  volumeName: <имя PV> # прямая привязка (опционально)
  dataSource: # для клонирования или восстановления из снапшота
    name: backup-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io

PVC автоматически связывается с подходящим PV при динамическом provision’инге.

StorageClass​

Определяет классы хранилища для динамического создания PV.

provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
  fsType: ext4
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer|Immediate
  • provisioner — драйвер, создающий тома
  • allowVolumeExpansion — разрешает увеличение размера PVC после создания
  • volumeBindingMode:
    • Immediate — PV создаётся сразу при создании PVC
    • WaitForFirstConsumer — PV создаётся только когда Pod, использующий PVC, будет назначен на Node (полезно для зональных томов)

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

Role-Based Access Control (RBAC)​

Kubernetes использует RBAC для управления доступом к API на основе ролей.

Основные объекты​

  • Role — определяет права в пределах одного Namespace.
  • ClusterRole — определяет права на уровне всего кластера.
  • RoleBinding — связывает пользователя или группу с Role в Namespace.
  • ClusterRoleBinding — связывает пользователя или группу с ClusterRole глобально.

Структура Role​

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

Допустимые глаголы (verbs)​

  • get, list, watch — чтение
  • create, update, patch, delete, deletecollection — запись
  • impersonate — подмена пользователя
  • bind, escalate — специфичные для RBAC

Пример RoleBinding​

kind: RoleBinding
meta
  name: read-pods
  namespace: dev
subjects:
  - kind: User
    name: alice
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

subjects может ссылаться на:

  • User
  • Group
  • ServiceAccount

ServiceAccount​

Специальный тип аккаунта для процессов внутри Pod’ов.

  • Каждый Pod по умолчанию использует default ServiceAccount в своём Namespace.
  • ServiceAccount автоматически монтирует токен (/var/run/secrets/kubernetes.io/serviceaccount/token) для аутентификации в API.

Создание ServiceAccount​

apiVersion: v1
kind: ServiceAccount
meta
  name: app-sa
  namespace: prod

Привязка к Pod:

spec:
  serviceAccountName: app-sa
  containers: [...]

SecurityContext​

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

Уровень Pod​

spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault

Уровень контейнера​

containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]
        add: ["NET_BIND_SERVICE"]

Ключевые поля​

  • runAsUser — UID, от которого запускается процесс
  • runAsNonRoot — требует, чтобы контейнер не запускался от root
  • readOnlyRootFilesystem — делает корневую ФС только для чтения
  • capabilities.add/drop — управление Linux capabilities
  • seccompProfile.type — RuntimeDefault, Localhost, Unconfined

PodSecurity Admission (PSA)​

Механизм, заменивший PodSecurityPolicy (устаревший с v1.25).

Работает через метки Namespace:

  • pod-security.kubernetes.io/enforce: baseline
  • pod-security.kubernetes.io/warn: restricted
  • pod-security.kubernetes.io/audit: privileged

Уровни безопасности​

  • Privileged — без ограничений
  • Baseline — минимальные ограничения, совместимо с большинством приложений
  • Restricted — строгие требования (например, запрет root, обязательные capabilities drop)

Пример меток:

apiVersion: v1
kind: Namespace
meta
  name: secure-app
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest

Мониторинг и логирование​

Metrics Server​

Лёгкий компонент, собирающий метрики CPU и памяти с Node и Pod’ов. Требуется для kubectl top и Horizontal Pod Autoscaler.

Устанавливается как Deployment в kube-system.

Prometheus​

Система мониторинга с pull-моделью. Использует ServiceMonitor и PodMonitor (через Prometheus Operator) для обнаружения целей.

Пример ServiceMonitor​

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
meta
  name: app-monitor
spec:
  selector:
    matchLabels:
      app: my-app
  endpoints:
    - port: metrics
      interval: 30s

Loki​

Система агрегации логов от Grafana Labs. Хранит логи без полнотекстового индекса, используя метки (labels) для фильтрации.

Интегрируется с Promtail — агентом, отправляющим логи из Pod’ов.

Расширяемость​

CustomResourceDefinition (CRD)​

Позволяет создавать пользовательские ресурсы в Kubernetes API.

Пример CRD​

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
meta
  name: databases.example.com
spec:
  group: example.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                size:
                  type: string
                  pattern: '^[1-9][0-9]*Gi$'
  scope: Namespaced
  names:
    plural: databases
    singular: database
    kind: Database
    listKind: DatabaseList

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

apiVersion: example.com/v1
kind: Database
meta
  name: my-db
spec:
  size: "10Gi"

Operators​

Паттерн расширения Kubernetes, реализующий доменную логику через контроллер, управляющий CRD.

Оператор наблюдает за состоянием CR и выполняет действия:

  • Создание PVC, Service, Secret
  • Выполнение SQL-миграций
  • Резервное копирование

Популярные Operators:

  • Prometheus Operator
  • Cert-Manager
  • Strimzi (Kafka)
  • Elastic Cloud on Kubernetes (ECK)

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

Helm​

Менеджер пакетов для Kubernetes. Пакет называется Chart.

Структура Chart​

my-chart/
├── Chart.yaml
├── values.yaml
├── charts/          # зависимости
└── templates/       # шаблоны YAML
    ├── deployment.yaml
    ├── service.yaml
    └── _helpers.tpl

Ключевые команды​

  • helm install my-release ./my-chart
  • helm upgrade my-release ./my-chart
  • helm rollback my-release 2
  • helm template ./my-chart — рендеринг без установки

Kustomize​

Инструмент для декларативной настройки манифестов без шаблонов.

Использует файл kustomization.yaml:

resources:
  - deployment.yaml
  - service.yaml
namePrefix: staging-
namespace: staging
commonLabels:
  env: staging
patchesStrategicMerge:
  - patch.yaml

Встроен в kubectl apply -k.

Полезные команды kubectl​

КомандаНазначение
kubectl get pods -n <ns>список Pod’ов
kubectl describe pod <name>детали Pod’а
kubectl logs <pod> -c <container>логи контейнера
kubectl exec -it <pod> -- shвход в контейнер
kubectl port-forward svc/<name> 8080:80проброс порта
kubectl top nodesиспользование ресурсов Node
kubectl auth can-i create pods --namespace devпроверка прав
kubectl diff -f manifest.yamlсравнение с текущим состоянием

CI/CD и GitOps​

Argo CD​

Инструмент GitOps, синхронизирующий состояние кластера с манифестами в Git.

  • Отслеживает ветку репозитория
  • Автоматически применяет изменения
  • Предоставляет UI и CLI для управления

Application CR​

apiVersion: argoproj.io/v1alpha1
kind: Application
meta
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook

Tekton​

Фреймворк для CI/CD на основе Kubernetes. Использует CRD: Task, Pipeline, PipelineRun.

Пример Task​

apiVersion: tekton.dev/v1beta1
kind: Task
meta
  name: build-image
spec:
  steps:
    - name: build
      image: gcr.io/kaniko-project/executor:v1.9.1
      args:
        - --dockerfile=/workspace/Dockerfile
        - --destination=my-registry/app:$(inputs.params.version)

Tekton хорошо интегрируется с Argo Events, GitHub Actions и другими триггерами.

Сетевые модели и CNI-плагины​

Kubernetes требует реализации Container Network Interface (CNI) для обеспечения сетевой связи между Pod’ами.

Общие требования к CNI​

  • Каждый Pod получает уникальный IP-адрес (IP-per-Pod)
  • Pod’ы могут общаться напрямую без NAT
  • Узлы могут общаться с Pod’ами без NAT
  • Поддержка политик безопасности (опционально)

Calico​

Высокопроизводительный CNI с поддержкой сетевых политик, BGP и eBPF.

Особенности​

  • Использует BGP для маршрутизации между Node
  • Поддерживает режимы:
    • IPIP — инкапсуляция трафика (подходит для облака)
    • VXLAN — альтернатива IPIP
    • eBPF — ускорение dataplane без iptables
  • Полная поддержка NetworkPolicy
  • Встроенный контроллер для управления политиками

Установка​

Через Helm или manifest:

kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

Cilium​

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

Особенности​

  • Полная замена iptables на eBPF
  • Поддержка L3–L7 политик (включая HTTP, Kafka, gRPC)
  • Встроенная видимость трафика (Hubble)
  • Безопасность на уровне identity, а не IP
  • Поддержка Service Mesh без sidecar (Cilium Service Mesh)

Установка​

helm install cilium cilium/cilium \
  --namespace kube-system \
  --set hubble.enabled=true

Flannel​

Простой и лёгкий CNI, использующий VXLAN по умолчанию.

Особенности​

  • Минимальная конфигурация
  • Не поддерживает NetworkPolicy (требуется дополнительный компонент)
  • Подходит для тестовых и небольших кластеров
  • Хранит конфигурацию в etcd или kube-api

Установка​

kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

Мультикластерное управление​

Karmada​

Проект CNCF для управления несколькими кластерами через единый control plane.

Возможности​

  • Распределение рабочих нагрузок по кластерам
  • Failover между регионами
  • Единая политика размещения (PropagationPolicy)
  • Поддержка федеративных ресурсов

Архитектура​

  • Control plane в отдельном кластере
  • Агенты (karmada-agent) в управляемых кластерах
  • Ресурсы дублируются через ResourceBinding

Cluster API (CAPI)​

Декларативный подход к управлению жизненным циклом Kubernetes-кластеров.

Компоненты​

  • Cluster: описание кластера
  • Machine: описание Node
  • Provider: облачный или bare-metal провайдер (AWS, Azure, Metal3)

Пример​

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
meta
  name: my-cluster
spec:
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: AWSManagedCluster
    name: my-cluster
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    kind: KubeadmControlPlane
    name: my-cluster-control-plane

Позволяет автоматизировать создание, масштабирование и удаление кластеров.

Rancher​

Платформа с UI для управления множеством кластеров (включая EKS, GKE, AKS, RKE).

Функции​

  • Централизованная аутентификация (LDAP, SAML)
  • RBAC на уровне проектов
  • Мониторинг и логирование из коробки
  • CI/CD через Fleet и GitRepo CRD
  • Поддержка Windows Node

Отладка и диагностика​

Чек-лист диагностики Pod’а​

  1. Проверка статуса

    kubectl get pod <name>

    Возможные состояния: Pending, Running, Succeeded, Failed, Unknown.

  2. Описание Pod’а

    kubectl describe pod <name>

    Показывает события: FailedScheduling, ImagePullBackOff, CrashLoopBackOff.

  3. Логи контейнера

    kubectl logs <pod> -c <container>
    kubectl logs <pod> --previous  # предыдущий запуск

  4. Интерактивный доступ

    kubectl exec -it <pod> -- sh

  5. Проверка сети

    kubectl run debug --image=busybox --rm -it --restart=Never -- sh
    nslookup service-name
    wget http://service-name:80

Типичные проблемы и решения​

ПроблемаПричинаРешение
ImagePullBackOffНеверный образ или нет доступа к registryПроверить имя образа, добавить imagePullSecrets
CrashLoopBackOffКонтейнер завершается с ошибкойПроверить логи, readinessProbe, зависимости
PendingНедостаточно ресурсов или taintsУвеличить capacity, добавить tolerations
Service unreachableНеправильный selector или портСверить selector и targetPort
Ingress not workingНет Ingress ControllerУстановить NGINX/Traefik

Резервное копирование: Velero​

Инструмент для резервного копирования и восстановления кластера.

Возможности​

  • Резервное копирование Namespace, PVC, PV
  • Восстановление в другой кластер
  • Планирование через CronJob
  • Интеграция с AWS S3, Azure Blob, GCS

Установка​

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.8.0 \
  --bucket k8s-backups \
  --secret-file ./credentials-velero

Создание бэкапа​

velero backup create full-backup --include-namespaces=prod
velero backup get
velero restore create --from-backup full-backup

Производительность и масштабируемость​

Официальные лимиты Kubernetes (v1.29+)​

  • До 5000 Node’ов
  • До 150 000 Pod’ов
  • До 110 Pod’ов на Node
  • До 10000 сервисов
  • До 200000 total objects

Best Practices​

  • Использовать HPA вместо ручного масштабирования
  • Ограничивать ресурсы через requests/limits
  • Избегать hostPath в production
  • Использовать PodDisruptionBudget для отказоустойчивости
  • Включать livenessProbe и readinessProbe
  • Разделять критические и некритические нагрузки по Namespace
  • Использовать nodeSelector или affinity для размещения GPU-нагрузок

PodDisruptionBudget (PDB)​

Гарантирует минимальное количество доступных Pod’ов при добровольных прерываниях (например, обновление Node).

apiVersion: policy/v1
kind: PodDisruptionBudget
meta
  name: app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: web

Альтернатива: maxUnavailable: 1