IP-адресация стручков в Кубернетесе

Question

Как модули получают уникальные IP-адреса, даже если они находятся на одном рабочем узле?

Кроме того, модуль не является устройством, что логично, если он имеет IP-адрес?
Назначен ли IP-адресстручку виртуальный IP?

Answer 1

Kubernetes создает сеть в вашей сети для контейнеров.в GKE, например, по умолчанию это / 14, но он может быть перезаписан пользователем в диапазоне от / 11 до /19.

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

Почему?Представьте себе, у вас есть VPN-туннель, который должен доставить пакет по адресу, который используется как модулем, так и виртуальной машиной.Кому оно доставит?

Итак, отвечая на ваш вопрос;нет, это не виртуальный IP-адрес, это физический IP-адрес вашей сети.

Answer 2

A pod является частью кластера (группы узлов), а кластерная сеть сообщает вам, что:

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

Это означает, что все контейнеры в модуле могут достигать портов друг друга на локальном хосте.
Это означает, что контейнеры в модуле должны координировать использование порта, но это ничем не отличается от процессов в ВМ.
Это называется модель «IP-per-pod» .

Ограничения:

• все контейнеры могут связыватьсясо всеми другими контейнерами без NAT
• все узлы могут связываться со всеми контейнерами (и наоборот) без NAT
• IP, который контейнер видит сам как тот же IP, что другие видят его как

Подробнее с " Сеть с Kubernetes " от Алок Кумар Сингх :

Здесь:

У нас есть машина, она называется узел в кубернетах.
Имеет IP 172.31.102.105, принадлежащий подсети с CIDR 172.31.102.0/24.

( CIDR: ClasslessМеждоменная маршрутизация , метод распределения IP-адресов и IP-маршрутизации)

К узлу подключен сетевой интерфейс eth0.Он принадлежит корневому сетевому пространству имен узла.
Для изоляции модулей они были созданы в своих собственных сетевых пространствах имен - это pod1 n / w ns и pod2 n / w ns.
IP-адресам назначен IP-адрес.адреса 100.96.243.7 и 100.96.243.8 из диапазона CIDR 100.96.0.0/11.

См. " Kubernetes Networking " с CloudNativelabs :

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

Ниже приведены возможные варианты реализации сети с помощью плагинов CNI, которые позволяют осуществлять связь «от одного к другому» с учетом требований Kubernetes:

• уровень 2 (коммутация) решение
• уровень3 (маршрутизация) решение
• оверлейные решения

слой 2 (коммутация)

Вы можете видеть их IP как часть диапазона адресов подсети контейнера.

уровень 3 (маршрутизация)

Этоо заполнении маршрутизатора шлюза по умолчанию маршрутами для подсети, как показано на рисунке.
Маршруты к 10.1.1.0/24 и 10.1.2.0/24 настроены так, чтобы проходить через узел 1 и узел 2 соответственно.

оверлейные решения

Как правило, не используются.

Примечание. См. Также (октябрь 2018 г.): " Google Kubernetes Engine network ".