Модуль cni-cilium

Модуль cni-cilium обеспечивает работу сети в кластере. Основан на проекте Cilium.

Ограничения

1. Сервисам с типом NodePort и LoadBalancer не подходят эндпоинты в LB-режиме DSR, работающие с hostNetwork. Если это необходимо, переключитесь на режим SNAT.
2. Поды hostPort связываются только с одним IP-адресом. Если в ОС есть несколько интерфейсов/IP, Cilium выберет один, предпочитая «серые» «белым».
3. Если ExternalIP узла не назначен ни одному сетевому интерфейсу узла, а предоставляется внешней инфраструктурой (например, через NAT 1:1), трафик из PodNetwork к этому адресу не проходит. Поэтому поды, не использующие hostNetwork, не смогут обратиться через ExternalIP узла к порту, опубликованному с помощью hostPort. Для такого подключения используйте InternalIP узла.
4. Для обеспечения стабильной работы cni-cilium на узлах кластера отключите Elastic Agent или ограничьте доступ этого агента к серверу управления Elastic. В состав Elastic Agent входит компонент Elastic Endpoint, который использует технологию Extended Berkeley Packet Filter (eBPF) на узлах кластера и может удалять критически важные eBPF-программы, необходимые для корректной работы cni-cilium. Детальная информация и обсуждение проблемы доступны в публикациях проектов Cilium и Elastic.
5. Требования к ядру:
   • ядро Linux версии не ниже 5.8 для работы модуля cni-cilium и его совместной работы с модулями istio, openvpn, node-local-dns.
6. Совместимость с ОС:
   • Ubuntu:
     • несовместим с версией 18.04;
     • для работы с версией 20.04 необходима установка ядра HWE.
   • Astra Linux:
     • несовместим с изданием «Смоленск».
   • CentOS:
     • для версий 7 и 8 необходимо новое ядро из репозитория.

Обработка внешнего трафика в разных режимах работы bpfLB (замена kube-proxy от Cilium)

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

В модуле возможен выбор режима работы, влияющий на поведение Service с типом NodePort и LoadBalancer:

• SNAT (Source Network Address Translation) — один из подвидов NAT, при котором для каждого исходящего пакета происходит трансляция IP-адреса источника в IP-адрес шлюза из целевой подсети, а входящие пакеты, проходящие через шлюз, транслируются обратно на основе таблицы трансляций. В этом режиме bpfLB полностью повторяет логику работы kube-proxy:
  • если в Service указан externalTrafficPolicy: Local, то трафик будет передаваться и балансироваться только в те целевые поды, которые запущены на том же узле, на который этот трафик пришел. Если целевой под не запущен на этом узле, то трафик будет отброшен.
  • если в Service указан externalTrafficPolicy: Cluster, то трафик будет передаваться и балансироваться во все целевые поды в кластере. При этом, если целевые поды находятся на других узлах, то при передаче трафика на них будет произведен SNAT (IP-адрес источника будет заменен на InternalIP узла).

  

• DSR - (Direct Server Return) — метод, при котором весь входящий трафик проходит через балансировщик нагрузки, а весь исходящий трафик обходит его. Такой метод используется вместо SNAT. Часто ответы имеют много больший размер чем запросы и DSR позволяет значительно увеличить общую пропускную способность схемы:
  • если в Service указан externalTrafficPolicy: Local, то поведение абсолютно аналогично kube-proxy и bpfLB в режиме SNAT.
  • если в Service указан externalTrafficPolicy: Cluster, то трафик так же будет передаваться и балансироваться во все целевые поды в кластере. При этом важно учитывать следующие особенности:
    • если целевые поды находятся на других узлах, то при передаче на них входящего трафика будет сохранен IP-адрес источника;
    • исходящий трафик пойдет прямо с узла, на котором был запущен целевой под;
    • IP-адрес источника будет заменен на внешний IP-адрес узла, на которую изначально пришел входящий запрос.

  

• Hybrid — в данном режиме TCP-трафик обрабатывается в режиме DSR, а UDP — в режиме SNAT.

Особенность эксплуатации CNI Cilium в облаке AWS

Если Cilium работает в режиме VXLAN (единственный доступный для AWS), то по умолчанию не работают соединения изнутри кластера (с узла или из пода) к внутренним ресурсам, опубликованным через балансировщик (Load Balancer) типа internal. При этом снаружи кластера адрес балансировщика отвечает. Причина - включенная опция preserve_client_ip (“Preserve client IP addresses”) на целевой группе: балансировщик не делает NAT и обратный трафик уходит напрямую через VXLAN-туннель мимо балансировщика. Трафик становится асимметричным, соединение сбрасывается. Чтобы устранить проблему, отключите preserve_client_ip для целевой группы одним из двух способов.

