@ Семь Во Страниц

Обучение никогда не заканчивается, рекорды всегда сопровождают вас! —— Люли Канкан

зачем писатьLinux | Давайте поговорим о стратегиях маршрутизации в системах LinuxА что насчет этой статьи?,Главным образом, чтобы подготовить почву для сегодняшней статьи.

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

Характеристики сети 5G включают сверхвысокую скорость, низкую задержку, широкие возможности подключения и большую емкость, что обеспечивает широкое пространство для разработки различных сценариев применения, таких как Интернет вещей, интеллектуальные фабрики, автономное вождение и т. д. Однако эти новые приложения предъявляют более высокие требования к надежности, гибкости и масштабируемости сети. В этом контексте появление Kubernetes стало важной технической поддержкой.

В сети связи существует очень строгий контроль трафика, который будет разделен на несколько VRF (виртуальная маршрутизация и пересылка). Трафик различных служб должен отправляться в соответствующий VRF, например, беспроводной трафик в базовую сеть и SBI между ними. Трафик базовых сетей 5G, трафик управления, который регистрируется на каждом устройстве для управления сетью, должен перемещаться под соответствующими VRF и не может быть перекрестно соединен.

Но базовая система Kubernetes — это ОС Linux. По умолчанию весь трафик исходит из основной таблицы маршрутизации, но таблица маршрутизации может нести только один маршрут по умолчанию. Если вы хотите распределять трафик по соответствующему VRF, вам нужно добавить. его в основную таблицу маршрутизации. В таблице определено множество записей маршрутизации.

Например, на рисунке ниже маршрут по умолчанию в основной таблице маршрутизации — к VRF1. Затем, когда устройство ssh взаимодействует с Linux, ответный пакет от Linux не может достичь устройства ssh при условии, что существует только маршрут по умолчанию (). при условии, что не разрешена маршрутизация между VRF):

Так что же делать? Есть два варианта: один — определить подробные маршруты в основной таблице маршрутизации, другой — определить политику маршрутизации;

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

Давайте вернемся к Kubernetes. В Kubernetes существует множество технических средств, позволяющих POD предоставлять услуги внешнему миру. Вот решение для использования MetalLB в качестве LoadBalancer, как показано на рисунке ниже, на котором указан IP-адрес. из 3.3 определен в Configmap MetalLB. Адрес 3.3 назначен Service ssh. В то же время конечной точкой Service ssh является POD ssh, POD. K8s назначает ssh внутренний адрес 192.168.1.1:

Затем давайте посмотрим на поток сообщений, когда внешний ssh-клиент хочет войти в ssh POD в K8s:

1. через SSH clientвходитьssh 3.3.3.3после,ssh Клиент отправил пакет данных, в котором исходным адресом IP-уровня пакета данных был его собственный адрес 10.10.10.10, а адресом назначения — 3.3.3.3;
2. Пакет данных достигает K8 после прохождения серии маршрутизаций.,После того, как K8s выполнит DNAT над пакетом данных,Исходный адрес пакета данных по-прежнему 10.10.10.10.,Адрес назначения DNAT становится адресом POD ssh 192.168.1.1.,Затем отправьте этот POD на ssh;
3. После получения запроса ssh POD ssh начинает формировать пакет ответных данных. Адресом источника является его собственный адрес POD, который равен 192.168.1.1, а адрес назначения — 10.10.10.10.
4. После того, как POD отправит пакет данных,,Затем K8s выполняет на нем SNAT.,В это время исходный адрес пакета данных становится адресом службы, то есть 3.3.3.3, по SNAT.,Адрес назначения: 10.10.10.10.,Тогда K8s соответствует таблице маршрутизации.,Отправьте пакет данных.

Затем давайте рассмотрим четвертый шаг. После SNAT K8s сопоставляет таблицу маршрутизации и отправляет пакет данных. Как вы можете видеть на рисунке выше, в основной таблице маршрутизации есть только один маршрут по умолчанию, но он отправляется в VRF1. ssh-бизнес завершается через VRF2, поэтому на ssh-клиенте появляются тайм-аут соединения и другие подобные ошибки, в результате чего вход в систему ssh завершается неудачей.

Есть еще два решения: одно — определить подробные маршруты в основной таблице маршрутизации; другое — использовать политику маршрутизации для добавления новой таблицы маршрутизации для vrf2, определения маршрута по умолчанию в таблице маршрутизации vrf2 и определения правил для пакетов данных. . Адрес источника — 3.3.3.3, тогда используется таблица маршрутизации vrf2.

Использование Routing Policy в Kubernetes сейчас работает только в ответ на входящий трафик. Как вы это понимаете?

Когда трафик, впервые инициированный внешним сервером, называется входящим трафиком, а POD внутри K8s пассивно отвечает на этот входящий трафик, будет использоваться маршрутизация. Policy,Потому что только при реагировании на внешний поток,Прежде чем пакет данных будет отправлен из K8sкластера, адрес источника будет преобразован в адрес LoadBalancer службы.,Поэтому оно будет соответствоватьip rule,Тогда будет использоваться соответствующая таблица маршрутизации.

А как насчет трафика, активно инициируемого внутри кластера K8s? Эта часть трафика называется исходящим трафиком. Когда POD инициирует исходящий трафик, он сначала инкапсулирует пакет данных: адрес источника — это IP-адрес POD, который равен 192.168.1.1, а адрес назначения — 10.10.10.10; затем пакет данных; отправляется на K8s, и K8s должен быть нацелен. Адрес назначения совпадает с маршрутом, а затем адрес источника 192.168.1.1. После преобразования его в eth-адрес пакет данных можно отправить на маршрутизатор, поскольку адрес POD используется только внутри кластера K8s и не может появляться во взаимодействии внешнего трафика.

Вот в чем проблема. Если Решение1 не используется для определения подробного маршрута к 10.10.10.10, оно все равно будет соответствовать значению по умолчанию в основной таблице маршрутизации, что означает, что оно будет отправлено в VRF1, и служба не будет выполнена. На данный момент маршрут должен быть определен. Настроенная нами политика маршрутизации не действительна.

А что, если политику маршрутизации можно сделать эффективной? Теоретически, прежде чем K8s прочитает таблицу маршрутизации, ему необходимо SNAT адрес источника пакета данных в адрес службы, который равен 3.3.3.3. После этого он может соответствовать пользовательской политике маршрутизации и использовать маршрут по умолчанию в маршрутизации vrf2. table, я не видел никакой официальной информации о K8s для реализации этой идеи.

Почему K8s не рассматривает этот вопрос? Поскольку K8s сам по себе является шедевром Интернета, во-первых, бизнес относительно одинок, и необходимости в разделении бизнеса не так уж и много, кроме того, кластеры K8s в Интернете в основном предоставляют услуги внешнему миру, и предприятий мало; активно инициируется внутри кластера и некоторых компаний. Для внутреннего мониторинга данных и других нужд IP-адреса внутри этих компаний относительно немногочисленны и фиксированы, и в основную таблицу маршрутизации легко добавить подробные маршруты.

Если у вас есть какие-либо идеи выше, пожалуйста, оставьте сообщение в чате!