Автор | Shengdong Alibaba Cloud послепродажный технический эксперт

Руководство:В настоящее время существует два решения для кластерной сети Alibaba Cloud K8S: одно — фланелевое решение, а другое — тервейное решение, основанное на калико и эластичной сетевой карте eni. Terway похож на фланель, разница в том, что terway поддерживает эластичную сетевую карту Pod и функцию NetworkPolicy. В этой статье, основанной на текущей версии 1.12.6, автор берет фланель в качестве примера для глубокого анализа метода реализации кластерной сети Alibaba Cloud K8S.

с высоты птичьего полета

Вообще говоря, после завершения конфигурации сети кластера Alibaba Cloud K8S, как показано на следующем рисунке: включая CIDR кластера, таблицу маршрутизации VPC, сеть узла, podCIDR узла, виртуальный мост cni0 на узле и veth, соединяющий Pod и мост. .

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

По сути, мы можем понять эти конфигурации в трех случаях: конфигурация кластера, конфигурация узла и конфигурация модуля. В соответствии с этими тремя ситуациями фактически существует три подразделения IP-сегмента кластерной сети: сначала каждому узлу выделяется кластерный CIDR, затем podCIDR (то есть сегмент подсети кластерного CIDR), и, наконец, каждый под назначенный в podCIDR.Назначьте свой собственный IP.

Построение кластерной сети

Начальная фаза

Создание кластера основано на облачных ресурсах VPC и ECS.После создания VPC и ECS мы можем в основном получить конфигурацию ресурсов, как показано на рисунке ниже. Получаем VPC, сетевой сегмент этого VPC 192.168.0.0/16, получаем несколько ECS, и им присваиваются IP адреса из сетевого сегмента VPC.

кластерный этап

На основе вышеуказанных исходных ресурсов мы используем консоль создания кластера для получения CIDR кластера. Это значение передается в качестве параметра сценарию подготовки узла кластера, который затем передается средству настройки узла кластера kubeadm. Наконец, kubeadm записывает этот параметр в файл yaml kube-controller-manager.yaml статического пода контроллера кластера.

Контроллер кластера имеет этот параметр.Когда узел kubelet регистрирует узел в кластере, контроллер кластера разделит подсеть для каждого зарегистрированного узла, то есть назначит podCIDR для каждого узла. Как показано выше, подсеть узла B — 172.16.8.1/25, а подсеть узла A — 172.16.0.128/25. Эта конфигурация будет записана в элементе данных podCIDR узла кластера.

этап узла

После описанной выше стадии кластера K8S разделяет CIDR кластера и podCIDR для каждого узла. На этой основе кластер будет выдавать фланельды каждому этапу и в дальнейшем строить сетевой фреймворк, который могут использовать поды на нодах. Здесь есть две основные операции:

• Во-первых, кластер настраивает VPC с записями таблицы маршрутизации через Cloud Controller Manager. Для каждого узла существует одна запись в таблице маршрутизации.Каждая запись означает, что если адрес назначения, полученный маршрутом VPC, является IP-адресом podCIDR узла, маршрут перенаправит сетевой пакет в соответствующий ECS;
• Второй — создать виртуальный мост cni0 и маршруты, связанные с cni0. Эффект этих конфигураций заключается в том, что сетевые пакеты, поступающие из-за пределов сцены, если IP-адрес назначения — podCIDR, будут пересылаться узлом в виртуальную локальную сеть cni0.

Примечание. В реальной реализации создание CNI0 создается, когда POD, используемый при первом использовании сети POD, запланирован для узла, но Flannal CNI в следующем разделе логически, CNI0 принадлежит сети узла, а не ей. к сети POD, как описано здесь.

Стадия стручка

На предыдущих трех этапах кластер фактически построил сетевую коммуникационную магистраль между модулями. В это время, если кластер назначит Pod на узел, kubelet создаст сетевое пространство имен и veth-устройство для самого Pod через фланельный cni, а затем добавит одно из veth-устройств к виртуальному мосту cni0 и создаст сетевое пространство имен для Pod в Pod.Veth-устройство настроено с IP-адресом. Таким образом, Pod подключается к магистрали сетевой связи. Здесь следует подчеркнуть, что фланель в предыдущем разделе и фланель cni в этом разделе полностью состоят из двух компонентов. flanneld — это модуль, доставляемый набором демонов на каждый узел. Его функция — построение сети (транка), а flannel cni — это подключаемый модуль cni, устанавливаемый через пакет rpm kubernetes-cni при создании узла. Он вызывается kubelet и использует его для создания сети (ветки) для конкретного пода. Понимание разницы между ними поможет нам понять назначение файлов конфигурации, связанных с фланнелдом и фланнелем cni. Например, /run/flannel/subnet.env — это файл переменной среды, созданный flanneld и предоставляющий входные данные для flannel cni; другим примером является /etc/cni/net.d/10-flannel.conf, который также является pod (точнее, это скрипт install-cni в pod'е), скопированный из pod’а в каталог node, файл конфигурации подсети, используемый flannel cni.

коммуникация

Вышеизложенное завершает построение сетевой среды Pod. Основываясь на приведенной выше сетевой среде, Pod может выполнять четыре типа связи: локальная связь, связь с Pod на том же узле, связь Pod между узлами и связь Pod и объекта за пределами сети Pod.

Среди них локальная связь относится к связи между различными контейнерами в поде. Поскольку контейнеры интрасети Pod совместно используют стек сетевых протоколов, связь между ними может осуществляться через петлевое устройство.

Связь между модулями на одном узле — это связь внутри виртуального моста cni0, что эквивалентно связи между устройствами в локальной сети уровня 2.

Связь Pod между узлами немного сложнее, но также очень интуитивно понятна: пакет данных отправителя через шлюз моста cni0 поступает на узел, а затем отправляет его на маршрут VPC через узел eth0. Здесь не будет пакетирования. Когда маршрутизация VPC получает пакет, она запрашивает таблицу маршрутизации, чтобы подтвердить назначение пакета, и отправляет пакет на соответствующий узел ECS. После входа в узел, поскольку flanneld создает маршрут cni0 на узле, пакет данных будет отправлен в локальную сеть cni0 пункта назначения, а затем в блок назначения.

В последнем случае связь между Pod и сетевыми объектами, не относящимися к Pod, должна выполнять SNAT через правило iptables на узле, и это правило является конфигурацией, выполненной фланельдом в соответствии с параметром командной строки --ip-masq.

Суммировать

Вышеизложенный принцип построения и связи кластерной сети Alibaba Cloud K8S. В основном мы анализируем кластерную сеть K8S с точки зрения построения сети и связи. Построение сети включает в себя начальную стадию, стадию кластера, стадию узла и стадию Pod, Эта классификация помогает нам понять эти сложные конфигурации. После понимания каждой конфигурации становится легче понять принцип взаимодействия кластера.

Официальная учетная запись Alibaba Cloud Native WeChat (идентификатор: Alicloudnative) фокусируется на микросервисах, бессерверных технологиях, контейнерах, Service Mesh и других технических областях, фокусируется на популярных тенденциях облачных технологий и практиках крупномасштабного внедрения облачных технологий и является лучшим облачным сервисом. разработчик. Технический паблик аккаунт."