Через веб-интерфейс AWS. Откройте EC2 → Target groups, выберите целевую группу балансировщика (например, k8s-d8ingres-internal-...), нажмите Edit target group attributes и в блоке Traffic configuration отключите переключатель Preserve client IP addresses.

Через CLI AWS. Выполните команду, подставив ARN своей целевой группы и регион (ARN можно посмотреть в том же разделе Target groups или командой aws elbv2 describe-target-groups):

aws elbv2 modify-target-group-attributes \
  --target-group-arn arn:aws:elasticloadbalancing:REGION:ACCOUNT:targetgroup/NAME/ID \
  --attributes Key=preserve_client_ip.enabled,Value=false \
  --region REGION

Использование CiliumClusterwideNetworkPolicy

Безопасный порядок внедрения CiliumClusterwideNetworkPolicy, включая обязательные правила для control plane и host firewall, описан в разделе документации Сетевые политики. Подробности по форматам политик Cilium — на странице CiliumNetworkPolicy и CiliumClusterwideNetworkPolicy.

Смена режима работы Cilium

При смене режима работы Cilium (параметр tunnelMode) c Disabled на VXLAN или обратно, необходимо перезагрузить все узлы, иначе возможны проблемы с доступностью подов.

Выключение модуля kube-proxy

Cilium полностью заменяет собой функционал модуля kube-proxy, поэтому kube-proxy автоматически отключается при включении модуля cni-cilium.

Использование выборочного алгоритма балансировки нагрузки для сервисов

В Deckhouse Platform для балансировки нагрузки трафика сервисов можно применять следующие алгоритмы:

• Random — случайный выбор бэкенда для каждого соединения. Прост в реализации, но не всегда обеспечивает равномерное распределение.
• Maglev — использует консистентное хеширование для равномерного распределения трафика, подходит для масштабных сервисов с множеством бэкендов, которые часто ротируются.
• Least Connections — направляет трафик на бэкенд с наименьшим количеством активных соединений, оптимизируя нагрузку для приложений с длительными соединениями.

По умолчанию для всех сервисов задан алгоритм балансировки Random. Однако Deckhouse позволяет переопределять алгоритм для отдельных сервисов. Чтобы использовать выборочный алгоритм балансировки для конкретного сервиса, выполните следующие шаги:

• Отредактируйте конфигурацию модуля cni-cilium в Deckhouse, включив параметр extraLoadBalancerAlgorithmsEnabled. Это активирует поддержку аннотаций сервисов для выборочных алгоритмов.
• В манифесте сервиса укажите аннотацию service.cilium.io/lb-algorithm с одним из значений: random, maglev или least-conn.

Использование Egress Gateway

Egress Gateway в Deckhouse Platform может быть использован в одном из двух режимов: Базовый и Режим с Virtual IP. Для выбора режима используйте ресурс EgressGateway (параметр spec.sourceIP.mode).

Базовый режим

Используются предварительно настроенные IP-адреса на egress-узлах.

Режим с Virtual IP

Реализована возможность динамически назначать дополнительные IP-адреса узлам.

Экспорт данных из Hubble

Deckhouse Platform позволяет настраивать экспорт данных из Hubble, работающего внутри агентов Cilium, с помощью кластерного пользовательского ресурса HubbleMonitoringConfig: Чтобы включить экспорт, создайте ресурс HubbleMonitoringConfig.

После применения манифеста:

• метрики Hubble станут доступны в Prometheus. Все экспортируемые метрики имеют префикс hubble_*;
• логи Hubble будут записываться на каждом узле в файл /var/log/cilium/hubble/flow.log.

Внешние компоненты

Список стороннего программного обеспечения, используемого в модуле cni-cilium (информация представлена на английском языке):

• Cilium 1.17.17

  License: Apache License 2.0

  Cilium is open source software for providing and transparently securing network connectivity and loadbalancing between application workloads such as application containers or processes.

• CNI plugins 1.9.1

  License: Apache License 2.0

  Some reference and example networking plugins, maintained by the CNI team.

• Gops 0.3.27

  License: BSD 3-Clause License

  A tool to list and diagnose Go processes currently running on your system.