Кубернетес CNI против Кубе-прокси - PullRequest
Новая
       16

Кубернетес CNI против Кубе-прокси

0 голосов
/ 29 ноября 2018

Я не уверен, в чем разница между плагином CNI и Kube-прокси в Kubernetes.Из того, что я извлек из документации, я заключаю следующее:

Kube-proxy отвечает за связь с главным узлом и маршрутизацию.

CNI обеспечивает подключение, назначая IP-адреса модулям и службам.и достижимость через его маршрутизацию Deamon.

маршрутизация кажется перекрывающей функцией между ними, это правда?

С уважением, Чарльз

Ответы [ 2 ]

0 голосов
/ 26 февраля 2019

В kubernetes есть два вида IP: ClusterIP и Pod IP.

CNI

CNI заботится о Pod IP.

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

В Calico это реализовано с помощью N маршрутов хоста (N = количество устройств калибровки) и M прямых маршрутов на tun0 (M = количество узлов кластера K8s). 

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.130.29.1     0.0.0.0         UG    100    0        0 ens32
10.130.29.0     0.0.0.0         255.255.255.0   U     100    0        0 ens32
10.244.0.0      0.0.0.0         255.255.255.0   U     0      0        0 *
10.244.0.137    0.0.0.0         255.255.255.255 UH    0      0        0 calid3c6b0469a6
10.244.0.138    0.0.0.0         255.255.255.255 UH    0      0        0 calidbc2311f514
10.244.0.140    0.0.0.0         255.255.255.255 UH    0      0        0 califb4eac25ec6
10.244.1.0      10.130.29.81    255.255.255.0   UG    0      0        0 tunl0
10.244.2.0      10.130.29.82    255.255.255.0   UG    0      0        0 tunl0

В этом случае 10.244.0.0/16 - это CIDR Pod IP, а 10.130.29.81 - это узел в кластере.Вы можете себе представить, если у вас есть TCP-запрос к 10.244.1.141, он будет отправлен на 10.130.29.81, следуя седьмому правилу.И на 10.130.29.81 будет правило маршрута, подобное этому: 

10.244.1.141    0.0.0.0         255.255.255.255 UH    0      0        0 cali4eac25ec62b

Это, наконец, отправит запрос на правильный Pod.

Я не уверен, почему демонnessesary, я думаю, демон должен предотвратить ручное удаление созданных им правил маршрута.

kube-proxy

Работа kube-proxy довольно проста, он просто перенаправляет запросы с IP-адреса кластера на PodIP.

kube-proxy имеет два режима, IPVS и iptables.Если ваш kube-proxy работает в режиме IPVS, вы можете увидеть правила перенаправления, созданные kube-proxy, выполнив следующую команду на любом узле кластера: 

ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.96.0.1:443 rr
  -> 10.130.29.80:6443            Masq    1      6          0         
  -> 10.130.29.81:6443            Masq    1      1          0         
  -> 10.130.29.82:6443            Masq    1      0          0         
TCP  10.96.0.10:53 rr
  -> 10.244.0.137:53              Masq    1      0          0         
  -> 10.244.0.138:53              Masq    1      0          0   
...

В этом случае выможет видеть IP-адрес кластера по умолчанию CoreDNS 10.96.0.10, а за ним находятся два реальных сервера с IP-адресом: 10.244.0.137 и 10.244.0.138.

Это правило - то, что нужно создать для kube-прокси, и чтоСоздан kube-proxy. Режим

PS iptables почти такой же, но правила iptables выглядят ужасно.Я не хочу вставлять это здесь.: Р

0 голосов
/ 29 ноября 2018

OVERLAY NETWORK

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

Все остальные сетевые элементы Kubernetes основаны на корректной работе оверлейной сети.

Существует множество наложенных сетевых бэкэндов (ситцевое, фланелевое, ткацкое), и ландшафт довольно запутанный.Но, насколько я понимаю, оверлейная сеть имеет 2 обязанности:

  1. Убедитесь, что ваши модули могут отправлять сетевые запросы вне кластера
  2. Поддерживайте стабильное отображение узлов в подсети иДержите каждый узел в вашем кластере обновленным с этим отображениемДелайте правильно, когда узлы добавляются и удаляются.

KUBE-PROXY

Просто чтобы понять, что такое kube-proxy, Вот как работают сервисы Kubernetes!Служба - это набор модулей, каждый из которых имеет свой собственный IP-адрес (например, 10.1.0.3, 10.2.3.5, 10.3.5.6)

  1. Каждая служба Kubernetes получает IP-адрес (например, 10.23.1.2).)
  2. kube-dns разрешает DNS-имена службы Kubernetes в IP-адреса (поэтому my-svc.my-namespace.svc.cluster.local может сопоставляться с 10.23.1.2)
  3. наборы kube-proxyдо правил iptables для случайной балансировки нагрузки между ними.

Итак, когда вы делаете запрос к my-svc.my-namespace.svc.cluster.local, он разрешается в 10.23.1.2,и затем правила iptables на вашем локальном хосте (генерируемые kube-proxy) перенаправляют его на один из 10.1.0.3 или 10.2.3.5 или 10.3.5.6 в произвольном порядке.

Короче говоря, overlay networks определяет базовую сетькоторый может быть использован для общения различных компонентов kubernetes.kube-proxy - это инструмент для создания магии IP-таблиц, который позволяет вам подключаться к любому модулю (используя сервики) в kubernetes независимо от того, на каком узле существует этот модуль.

Я настоятельно рекомендую вам прочитать следующееблог для лучшего понимания:

https://jvns.ca/blog/2017/10/10/operating-a-kubernetes-network/

Надеюсь, это даст вам краткое представление о сети kubernetes.

...