Платформа падала на вебинарах: внедрение Kubernetes для EdTech-стартапа

Мы провели аудит и определили, что для данного клиента Kubernetes действительно оправдан. Kubernetes имеет смысл, если выполняются 3-4 условия:

• Микросервисная архитектура — у клиента 6 независимых сервисов (да)
• Высокие требования к доступности — платформа теряет деньги при каждом простое (да)
• Переменная нагрузка — пики в 5-10 раз при вебинарах (да)
• Частые релизы — команда деплоит 2-3 раза в день (да)
• Команда DevOps — есть один DevOps-инженер (частично)

Однако мы честно объяснили клиенту альтернативы:

Для клиента с 6 микросервисами и переменной нагрузкой Kubernetes был правильным выбором.

K3s — бинарный файл менее 100 МБ с минимальными требованиями (512 МБ RAM):

# Установка K3s (мастер-нода)
curl -sfL https://get.k3s.io | sh -

# Проверка статуса
sudo systemctl status k3s
sudo k3s kubectl get nodes

# Копируем kubeconfig
mkdir -p ~/.kube
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown $(id -u):$(id -g) ~/.kube/config
export KUBECONFIG=~/.kube/config

# Проверка кластера
kubectl get nodes
kubectl get pods -A

Добавили 2 воркер-ноды:

# На мастер-ноде получаем токен
sudo cat /var/lib/rancher/k3s/server/node-token

# На воркер-нодах
curl -sfL https://get.k3s.io | K3S_URL=https://MASTER_IP:6443 \
  K3S_TOKEN="TOKEN_VALUE" sh -

K3s включает из коробки: Traefik (ingress), CoreDNS, ServiceLB, Local Path Provisioner — полноценный кластер готов к работе.

Установка мастер-ноды заняла буквально 2 минуты — один curl-скрипт, и полноценный Kubernetes-кластер готов к работе.

Мы сравнили оба варианта и выбрали K3s:

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

Создали Deployment с автомасштабированием и health checks:

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web-app
        image: myregistry/web-app:1.0.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "500m"
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: app-secrets
              key: database-url
        - name: APP_ENV
          value: "production"

Управление деплоем:

kubectl apply -f deployment.yaml
kubectl get deployments
kubectl get pods

# Масштабирование
kubectl scale deployment web-app --replicas=5

# Rolling update без простоя
kubectl set image deployment/web-app web-app=myregistry/web-app:1.1.0

# Откат
kubectl rollout undo deployment/web-app
kubectl rollout history deployment/web-app

Стратегия RollingUpdate с maxSurge: 1 и maxUnavailable: 0 означает, что при обновлении Kubernetes сначала создаёт новый Pod с новой версией, дожидается, пока он пройдёт readinessProbe, и только потом останавливает старый. Это гарантирует нулевой простой — пользователи платформы не замечают обновления. Для видеостримингового сервиса мы дополнительно настроили terminationGracePeriodSeconds: 60, чтобы текущие видеосессии корректно завершались перед остановкой Pod.

Resource requests и limits были подобраны эмпирически на основе нагрузочного тестирования: мы использовали k6 для имитации 500 одновременных пользователей и замерили реальное потребление CPU и RAM каждым сервисом. Это позволило установить точные значения без overprovisioning — каждый Pod получает ровно столько ресурсов, сколько ему необходимо, а scheduler Kubernetes может эффективно распределять Pod по нодам.

Настроили сетевой доступ к сервисам:

# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: web-app-service
spec:
  type: ClusterIP
  selector:
    app: web-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Ingress для маршрутизации по доменам:

# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-app-ingress
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - app.example.com
    secretName: app-tls
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-app-service
            port:
              number: 80
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

kubectl apply -f service.yaml
kubectl apply -f ingress.yaml
kubectl get services
kubectl get ingress

Для SSL-терминации мы установили cert-manager, который автоматически получает и продлевает Let's Encrypt сертификаты. Клиенту больше не нужно вручную обновлять SSL — cert-manager делает это за 30 дней до истечения. Маршрутизация через Ingress позволила разделить трафик между фронтендом, API и видеостримингом по путям, сохранив один домен и один IP-адрес.

Безопасное хранение credentials:

# Создание секретов
kubectl create secret generic app-secrets \
  --from-literal=database-url='postgresql://appuser:SecretPass123@postgres-service:5432/appdb' \
  --from-literal=redis-url='redis://redis-service:6379/0' \
  --from-literal=secret-key='your-app-secret-key-here'

# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: "production"
  APP_LOG_LEVEL: "warning"
  APP_WORKERS: "4"
  NGINX_WORKER_PROCESSES: "auto"

