Понимание ключевого различия между Pod и Node в Kubernetes

Если вы новичок в Kubernetes, различие между pod и node — одна из первых вещей, которая помогает понять всю систему. Node — это машина. Pod — это рабочая нагрузка, которую Kubernetes размещает на этой машине. Контейнеры работают внутри pod, а pod работают на node.

Это звучит просто, но объясняет множество повседневных проблем. Если pod находится в состоянии Pending, Kubernetes, возможно, не нашел подходящий node. Если node находится в состоянии NotReady, каждый pod на нем находится под угрозой. Если вашему приложению требуется высокая доступность, запуска большего количества контейнеров недостаточно; вам нужны реплики, распределенные по разным node.

---

Обзор архитектуры кластера Kubernetes

Кластер Kubernetes состоит из набора машин (физических или виртуальных), работающих вместе. Эти машины широко делятся на Control Plane (мозг, управляющий состоянием кластера) и Worker Nodes (мышцы, выполняющие фактические рабочие нагрузки). Pod и Node взаимодействуют в этой структуре.

• Node: Физическая или виртуальная машина, предоставляющая CPU, память, диск и сеть.
• Pod: Наименьшая развертываемая единица, которую планирует Kubernetes. Он размещает один или несколько контейнеров.

Понимание этой иерархии — где Node размещают Pod, а Pod размещают Контейнеры — является отправной точкой для освоения Kubernetes.

Node Kubernetes: Основа вычислительной мощности

Node Kubernetes (иногда называемый рабочей машиной) — это машина, которая предоставляет необходимые вычислительные ресурсы — CPU, RAM и сеть — для запуска ваших приложений. Кластер должен иметь как минимум один Node, хотя производственные среды обычно используют множество для обеспечения избыточности и масштабируемости.

Ключевые обязанности Node

Каждый Node запускает основные компоненты, которые позволяют ему взаимодействовать с Control Plane и размещать рабочие нагрузки приложений:

1. Kubelet: Агент, работающий на каждом Node, отвечающий за связь с Control Plane. Он работает с средой выполнения контейнеров, чтобы гарантировать, что контейнеры, описанные в PodSpecs, работают и исправны на его Node.
2. Среда выполнения контейнеров: Программное обеспечение, отвечающее за извлечение образов и запуск контейнеров, обычно containerd или CRI-O в современных кластерах.
3. Kube-proxy: Поддерживает сетевые правила на Node, обеспечивая связь с Pod и от Pod, как внутреннюю, так и внешнюю.

Практический пример: Представление Node

Когда вы проверяете Node в своем кластере, вы видите базовую инфраструктуру, которую использует Kubernetes:

kubectl get nodes

NAME           STATUS   ROLES    AGE     VERSION
worker-node-01 Ready    <none>   2d1h    v1.27.4
worker-node-02 Ready    <none>   2d1h    v1.27.4

Ключевой вывод: Node — это уровень машины, где происходит выполнение.

Pod Kubernetes: Наименьшая развертываемая единица

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

Почему Pod вместо прямых контейнеров?

Kubernetes управляет Pod, а не отдельными контейнерами, по нескольким критическим причинам:

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

Анатомия Pod

Чаще всего Pod содержит один основной контейнер приложения. Однако они часто используются для шаблона Sidecar, где вторичный контейнер помогает основному (например, агент ведения журнала, прокси-сервер сервисной сетки).

Пример определения Pod (упрощенный YAML)

Следующий YAML определяет Pod, оборачивающий один контейнер Nginx:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80

Ключевой вывод: Pod — это логический хост для контейнеров вашего приложения и единица, которая планируется на Node.

Основные отношения: Планирование и размещение

Фундаментальное взаимодействие между Pod и Node регулируется планировщиком Kubernetes, который находится в Control Plane.

Как Pod попадают на Node

