Автор | Старший технический эксперт Alibaba Йе Лэй

1. Базовая сетевая модель Kubernetes

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

Смысл главы 3: при оценке контейнерной сети или проектировании контейнерной сети условия ее доступа. Каким трем требованиям он должен соответствовать? Только в этом случае его можно будет считать квалифицированным сетевым решением.
Четыре цели означают, что при проектировании топологии сети и реализации конкретных функций сети необходимо четко продумать, сможет ли она достичь связности и других основных показателей.

Три главы завета

Давайте сначала рассмотрим три главы завета:

Статья 1. Любые два модуля могут взаимодействовать напрямую без явного использования NAT для получения данных и преобразования адресов;
Пункт 2. Узлы и модули могут взаимодействовать напрямую без использования явного преобразования адресов;
Статья 3: IP-адрес, который видит модуль, совпадает с IP-адресом, используемым другими для его просмотра, и не может быть преобразован в середине.

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

Четыре гола

Четыре цели на самом деле заключаются в том, чтобы при проектировании системы K8s предоставлять услуги внешнему миру, с точки зрения сети, как шаг за шагом подключить внешний мир к приложениям внутри контейнера?

**Как осуществляется связь между внешним миром и сервисом? **Есть ли интернет или пользователь вне компании, как пользоваться сервисом? service относится именно к концепции обслуживания в K8s.
Как служба взаимодействует со своими внутренними модулями?
Как взаимодействуют вызовы между модулями и модулями?
Наконец, связь между контейнером внутри пода и контейнером?

Конечная цель состоит в том, чтобы внешний мир мог подключаться к самому внутреннему и предоставлять услуги контейнеру.

Объяснение основных ограничений

Для основных ограничений можно сделать некоторые интерпретации: потому что сложность сетевой разработки контейнера заключается в том, что он фактически паразитирует в сети Host. С этой точки зрения решение контейнерной сети можно условно разделить на две основные части: **Подложка/Наложение**:

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

Почему сообщество предложило такую простую и произвольную модель perPodperIP? Лично я считаю, что управление отслеживанием производительности некоторых сервисов дает много преимуществ для следующих сервисов. Поскольку ИС непротиворечива до конца, она будет очень полезна для кейсов или различных мелких вещей.

2. Изучение Netns

Чего именно добивается Netns

Давайте кратко поговорим о фундаменте ядра, который может быть реализован в сетевом пространстве имен. В узком смысле контейнерная технология runC не зависит ни от какого оборудования.Основа ее выполнения находится в ее ядре.Ядро процесса представляет собой задачу.Если ему не нужна изоляция, он использует пространство хоста (пространство имен), а не Структура данных изоляции пространства (прокси-сервер nsproxy-namespace), требующая специальной настройки.

Наоборот, если независимый сетевой прокси или монтированный прокси, он должен быть заполнен реальными приватными данными. Структура данных, которую он может видеть, показана на рисунке выше.

С сенсорной точки зрения изолированное киберпространство будет иметь свою собственную сетевую карту или сетевое устройство. Сетевая карта может быть виртуальной или физической, и у нее будет свой собственный IP-адрес, таблица IP-адресов и таблица маршрутизации, а также собственное состояние стека протоколов. В частности, это относится к стеку протоколов TCP/IP, который будет иметь свой собственный статус, свои собственные iptables и ipvs.

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

Отношения между Pod и Netns

На этом рисунке можно ясно показать взаимосвязь между Netns в модулях.Каждый модуль имеет независимое сетевое пространство, и сетевой контейнер модуля будет разделять это сетевое пространство. Как правило, K8s рекомендует использовать интерфейс Loopback для связи между сетевыми контейнерами модуля, и все контейнеры предоставляют внешние службы через IP-адрес модуля. Кроме того, для Root Netns на хосте его можно рассматривать как особое сетевое пространство, за исключением того, что его Pid равен 1.

3. Введение в основные сетевые решения

Типичная реализация контейнерной сети

Ниже приводится краткое введение в типичную схему реализации контейнерной сети. Контейнерное сетевое решение может быть одним из самых перспективных направлений в K8s, и оно имеет различные реализации. Сложность контейнерной сети заключается в том, что она должна согласовываться с базовой сетью уровня Iass, а также должна выбирать гибкость производительности и распределения IP-адресов.Существуют различные решения.

Ниже приводится краткое введение в несколько основных схем: Flannel, Calico, Canal и, наконец, WeaveNet.Большинство схем в середине используют метод маршрутизации на основе политик, аналогичный Calico.

**Flannel** — это относительно большое и унифицированное решение, предоставляющее различные сетевые серверные части. Различные серверные части реализуют разные топологии, которые могут охватывать несколько сценариев;
**Calico** в основном использует маршрутизацию на основе политик, а протокол BGP используется между узлами для синхронизации маршрутов. Он характеризуется богатыми функциями, особенно хорошей поддержкой Network Point.Все мы знаем, что требования Calico к базовой сети, как правило, заключаются в том, что mac-адрес может быть подключен напрямую и не может пересекать домен второго уровня;
Конечно, некоторые студенты сообщества интегрируют преимущества фланели и бязи. Мы называем это инновационным проектом прививочного типаCilium;
Наконец поговорим оWeaveNet, если вам нужно зашифровать используемые данные, вы можете использовать WeaveNet, его динамическая схема может обеспечить лучшее шифрование.

