Twój węzeł jest obciążony. Użycie CPU rośnie. Sprawdzasz obciążenia robocze – nic niepokojącego. Następnie patrzysz na kube-proxy i conntrack i to widzisz: jądro systemu jest zajęte przetwarzaniem reguł sieciowych, a nie Twoją aplikacją. Przy około 5 000 podów staje się to zauważalne. Przy 20 000 – to poważny problem. Ten artykuł wyjaśnia, dlaczego tak się dzieje i co Cilium faktycznie robi, aby to naprawić.
Kube-proxy od lat jest domyślnym komponentem sieciowym Kubernetes. Działa poprzez tłumaczenie abstrakcji Service na reguły iptables – długie ich łańcuchy. Każdy pakiet przechodzący przez węzeł przechodzi przez te łańcuchy sekwencyjnie. Złożoność czasowa wynosi O(n), gdzie n to liczba reguł.
Matematyka szybko daje o sobie znać. Klaster z 5 000 usług i rozsądną liczbą endpointów może zgromadzić dziesiątki tysięcy reguł iptables. W tej skali koszt przetwarzania pojedynczego pakietu przestaje być błędem zaokrąglenia. Mierzone na instancji Standard D4v3, opóźnienie P99 dla ruchu pod-do-usługi wynosi przy takim obciążeniu około 1,8 ms. Ta liczba sama w sobie może nikogo nie niepokoić, ale liczy się zachowanie systemu: opóźnienie rośnie nieliniowo wraz ze skalowaniem klastra. Nie stabilizuje się.
Drugim problemem jest conntrack. Śledzenie połączeń Linuksa utrzymuje stan dla każdego aktywnego połączenia TCP przechodzącego przez przestrzeń nazw sieci hosta. Jest to jedna z najbardziej intensywnych obliczeniowo operacji w stacku sieciowym jądra i na gęstym węźle Kubernetes z setkami równoległych podów działa nieustannie. To CPU, za który „płacisz” nie otrzymując nic użytecznego w zamian.
Razem, ewaluacja reguł iptables i conntrack odpowiadają za znaczący i mierzalny udział w wykorzystaniu CPU węzłów w dużych klastrach AKS. CPU, które mogłoby uruchamiać Twoje rzeczywiste obciążenia.
Cilium zastępuje cały model kube-proxy. Nie nakłada się na iptables – omija go. Mechanizmem jest eBPF: programy uruchamiane wewnątrz jądra Linuksa w sandboxie, podpięte do konkretnych punktów zaczepienia w stacku sieciowym.
Kluczowe punkty zaczepienia w implementacji Azure CNI Powered by Cilium to:
TC Ingress na interfejsach veth. Każdy pod łączy się z hostem przez wirtualną parę Ethernet (veth). Cilium podpina programy eBPF bezpośrednio do punktu TC Ingress na tych interfejsach, co oznacza, że przechwytuje pakiety natychmiast po opuszczeniu przestrzeni nazw sieci kontenera. W tym momencie pakiet nie dotknął jeszcze w ogóle przestrzeni nazw sieci hosta. Tu właśnie następuje eliminacja conntrack. Cilium podejmuje decyzje o przekazywaniu bez utrzymywania stanu połączenia w tradycyjnym sensie, używając map haszujących eBPF z wyszukiwaniem O(1).
XDP (eXpress Data Path). Dla węzłów wystawionych na ruch zewnętrzny, haki XDP wyzwalają się jeszcze wcześniej – bezpośrednio w sterowniku karty sieciowej, przed alokacją przez jądro struktury sk_buff dla pakietu. Tu właśnie w Azure CNI Powered by Cilium działa łagodzenie ataków DDoS i wczesne filtrowanie ruchu przychodzącego. Koszt jest bliski zeru, ponieważ pakiety, które powinny być odrzucone, nigdy nie wchodzą do stacku jądra.
Operacje gniazd przez cgroups. Dla ruchu pod-do-pod na tym samym węźle Cilium podpina się do wywołań systemowych na poziomie gniazd (connect, sendmsg). Pozwala to na skrócenie trasy komunikacji wewnątrzwęzłowej zanim stanie się ona w ogóle pakietem sieciowym. Jądro przekierowuje dane bezpośrednio między gniazdami. Żadnego przejścia przez veth, żadnego wyszukiwania w tablicy routingu, żadnego wpisu conntrack.
Praktyczny rezultat: routing usług używa wyszukiwań w mapach haszujących eBPF (O(1)) zamiast sekwencyjnych łańcuchów iptables. Na tej samej instancji D4v3, gdzie iptables produkowało 1,8 ms P99 przy skali, Cilium z eBPF datapath dostarcza około 0,9 ms. W przeciwieństwie do iptables, ta liczba pozostaje stabilna wraz ze wzrostem klastra. Przepustowość pod-do-usługi rośnie z około 22 Gbps do 28 Gbps. To nie są różnice z syntetycznych mikrobenchmarków – pojawiają się w rzeczywistym zachowaniu klastra.
eBPF Host Routing: kolejna warstwa
Domyślna konfiguracja Cilium eliminuje już kube-proxy. eBPF Host Routing, dostępny przez Advanced Container Networking Services (ACNS), idzie dalej.
Bez niego pakiety podróżujące między podami na różnych węzłach nadal przechodzą przez warstwę routingu IP hosta, co oznacza wyszukiwania w tablicy routingu jądra i potencjalne przejście przez iptables dla reguł żyjących w przestrzeni nazw hosta. eBPF Host Routing przenosi tę decyzję w całości do programu eBPF. Ścieżka przekazywania nigdy nie dotyka tych warstw jądra.
Na Azure Linux 3.0 (jądro 6.6+) i Ubuntu 24.04 jest to sparowane z trybem BpfVeth, który zastępuje standardowy sterownik veth zoptymalizowaną implementacją redukującą koszt przełączania kontekstu CPU między przestrzenią nazw kontenera a interfejsem hosta. Dla obciążeń AI/ML generujących duże wolumeny małych pakietów (rozproszone trenowanie, serwery parametrów, obsługa inferencji) – tu właśnie można odzyskać 10–15% CPU węzła.
Istnieją trzy znaczące opcje, a wybór ma długoterminowe konsekwencje dla zarządzania przestrzenią IP i architektury routingu.
Azure CNI (VNet IP) przydziela adresy IP podów bezpośrednio z podsieci VNet. Każdy pod jest pełnoprawnym uczestnikiem sieci, bezpośrednio osiągalnym bez żadnej nakładki. Kosztem jest wyczerpanie adresów IP: pula węzłów ze 100 węzłami po 30 podów na węzeł zużywa 3 000 adresów IP z podsieci. Dla środowisk enterprise z ograniczoną przestrzenią RFC 1918 szybko staje się to problemem planistycznym.
Azure CNI Overlay oddziela adresację podów od adresacji VNet. Pody otrzymują adresy IP z prywatnego CIDR, który nie zużywa przestrzeni VNet; SDN Azure obsługuje routing między nakładką a VNet. Na poziomie węzłów nie ma enkapsulacji VXLAN (w przeciwieństwie do większości innych implementacji nakładek chmurowych), co minimalizuje wpływ na wydajność.
Azure CNI Powered by Cilium obsługuje zarówno adresację VNet IP, jak i Overlay, ale zastępuje cały datapath przez eBPF. To model, który umożliwia eBPF Network Policies, obserwowalność Hubble i filtrowanie L7.
Nasza domyślna rekomendacja dla nowych klastrów enterprise: Overlay z Cilium. Rozwiązuje problem wyczerpania IP bez poświęcania wydajności, obsługuje do 5 000 węzłów i 200 000 podów na klaster i daje pełen zestaw funkcji eBPF. Jedynym powodem wyboru VNet IP z Cilium jest sytuacja, gdy pody muszą być bezpośrednio dostępne z sieci lokalnej bez dodatkowej konfiguracji routingu – na przykład gdy starsze systemy łączą się bezpośrednio z adresami IP podów.
W kwestii Node Subnet vs Pod Subnet: jeśli działasz w środowisku, gdzie sieciowe grupy zabezpieczeń (NSG) muszą być stosowane inaczej dla ruchu podów niż dla ruchu węzłów, lub gdzie compliance wymaga widoczności adresów IP podów w logach sieciowych – użyj Pod Subnet (dynamiczna alokacja IP). W pozostałych przypadkach Node Subnet jest prostsze w utrzymaniu i eliminuje jedną warstwę zarządzania podsieciami.
Oznaczenie „Powered by Cilium” oznacza, że Microsoft zarządza agentami Cilium, wersjonowaniem i kompatybilnością z płaszczyzną kontrolną AKS. To nie jest kosmetyczne rozróżnienie.
W konfiguracji samodzielnie zarządzanej (BYOCNI) jesteś właścicielem ścieżki aktualizacji Cilium, testowania kompatybilności z jądrem oraz – co kluczowe – rozmiarowania map BPF. Mapy BPF to struktury danych jądra o stałych pojemnościach, które muszą być ustawione przy starcie agenta. Na dużych węzłach obsługujących wiele podów, zbyt małe mapy produkują błędy (presja mapy, błąd wstawiania do mapy), które są ciche aż do momentu gdy powodują gubione pakiety lub zepsute wykrywanie usług. Prawidłowe rozmiarowanie tych map wymaga znajomości liczby CPU węzła, pamięci, maksymalnej gęstości podów i oczekiwanej współbieżności połączeń. Popełnij błąd w klastrze tysiąca węzłów a będziesz debugować wyczerpanie struktur danych na poziomie jądra pod obciążeniem produkcyjnym.
Wersja zarządzana obsługuje to automatycznie, rozmiarując mapy BPF na podstawie SKU maszyny wirtualnej. To samo w sobie uzasadnia podejście zarządzane dla większości wdrożeń enterprise.
Czego nie możesz zrobić z zarządzanym Cilium: konfigurować BGP (Azure SDN obsługuje routing), włączyć szyfrowania tuneli IPsec (używaj natywnego szyfrowania Azure VNet lub WireGuard jeśli dostępny), ani modyfikować bezpośrednio parametrów cilium-config. CRD CiliumClusterwideNetworkPolicy można stosować, ale nie są oficjalnie wspierane. Jeśli powodują problemy, wsparcie Microsoft ich nie obejmuje. Zamiast tego używaj CiliumNetworkPolicy o zasięgu przestrzeni nazw.
Pule węzłów Windows nie są obsługiwane. Cilium w AKS działa wyłącznie na pulach węzłów Linux; pule Windows nadal używają Azure NPM.
Fundamentalna zmiana w modelu bezpieczeństwa Cilium jest warta jasnego zrozumienia, ponieważ zmienia sposób pisania i rozumowania o politykach.
Tradycyjne polityki sieciowe (Azure NPM, Calico w trybie iptables, natywna Kubernetes NetworkPolicy) operują na adresach IP. W Kubernetes adresy IP podów są efemeryczne. Każdy restart potencjalnie zmienia adres IP, co oznacza, że mechanizm egzekwowania polityki goni ruchomy cel. Obejście to reguły oparte na CIDR lub utrzymywanie polityk wystarczająco szerokich by przeżyły restarty podów – oba podejścia erodują precyzję bezpieczeństwa.
Cilium przypisuje numeryczną Tożsamość Bezpieczeństwa każdemu podowi na podstawie jego etykiet. Wszystkie pody współdzielące ten sam zestaw etykiet mają tę samą tożsamość. Kiedy pakiet dociera do poda docelowego, program eBPF na węźle docelowym ocenia tożsamość pakietu w stosunku do tablicy polityk w jednym wyszukiwaniu mapy haszującej. Rezultat: egzekwowanie polityki nie psuje się przy restarcie poda dopóki etykiety pozostają te same, nie ma warunków wyścigu przy zmianie przypisań IP, a dodanie nowych replik poda nigdy nie wymaga aktualizacji polityki.
Dla polityk L3/L4 działa to w całości w eBPF z pomijalnym narzutem. Dla polityk L7 (filtrowanie ścieżek HTTP, filtrowanie metod gRPC, filtrowanie tematów Kafka) Cilium przekierowuje pasujący ruch do lokalnej instancji Envoy działającej jako DaemonSet. To model odłączonego Envoy: bez wstrzykiwania sidecarów, bez zmian w manifestach aplikacji, bez narzutu pamięciowego od procesu proxy na każdy pod. Kosztem jest mierzalne opóźnienie dla ruchu inspektowanego na L7 (typowo 0,2–0,5 ms w zależności od złożoności reguł), ale jest ono ograniczone do ruchu wymagającego inspekcji, nie do całego ruchu.
Hubble to warstwa obserwowalności Cilium, a kluczową jej cechą jest to, że nie wymaga żadnych zmian w aplikacjach, żadnych proxy sidecar ani żadnej instrumentacji. Wszystko co widzi pochodzi z programów eBPF już działających w jądrze.
W integracji ACNS Hubble dostarcza trzy rzeczy istotne operacyjnie:
Logi przepływu do Azure Log Analytics. Każde połączenie (pod źródłowy, pod docelowy, przestrzeń nazw, werdykt polityki, powód odrzucenia) jest logowane. Pole „powód odrzucenia” sprawia, że jest to naprawdę użyteczne: zamiast widzieć odmowę połączenia i zgadywać czy to błędnie skonfigurowana NetworkPolicy, czy usługa jest wyłączona, czy to awaria DNS, do każdego odrzuconego pakietu jest dołączony konkretny powód. Analiza post-incydentowa zmienia się z „odtwórzmy to” na „przeczytajmy logi z momentu, gdy to się stało”.
Metryki do Azure Managed Prometheus. Retransmisje TCP między węzłami, opóźnienia zapytań DNS i wskaźniki błędów, rozkłady kodów odpowiedzi HTTP – wszystko widoczne bez wdrażania service meshu. Dla zespołów SRE budujących dashboardy SLO, zamyka to lukę która wcześniej wymagała albo Istio albo instrumentacji na poziomie aplikacji.
Mapa usług. Topologia w czasie rzeczywistym pokazująca które usługi komunikują się z którymi, z wolumenem ruchu i wskaźnikami błędów. Przydatna do audytu rzeczywistych versus zamierzonych wzorców komunikacji, szczególnie po migracji do bardziej restrykcyjnych konfiguracji NetworkPolicy.
Tryb „Stored Logs Mode” w ACNS zachowuje dane przepływu po usunięciu podów. Dla regulowanych środowisk gdzie incydenty bezpieczeństwa wymagają śladów audytowych na poziomie sieci, ma to znaczenie. Pod który został naruszony i usunięty zniknął, ale jego aktywność sieciowa jest zachowana.
Wyczerpanie tożsamości w klastrach Spark. Cilium obsługuje maksymalnie 65 535 unikalnych Tożsamości Bezpieczeństwa na klaster. Zadania Apache Spark działające na Kubernetes często używają etykiet podów zawierających unikalne identyfikatory zadania lub wykonawcy. Każda unikalna kombinacja etykiet to oddzielna tożsamość. Zajęty klaster Spark z wieloma krótkotrwałymi zadaniami może wyczerpać ten limit, w którym momencie agent Cilium nie może przypisywać tożsamości nowym podom i łączność sieciowa ulega awarii. Rozwiązaniem jest konfiguracja reguł wykluczania tożsamości Cilium by ignorował etykiety niosące unikalne identyfikatory, ale trzeba to wykryć zanim limit zostanie osiągnięty w produkcji. Jeśli Twoje obciążenia używają Spark, Flink lub czegokolwiek generującego pody z unikalnymi wartościami etykiet, przeprowadź audyt schematów etykiet przed włączeniem Cilium.
Problem ponownego obrazowania przy migracji. Aktualizacja istniejącego klastra AKS do Azure CNI Powered by Cilium wyzwala jednoczesne ponowne obrazowanie wszystkich pul węzłów. Nie ma migracji kroczącej. Wszystkie węzły są ponownie obrazowane jednocześnie, co oznacza że pody są eksmitowane i ponownie zaplanowane w całym klastrze. Zaplanuj okno konserwacyjne. Jeśli masz PodDisruptionBudgets uniemożliwiające eksmisję, migracja może utknąć. Przejrzyj swoje PDB przed rozpoczęciem.
Kompatybilność Istio z eBPF Host Routing. Niektóre wersje Istio używają reguł iptables w przestrzeni nazw sieci poda do przechwytywania ruchu i przekierowywania go do sidecara Envoy. eBPF Host Routing może kolidować z tym mechanizmem przechwytywania. Konkretny tryb awarii to ruch całkowicie omijający sidecar Istio, co psuje mTLS i egzekwowanie polityki bez oczywistych komunikatów błędów. Przed włączeniem eBPF Host Routing na klastrach z Istio, sprawdź macierz kompatybilności Cilium-Istio dla Twoich konkretnych wersji. Według stanu na Cilium 1.14/1.15 istnieją sprawdzone konfiguracje, ale wymagają jawnego dostrajania.
Poniżej 200 węzłów i bez rygorystycznych wymagań polityki bezpieczeństwa, zyski wydajnościowe z eBPF są realne, ale nie dramatyczne. kube-proxy działa. Jeśli Twój klaster jest stabilny, a możliwości Twojego zespołu są ograniczone, to nie jest pilna migracja.
Powyżej 500 węzłów, narzut CPU z iptables i conntrack staje się mierzalny pod względem kosztów. W tej skali, samo automatyczne rozmiarowanie map BPF w wersji zarządzanej jest warte wysiłku migracji, jeszcze przed uwzględnieniem poprawy wydajności. Model bezpieczeństwa oparty na tożsamości staje się też coraz bardziej wartościowy wraz ze wzrostem liczby usług i gdy polityki oparte na IP stają się trudniejsze do rozumowania.
Dla obciążeń AI/ML konkretnie (rozproszone trenowanie, inferencja na dużą skalę) kombinacja eBPF Host Routing i optymalizacji wewnątrzwęzłowej na poziomie gniazd może odzyskać znaczące zasoby obliczeniowe z narzutu sieciowego. Na ciężkich typach węzłów GPU gdzie koszt maszyny wirtualnej jest wysoki, ten odzysk ma bezpośredni wpływ finansowy.
Najsilniejszy argument za Cilium w każdym klastrze, niezależnie od rozmiaru, to Hubble. Widoczność operacyjna którą zapewnia – bez złożoności service meshu, bez wstrzykiwania kontenerów sidecar, bez zmian w aplikacjach – wypełnia realną lukę w tym jak sieć Kubernetes jest dziś obserwowalna. Ta korzyść nie jest związana ze skalą klastra.
eBPF datapath to nie jest optymalizacja wydajności; to inny model wykonania dla przetwarzania pakietów. Liczby wydajnościowe są realne, ale trwalszą korzyścią jest to, że nie degradują się wraz ze wzrostem klastra. Systemy oparte na iptables są ograniczone; systemy oparte na eBPF skalują się do tego co AKS obecnie obsługuje (200 000 podów) bez zmian architektonicznych.
Zarządzana wersja Cilium w AKS jest właściwym domyślnym wyborem dla wdrożeń enterprise. Samo zarządzanie mapami BPF to uzasadnia. Zaakceptuj ograniczenia (brak BGP, brak niestandardowej konfiguracji) i zaplanuj architekturę NetworkPolicy wokół zasobów CiliumNetworkPolicy o zasięgu przestrzeni nazw.
Jeśli projektujesz nowy klaster AKS i nie planujesz Cilium, planujesz migrację później pod większą presją niż byś chciał.
