Книга «Осваиваем Kubernetes. Оркестрация контейнерных архитектур» +11



image Привет, Хаброжители! Мы недавно издали книгу по 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.

image

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.

image

Заметьте, что при интеграции с Kubernetes Canal обращается не напрямую к etcd, а к API-серверу Kubernetes.

Flannel


Flannel — это виртуальная сеть, которая выделяет каждому узлу по виртуальной сети для работы со средами выполнения контейнеров. На каждом узле запускается агент flaneld, поднимающий подсеть на основе зарезервированного адресного пространства, хранящегося в кластере etcd. Обмен пакетами между контейнерами и, по большому счету, узлом производится одним из нескольких серверов. Чаще всего на сервере используется UDP поверх TUN-устройства, которое по умолчанию туннелирует трафик через порт 8285 (не забудьте открыть его в своем брандмауэре).

На рис. 10.8 подробно описываются различные компоненты сети Flannel, создаваемые ею виртуальные сетевые устройства и то, как они общаются с узлом и подом через мост docker0. Здесь также можно видеть процесс инкапсуляции UDP-пакетов и их перемещение между узлами.

image

Поддерживаются и другие сетевые технологии:

  • 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 можно избавиться от множества накладных расходов.

image

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% от стоимости книги пойдет на перевод новых компьютерных книг, список сданных в типографию книг здесь.

Вы можете помочь и перевести немного средств на развитие сайта

Теги:



Комментарии (8):

  1. Neyury
    /#19814146

    Мне пришла рассылка про эту книгу с купоном, но я купил её как только она вышла, зачем отправлять мне письмо о ней?

  2. DarkHost
    /#19814350

    Отличная статья. Но есть несколько замечаний:
    Странное написание статьи. В описании flannel указана подробная техническая реализация. В описании calico — лишь общие положения. В описании weave — способ развертывания. Вообще-то почти все они развертываются одной командой. Почему же это только в разделе weave указано?
    Думаю, стоило бы упомянуть, что в отличие от flannel, calico использует iptables вместо overlay.

    • vman
      /#19815444

      это ведь выдержка из перевода англоязычной книги, а не статья.

      • DarkHost
        /#19818396

        Да, я уже заметил. За такой вот перевод «реализация топологии «сетевая ткань»» надо бить.

  3. Neyury
    /#19814718

    Я купил бумажную книгу до того как появилась электронная версия, и у меня её в итоге нет (либо из-за не очень гладкого объединения аккаунтов на piter.com), могу ли я как-то получить электронную версию?

    И кстати, наткнулся на пару ошибок, связанных с форматированием книги, куда я могу написать о них?

    • cynovg
      /#19814942

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

      PS: Ха, и только после комментария увидел их предложение :)

    • ph_piter
      /#19815450

      Будьте добры в личку номер заказа, и написать примеры ошибок, если таковые есть — исправим.

  4. random1st
    /#19815956

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