какую роль играет сетевой мост `docker0` в k8s с фланелью - PullRequest
Новая
       37

какую роль играет сетевой мост `docker0` в k8s с фланелью

0 голосов
/ 09 января 2019

k8s версия: v1.10.4
фланелевая версия: v0.10.0
версия докера v1.12.6

когда я использую команду brctl show на узле, она отображается следующим образом: 

[root@node03 tmp]# brctl show
bridge name bridge id       STP enabled interfaces
cni0        8000.0a580af40501   no      veth39711246
                                        veth591ea0bf
                                        veth5b889fed
                                        veth61dfc48a
                                        veth6ef58804
                                        veth75f5ef36
                                        vethc162dc8a
docker0     8000.0242dfd605c0   no
он показывает, что vethXXX привязаны к сетевому мосту с именем cni0, но когда я использую команду `ip addr`, он показывает: 
[root@node03 tmp]# ip addr |grep veth
6: veth61dfc48a@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP 
7: veth591ea0bf@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP 
9: veth6ef58804@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP 
46: vethc162dc8a@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP 
55: veth5b889fed@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP 
61: veth75f5ef36@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP 
78: veth39711246@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP
все эти ветки являются обязательными для `if3`, но` if3` не является cni0.it является `docker0` 
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN

кажется, что сетевой мост docker0 бесполезен, но ip addr показывает, что все устройства veth привязаны к нему. Какую роль играет сетевой мост docker0 в k8s с фланелью? спасибо

1 Ответ

0 голосов
/ 09 января 2019

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

Модель докера

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

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

модель Kubernetes

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

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

Kubernetes применяет IP-адреса в области Pod - контейнеры в пределах 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 .

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

flannel

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

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

...