08.08.2024 16:38
kirillkosolapov 2 3100 Источник

Сеть Kubernetes — это сложная и увлекательная тема, наполненная множеством подвижных частей. Одним из ключевых компонентов, обеспечивающих сетевую связность и взаимодействие различных элементов кластера, является CNI (Container Networking Interface).

CNI или Container Network Interface - это спецификация, разработанная CNCF (Cloud Native Computing Foundation) для стандартизации процесса подключения сетевых интерфейсов к контейнерам. CNI обеспечивает гибкость и адаптивность сетевой инфраструктуры, позволяя интегрировать различные сетевые решения в Kubernetes.

Давайте подробнее разберем, что такое Container Network Interface?

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

CNI применяется для настройки оверлейных и андерлейных сетей:

  • Оверлейными сетями, называют сетевой трафик, который инкапсулируется с помощью виртуального интерфейса, такого как виртуальная расширяемая локальная сеть VXLAN.

  • Андерлейные сети работают на физическом уровне, состоят из коммутаторов и маршрутизаторов.

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

CNI применяется с Kubernetes и другими платформами контейнерной оркестрации на основе Kubernetes, такими как OpenShift. Взаимодействие контейнеров во всех кластерах унифицируется здесь с помощью технологии программно-определяемых сетей.

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

Сетевая архитектура в Kubernetes основана на спецификации плагина CNI  —  единого интерфейса среды запуска Kubernetes и базовой сети с поддержкой различных сетевых решений.

Работа сети Kubernetes

Когда создается под Kubernetes, плагином CNI настраивается сетевой интерфейс с присвоением поду IP-адреса. Этим облегчается взаимодействие внутри сети подов Kubernetes  —  плоской сети, доступной всем подам кластера. Кроме того, поды взаимодействуют с внешними приложениями через виртуальную сеть Service Kubernetes с предоставлением подов внешним сущностям.

Преимущества сети Kubernetes:

  • Переносимость: кластеры Kubernetes разворачиваются в различных облачных и необлачных средах.

  • Масштабируемость: с поддержкой большого количества подов в кластере Kubernetes.

  • Надежность: в кластере Kubernetes обеспечивается стабильное подключение подов.

Linux-контейнер и технология контейнерных сетей неуклонно развиваются, чтобы соответствовать задачам запускаемых в различных средах приложений. CNI  —  это инициатива Cloud-Native Computing Foundation, которым определяется конфигурация сетевых интерфейсов контейнеров Linux.

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

CNI  —  неродной для Kubernetes фреймворк. Для взаимодействия с различными средами запуска контейнеров разработчики, которыми применяется стандарт CNI, создают сетевые плагины. В сетях CNI используется инкапсулированная сетевая модель, такая как виртуальная расширяемая локальная сеть VXLAN, или неинкапсулированная  —  называемая также декапсулированной  —  сетевая модель, такая как протокол граничного шлюза BGP.

Работа CNI

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

Кроме того, для выделения IP-адресов контейнерам плагин CNI взаимодействует с плагином службы управления IP-адресами IPAM. Сюда относится при необходимости управление пулом доступных IP-адресов и их присвоение. Как только сетевой интерфейс установлен, контейнер с помощью kubelet запускается и может взаимодействовать с другими контейнерами в сети Kubernetes.

CNI фокусируется на связности сети контейнеров и удалении выделенных ресурсов после завершения работы контейнеров. Таким фокусом спецификации CNI упрощаются, их применяемость увеличивается.

Подробнее о спецификациях CNI, сторонних плагинах и средах запуска  —  в проекте на GitHub.

Выбор подходящего CNI плагина критически важен для обеспечения стабильной и эффективной работы кластера Kubernetes. Он влияет на производительность, безопасность, масштабируемость и удобство управления сетевой инфраструктурой. В этой статье мы рассмотрим архитектурные концепции CNI, проведем анализ популярных решений, таких как Calico, Flannel, Weave и Cilium, их архитектурные особенности, преимущества и недостатки, а также предоставим практические примеры установки и настройки этих плагинов.

Архитектурные Концепции CNI

CNI плагины разработаны по принципу модульности и расширяемости, обеспечивая стандартизированный способ подключения сетевых интерфейсов к контейнерам в Kubernetes. Они выполняют: выделение IP-адресов, настройку маршрутизации, применение сетевых политик и управление жизненным циклом сетевых интерфейсов.

Рассмотрим эти компоненты более подробно.