Фланелевый раствор

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

Теперь давайте представим три основных бэкэнда:

Одним из них является udp пользовательского режима, который является самой ранней реализацией;
Затем есть Vxlan ядра, оба из которых являются схемами наложения. Производительность Vxlan будет лучше, но у него есть требования к версии ядра, а ядро должно поддерживать возможности и функции Vxlan;
Если ваш кластер недостаточно велик и находится в том же домене уровня 2, вы также можете использовать метод host-gw. Этот способ серверной части в основном запускается правилом широковещательной маршрутизации, и его производительность относительно высока.

4. Полезность сетевой политики

Основные понятия сетевой политики

Познакомимся с понятием сетевой политики.

Только что упомянул, что базовая модель сети Kubernetes требует полного взаимодействия между модулями, что принесет некоторые проблемы: в кластере K8s некоторые цепочки вызовов могут не вызываться напрямую. Например, между двумя отделами, то я надеюсь, что отдел А не будет пользоваться услугами отдела Б, и в это время можно использовать концепцию стратегии.

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

Прежде чем использовать Network Policy, как показано на рисунке выше, следует отметить, что apiserver должен включить эти переключатели. Еще одна важная вещь заключается в том, что выбранный нами сетевой плагин должен поддерживать реализацию сетевой политики. Каждый должен знать, что Сетевая политика — это только объект, предоставляемый K8s, и нет встроенного компонента для реализации.Это зависит от поддержки и полноты выбранного вами контейнерного сетевого решения.Если вы выберете Flannel или ему подобное, это на самом деле не реализует Политику, так что если вы попробуете, это будет бесполезно.

Экземпляр конфигурации

Далее поговорим о примере настройки, или что делать при проектировании сетевой политики? Лично я считаю, что необходимо решить три вещи:

Во-первых, это объект управления, например, спецификация этого экземпляра. В спецификации с помощью podSelector или селектора пространства имен вы можете сделать так, чтобы определенная группа модулей приняла наш контроль;
Во-вторых, необходимо четко учитывать направление потока.Нужно контролировать входящее или исходящее направление? Или вам нужно контролировать оба направления?
Самая важная часть — это третья часть.Если вы хотите добавить объект управления в выбранное направление для описания его потока, какие потоки можно вводить или выпускать? По аналогии с пятью функциями потока вы можете использовать некоторые селекторы, чтобы решить, какие из них могут использоваться в качестве моих удаленных концов, что является выбором объектов; вы также можете использовать механизм IPBlock, чтобы получить, какие IP-адреса могут быть освобождены; последний Какие протоколы или какие порты. По сути, комбинация характеристик потока представляет собой пятерку, которая позволит выбрать конкретный приемлемый поток.

Резюме этой статьи

На этом содержание данной статьи заканчивается, давайте кратко подытожим:

В контейнерной сети модулей основной концепцией является IP, который является адресной основой для внешней связи каждого модуля, которая должна быть согласованной внутри и снаружи, в соответствии с характеристиками модели K8s;
При внедрении сетевого решения наиболее важным фактором, влияющим на производительность контейнерной сети, является топология. Чтобы иметь возможность понять, как ваши пакеты соединены end-to-end, как добраться до хоста из контейнера и нужно ли инкапсулировать или декапсулировать хост после выхода из контейнера? Или через политику маршрутизации? Как вы, наконец, добрались до противоположного конца?
Выбор контейнерной сети и выбор дизайна. Если вы не знаете свою внешнюю сеть или вам нужно самое универсальное решение, предполагая, что вы не знаете, подключен ли mac напрямую, и можете ли вы управлять таблицей маршрутизации внешнего маршрутизатора, то вы можете выбрать Flannel использовать Vxlan в качестве серверной части этой схемы. Если вы уверены, что ваша сеть напрямую подключается на уровне 2, вы можете выбрать Calico или Flannel-Hostgw в качестве серверной части;
Наконец, для сетевой политики это очень мощный инструмент в работе, обслуживании и использовании, который может обеспечить точный контроль входящих и исходящих потоков. Мы также представили метод реализации, чтобы выяснить, кого вы хотите контролировать, а затем как определить свой поток.

5. Время на обдумывание

Наконец, оставьте некоторые мысли, вы можете подумать об этом:

Почему интерфейс CNI стандартизирован, а у контейнерной сети не очень стандартная реализация, которая встроена в K8s?
Почему Network Policy не имеет стандартного контроллера или стандартной реализации, а предоставляется владельцем контейнерной сети?
Можно ли реализовать контейнерную сеть вообще без использования сетевого оборудования? Учитывая, что сейчас есть такие схемы, как RDMA, отличные от TCP/IP.
В процессе эксплуатации и обслуживания возникает много сетевых проблем, и их трудно устранить, поэтому не стоит делать инструмент с открытым исходным кодом, чтобы его можно было удобно отображать из контейнера на хост, хост на хост или инкапсуляцию. и декапсуляция.Во время, есть ли проблема с сетевой ситуацией на каждом этапе, ее можно быстро локализовать. Насколько я знаю, такого инструмента сейчас быть не должно.

Вышеизложенное является моим введением в основные концепции контейнерной сети K8s и сетевой политики.

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