Почему мост docker0 показывается внизу в кластере kubernetes с фланелью? - PullRequest
Новая
       42

Почему мост docker0 показывается внизу в кластере kubernetes с фланелью?

0 голосов
/ 31 октября 2019

У меня есть кластер kubernetes, созданный с использованием kubadm с 1 мастером и 2 работниками. фланель используется в качестве сетевого плагина. Заметил, что мост docker0 отключен на всех рабочих и главных узлах, но работа кластера работает нормально. По замыслу, мост docker0 будет недоступен, если мы используем какой-либо сетевой плагин, например, фланель в кластере kubernetes? 

docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
    link/ether 02:42:ad:8f:3a:99 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0

1 Ответ

0 голосов
/ 04 ноября 2019

Я публикую вики-ответ сообщества от этой ТАКОЙ темы, так как считаю, что она отвечает на ваш вопрос.

Здесь есть две сетевые модели Docker и Kubernetes.

Модель Docker

По умолчанию Docker использует частные сети. Он создает виртуальный мост, который по умолчанию называется docker0, и выделяет подсеть из одного из блоков частных адресов, определенных в RFC1918 для этого моста. Для каждого контейнера, который создает Docker, он выделяет виртуальное устройство Ethernet (называемое veth), которое подключено к мосту. Ветвь отображается как eth0 в контейнере с использованием пространств имен Linux. Интерфейс eth0 в контейнере получает IP-адрес из диапазона адресов моста.

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

Модель Kubernetes

Kubernetes предъявляет следующие фундаментальные требования к любой сетевой реализации (за исключением любых политик преднамеренной сегментации сети):

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

Kubernetes применяет IP-адреса на Pod scope - контейнеры в пределах Pod совместно используют свои сетевые пространства имен - включая их IP-адреса. Это означает, что все контейнеры в Pod могут достигать портов друг друга в localhost. Это подразумевает, что контейнеры в Pod должны координировать использование порта, но это ничем не отличается от процессов в ВМ. Это называется моделью «IP-per-pod». Это реализовано с использованием Docker в качестве «контейнера pod», который держит пространство имен сети открытым, в то время как «контейнеры приложений» (вещи, указанные пользователем) присоединяются к этому пространству имен с помощью функции --net=container:<id> Docker.

Как и в DockerМожно запросить порты хоста, но это сводится к очень нишевой операции. В этом случае порт будет выделен на хосте Node, а трафик будет перенаправлен на Pod. Сам по себе Pod не учитывает существование или отсутствие портов хоста.

Для интеграции платформы с базовой сетевой инфраструктурой Kubernetes предоставляет спецификацию плагина, называемую Контейнерный сетевой интерфейс(CNI) . Если основные требования Kubernetes выполнены, поставщики могут использовать сетевой стек по своему усмотрению, обычно используя оверлейные сети для поддержки кластеров multi-subnet и multi-az .

Bellowпоказано, как оверлейные сети реализуются через Flannel , который является популярным CNI .

flannel

Вы можетеУзнайте больше о других CNI здесь . Подход Kubernetes объяснен в Cluster Networking документах. Я также рекомендую прочитать Kubernetes Is Hard: почему EKS делает его проще для архитекторов сетей и безопасности , в котором объясняется, как работает Фланель , а также еще одна статья из Medium

Надеюсь, это ответит на ваш вопрос.

...