Основные Функции CNI

  1. Выделение IP-адресов:

    • CNI плагины выделяют IP-адреса для каждого контейнера. Это важный шаг, который обеспечивает уникальность IP-адресов внутри кластера и позволяет контейнерам общаться как друг с другом, и с внешними системами. Рассмотрим методы выделения IP-адресов более подробно.

    Методы:

    1. DHCP:

      • Сценарий: Использование DHCP сервера для динамического назначения IP-адресов.

      • Как это работает:

        • При запуске контейнера CNI плагин отправляет запрос на DHCP сервер с просьбой назначить IP-адрес для контейнера.

        • DHCP сервер выделяет IP-адрес из доступного пула и отправляет его обратно плагину.

        • Плагин применяет полученные настройки (IP-адрес, маска подсети, шлюз, DNS) к сетевому интерфейсу контейнера.

      • Преимущества:

        • Динамическое управление IP-адресами.

        • Поддержка существующих DHCP инфраструктур.

      • Недостатки:

        • Зависимость от внешнего DHCP сервера.

        • Потенциальные задержки при назначении IP-адресов.

      Пример использования, когда при запуске контейнера, CNI плагин обращается к DHCP серверу для получения IP-адрес.

{
  "cniVersion": "0.3.1",
  "name": "dhcp-network",
  "type": "dhcp"
}

  1. Статические диапазоны IP-адресов:

    • Сценарий: Администратор задает фиксированные диапазоны IP-адресов, из которых плагины выделяют IP для контейнеров.

    • Как это работает:

      • Администратор конфигурирует диапазон IP-адресов в конфигурационных файлах CNI плагина.

      • При запуске контейнера плагин выделяет следующий доступный IP-адрес из заданного диапазона.

      • Плагин обновляет информацию о выделенных IP-адресах для предотвращения конфликтов.

    • Преимущества:

      • Простота настройки и управления.

      • Отсутствие зависимости от внешних сервисов.

    • Недостатки:

      • Ограниченная гибкость в управлении IP-адресами.

      • Возможные конфликты при неправильной настройке диапазонов.

    Примеры использования, когда плагин выделяет IP-адреса из диапазона 10.22.0.0/16.

    Пример YAML-файла

{
  "cniVersion": "0.3.1",
  "name": "static-range-network",
  "type": "bridge",
  "bridge": "cni0",
  "isGateway": true,
  "ipMasq": true,
  "ipam": {
      "type": "host-local",
      "subnet": "10.22.0.0/16",
      "routes": [
          { "dst": "0.0.0.0/0" }
      ]
  }
}

  1. IPAM (IP Address Management) модули:

    • Сценарий: Специализированные модули, которые управляют выделением IP-адресов с учетом политик и конфигураций сети.

    • Как это работает:

      • IPAM модули могут быть встроенными или внешними и обеспечивают централизованное управление IP-адресами.

      • При запуске контейнера плагин отправляет запрос к IPAM модулю с просьбой выделить IP-адрес.

      • IPAM модуль применяет заданные политики и конфигурации для выбора подходящего IP-адреса и возвращает его плагину.

      • Плагин применяет полученные настройки к сетевому интерфейсу контейнера.

    • Преимущества:

      • Централизованное управление IP-адресами.

      • Гибкость в применении политик и конфигураций.

      • Масштабируемость для крупных кластеров.

    • Недостатки:

      • Сложность настройки и управления.

      • Возможные задержки при взаимодействии с внешними IPAM сервисами.

    Пример использования Calico IPAM для управления IP-адресами.

{
  "cniVersion": "0.3.1",
  "name": "ipam-network",
  "type": "bridge",
  "bridge": "cni0",
  "isGateway": true,
  "ipMasq": true,
  "ipam": {
      "type": "calico-ipam",
      "assign_ipv4": "true",
      "assign_ipv6": "false"
  }
}

Настройка маршрутизации

Описание

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

Примеры маршрутизации

  1. Подсеть узла (Node Subnet)

    • Сценарий: Настройка маршрутов для трафика между подами внутри одного узла.

    • Как это работает:

      • Подсеть узла — это диапазон IP-адресов, выделенный для всех подов, работающих на одном физическом или виртуальном узле.

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

      • Обычно это достигается через создание мостов или использование виртуальных Ethernet интерфейсов (veth).

    • Пример:

      • Допустим, узел имеет подсеть 10.1.0.0/24. Когда контейнер запускается, ему присваивается IP-адрес, например, 10.1.0.5.

      • CNI плагин настраивает маршрут на узле, чтобы весь трафик для 10.1.0.0/24 направлялся через виртуальный сетевой интерфейс, связывающий все поды на этом узле.

