Как модуль kubernetes получает IP вместо контейнера вместо него, так как плагин CNI работает на уровне контейнера

Question

Как модуль kubernetes получает IP вместо контейнера вместо него, поскольку плагин CNI работает на уровне контейнера?

Как все контейнеры одного модуля совместно используют один и тот же сетевой стек?

Answer 1

Существует специальный контейнер, называемый «контейнер паузы», который содержит пространство имен сети для модуля.Он ничего не делает, и его контейнерный процесс просто переходит в спящий режим.

Kubernetes создает один контейнер паузы для каждого модуля, чтобы получить IP-адрес соответствующего модуля и настроить пространство имен сети для всех других контейнеров, которые являются частьюконкретный стручокВсе контейнеры в модуле могут достигать друг друга, используя localhost.

Это означает, что ваш контейнер «приложения» может умереть и вернуться к жизни, и все настройки сети все равно останутся без изменений.

Answer 2

Контейнеры используют функцию ядра, называемую виртуальный сетевой интерфейс , виртуальный сетевой интерфейс (назовем его veth0 ) создается и затем назначаетсяПространство имен, когда контейнер создается, он также назначается пространству имен. Когда в одном пространстве имен создается несколько контейнеров, будет создан только один сетевой интерфейс veth0.

POD - это просто термин, используемый дляукажите набор ресурсов и функций, одним из которых является пространство имен и работающие в нем контейнеры.

Когда вы говорите, что POD получает IP, то, что фактически получает ip, это интерфейс veth0, приложения-контейнеры видятТочно так же приложения вне контейнера видят одну физическую сетевую карту на сервере.

CNI - это просто техническая спецификация того, как он должен работать, чтобы несколько сетевых плагинов работали без изменений в платформе.Вышеописанный процесс должен быть одинаковым для всех сетевых плагинов.

В этом посте есть хорошее объяснение

Answer 3

Во-первых, давайте углубимся в аспект CNI.В производственных системах рабочая нагрузка / модуль (рабочую нагрузку можно рассматривать как одно или несколько контейнерных приложений, используемых для выполнения определенной функции), изоляция сети является требованием безопасности первого класса.Более того, в зависимости от того, как настроена инфраструктура, плоскости маршрутизации может также потребоваться атрибут рабочей нагрузки (прокси-сервер kubectl), прокси-сервера уровня хоста (прокси-сервер kube) или центральной плоскости маршрутизации (прокси-сервер apiserver).что прокси-сервер уровня хоста предоставляет шлюз для.

как для обнаружения службы, так и для фактической отправки запросов из рабочей нагрузки / модуля, вы не хотите, чтобы отдельные разработчики приложений общались с прокси-сервером apiserver, поскольку это можетпонести накладные расходы.Вместо этого вы хотите, чтобы они взаимодействовали с другими приложениями через прокси-сервер kubectl или kube, причем эти уровни отвечают за знание того, когда и как взаимодействовать с плоскостью apiserver.

Следовательно, при ускорении новой рабочей нагрузкиkubelet может быть передано --network-plugin=cni и путь к конфигурации, указывающий kubelet, как настроить виртуальный сетевой интерфейс для этой рабочей нагрузки / модуля.

Например, если вы не хотите, чтобы ваши контейнеры приложений в pod могли напрямую взаимодействовать с прокси-сервером куба на уровне хоста, так как вы хотите провести некоторый мониторинг, специфичный для инфраструктуры, ваш CNI и конфигурация рабочей нагрузки будут:

• мониторинг в самом внешнем контейнере
• внешний контейнер создает виртуальный сетевой интерфейс для каждого другого контейнера в pod
• внешний контейнер находится на мостовом интерфейсе (также частный интерфейс виртуальной сети)который может общаться с прокси-сервером kube на хосте

IP-адрес, который получает модуль, позволяет другим рабочим нагрузкам отправлять байты этому модулю через его мостовой интерфейс - поскольку, по сути, другие люди должны общаться сстручок, а не отдельные рабочие единицы внутри стручка.

Answer 4

это kubeproxy, который заставляет все работать.один модуль имеет один прокси, который переводит все порты через один IP для остальных контейнеров.только в определенных случаях говорится, что вы хотите иметь несколько контейнеров в одном модуле.его не предпочитают, но это возможно.Вот почему они называют это «тесно» в сочетании.пожалуйста, обратитесь к: https://kubernetes.io/docs/concepts/cluster-administration/proxies/