Что общего у контейнеров, запущенных в рамках одного pod

Общие характеристики контейнеров внутри Pod в Kubernetes

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

1. Общие сетевые пространства

Контейнеры внутри Pod используют одну сетевую модель:

• IP-адрес: Все контейнеры в Pod имеют один общий IP-адрес (адрес Pod). Это означает, что они "видят" друг друга через localhost и могут коммуницировать внутри Pod без использования сервисов или внешних сетевых правил.
• Портовая пространство: Контейнеры делят портовое пространство, поэтому порты должны быть уникальными внутри Pod (нельзя назначить один порт двум разным контейнерам).

Пример коммуникации между контейнерами внутри Pod через localhost:

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: app
    image: myapp:latest
    ports:
      - containerPort: 8080
  - name: sidecar
    image: logger:latest

# Внутри контейнера 'app' можно обратиться к контейнеру 'sidecar' на порту 8081
curl http://localhost:8081

2. Общие хранилище (Volume)

Контейнеры могут монтировать одинаковые Volume (томы) для обмена данными:

• Persistent Volume (PV) или временные Volume: Определяются на уровне Pod и монтируются в каждый контейнер, нуждающийся в них.

Пример Pod с общим Volume:

apiVersion: v1
kind: Pod
metadata:
  name: shared-volume-pod
spec:
  volumes:
  - name: shared-data
    emptyDir: {}
  containers:
  - name: writer
    image: writer:latest
    volumeMounts:
    - name: shared-data
      mountPath: /data
  - name: reader
    image: reader:latest
    volumeMounts:
    - name: shared-data
      mountPath: /shared-data

3. Общие ресурсы и ограничения

Pod определяет общие ресурсы (CPU, память) для всех контейнеров:

• Requests и Limits: Устанавливаются на уровне каждого контейнера, но суммируются для Pod. Kubernetes планирует Pod на основе суммарных requests.

Пример ресурсов:

spec:
  containers:
  - name: main
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "256Mi"
        cpu: "500m"
  - name: auxiliary
    resources:
      requests:
        memory: "64Mi"
        cpu: "100m"
      limits:
        memory: "128Mi"
        cpu: "200m"

4. Общий жизненный цикл и планирование

• Жизненный цикл: Pod имеет единый статус (Pending, Running, Failed, etc.). Контейнеры запускаются и управляются вместе; если один контейнер завершается с ошибкой, весь Pod может быть перезапущен (зависит от политики restartPolicy).
• Планирование: Pod планируется на один Node (узле). Все контейнеры внутри Pod будут запущены на том же физическом или виртуальном узле.

5. Общие метки и аннотации (Labels и Annotations)

• Метки и аннотации Pod: Применяются к Pod целиком и используются для селекции сервисов, deployments, и других объектов Kubernetes. Они не индивидуализируются для каждого контейнера.

6. Общие переменные среды (Environment Variables) и секреты (Secrets)

Контейнеры могут использовать одинаковые переменные среды и Secrets, определенные на уровне Pod или контейнера:

spec:
  containers:
  - name: container1
    env:
      - name: DATABASE_URL
        valueFrom:
          secretKeyRef:
            name: db-secret
            key: url
  - name: container2
    env:
      - name: DATABASE_URL
        valueFrom:
          secretKeyRef:
            name: db-secret
            key: url

7. Общий namespace (пространство имен) для некоторых ресурсов Linux

• Linux namespaces: Контейнеры в Pod могут делиться некоторыми namespace, например, IPC (Inter-Process Communication), что позволяет им использовать механизмы, такие как System V IPC или POSIX message queues.

Практические примеры использования общего контекста

Sidecar-контейнеры часто используют общие сети и Volume для:

• Логирования (log collector)
• Мониторинга (metrics scraper)
• Проксирования (proxy для входящих запросов)

Init-контейнеры также запускаются в Pod и делят Volume, но выполняются перед основными контейнерами для предварительной подготовки (например, загрузки данных).

Итог

Контейнеры внутри Pod не являются полностью изолированными, как отдельные Pod. Их общие ресурсы позволяют создавать紧密-coupled (tightly coupled) микросервисы или вспомогательные сервисы, которые должны работать вместе на одном узле с минимальными накладными расходами на коммуникацию. Это ключевое отличие от традиционных контейнерных моделей, где каждый контейнер имеет полную изоляцию.