1. Создание Pod: Пользователь отправляет определение YAML для Pod (или объекта более высокого уровня, такого как Deployment, который создает Pod) на API Server.
2. Решение о планировании: Планировщик определяет лучший доступный Node для запуска этого Pod на основе запросов ресурсов, ограничений и доступной емкости.
3. Привязка: После выбора Node Pod привязывается к этому конкретному Node.
4. Выполнение: Kubelet на назначенном Node замечает новое назначение Pod, извлекает необходимые образы и запускает контейнеры.

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

Особенность	Node Kubernetes	Pod Kubernetes
Роль	Предоставляет физические/виртуальные вычислительные ресурсы.	Запускает один или несколько контейнеров приложений.
Область	Уровень инфраструктуры кластера.	Уровень рабочей нагрузки приложения.
Единица планирования	Получает Pod от планировщика.	Единица, которая планируется на Node.
Компоненты	Kubelet, Среда выполнения контейнеров, Kube-proxy.	Контейнеры приложений, общие тома, общий IP.
Количество	Обычно от нескольких до многих на кластер.	Может быть сотни или тысячи в зависимости от рабочей нагрузки.

Реальный пример развертывания

Представьте веб-приложение с таким Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: storefront
spec:
  replicas: 3
  selector:
    matchLabels:
      app: storefront
  template:
    metadata:
      labels:
        app: storefront
    spec:
      containers:
      - name: web
        image: example/storefront:v1
        ports:
        - containerPort: 8080

Это не создает три node. Это создает три реплики pod. Затем планировщик решает, какие существующие node должны запускать эти pod. В небольшом кластере вы можете увидеть это:

kubectl get pods -o wide

NAME                          READY   STATUS    NODE
storefront-6d8f8c7f9b-2xk9p   1/1     Running   worker-node-01
storefront-6d8f8c7f9b-7hxm4   1/1     Running   worker-node-02
storefront-6d8f8c7f9b-q4zpt   1/1     Running   worker-node-02

Есть три pod, но задействовано только два node. Если worker-node-02 выйдет из строя, две реплики исчезнут сразу. Deployment попытается заменить их, но для этого ему потребуется исправная емкость node. Вот почему размещение node имеет значение, даже если ваш Deployment имеет несколько реплик.

Если вы хотите побудить Kubernetes распределять реплики по node, используйте ограничения распространения топологии или анти-сродство pod. Это не нужно для каждого небольшого внутреннего инструмента, но следует рассмотреть для сервисов, ориентированных на клиентов, где отказ одного node не должен удалять большую часть емкости.

Pod заменяемы; Node — это управляемая емкость

Здоровый образ мышления в Kubernetes заключается в том, что pod заменяемы. Deployments, ReplicaSets, StatefulSets, Jobs и DaemonSets постоянно создают и заменяют pod. Имя pod со случайным суффиксом не то, на что вы должны полагаться навсегда.

Node также заменяемы в хорошо управляемом кластере, но они являются единицами емкости. Им требуются исправления операционной системы, исправность kubelet, достаточно места на диске, работающая среда выполнения контейнеров и сетевое подключение. Когда у node возникает проблема, многие pod могут почувствовать это одновременно.

Эта разница проявляется в том, как вы отлаживаете:

• Если один pod выходит из строя, а другие pod на том же node исправны, начните с журналов pod, конфигурации, проб, образа и ограничений ресурсов.
• Если многие несвязанные pod на одном node выходят из строя, начните с node: давление на диск, давление на память, статус kubelet, работоспособность CNI и журналы среды выполнения контейнеров.
• Если новые pod не могут запуститься нигде, посмотрите на обще кластерную емкость, квоты, правила планирования и работоспособность control plane.

Распространенные заблуждения

Первое заблуждение — думать, что pod — это то же самое, что контейнер. Большинство pod содержат один основной контейнер, поэтому сокращение кажется безвредным. Но sidecars делают различие важным. Прокси-сервер сервисной сетки, сборщик журналов или вспомогательный контейнер могут работать в том же pod, что и приложение. Они разделяют сетевое пространство имен pod, поэтому localhost между этими контейнерами работает внутри этого pod.

