Главная› Roadmap› Модуль 10

Модуль 10 — Kubernetes ⭐⭐⭐⭐

Король DevOps. Освой глубоко — и до пенсии без работы не останешься. 96% компаний с контейнерами используют K8s.

Цель модуля (4-6 месяцев работы)

Понимаешь архитектуру в деталях. Поднимаешь кластер kubeadm-ом. Дебажишь упавшие pod-ы по events/logs/describe. Пишешь Helm chart. Понимаешь Operator pattern. Знаешь когда service mesh нужен. Сдан CKA.

Архитектура — must understand

Control Plane kube-apiserver единая точка REST etcd KV хранилище scheduler куда поместить pod controller-manager controllers Worker Nodes Node 1 kubelet kube-proxy containerd / CRI-O (runtime) Node 2 kubelet kube-proxy containerd Node 3 ... добавляются автоматически (Karpenter)
Архитектура Kubernetes: control plane управляет worker nodes

Control plane

Worker components

Объекты Kubernetes

Workloads

ОбъектЧто делает
PodНаименьшая единица. 1+ контейнеров с общим net/storage
ReplicaSetПоддерживает желаемое число pod (через Deployment)
DeploymentДекларативный апгрейд stateless приложений
StatefulSetДля БД: stable network ID, persistent volumes
DaemonSetPod на каждой ноде (логи, мониторинг агенты)
JobВыполнить и завершиться
CronJobJob по расписанию

Pod в production

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  labels: {app: api}
spec:
  replicas: 3
  selector: {matchLabels: {app: api}}
  template:
    metadata:
      labels: {app: api}
    spec:
      # Безопасность
      securityContext:
        runAsNonRoot: true
        runAsUser: 10000
        fsGroup: 10000
        seccompProfile: {type: RuntimeDefault}
      # Анти-аффинити: не два pod-а на одной ноде
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchLabels: {app: api}
                topologyKey: kubernetes.io/hostname
      containers:
        - name: api
          image: ghcr.io/me/api@sha256:abc123  # pin to digest!
          imagePullPolicy: IfNotPresent
          securityContext:
            readOnlyRootFilesystem: true
            allowPrivilegeEscalation: false
            capabilities: {drop: [ALL]}
          ports:
            - containerPort: 8000
          resources:
            requests: {cpu: 100m, memory: 128Mi}
            limits:   {cpu: 500m, memory: 256Mi}
          livenessProbe:
            httpGet: {path: /healthz, port: 8000}
            initialDelaySeconds: 10
            periodSeconds: 10
          readinessProbe:
            httpGet: {path: /ready, port: 8000}
            periodSeconds: 5
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef: {name: api-secrets, key: db-url}

Networking

Storage

Configuration

Безопасность и доступ

Resource management

Подвох с CPU limits

В отличие от memory, CPU limits часто вредят latency. Throttling может убивать tail latency. Многие компании (Netflix, Uber) рекомендуют ставить requests без limits для CPU. Memory limits — обязательны.

Helm и Kustomize

Helm

Kustomize

Истина: используй оба, для разного.

Auto-scaling

ТипЧто
HPAHorizontal — добавляет pod-ы по CPU/memory/custom metrics
VPAVertical — рекомендует/применяет requests/limits
Cluster AutoscalerДобавляет/удаляет ноды (классический)
Karpenter ⭐Замена CA на AWS — быстрее, гибче. Стандарт сейчас
KEDAEvent-driven scaling: Kafka, RabbitMQ, Prometheus, etc.

Продвинутые темы

CRDs и Operators ⭐

Operator pattern: контроллер для CRD = автоматизированное знание SRE.

Примеры: cert-manager, external-secrets, prometheus-operator, postgres-operator, argo-cd.

Фреймворки: Operator SDK, kubebuilder.

CNI (Container Network Interface)

Service Mesh

Когда service mesh: 10+ микросервисов, нужен mTLS, advanced traffic management.
Когда НЕ нужен: 5 сервисов, монолит — overkill.

Backups

Velero ⭐ — стандарт. Backups объектов K8s + volumes. Можно мигрировать кластер.

Multi-cluster

Managed K8s

Дебаг — алгоритм для упавшего pod

  1. kubectl get pod — состояние
  2. kubectl describe pod <name> — events, причины
  3. kubectl logs <name> (-p предыдущий, -f follow, -c контейнер)
  4. kubectl exec -it <name> -- sh
  5. kubectl debug — ephemeral debug containers
  6. kubectl get events --sort-by='.lastTimestamp'
  7. kubectl top pod / node (нужен metrics-server)

Частые причины

Best practices

  1. Везде ставь requests
  2. Probes liveness и readiness — обязательно
  3. Pod Disruption Budget для важных сервисов
  4. Anti-affinity для HA
  5. Namespace per env / per team
  6. NetworkPolicy «default deny», потом разрешай
  7. Pod Security Standards Restricted
  8. Минимизируй RBAC — точечно, не cluster-admin всем
  9. Limits на namespace через ResourceQuota
  10. Labels систематически: app, version, env, owner

Сертификации

СертификацияКогдаЦенность
CKA ⭐После фазы фундаментаОчень высокая. Практический экзамен 2 ч.
CKADПосле CKAХорошая
CKS ⭐⭐После DevSecOps модуляТоп для DevSecOps
KCNAДля уверенностиНизкая

Чек-лист

Источники

Kubernetes — самый сложный модуль — освоен. Теперь — observability.

Модуль 11 → Observability