Можно ли развернуть БД и микросервис на одном Pod в Kubernetes?

Размещение БД и микросервиса в одном Pod Kubernetes: возможно ли?

Короткий ответ: технически можно, но это считается плохой практикой. Давайте разберёмся почему.

Технически возможно

# Pod с двумя контейнерами: микросервис и БД
apiVersion: v1
kind: Pod
metadata:
  name: app-with-db
spec:
  containers:
  - name: user-service
    image: user-service:latest
    ports:
    - containerPort: 8080
    env:
    - name: DB_HOST
      value: localhost # БД в том же pod
    - name: DB_PORT
      value: "5432"
  
  - name: postgres
    image: postgres:15
    ports:
    - containerPort: 5432
    env:
    - name: POSTGRES_PASSWORD
      value: secret
    volumeMounts:
    - name: db-data
      mountPath: /var/lib/postgresql/data
  
  volumes:
  - name: db-data
    emptyDir: {}

Да, это работает. Оба контейнера могут общаться через localhost. Но это плохо!

Почему это плохая идея

1. Нарушение принципа Single Responsibility

Pod должен выполнять одну роль.

# ❌ Плохо: Pod несет две ответственности
Pod: user-service + database
  ├── User Service (java приложение)
  └── PostgreSQL (база данных)

# ✅ Хорошо: каждый pod со своей ролью
Pod 1: user-service (Deployment)
Pod 2: postgres-0 (StatefulSet)
Pod 3: postgres-1
Pod 4: postgres-2 (репликация)

2. Проблемы масштабирования

# ❌ Проблема
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-with-db
spec:
  replicas: 3 # Хотим 3 реплики микросервиса
  template:
    spec:
      containers:
      - name: user-service
      - name: postgres # Но создаём 3 инстанции БД!

При масштабировании приложения с 1 до 3 реплик:

• Создаётся 3 инстанции микросервиса ✅
• Создаётся 3 отдельные инстанции PostgreSQL ❌
• Каждая БД со своей базой данных
• Синхронизация данных — nightmare
• Потребление памяти/дискового пространства × 3

// Микросервис в Pod 1 видит одну БД
// Микросервис в Pod 2 видит другую БД
// Микросервис в Pod 3 видит третью БД
// ДАННЫЕ НЕ СИНХРОНИЗИРОВАНЫ!

3. Независимые жизненные циклы

# Проблема: разные time-to-restart
# Если микросервис упадает:
Pod: user-service + postgres
├── user-service упал ← нужно перезапустить
└── postgres работает и может быть убит при перезапуске pod'а

# Если БД упадает:
Pod: user-service + postgres
├── user-service потеряет доступ к БД
└── postgres упал ← нужен отдельный рестарт

4. Проблемы с персистентностью данных

# ❌ Неправильно
volumes:
- name: db-data
  emptyDir: {} # Данные теряются при удалении pod'а!

# ✅ Правильно (для отдельного pod'а)
volumes:
- name: db-data
  persistentVolumeClaim:
    claimName: postgres-pvc

Время жизни данных привязано к времени жизни pod'а.

5. Сложность управления ресурсами

# ❌ Проблема: как разделить resources?
apiVersion: v1
kind: Pod
metadata:
  name: app-with-db
spec:
  containers:
  - name: user-service
    resources:
      limits:
        memory: 512Mi
        cpu: 500m
  - name: postgres
    resources:
      limits:
        memory: 2Gi # А если БД нужно больше?
        cpu: 1000m

Оба контейнера конкурируют за одни ресурсы pod'а.

6. Отсутствие репликации БД

# ❌ В нашей схеме
3 Pod'а × 1 инстанция БД = 3 изолированные БД (бессмысленно)

# ✅ Правильная архитектура
3 Pod'а микросервиса → 1 StatefulSet PostgreSQL
PostgreSQL (primary): 1 Pod
PostgreSQL (replica): 2 Pod'а
↓
Высокая доступность БД

Правильная архитектура Kubernetes

# 1. Микросервис как Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: user-service
  template:
    metadata:
      labels:
        app: user-service
    spec:
      containers:
      - name: user-service
        image: user-service:latest
        env:
        - name: DB_HOST
          value: postgres-service # Service перед БД
        - name: DB_PORT
          value: "5432"
        resources:
          requests:
            memory: 256Mi
            cpu: 250m
          limits:
            memory: 512Mi
            cpu: 500m
