Как модуль kubernetes получает IP вместо контейнера вместо него, так как плагин CNI работает на уровне контейнера
Как модуль kubernetes получает IP вместо контейнера вместо него, так как плагин CNI работает на уровне контейнера?
Как все контейнеры одного модуля используют один и тот же сетевой стек?
4 ответа
Контейнеры используют функцию ядра, называемую виртуальным сетевым интерфейсом, интерфейс виртуальной сети (назовем его veth0) создается и затем назначается пространству имен; при создании контейнера он также назначается пространству имен при создании нескольких контейнеров. в одном и том же пространстве имен будет создан только один сетевой интерфейс veth0.
POD - это просто термин, используемый для указания набора ресурсов и функций, одним из которых является пространство имен и контейнеры, работающие в нем.
Когда вы говорите, что POD получает IP, то, что фактически получает ip, это интерфейс veth0, контейнерные приложения видят veth0 так же, как приложения вне контейнера видят одну физическую сетевую карту на сервере.
CNI - это просто техническая спецификация того, как он должен работать, чтобы несколько сетевых плагинов работали без изменений в платформе. Процесс выше должен быть одинаковым для всех сетевых плагинов.
В этом посте есть хорошее объяснение
Это kubeproxy, который заставляет все работать. один модуль имеет один прокси, который переводит все порты через один IP для остальных контейнеров. только в определенных случаях говорится, что вы хотите иметь несколько контейнеров в одном модуле. его не предпочитают, но это возможно. Вот почему они называют это "тесно" в сочетании. пожалуйста, обратитесь к: https://kubernetes.io/docs/concepts/cluster-administration/proxies/
Существует специальный контейнер, называемый "контейнер паузы", который содержит пространство имен сети для модуля. Он ничего не делает, и его контейнерный процесс просто засыпает.
Kubernetes создает один контейнер паузы для каждого модуля, чтобы получить IP-адрес соответствующего модуля и настроить пространство имен сети для всех других контейнеров, которые являются частью определенного модуля. Все контейнеры в модуле могут достигать друг друга, используя localhost.
Это означает, что ваш контейнер "приложения" может умереть и вернуться к жизни, и все настройки сети все равно останутся без изменений.
Во-первых, давайте углубимся в аспект CNI. В производственных системах рабочая нагрузка / модуль (рабочую нагрузку можно рассматривать как одно или несколько контейнерных приложений, используемых для выполнения определенной функции), изоляция сети является требованием безопасности первого класса. Более того, в зависимости от того, как настроена инфраструктура, плоскости маршрутизации может также потребоваться атрибут рабочей нагрузки (прокси-сервер kubectl), прокси-сервера уровня хоста (прокси-сервер kube) или центральной плоскости маршрутизации (прокси-сервер apiserver). что прокси на уровне хоста предоставляет шлюз для.
Как для обнаружения службы, так и для фактической отправки запросов из рабочей нагрузки / модуля вам не нужно, чтобы отдельные разработчики приложений общались с прокси-сервером apiserver, поскольку это может привести к дополнительным расходам. Вместо этого вы хотите, чтобы они связывались с другими приложениями через прокси-сервер kubectl или kube, причем эти уровни отвечают за знание того, когда и как взаимодействовать с плоскостью apiserver.
Поэтому при раскрутке новой рабочей нагрузки кубелет можно пропустить --network-plugin=cni и путь к конфигурации, сообщающий kubelet, как настроить интерфейс виртуальной сети для этой рабочей нагрузки / модуля.
Например, если вы не хотите, чтобы ваши контейнеры приложений в pod могли напрямую взаимодействовать с прокси-сервером куба на уровне хоста, так как вы хотите провести некоторый мониторинг для конкретной инфраструктуры, ваш CNI и конфигурация рабочей нагрузки будут:
- мониторинг на крайнем контейнере
- Внешний контейнер создает виртуальный сетевой интерфейс для каждого другого контейнера в модуле.
- внешний контейнер находится на мостовом интерфейсе (также частном виртуальном сетевом интерфейсе), который может общаться с прокси-сервером kube на хосте
IP-адрес, который получает модуль, позволяет другим рабочим нагрузкам посылать байты этому модулю через его мостовой интерфейс - поскольку, по сути, другие люди должны общаться с модулем, а не с отдельными рабочими единицами внутри модуля.