Cilium как универсальный компонент Kubernetes-инфраструктуры: от CNI до Service Mesh
Всем привет! На связи Алексей Баранович, сегодня я хочу вам рассказать о Cilium.
В современных Kubernetes-платформах стремление к упрощению архитектуры и снижению числа зависимостей становится всё более актуальным. Особенно это заметно при построении MVP-решений или управляемых платформ, где каждый дополнительный компонент — это не только рост сложности, но и увеличение поверхности для потенциальных сбоев и уязвимостей. В этом контексте Cilium выделяется как один из немногих проектов, способных заменить сразу несколько традиционных инструментов: CNI-плагин, Ingress-контроллер, Service Mesh и даже внешний LoadBalancer. Давайте разберёмся, как это работает и почему Cilium может стать единственным «сетевым» компонентом в вашем кластере.
Cilium как CNI: основа всего
Изначально Cilium позиционировался как высокопроизводительный CNI-плагин, использующий eBPF (extended Berkeley Packet Filter) вместо iptables или IPVS. Это даёт не только значительный прирост производительности, но и гибкость на уровне ядра Linux: политики сети, observability, балансировка трафика — всё это реализуется без перезаписи цепочек правил или установки дополнительных прокси.
Но Cilium быстро вырос за рамки CNI. Сегодня он предлагает полноценную платформу для сетевой и сервисной безопасности, объединяя в себе функциональность, которая раньше требовала развёртывания десятков отдельных компонентов.
Установка Cilium через Helm
Самый распространённый способ установки Cilium — через Helm. Сначала добавьте официальный репозиторий:
helm repo add cilium https://helm.cilium.io/
helm repo update
Затем установите с базовыми настройками (для большинства сред подойдёт):
helm install cilium cilium/cilium \
--namespace kube-system \
--set ipam.mode=kubernetes
Если вы хотите использовать собственный Pod CIDR (например, 10.224.0.0/13), как часто делают в on-prem:
helm install cilium cilium/cilium \
--namespace kube-system \
--set ipam.mode=cluster-pool \
--set ipam.operator.clusterPoolIPv4PodCIDRList="{10.224.0.0/13}" \
--set ipam.operator.clusterPoolIPv4MaskSize=22 \
--set ipv4NativeRoutingCIDR=10.224.0.0/13 \
--set routingMode=native \
--set autoDirectNodeRoutes=true
Эти параметры включают режим cluster-pool для IPAM и native routing через eBPF, что даёт максимальную производительность без kube-proxy.
Встроенный LoadBalancer без MetalLB или облачных провайдеров
Одна из самых болезненных тем в on-prem Kubernetes — отсутствие встроенного решения для внешнего LoadBalancer. Обычно приходится ставить MetalLB, использовать внешние балансировщики или обходиться NodePort.
Cilium решает эту проблему с помощью BGP-интеграции и DSR (Direct Server Return). Начиная с версии 1.13, Cilium поддерживает собственный L2 и BGP-режимы для сервисов типа LoadBalancer, что позволяет:
Назначать внешние IP-адреса сервисам без MetalLB.
Работать в bare-metal и виртуальных средах (включая VMware).
Использовать DSR для минимизации latency и снижения нагрузки на worker-ноды.
Чтобы включить встроенный LoadBalancer через Helm:
helm install cilium cilium/cilium \
--namespace kube-system \
--set loadBalancer.mode=dsr \
--set loadBalancer.acceleration=native \
--set loadBalancer.serviceTopology=true
Если вы используете BGP, добавьте:
--set loadBalancer.mode=bgp \
--set loadBalancer.bgp.announce=pool
И определите IP-пул в ConfigMap или через Helm-параметры, например:
--set loadBalancer.ipam.kubernetes.serviceIPBlocks="{192.168.10.0/24}"
Теперь любой Service с типом LoadBalancer автоматически получит IP из этого пула.
Gateway API: единая модель для Ingress и Egress
Традиционные Ingress-контроллеры (Nginx, Traefik, HAProxy) требуют отдельного развёртывания, настройки TLS, rate limiting, WAF и т.д. Cilium предлагает нативную поддержку Kubernetes Gateway API — современного стандарта управления трафиком, который заменяет устаревший Ingress API.
Чтобы включить Gateway API в Cilium, достаточно установить:
helm install cilium cilium/cilium \
--namespace kube-system \
--set gatewayAPI.enabled=true
После этого вы можете создавать ресурсы Gateway, HTTPRoute и другие. Пример Gateway:
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: public-gateway
namespace: default
spec:
gatewayClassName: cilium
listeners:
- name: http
port: 80
protocol: HTTP
И HTTPRoute:
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: my-app-route
namespace: default
spec:
parentRefs:
- name: public-gateway
rules:
- matches:
- path:
type: PathPrefix
value: /api
backendRefs:
- name: my-app
port: 8080
Всё это работает без sidecar-прокси, благодаря eBPF и L7-парсингу на уровне ядра.
Service Mesh без Istio: Cilium + Envoy (опционально)
Istio — мощный, но тяжёлый Service Mesh. Он требует внедрения sidecar-прокси (Envoy) в каждый под, что увеличивает потребление ресурсов и усложняет отладку.
Cilium предлагает альтернативу: Cilium Service Mesh. Он реализует ключевые функции Service Mesh:
mTLS между сервисами (на основе SPIFFE/SPIRE или собственного PKI).
L7-наблюдаемость (HTTP, gRPC, Kafka).
Трассировка (через OpenTelemetry).
Retry, timeout, circuit breaking — через Envoy только при необходимости.
Чтобы включить базовые функции Service Mesh через Helm:
helm install cilium cilium/cilium \
--namespace kube-system \
--set l7Proxy=true \
--set hubble.enabled=true \
--set hubble.relay.enabled=true \
--set hubble.ui.enabled=true \
--set securityContext.capabilities.ciliumAgent="{CHOWN,KILL,NET_ADMIN,NET_RAW,IPC_LOCK,SYS_ADMIN,SYS_RESOURCE,DAC_OVERRIDE,FOWNER,SETGID,SETUID}"
Для mTLS:
--set encryption.enabled=true \
--set encryption.type=wireguard
Или для TLS на уровне сервисов:
--set serviceMesh.enabled=true
Если нужны продвинутые L7-политики с Envoy:
--set envoy.enabled=true
При этом sidecar не обязателен: базовые функции (шифрование, политики, метрики) работают через eBPF. Envoy подключается лишь тогда, когда нужны продвинутые L7-фичи. Это даёт гибкость: вы получаете Service Mesh без накладных расходов там, где он не нужен.
Cluster Mesh: много-кластерная сеть «из коробки»
Если у вас несколько Kubernetes-кластеров (например, dev/stage/prod или multi-region), традиционно для их объединения требуются сложные решения: submariner, istio multi-cluster, custom overlay-сети.
Cilium предлагает Cluster Mesh — встроенную возможность объединять кластеры в единую логическую сеть:
Сервисы из одного кластера доступны в другом по DNS-имени.
Единые сетевые политики применяются кросс-кластерно.
Поддержка identity-based security (не привязка к IP!).
Для включения Cluster Mesh нужно:
Установить Cilium в каждом кластере с уникальным cluster.id и cluster.name.
Настроить общий etcd или использовать clustermesh-apiserver.
Пример установки с поддержкой Cluster Mesh:
helm install cilium cilium/cilium \
--namespace kube-system \
--set cluster.name=cluster-a \
--set cluster.id=1 \
--set clustermesh.enabled=true \
--set clustermesh.useAPIServer=true
Затем выполнить настройку связи между кластерами с помощью cilium-cli:
cilium clustermesh enable --context cluster-a
cilium clustermesh enable --context cluster-b
cilium clustermesh connect cluster-a cluster-b
После этого сервисы автоматически станут доступны через DNS вида <service>.<namespace>.svc.clusterset.local.
Заключение
Cilium — это не просто CNI. Это единая платформа для всего сетевого стека Kubernetes, которая позволяет отказаться от Nginx Ingress, MetalLB, Istio и даже внешних балансировщиков в большинстве сценариев. Для инженеров, строящих управляемые, безопасные и минималистичные Kubernetes-платформы, Cilium становится не просто выбором, а стратегическим решением.
Если вы стремитесь к «меньше компонентов — больше контроля», Cilium стоит рассмотреть уже сегодня.