Мы разделили конфигурацию на секреты (credentials, API-ключи) и ConfigMap (настройки среды, параметры приложения). Секреты шифруются Kubernetes и доступны только тем Pod, которым они явно назначены. ConfigMap позволяет менять параметры приложения без пересборки Docker-образа — например, переключить уровень логирования с warning на debug для диагностики проблемы, а затем вернуть обратно.

Для production-среды мы также настроили NetworkPolicy — правила сетевой изоляции между сервисами. Например, PostgreSQL доступен только из Pod API-сервиса, Redis — из API и видеостримингового сервиса. Это снижает поверхность атаки: даже если злоумышленник получит доступ к одному контейнеру, он не сможет подключиться к базе данных напрямую.

Данные БД сохраняются при перезапуске Pod:

# postgres-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: local-path

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:15-alpine
        ports:
        - containerPort: 5432
        env:
        - name: POSTGRES_DB
          value: appdb
        - name: POSTGRES_USER
          value: appuser
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: password
        - name: PGDATA
          value: /var/lib/postgresql/data/pgdata
        volumeMounts:
        - name: postgres-storage
          mountPath: /var/lib/postgresql/data
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
      volumes:
      - name: postgres-storage
        persistentVolumeClaim:
          claimName: postgres-pvc

---
apiVersion: v1
kind: Service
metadata:
  name: postgres-service
spec:
  type: ClusterIP
  selector:
    app: postgres
  ports:
  - port: 5432
    targetPort: 5432

Redis для кэша:

# redis-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis:7-alpine
        ports:
        - containerPort: 6379
        resources:
          requests:
            memory: "64Mi"
            cpu: "50m"
          limits:
            memory: "128Mi"
            cpu: "100m"

---
apiVersion: v1
kind: Service
metadata:
  name: redis-service
spec:
  selector:
    app: redis
  ports:
  - port: 6379
    targetPort: 6379

Собрали всё через kustomize:

# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - secrets.yaml
  - postgres-pvc.yaml
  - postgres-deployment.yaml
  - redis-deployment.yaml
  - deployment.yaml
  - service.yaml
  - ingress.yaml

kubectl apply -k .

Проверка:

kubectl get all
kubectl logs -f deployment/web-app
kubectl exec -it deployment/web-app -- /bin/sh
kubectl port-forward service/web-app-service 8080:80

После успешного деплоя мы провели smoke-тестирование: проверили доступность всех API-эндпоинтов, работоспособность видеостриминга, корректность соединения с базой данных и Redis. Также убедились, что Ingress корректно маршрутизирует трафик по доменам и путям, а SSL-сертификат автоматически выпущен через cert-manager. Всё работало штатно с первого раза благодаря предварительному тестированию в staging.

Установили Prometheus + Grafana + Alertmanager:

# Установка Helm
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set grafana.adminPassword='SecureGrafanaPass' \
  --set prometheus.prometheusSpec.retention=15d \
  --set prometheus.prometheusSpec.resources.requests.memory=512Mi

Дашборды Grafana для K8s:

• Node Exporter Full (ID: 1860) — метрики нод
• Kubernetes Cluster Monitoring (ID: 6417) — обзор кластера
• Kubernetes Pod Monitoring (ID: 6336) — метрики Pod
• Nginx Ingress Controller (ID: 9614) — входящий трафик

Мы настроили кастомные алерты для каждого микросервиса: если API-сервис возвращает более 1% ошибок 5xx в течение 5 минут, если среднее время ответа превышает 2 секунды, если потребление памяти Pod приближается к limit. Все алерты отправляются в Slack-канал команды разработки с детальной информацией для быстрой диагностики.

Мы настроили алерты и передали клиенту набор диагностических команд:

# Общее состояние
kubectl cluster-info
kubectl top nodes
kubectl top pods --all-namespaces

# Диагностика Pod
kubectl describe pod POD_NAME
kubectl logs POD_NAME --previous
kubectl events --sort-by=.lastTimestamp

# Ресурсы
kubectl get pods -o custom-columns='NAME:.metadata.name,CPU_REQ:.spec.containers[*].resources.requests.cpu,MEM_REQ:.spec.containers[*].resources.requests.memory'

# Persistent Volumes
kubectl get pv,pvc --all-namespaces

Частые проблемы: Pending — не хватает ресурсов; CrashLoopBackOff — приложение падает; ImagePullBackOff — проблема с образом.

Сравнение для типичного приложения клиента:

Проект шёл по нашей проверенной методологии:

Этап 1: Контейнеризация (1 неделя) — создали Dockerfile для каждого сервиса, стабилизировали в Docker Compose.

Этап 2: Кластер разработки (1 неделя) — перенесли Docker Compose в K8s-манифесты, настроили CI/CD.

Этап 3: Продакшен (2 недели) — кластер из 3 нод, Ingress, TLS, мониторинг, бэкапы.

Этап 4: Оптимизация (постоянно) — Horizontal Pod Autoscaler, оптимизация resource limits, GitOps.