> Как описать Deployment в Kubernetes для репликации приложения (Node.js, JavaScript)

Короткий ответ

Deployment в Kubernetes описывает желаемое состояние реплицированного приложения: образ контейнера, количество реплик, стратегию обновления и политику перезапуска. Для frontend-приложения на Node.js это обычно включает контейнер с nginx или Node.js сервером, readiness/liveness probes для проверки здоровья, resource limits и selector для связи с Service. Deployment автоматически поддерживает заданное число реплик и выполняет rolling update при изменении спецификации.

Подробное объяснение

Deployment - это Kubernetes resource, который управляет ReplicaSet и обеспечивает декларативное обновление подов. Для frontend-приложения на Node.js ключевые поля:

• replicas: количество экземпляров приложения (обычно 2-3 для отказоустойчивости)
• selector: matchLabels для связи с подами
• template: описание пода (контейнер с образом, порты, env variables, probes)
• strategy: тип обновления (RollingUpdate с maxSurge и maxUnavailable)
• revisionHistoryLimit: количество хранимых версий для rollback

Особенности для frontend:

• Если приложение - статика (SPA), контейнер обычно содержит nginx, а Node.js используется только для сборки
• Если приложение - SSR (Next.js, Nuxt), контейнер запускает Node.js сервер
• Readiness probe проверяет, что сервер отвечает на HTTP-запросы (например, /health)
• Liveness probe перезапускает под, если приложение зависло

На практике

При описании Deployment для frontend на Node.js:

1. Используй resource requests/limits - frontend-приложения часто потребляют мало CPU, но могут иметь пики памяти при сборке или SSR
2. Настрой readinessProbe с начальной задержкой (initialDelaySeconds) - Node.js серверу нужно время для инициализации
3. Для статики используй nginx в контейнере, а Node.js только для сборки в multi-stage build
4. Добавь env variables через ConfigMap или Secret для конфигурации (API endpoint, feature flags)
5. Укажи terminationGracePeriodSeconds - дай время Node.js завершить активные соединения
6. Для SSR приложений добавь podAntiAffinity чтобы поды были на разных нодах

Пример кода

YAML
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend-app
  labels:
    app: frontend
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: app
        image: myregistry/frontend:1.2.3
        ports:
        - containerPort: 3000
        env:
        - name: API_URL
          valueFrom:
            configMapKeyRef:
              name: frontend-config
              key: api-url
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "200m"
        readinessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 15
          periodSeconds: 20
      terminationGracePeriodSeconds: 30

Как отвечать на собеседовании

Начни с определения Deployment как декларативного способа управления репликацией. Упомяни, что для frontend важно различать статику (SPA) и SSR - это влияет на выбор образа и probes. Подчеркни практические аспекты: resource limits для Node.js, readiness probe для graceful shutdown, стратегия обновления с maxUnavailable=0 для zero-downtime. Если спросят про масштабирование, добавь HPA (Horizontal Pod Autoscaler) на основе CPU или custom metrics.

Что проверяет интервьюер

• Понимание lifecycle пода и probes
• Знание стратегий обновления (RollingUpdate, Recreate)
• Умение настраивать ресурсы для Node.js приложений
• Понимание разницы между frontend-статикой и SSR
• Знание best practices: health checks, graceful shutdown, resource limits
• Способность объяснить, как Deployment взаимодействует с Service и Ingress

Типичные ошибки

• Отсутствие readiness probe - трафик идёт на ещё не готовый под
• Слишком маленький initialDelaySeconds - Node.js не успевает запуститься
• maxUnavailable=1 при одном реплике - при обновлении будет downtime
• Отсутствие resource limits - под может потребить всю память ноды
• Использование latest тега образа - невозможно откатиться
• Неправильный port в probe - если приложение слушает на 3000, а probe на 80
• Игнорирование terminationGracePeriodSeconds - Node.js не успевает завершить соединения