Второе заблуждение — думать, что Kubernetes перемещает работающий pod на другой node, как живую миграцию виртуальной машины. Обычно это не так. Если node истощается или выходит из строя, Kubernetes завершает или теряет старый pod и создает замену pod в другом месте. Эта замена имеет другую идентичность pod, и любые изменения локальной файловой системы контейнера из старого pod теряются, если они не были записаны в постоянное хранилище.

Третье заблуждение — предполагать, что Service работает на node. Service — это стабильная сетевая абстракция перед pod. Он выбирает pod по меткам и направляет трафик на их IP-адреса. Node предоставляют место, где работают эти pod, но сам Service не "находится" на одном рабочем node так же, как pod.

Как это влияет на повседневный дизайн

Когда вы выбираете количество реплик, вы выбираете, сколько копий pod Kubernetes должен пытаться поддерживать в работе. Вы не выбираете, сколько node будет существовать. Deployment с десятью репликами все еще может разместить несколько pod на одном node, если вы не добавите правила распространения и в кластере не будет достаточной емкости node.

Когда вы выбираете размер node, вы выбираете форму пула емкости. Несколько больших node могут быть эффективными, но отказ одного node удаляет большую долю ваших работающих pod. Больше меньших node может улучшить изоляцию отказов, но они добавляют накладные расходы и могут сделать упаковку менее эффективной. Универсального ответа нет; правильный выбор зависит от размера рабочей нагрузки, потребностей в доступности и стоимости.

Государственные рабочие нагрузки добавляют еще один нюанс. StatefulSet все еще создает pod, и эти pod все еще работают на node, но каждый pod может иметь стабильную идентичность и постоянный том. Если node умирает, Kubernetes может воссоздать pod в другом месте, но уровень хранения должен поддерживать подключение или доступ к тому из нового местоположения.

Лучшие практики и советы по устранению неполадок

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

Управление ресурсами

• Запросы/Лимиты ресурсов: Всегда определяйте requests и limits ресурсов в спецификациях вашего Pod. Это позволяет планировщику точно сопоставлять Pod с Node, имеющими достаточную емкость, предотвращая конкуренцию за ресурсы.
• Давление на Node: Если Node становится перегруженным (заканчивается место на диске или память), Kubelet сообщает об этом состоянии. Затем Kubernetes может вытеснить Pod с этого Node для поддержания стабильности.

Высокая доступность (HA)

• Избыточность: Для достижения HA вы должны запускать несколько копий (реплик) ваших Pod, управляемых Deployments или StatefulSets. Планировщик попытается разместить эти реплики на разных Node, чтобы гарантировать, что отказ одного Node не приведет к падению всего приложения.

Устранение неполадок

Когда приложение не запускается:

1. Проверьте статус Pod: Используйте kubectl describe pod <имя-pod>. Посмотрите на раздел 'Events', чтобы увидеть, на какой Node был запланирован Pod.
2. Проверьте статус Node: Если Pod застрял в состоянии Pending, проблема обычно связана с планированием (например, ни один Node не соответствует требуемым ограничениям). Если Pod работает, но дает сбой, проверьте журналы Kubelet на конкретном Node, на котором он находится.

Полезные команды:

kubectl get pods -o wide
kubectl describe pod <имя-pod>
kubectl get nodes
kubectl describe node <имя-node>

Вывод -o wide недооценен. Он показывает, на каком node находится каждый pod, что часто является ключом к разделению проблемы приложения и проблемы инфраструктуры.

Краткая версия

Node отвечает на вопрос "где это может работать?" Pod отвечает на вопрос "что должно работать вместе?" Планировщик соединяет эти две идеи, размещая pod на node. Как только вы увидите эту взаимосвязь, ошибки Kubernetes станет легче читать: ожидающие pod часто являются проблемами размещения, выходящие из строя pod часто являются проблемами рабочей нагрузки, а нездоровые node могут создавать множество проблем с pod одновременно.