ip route add 10.1.0.0/24 dev cni0

  1. Межузловая маршрутизация (Inter-Node Routing)

    • Сценарий: Настройка туннелей или прямой маршрутизации для обмена трафиком между подами на разных узлах.

    • Как это работает:

      • Для маршрутизации трафика между узлами, CNI плагины могут использовать разные подходы, включая IP-туннели (например, VXLAN, GRE) или прямую маршрутизацию через физическую сеть.

      • Это позволяет подам на одном узле связываться с подами на других узлах так, как если бы они находились в одной локальной сети.

    • Пример:

      • Узел A имеет подсеть 10.1.0.0/24, а узел B — подсеть 10.2.0.0/24. Под на узле A с IP 10.1.0.5хочет связаться с подом на узле B с IP 10.2.0.6.

      • Плагин настраивает маршруты, чтобы трафик для 10.2.0.0/24 отправлялся через IP-адрес узла B, например, 192.168.1.2.

ip route add 10.2.0.0/24 via 192.168.1.2

В случае использования VXLAN, на каждом узле создается виртуальный туннель для инкапсуляции и передачи трафика между узлами.

ip link add vxlan0 type vxlan id 42 dev eth0 dstport 4789
ip addr add 10.1.0.1/24 dev vxlan0
ip link set vxlan0 up

Типы межузловых туннелей

  1. VXLAN (Virtual Extensible LAN):

    • Описание: Технология инкапсуляции уровня 2 для создания виртуальных сетей поверх существующих IP-сетей.

    • Преимущества:

      • Хорошо подходит для больших и динамичных сетей.

      • Поддерживает изоляцию сетевого трафика.

    • Недостатки:

      • Некоторое увеличение нагрузки из-за инкапсуляции.

      • Требует поддержки на уровне сетевого оборудования или программного обеспечения.

  2. GRE (Generic Routing Encapsulation):

    • Описание: Простой туннельный протокол для инкапсуляции широкого диапазона протоколов в виртуальные точка-точка соединения.

    • Преимущества:

      • Простота настройки и поддержки.

      • Низкая накладная стоимость инкапсуляции.

    • Недостатки:

      • Ограниченная поддержка некоторых функций безопасности.

  3. IPsec (Internet Protocol Security):

    • Описание: Набор протоколов для обеспечения защищенной передачи данных на уровне IP.

    • Преимущества:

      • Высокий уровень безопасности благодаря шифрованию и аутентификации.

      • Поддержка в большинстве современных операционных систем и сетевых устройств.

    • Недостатки:

      • Более высокая нагрузка на процессор из-за шифрования.

      • Сложность настройки и управления.

Управление жизненным циклом сетевых интерфейсов

Плагины CNI управляют созданием и удалением сетевых интерфейсов в контейнерах, что позволяет динамически изменять сетевые настройки при запуске и остановке контейнеров. Это важный аспект, обеспечивающий гибкость и адаптивность сетевой инфраструктуры в Kubernetes. Управление жизненным циклом сетевых интерфейсов включает создание, настройку и удаление сетевых интерфейсов, что позволяет эффективно использовать сетевые ресурсы и поддерживать стабильность работы кластера.

Функции управления жизненным циклом

  1. Создание интерфейсов

    • Сценарий: Настройка сетевых интерфейсов при запуске контейнеров.

    • Как это работает:

      • Когда контейнер запускается, CNI плагин вызывается с командой ADD.

      • Плагин создает виртуальный сетевой интерфейс (например, veth-пара) на узле и подключает его к контейнеру.

      • Настраиваются IP-адреса, маска подсети, маршруты и другие сетевые параметры.

      • Плагин обновляет сетевые таблицы и правила для обеспечения корректной маршрутизации и применения сетевых политик.

    • Пример:

      • Контейнер с идентификатором container123 запускается. Плагин создает пару veth-интерфейсов: один интерфейс подключается к контейнеру, другой — к сетевому мосту на узле.

ip link add veth123 type veth peer name veth-host123
ip link set veth123 netns container123
ip addr add 10.1.0.5/24 dev veth123
ip link set veth123 up
ip link set veth-host123 up

После настройки интерфейса, контейнер container123 получает IP-адрес 10.1.0.5 и может взаимодействовать с другими подами.

  1. Удаление интерфейсов

    • Сценарий: Очистка конфигураций и освобождение ресурсов при завершении работы контейнеров.

    • Как это работает:

      • Когда контейнер завершает работу, CNI плагин вызывается с командой DEL.

      • Плагин удаляет виртуальные сетевые интерфейсы, связанные с контейнером.

      • Освобождаются IP-адреса и другие сетевые ресурсы, связанные с контейнером.

      • Плагин обновляет сетевые таблицы и правила для удаления маршрутов и освобождения ресурсов.

    • Пример:

      • Контейнер container123 завершает работу. Плагин удаляет соответствующие интерфейсы и освобождает IP-адрес 10.1.0.5.

      ip link delete veth-host123
