Docker vs. Kubernetes — от изолированных контейнеров к единой среде

🔄Сегодня разбираем, почему одного контейнера недостаточно для обмена данными между процессами внутри Pod.

Контейнер запускает приложение как отдельный процесс: отдельный сетевой стек (IP, интерфейсы и маршруты), своё PID-пространство и управление ресурсами через cgroups (CPU и память). Эти механизмы изолируют и сохраняют предсказуемость работы — один процесс, один контейнер.

На практике несколько процессов работают параллельно, обмениваются данными и используют общие ресурсы. Например, основной контейнер выполняет приложение, а вспомогательный (sidecar) собирает логи, проксирует трафик или ведёт метрики.

📱В статье от iximiuz Labs дан подробный разбор того, как Kubernetes реализует Pods на уровне Linux и можно ли воспроизвести функциональность Pod в чистом Docker.
Спойлер: можно, если вручную подключить сетевые и IPC namespace, но не всё получится — UTS, например, остаётся изолированным.

Полный разбор здесь ⬅️, а ниже — практика от iximiuz Labs
• Run a Sidecar Container in the Namespace of Another Container— проверь, как контейнеры делят namespace, как в Pod.
• Limit CPU and Memory Usage of a Docker Compose Application — узнай, как задать лимиты CPU и памяти через cgroups.

#devops #kubernetes #containers #pods

Как работать с Docker Networking: концепции и применение

👩‍💻Автор статьи описывает классический случай из практики с Docker: разработчик запускает контейнер, подключается к нему через localhost и…возникает проблема. Веб-сервис развёрнут в одном контейнере, БД — в отдельном. Как настроить сетевое взаимодействие между ними?
На деле Docker уже делает всю работу – ниже расскажем об основном, подробнее найдете в статье.

👀Почему проблема возникла?
При установке Docker создает дефолтный сетевой мост (network-bridge), где он выстраивает коммуникацию по временным IP таким образом, что многоконтейнерные приложения становятся неудобными: разработчик не находит сервисы по имени, и каждый перезапуск меняет адреса контейнеров.

⏺Как решать?
Для устранения проблемы автор предлагает использовать user-defined bridge сети. При создании такой сети Docker автоматически включает внутренний DNS, и контейнеры получают постоянные hostname. Всё, что потребуется от разработчика – запустить контейнеры и подключить их к одной сети, чтобы приложение могло обращаться к базе по имени к БД, независимо от IP и рестарта контейнера.

Контейнеры с user-defined bridge


services:
  app2:
    image: nginx
    networks:
      - mybridge

  app3:
    image: alpine
    command: ["sh", "-c", "while true; do sleep 3600; done"]
    networks:
      - mybridge

networks:
  mybridge:
    driver: bridge

Контейнер со статическим IP и объявленная сеть
Для выполнения данного решения разработчик создает пользовательскую bridge-сеть с объявленным пулом адресов (subnet) и назначением контейнеру фиксированного IPv4 через ipv4_address. Так, мы обеспечиваем предсказуемую адресацию, полезную для интеграции с системой, которая зависит от IP. При этом сеть сохраняет встроенный DNS Docker, позволяющий обращаться к контейнерам по имени.

services:
  app:
    image: nginx
    networks:
      custom_net:
        ipv4_address: 172.20.0.10

networks:
  custom_net:
    driver: bridge
    ipam:
      config:
        - subnet: 172.20.0.0/24

🚀Вывод: для многоконтейнерных приложений не стоит использовать дефолтный bridge. Создавайте собственные сети или пользуйтесь Docker Compose, чтобы надёжно связать сервисы по их именам, а не по временным IP-адресам.

#devops #docker #dockercompose #networking #containers