Привет, Хаброжители! Мы недавно издали книгу по Kubernetes версии 1.10. В посте рассмотрен отрывок «Сетевые решения для Kubernetes»Организация сети — обширная тема. Существует множество способов настроить сеть с подключением устройств, подов и контейнеров. Kubernetes вас в этом не ограничивает. Все, что предписывает данная платформа, — это высокоуровневая сетевая модель с плоским адресным пространством для подов. В рамках этого пространства можно реализовать множество хороших решений с разными возможностями и для разного окружения. В этом разделе рассмотрим некоторые из них и попытаемся понять, каким образом они укладываются в сетевую модель Kubernetes.
Создание мостов в аппаратных кластерах
Самым простым окружением является кластер на «голом железе», который представляет собой обычную физическую сеть уровня L2. Для подключения контейнеров к такой сети можно использовать стандартный для Linux мост. Это довольно кропотливая процедура, требующая опыта работы с низкоуровневыми сетевыми командами Linux, такими как brctl, ip addr, ip route, ip link, nsenter и т. д. Реализацию такого решения можно начать со знакомства со следующим руководством: blog.oddbit.com/
2014/08/11/four-ways-to-connect-a-docker/ (ищите раздел With Linux Bridge devices).
Contiv
Contiv — это сетевое дополнение общего назначения. Оно предназначено для подключения контейнеров через CNI и может использоваться вместе с Docker (напрямую), Mesos, Docker Swarm и, естественно, Kubernetes. Contiv занимается сетевыми политиками и частично дублирует аналогичный объект в Kubernetes. Далее перечислены некоторые из возможностей этого сетевого дополнения:
- поддержка CNM в libnetwork и спецификации CNI;
- механизм политик с богатыми возможностями, обеспечивающий безопасность и предсказуемое развертывание приложений;
- лучшая в своем роде производительность контейнеров;
- мультиарендность, изоляция и пересекающиеся подсети;
- интеграция с IPAM и обнаружение сервисов;
- широкий выбор физических топологий:
а) протоколы уровня 2 (VLAN);
б) протоколы уровня 3 (BGP);
в) оверлейные сети;
г) Cisco SDN (ACI); - поддержка IPv6;
- масштабируемая политика и распределение маршрутов;
- интеграция с шаблонами приложений, включая следующие:
а)Docker-compose;
б)диспетчер развертывания Kubernetes;
в)распределение нагрузки на сервисы, встроенное в балансировщик микросервисов типа «восток — запад» (east — west);
г)изоляция трафика во время хранения, контроля доступа (например, etcd/consul), передачи по сети и управления.
Contiv имеет множество возможностей. Этот инструмент реализует широкий спектр задач и поддерживает различные платформы, поэтому я не уверен, станет ли он лучшим выбором для Kubernetes.
Open vSwitch
Open vSwitch — это зрелое решение для создания виртуальных (программных) коммутаторов, поддерживаемое многими крупными игроками на рынке. Система Open Virtualization Network (OVN) позволяет выстраивать различные виртуальные сетевые топологии. У нее есть специальное дополнение для Kubernetes, но его очень непросто настроить (см. руководство github.com/openvswitch/ovn-kubernetes). У дополнения Linen CNI меньше возможностей, но его конфигурация проходит намного легче: github.com/John-Lin/linen-cni. Структура Linen CNI показана на рис. 10.6.
Open vSwitch может объединять физические серверы, ВМ и поды/контейнеры в единую логическую сеть. Эта система поддерживает как оверлейный, так и физический режим.
Вот некоторые из ее ключевых возможностей:
- стандартная модель 802.1Q VLAN с магистральными и общедоступными портами;
- привязка по NIC с LACP или без него для коммутатора более высокого уровня;
- NetFlow, sFlow® и зеркалирование для обеспечения улучшенной видимости;
- конфигурация QoS (Quality of Service — качество обслуживания) плюс политики;
- туннелирование через Geneve, GRE, VXLAN, STT и LISP;
- контроль за разрывами соединения в 802.1ag;
- OpenFlow 1.0 плюс многочисленные дополнения;
- транзакционная база данных для хранения конфигурации с привязками для C и Python;
- высокопроизводительное перенаправление с помощью модулей ядра Linux.
Nuage Networks VCS
Virtualized Cloud Services (VCS) — это продукт от компании Nuage, который представляет собой хорошо масштабируемую, основанную на политиках платформу для построения программно-определяемых сетей (Software-Defined Networking, SDN). Это решение уровня предприятия, в основе которого лежат открытая система Open vSwitch (для перенаправления данных) и многофункциональный SDN-контроллер, построенный на открытых стандартах.
Платформа Nuage объединяет поды Kubernetes и сторонние окружения (виртуальные и аппаратные) в прозрачные оверлейные сети и позволяет описывать подробные политики для разных приложений. Ее механизм анализа в реальном времени дает возможность отслеживать видимость и безопасность приложений Kubernetes.
Кроме того, все компоненты VCS можно установить в виде контейнеров. Каких-либо специфических аппаратных требований нет.
Canal
Canal — это смесь двух проектов с открытым исходным кодом: Calico и Flannel. Отсюда и название. Проект Flannel, разрабатываемый командой CoreOS, занимается сетевыми возможностями контейнеров, а Calico отвечает за сетевые политики. Изначально они разрабатывались отдельно друг от друга, но пользователи хотели применять их совместно. Сейчас открытый проект Canal представляет собой шаблон развертывания для установки Calico и Flannel в виде отдельных CNI-дополнений. Компания Tigera, созданная основателями Calico, занимается поддержкой обоих проектов и даже планировала более тесную интеграцию, но с момента выпуска собственного решения для безопасной организации сети между приложениями в Kubernetes приоритет сместился в сторону облегчения конфигурации и интеграции Flannel и Calico вместо разработки объединенного решения. На рис. 10.7 демонстрируется текущее состояние системы Canal и то, как она соотносится с платформами оркестрации, такими как Kubernetes и Mesos.
Заметьте, что при интеграции с Kubernetes Canal обращается не напрямую к etcd, а к API-серверу Kubernetes.
Flannel
Flannel — это виртуальная сеть, которая выделяет каждому узлу по виртуальной сети для работы со средами выполнения контейнеров. На каждом узле запускается агент flaneld, поднимающий подсеть на основе зарезервированного адресного пространства, хранящегося в кластере etcd. Обмен пакетами между контейнерами и, по большому счету, узлом производится одним из нескольких серверов. Чаще всего на сервере используется UDP поверх TUN-устройства, которое по умолчанию туннелирует трафик через порт 8285 (не забудьте открыть его в своем брандмауэре).
На рис. 10.8 подробно описываются различные компоненты сети Flannel, создаваемые ею виртуальные сетевые устройства и то, как они общаются с узлом и подом через мост docker0. Здесь также можно видеть процесс инкапсуляции UDP-пакетов и их перемещение между узлами.
Поддерживаются и другие сетевые технологии:
- vxlan — инкапсулирует пакеты с помощью VXLAN внутри ядра;
- host-gw — создает IP-маршруты к подсетям через IP-адреса удаленного сервера. Стоит отметить, что это требует прямого соединения на втором сетевом уровне между серверами, выполняющими Flannel;
- aws-vpc — создает IP-маршруты в таблице маршрутизации Amazon VPC;
- gce — создает IP-маршруты в сети Google Compute Engine;
- alloc — выполняет лишь выделение подсети, но не перенаправление пакетов;
- ali-vpc — создает IP-маршруты в таблице маршрутизации Alicloud VPC.
Проект Calico
Calico — это комплексное решение для организации сети между контейнерами и обеспечения сетевой безопасности. Его можно интегрировать со всеми основными платформами оркестрации и средами выполнения:
- Kubernetes (дополнение для CNI);
- Mesos (дополнение для CNI);
- Docker (дополнение для libnework);
- OpenStack (дополнение для Neutron).
Calico можно развертывать также локально или в публичном облаке с сохранением всех возможностей. Применение сетевых политик может зависеть от нагрузки, что обеспечивает четкий контроль трафика и гарантирует, что пакеты всегда будут доходить до нужных адресатов. Calico умеет автоматически импортировать сетевые политики с платформ оркестрации. На самом деле он отвечает за реализацию сетевых политик в Kubernetes.
Romana
Romana — это современное решение для организации сети между контейнерами. Оно изначально рассчитано на использование в облаке и работает на третьем сетевом уровне, опираясь на стандартные методы управления IP-адресами. Romana позволяет изолировать целые сети, создавая для них шлюзы и маршруты с помощью серверов на базе Linux. Работа на третьем сетевом уровне не требует инкапсуляции. Сетевая политика применяется ко всем конечным точкам и сервисам в виде распределенного брандмауэра. Romana облегчает локальное и гибридное развертывание между разными облачными платформами, так как больше не нужно настраивать виртуальные оверлейные сети.
Недавно появившиеся в Romana виртуальные IP-адреса позволяют локальным пользователям открывать доступ к своим сервисам в локальных сетях второго уровня, используя внешние адреса и спецификации сервисов.
Разработчики Romana утверждают, что их подход значительно улучшает производительность. На рис. 10.9 видно, как вместе с отказом от инкапсуляции VXLAN можно избавиться от множества накладных расходов.
Weave Net
Основными чертами проекта Weave Net являются простота в применении и отсутствие конфигурации. Он использует инкапсуляцию VXLAN и устанавливает микро-DNS на каждый узел. Как разработчик, вы будете иметь дело с высоким уровнем абстракции. После того как вы дадите имена своим контейнерам, Weave Net позволит вам подключаться к стандартным портам и задействовать соответствующие сервисы. Это помогает при миграции существующих приложений на платформы микросервисов и контейнеризации. В Weave Net предусмотрено CNI-дополнение для работы с Kubernetes и Mesos. Начиная с Kubernetes 1.4, интеграцию с Weave Net можно выполнить одной командой, которая развертывает DaemonSet:
kubectl apply -f https://git.io/weave-kubeПоды Weave Net, размещенные на каждом узле, отвечают за подключение любых других экземпляров подов к сети Weave. Weave Net поддерживает API с сетевыми политиками, предоставляя полноценное и простое в настройке решение.
Эффективное использование сетевых политик
Сетевая политика Kubernetes предназначена для управления трафиком, который направлен к определенным подам и пространствам имен. При управлении сотнями развернутых микросервисов (как часто бывает с Kubernetes) организация сетевых соединений между подами выходит на первый план. Важно понимать, что этот механизм лишь опосредованно относится к безопасности. Если злоумышленник способен проникнуть во внутреннюю сеть, он, скорее всего, сможет создать собственный экземпляр пода, который будет соответствовать сетевой политике и позволит свободно общаться с другими подами. В предыдущем разделе мы рассмотрели различные решения для организации сети в Kubernetes, сосредоточившись на сетевых интерфейсах. Здесь же основное внимание уделим сетевой политике, реализуемой поверх этих решений, хотя оба компонента тесно взаимосвязаны.
Архитектура сетевой политики в Kubernetes
Сетевая политика определяет, каким образом подмножества подов могут взаимодействовать друг с другом и с другими конечными точками сети. Ресурс NetworkPolicy использует метки для выбора подов и определяет список разрешительных правил, которые позволяют направлять трафик к выбранным экземплярам подов (в дополнение к тому, что уже позволено политикой изоляции в заданном пространстве имен).
» Более подробно с книгой можно ознакомиться на сайте издательства
» Оглавление
» Отрывок
Для Хаброжителей скидка 20% по купону — Kubernetes
По факту оплаты бумажной версии книги на e-mail высылается электронная версия книги.
P.S.: 7% от стоимости книги пойдет на перевод новых компьютерных книг, список сданных в типографию книг здесь.