ip netns exec container123 ip link delete veth123

      • Плагин обновляет сетевые маршруты и правила, чтобы исключить IP-адрес 10.1.0.5 из сети.

Примеры управления жизненным циклом

Создание интерфейсов

При запуске контейнера CNI плагин вызывается с командой ADD. Ниже приведен пример JSON-запроса, передаваемого плагину

{
  "cniVersion": "0.3.1",
  "containerId": "container123",
  "netns": "/var/run/netns/container123",
  "ifName": "eth0",
  "args": {
    "K8S_POD_NAMESPACE": "default",
    "K8S_POD_NAME": "my-pod"
  },
  "ipam": {
    "type": "host-local",
    "subnet": "10.1.0.0/16",
    "routes": [
      { "dst": "0.0.0.0/0" }
    ]
  }

В ответ плагин возвращает информацию о созданном интерфейсе и присвоенном IP-адресе:

{
  "cniVersion": "0.3.1",
  "interfaces": [
    {
      "name": "eth0",
      "mac": "c2:00:54:12:32:1c",
      "sandbox": "/var/run/netns/container123"
    }
  ],
  "ips": [
    {
      "version": "4",
      "address": "10.1.0.5/24",
      "gateway": "10.1.0.1"
    }
  ],
  "routes": [
    { "dst": "0.0.0.0/0" }
  ]

Удаление интерфейсов

При завершении работы контейнера CNI плагин вызывается с командой DEL. Пример JSON-запроса:

{
  "cniVersion": "0.3.1",
  "containerId": "container123",
  "netns": "/var/run/netns/container123",
  "ifName": "eth0",
  "args": {
    "K8S_POD_NAMESPACE": "default",
    "K8S_POD_NAME": "my-pod"
  }
}

Плагин выполняет необходимые действия по удалению сетевого интерфейса и освобождению ресурсов.

Теперь поговорим о нашумевшем Cilium. Что это такое и с чем его едят ?

CNI с Cilium

Cilium — проект с открытым исходным кодом для сетевого взаимодействия, безопасности и наблюдаемости кластеров Kubernetes и других контейнеризированных сред. Он основан на технологии eBPF, внедряющей логику сетевого управления, контроля безопасности и функционала наблюдаемости прямо в ядро Linux.

Преимущества Cilium

Cilium является сетевым плагином для Kubernetes, предоставляющим повышенную безопасность и сетевые возможности контейнерных приложений. Используя программируемую технологию уровня ядра eBPF (extended Berkeley Packet Filter), Cilium обеспечивает сквозную сетевую безопасность и мониторинг трафика.

Основные функции и возможности Cilium:

  • Оверлейная сеть с VXLAN: Использование VXLAN для формирования оверлейной сети позволяет Cilium эффективно инкапсулировать и маршрутизировать трафик.

  • Неинкапсулированная маршрутизация с BGP: Cilium поддерживает BGP для управления сетевой связностью и маршрутизацией без инкапсуляции. В версии Cilium 1.3 появилась собственная реализация BGP на базе GoBGP, ранее для этого использовался metallb.

  • Поддержка IPv4 и IPv6: Cilium обеспечивает адресацию как по IPv4, так и по IPv6.

  • Поддержка нескольких кластеров Kubernetes: Cilium может работать в мультикластерных средах.

  • Множественные CNI, как в Multus: Cilium позволяет использовать несколько CNI плагинов одновременно.

Сетевые политики Cilium

Cilium предоставляет возможность реализации сетевых политик на различных уровнях, включая уникальные возможности для политики седьмого уровня (L7). Это позволяет применять фильтры HTTP-запросов, контролировать DNS, HTTP и даже Kafka-трафик. Политики записываются в файлы YAML или JSON, которые используются для контроля входящего и исходящего сетевого трафика.

Примеры сетевых политик

Cilium позволяет создавать детализированные сетевые политики для контроля трафика. Рассмотрим несколько примеров:

  1. Ограничение DNS-разрешения подмножеством

Эта политика ограничивает DNS-запросы только определенным подмножествам:

apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: dns-policy
spec:
  endpointSelector:
    matchLabels:
      app: my-app
  egress:
  - toEndpoints:
    - matchLabels:
        k8s:io.kubernetes.pod.namespace: kube-system
        k8s-app: kube-dns
    toPorts:
    - ports:
      - port: '53'
        protocol: UDP
      rules:
        dns:
        - matchPattern: '*.example.com'

  1. Разрешение HTTP-запросов методом POST на abc.xyz

Эта политика разрешает HTTP-запросы методом POST на домен abc.xyz:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: http-post-abc-xyz
spec:
  endpointSelector: {}
  egress:
  - toPorts:
    - ports:
      - port: '443'
        protocol: TCP
      rules:
        http:
        - method: POST
          toFQDNs:
          - matchPattern: '*.abc.xyz'

  1. Ограничение доступа к теме Kafka по меткам

Эта политика ограничивает доступ к отдельным темам Kafka в зависимости от меток:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: beer-brewers
spec:
  ingress:
  - fromEndpoints:
    - matchLabels:
        role: beer-brewer
    toPorts:
    - ports:
      - port: 9092
        protocol: TCP
      rules:
        kafka:
        - role: producer
          topic: hops

Установка Cilium

Cilium устанавливается в виде чарта Helm. Рассмотрим основные шаги для установки:

  1. Добавьте репозиторий Helm:

helm repo add cilium https://helm.cilium.io/

  1. Настройте значения по умолчанию для установки:

helm upgrade --install cilium/cilium cilium \
--version 1.13.4 \
--namespace kube-system \
--set image.repository=quay.io/cilium/cilium \
--set global.ipam.mode=cluster-pool \
--set global.ipam.operator.clusterPoolIPv4PodCIDR=192.168.0.0/16 \
--set global.ipam.operator.clusterPoolIPv4MaskSize=23 \
--set global.nativeRoutingCIDR=192.168.0.0/16 \
--set global.endpointRoutes.enabled=true \
--set global.hubble.relay.enabled=true \
--set global.hubble.enabled=true \
--set global.hubble.listenAddress=":4244" \
--set global.hubble.ui.enabled=true \
--set kubeProxyReplacement=probe \
--set k8sServiceHost=${PUBLIC_IPv4} \
--set k8sServicePort=6443

Cilium быстро стал стандартом для сетей Kubernetes благодаря внедрению eBPF и XDP, предоставлению расширенных возможностей сетевых политик и мониторинга через Hubble, а также гибкости и скорости разработки. Хотя Calico также является отличным вариантом, Cilium выделяется своими уникальными возможностями и перспективами для сетевого взаимодействия в Kubernetes.

Заключение

В данной статье мы рассмотрели важность сетевого взаимодействия в Kubernetes и роль CNI (Container Network Interface) плагинов в обеспечении сетевой связности и безопасности контейнерных приложений. Мы выделили ключевые функции CNI, включая управление жизненным циклом сетевых интерфейсов, применение сетевых политик и настройку маршрутизации.

Особое внимание было уделено Cilium, инновационному CNI-плагину, использующему технологию eBPF для высокоэффективного выполнения сетевых функций. Cilium обеспечивает не только стандартные возможности сетевого взаимодействия, но и расширенные функции безопасности и наблюдаемости, включая поддержку сетевых политик седьмого уровня (L7).

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

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

Автор: Алексей Пономарев

Если у вас несколько микросервисов и вы не хотите тратить время на настройку Kubernetes, попробуйте наше облако - Amvera Cloud. Amvera - это альтернатива managed Kubernetes. У нас вы сможете обновлять ваши сервисы через простые коммиты в Git и получите почти все преимущества Kubernetes, не задумываясь об администрировании, настройки CI/CD, мониторинга, алертинга и сопутствующих сервисов. Это дешевле, чем классический managed k8s. Kubernetes у нас внутри, но вы полностью абстрагированы от его администрирования, достаточно просто привязать к сервису ваш Git-репозиторий и обновлять приложения командой “git push amvera master”.

А если у вас сложный проект и вам нужна помощь в построении инфраструктуры на основе Kubernetes, или просто консультация, пишите мне в телеграм (Кирилл Косолапов), либо оставьте контакт для связи на странице нашей DevOps-команды.

Комментарии (2)


  1. polRk
    10.08.2024 12:29
    #27149138

    Вообще ничего полезного в статье нет. как что сделать, как настроить, нет объяснения фундаментала, нет объяснения выбора цилиум и его настройки... такое чувство, что текст создан chatgpt


  1. JuriM
    10.08.2024 12:29
    #27150466
    +1

    1. Сетевые плагины (CNI) в Kubernetes

    2. Реклама Cilium