---
# 2. БД как StatefulSet
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  replicas: 3
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:15
        env:
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: password
        volumeMounts:
        - name: postgres-storage
          mountPath: /var/lib/postgresql/data
        resources:
          requests:
            memory: 512Mi
            cpu: 500m
          limits:
            memory: 2Gi
            cpu: 1000m
  volumeClaimTemplates:
  - metadata:
      name: postgres-storage
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "fast-ssd"
      resources:
        requests:
          storage: 50Gi
---
# 3. Service для доступа к БД
apiVersion: v1
kind: Service
metadata:
  name: postgres-service
spec:
  selector:
    app: postgres
  ports:
  - port: 5432
    targetPort: 5432
  type: ClusterIP
---
# 4. Service для микросервиса (опционально)
apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-service
  ports:
  - port: 80
    targetPort: 8080
  type: LoadBalancer

Когда ВСЕ ЖЕ можно использовать multi-container pod?

Есть редкие случаи, когда это оправдано:

1. Sidecar pattern

# Pod с основным контейнером + вспомогательным
apiVersion: v1
kind: Pod
metadata:
  name: app-with-logging
spec:
  containers:
  # Основной контейнер
  - name: user-service
    image: user-service:latest
    volumeMounts:
    - name: shared-logs
      mountPath: /var/logs
  
  # Sidecar: логирование, мониторинг, трассировка
  - name: log-collector
    image: fluent-bit:latest
    volumeMounts:
    - name: shared-logs
      mountPath: /var/logs
      readOnly: true
  
  volumes:
  - name: shared-logs
    emptyDir: {}

Это OK, потому что:

• Log collector это просто вспомогательный сервис
• Они имеют одинаковый жизненный цикл
• Масштабируются вместе (оба одного экземпляра)
• Логи — не критические данные

2. Ambassador pattern

# Pod с микросервисом + проксей
apiVersion: v1
kind: Pod
metadata:
  name: app-with-ambassador
spec:
  containers:
  - name: user-service
    image: user-service:latest
  
  # Ambassador: прокси для доступа к внешним сервисам
  - name: ambassador-proxy
    image: envoy-proxy:latest

Примеры sidecar'ов:

• Fluent-bit, Filebeat (логирование)
• Prometheus exporter (мониторинг)
• Jaeger agent (трассировка)
• Istio sidecar proxy (service mesh)
• OAuth proxy (аутентификация)

Сравнение: Pod с БД vs Отдельный StatefulSet

Практический пример неправильной архитектуры

# ❌ НЕПРАВИЛЬНО
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: app
      - name: postgres

# Что происходит при обновлении приложения:
# kubectl apply -f deployment.yaml
#
# 1. Создаётся 3 новых Pod'а (с новой версией)
# 2. Старые 3 Pod'а удаляются
# 3. ВСЕ 3 БД теряют свои данные (emptyDir!)
# 4. Приложение не может запуститься
# 5. Production downtime!

Правильный production stack

┌─────────────────────────────────────────┐
│     Kubernetes Cluster                  │
├─────────────────────────────────────────┤
│                                         │
│  ┌─ Deployment: user-service           │
│  │  ├─ Pod 1 (user-service)            │
│  │  ├─ Pod 2 (user-service)            │
│  │  └─ Pod 3 (user-service)            │
│  │        ↓                             │
│  │    Service: user-service            │
│  │                                     │
│  ├─ StatefulSet: postgres              │
│  │  ├─ Pod 0 (postgres primary)        │
│  │  ├─ Pod 1 (postgres replica)        │
│  │  └─ Pod 2 (postgres replica)        │
│  │        ↓                             │
│  │    Service: postgres                │
│  │                                     │
│  └─ PersistentVolumes (block storage)  │
│                                         │
└─────────────────────────────────────────┘

Выводы

1. Технически возможно: Да, можно положить БД и микросервис в один Pod

2. На практике: НИКОГДА не делай этого в production

3. Почему:

   • Нарушение single responsibility
   • Проблемы с масштабированием
   • Потеря данных
   • Невозможность репликации
   • Сложное управление ресурсами

4. Правильно:

   • Микросервис в Deployment
   • БД в StatefulSet
   • Каждый на своём Pod'е
   • Связь через Service
   • Персистентность через PersistentVolumes

5. Исключения: Только для sidecar паттернов (логирование, мониторинг, прокси)