Infrastruktura sieciowa pod Kubernetes: CNI, overlay networks i najczęstsze problemy

Fundamenty sieci w Kubernetes – model, założenia, ograniczenia

Model komunikacji w Kubernetes: IP dla każdego poda

Sieć Kubernetes opiera się na prostym z założenia modelu: każdy pod ma własny adres IP, a cała przestrzeń adresowa podów jest logicznie płaska w obrębie klastra. Pody komunikują się ze sobą bez NAT, tak jakby były w jednej dużej podsieci. Ta prostota logiczna jest kluczowa: aplikacja nie musi znać szczegółów routingu, nie musi wiedzieć, na którym node działa sąsiadujący pod.

Z tego podejścia wynikają trzy podstawowe reguły sieciowe Kubernetes:

• wszystkie pody w klastrze mogą się ze sobą komunikować bez NAT (pod-to-pod),
• każdy node musi być w stanie routować ruch do każdego IP poda,
• adres IP poda jest unikalny w skali klastra (a nie pojedynczego node’a).

To jest podstawowy kontrakt, który musi zapewnić warstwa CNI (Container Network Interface) wraz z infrastrukturą pod spodem. Implementacja – czy to overlay network, czy direct routing – jest szczegółem technicznym, ale niespełnienie kontraktu skutkuje losowymi timeoutami, zrywaniem połączeń i trudnymi do odtworzenia błędami.

Jeżeli mapa „IP poda → node → segment sieci fizycznej” nie jest jasno zdefiniowana i udokumentowana, to jest to sygnał ostrzegawczy już na etapie projektu. Taki brak czytelności zwykle kończy się konfliktem z zespołem sieciowym, niespójnymi politykami firewalli i nieprzewidywalnym zachowaniem klastra.

Sieć klastrowa vs sieć infrastruktury – dwa różne światy

Pod infrastrukturą sieciową Kubernetes kryją się co najmniej dwie warstwy, które trzeba rozróżnić:

• sieć klastrowa – ruch między podami, między podami a Service (ClusterIP), ewentualnie ruch do kube-proxy, core DNS, itp.; zarządzana głównie przez CNI i kube-proxy / kube-router / eBPF,
• sieć infrastruktury – ruch między node’ami, ruch north-south (z i do klastra), dostęp do API serwera, do rejestru obrazów, do storage, do systemów zewnętrznych.

Sieć klastrowa to najczęściej overlay network działająca nad siecią infrastruktury. Dla podów jest przeźroczysta – widzą one jedynie własne IP i IP innych podów. Sieć infrastruktury musi zapewnić:

• stabilną i wystarczająco szybką łączność między node’ami (L3),
• odpowiednio skonfigurowane MTU i brak niekontrolowanej fragmentacji,
• otwarte porty niezbędne dla ruchu kontrol-plane, kubeletów, CNI, itp.

Konflikt pojawia się, gdy zespół sieciowy projektuje infrastrukturę tak, jakby każdy node był klasycznym serwerem z kilkoma portami, a nie hostem wielu tysięcy wirtualnych interfejsów (podów). Jeśli polityki bezpieczeństwa organizacji wymagają twardych podziałów L3/L4, a jednocześnie oczekuje się, że „pody widzą się jak w jednej podsieci”, to jest to wyraźny sygnał ostrzegawczy, że wymagania są sprzeczne.

Ograniczenia chmury publicznej i środowisk bare metal

Projekt sieci pod Kubernetes w chmurze publicznej i on-premise (bare metal) różni się znacząco, choć model logiczny Kubernetes jest ten sam. W chmurze, takiej jak AWS, Azure czy GCP, dochodzi warstwa VPC/VNet, security groups, routing wirtualny i dedykowane pluginy CNI integrujące pody z siecią dostawcy. Na bare metal opierasz się zwykle na VLAN-ach, VRF, fizycznych routerach, firewallach sprzętowych i samodzielnie wdrożonym CNI.

Typowe ograniczenia w chmurze publicznej:

• limity liczby IP na interfejs sieciowy/instancję (np. ENI na AWS),
• brak możliwości „dowolnych” zmian w routingu poza tym, co umożliwia VPC/VNet,
• ograniczona kontrola nad MTU i ścieżką routingu między AZ/regionami.

Typowe ograniczenia w środowiskach bare metal:

• konieczność koordynacji z zespołem sieciowym przy BGP, VXLAN, zmianach routingowych,
• stare urządzenia nieobsługujące nowoczesnych protokołów (VXLAN, EVPN),
• ściśle kontrolowane polityki firewalli utrudniające ruch node-to-node.

Jeśli środowisko chmurowe ma twarde limity IP na instancję, a planowana jest duża gęstość podów, trzeba od razu sprawdzić, czy natywny CNI dostawcy poradzi sobie z tym obciążeniem. Jeśli w środowisku bare metal administrator sieci odrzuca BGP i tunelowanie jako „zbyt skomplikowane”, bez alternatywy, projekt klastra Kubernetes będzie miał bardzo ograniczone możliwości skalowania.

Minimalne wymagania sieciowe klastra – lista kontrolna

Przed wyborem CNI i startem klastra warto przejść przez podstawową listę kontrolną, obejmującą minimum parametrów sieciowych:

• przestrzeń adresowa dla podów – wydzielone CIDR (lub kilka) z planu adresacji, bez konfliktu z istniejącymi podsieciami w organizacji,
• przestrzeń adresowa dla Service (ClusterIP) – osobny CIDR, niewidoczny na zewnątrz (zwykle nie routowany poza klaster),
• otwarte porty node-to-node – ruch CNI, kubelet, gossip (w zależności od pluginu), ruch VXLAN/BGP jeśli używane,
• stabilne DNS – zarówno dla komponentów Kubernetes (CoreDNS), jak i dla aplikacji w podach,
• spójne MTU na ścieżce między node’ami – w szczególności przy overlay networks.

Jeśli nie ma formalnie przydzielonej puli adresowej dla podów i Service, konflikt adresacji z istniejącą siecią jest tylko kwestią czasu. Jeśli MTU jest ignorowane, pierwsze symptomy wyjdą dopiero pod obciążeniem lub przy komunikacji z zewnętrznymi systemami (np. VPN), co znacząco utrudni diagnozę.

Wnioski z warstwy fundamentów

Jeżeli architekt nie potrafi narysować mapy „pod IP → node → sieć fizyczna → routery/bramy”, to projekt sieciowy Kubernetes nie ma realnych podstaw. Jeśli założenie „pody widzą się jak w jednej podsieci” zderza się z polityką sieciową organizacji zakładającą twardą segmentację, to lepiej ten konflikt ujawnić przed wyborem CNI, a nie po wdrożeniu produkcyjnym.

Rola CNI w Kubernetes – jak działa, czego wymaga od infrastruktury

Standard CNI – kontrakt między kubeletem a siecią

CNI (Container Network Interface) to standard opisujący, jak system orkiestracji kontenerów (w tym Kubernetes) ma komunikować się z pluginem sieciowym. CNI definiuje prosty kontrakt: kubelet (przez CRI i runtime, np. containerd) wywołuje binarki pluginu z odpowiednią konfiguracją, a plugin ma za zadanie utworzyć interfejs sieciowy dla kontenera/poda, przypisać IP, ustawić routing i na końcu posprzątać.

Elementy składowe typowego wdrożenia CNI:

• binarki pluginów – zwykle w /opt/cni/bin, wykonywalne pliki, które kubelet wywołuje przy zdarzeniach sieciowych,
• konfiguracja CNI – pliki JSON w /etc/cni/net.d, określające m.in. nazwę sieci, typ pluginu, IPAM, parametry MTU,
• IPAM – komponent odpowiedzialny za przydział i zwalnianie adresów IP (może być częścią pluginu lub osobną wtyczką).

Standard CNI nie mówi, jak plugin ma zrealizować sieć (overlay, BGP, eBPF); definiuje tylko, jakich operacji oczekuje od niego kubelet. Jeżeli zespół nie wie, gdzie znajdują się pliki konfiguracji CNI i jakie binarki są faktycznie używane, debugowanie problemów sieciowych staje się loterią.

Cykl życia interfejsu dla poda z perspektywy CNI

Tworzenie i usuwanie podów wywołuje zestaw operacji po stronie CNI. Skrócony, ale istotny z punktu widzenia diagnozy cykl życia wygląda tak:

1. Scheduler przydziela pod do określonego node’a.
2. Kubelet na node’ie uruchamia kontener(y) przez runtime (np. containerd).
3. Runtime wywołuje CNI z poleceniem ADD, przekazując m.in. identyfikator kontenera/poda, nazwę sieci, namespace.
4. CNI:
   • tworzy interfejs (np. veth) w przestrzeni sieciowej poda,
   • za pomocą IPAM przydziela IP z wybranej puli,
   • konfiguruje routing tak, aby ruch do IP poda docierał przez odpowiedni mechanizm (overlay, BGP, itp.),
   • zapisuje stan (mapowanie IP → pod/containerId) w lokalnym store (plikowym, itp.) lub w rozproszonym backendzie.
5. Przy usuwaniu poda runtime wywołuje CNI z poleceniem DEL, a plugin:
   • usuwa interfejs poda,
   • zwalnia IP w IPAM,
   • aktualizuje routing / stan wewnętrzny.

W praktyce większość trudnych do uchwycenia błędów wynika z niekonsekwencji w tym cyklu – np. CNI z jakiegoś powodu nie dostaje zdarzenia DEL albo IPAM nie zwalnia IP po awarii node’a. Punkt kontrolny: zespół powinien wiedzieć, jak sprawdzić stan IPAM (np. polecenia CLI pluginu, pliki w /var/lib/cni) i jak rozpoznać „osierocone” IP.

Jeśli utracisz przejrzystość co do tego, gdzie IPAM trzyma stan i jak jest odtwarzany po restarcie node’a, każdy restart może generować ukryte wycieki adresów IP i losowe problemy z tworzeniem podów.

Typy pluginów CNI i łańcuchowanie funkcji

Pluginy CNI można podzielić na dwie główne grupy:

• pełnofunkcyjne pluginy sieciowe – np. Calico, Cilium, Flannel, Weave Net; obsługują zarówno część L3 (routing), jak i często network policy, IPAM, a niekiedy zaawansowane funkcje bezpieczeństwa (eBPF, IDS/IPS),
• proste pluginy „building blocks” – np. bridge, host-local, loopback; służą jako podstawowe klocki, z których można zbudować prostsze rozwiązania lub łańcuchy CNI.

CNI wspiera mechanizm chaining – jeden plugin może wykonać część operacji (np. przydział IP), a kolejny dodać kolejne funkcje (np. policy enforcement, mirroring ruchu). Przykład: plugin chmurowy (np. AWS VPC CNI) przydziela IP z poziomu ENI, a dodatkowy plugin eBPF (np. Cilium w trybie strict) implementuje network policy i obserwowalność L7.

Sygnałem ostrzegawczym jest sytuacja, w której w /etc/cni/net.d znajdują się dwa lub więcej plików konfiguracyjnych z różnymi pluginami, a nikt w zespole nie potrafi powiedzieć, w jakiej kolejności są wykonywane i co faktycznie zarządza IPAM. W takich układach łatwo o kolizje, np. dwa różne IPAM-y próbujące przydzielać adresy.

Integracja CNI z kubeletem, CRI i wpływ na debugowanie

Kubelet nie rozmawia z CNI bezpośrednio, lecz przez warstwę CRI (Container Runtime Interface) – np. containerd lub CRI-O. To runtime uruchamia binarki CNI i przekazuje im informacje o kontenerach. Stąd kilka skutków praktycznych:

• błędy CNI często pojawiają się w logach runtime (containerd), nie tylko kubeleta,
• jeśli istnieje problem z CRI (np. wersja niekompatybilna), CNI może nie być w ogóle wywoływane lub być wywoływane błędnie,
• w przypadku legacy Docker shim ścieżka była inna, co utrudnia diagnostykę w mieszanych środowiskach.

Minimalny punkt kontrolny przy debugowaniu sieci:

• sprawdzenie logów kubelet na node’ach z problemem,
• sprawdzenie logów runtime (np. journalctl -u containerd),
• sprawdzenie logów komponentów CNI (jeśli plugin takie prowadzi – np. Calico, Cilium).

Jeśli zespół przy każdym problemie sieciowym patrzy wyłącznie na logi aplikacji w podach i pomija kubeleta oraz runtime, diagnoza zawsze będzie niepełna. Jeżeli vendor CNI dostarcza własne narzędzia CLI (np. calicoctl, cilium status), brak ich znajomości to wyraźny sygnał ostrzegawczy dla utrzymania.

Gdzie CNI przechowuje stan i jak raportuje błędy

Większość produkcyjnych pluginów CNI utrzymuje własny stan kontrolny: informacje o przypisanych IP, tunelach, trasach, politykach. Może to być:

• lokalny store na node’zie (pliki, bazy key-value),
• rozproszony backend – np. etcd (Calico w trybie etcd), CRD w Kubernetes (Calico/Cilium w trybie „kubernetes datastore”),
• konsola centralna vendora (rozwiązania komercyjne).

Kluczowe pytania kontrolne:

• gdzie dokładnie przechowywany jest stan IPAM,

Mechanizmy raportowania stanu i błędów w praktycznych wdrożeniach

Sam fakt, że CNI „gdzieś trzyma stan”, to za mało. Zespół utrzymaniowy musi mieć operacyjne ścieżki dojścia do informacji o aktualnym stanie sieci i o błędach. W praktyce oznacza to kilka kanałów obserwacji:

• logi demonów CNI – typowo jako DaemonSet (np. calico-node, cilium-agent); powinny być zbierane centralnie i tagowane po node’ach,
• metryki – endpointy Prometheus (np. /metrics) z liczbą nieudanych operacji CNI, stanem BGP, liczbą aktywnych tuneli,
• narzędzia CLI vendora – komendy w rodzaju calicoctl node status, cilium status, cilium connectivity test,
• zdrowie DaemonSetów – status podów CNI w kube-system, restart policy, CrashLoopBackOff.

Sygnałem ostrzegawczym jest sytuacja, gdy zespół ma centralny monitoring dla kubeletów i aplikacji, ale nie ma ani jednego dashboardu dla CNI (tuneli, BGP, eBPF, IPAM). W takim środowisku problemy sieciowe są wykrywane dopiero wtedy, gdy aplikacja przestaje odpowiadać, a nie wtedy, gdy np. wypada peer BGP lub kończy się pula IP.

Jeśli narzędzia CLI CNI nie są dopuszczone do użycia w środowisku produkcyjnym (brak procedur, brak uprawnień), to każdy incydent sieciowy będzie się kończył eskalacją do vendora lub „strzelaniem” w ciemno komendami kubectl exec na losowych podach.

Typy sieci w Kubernetes – overlay, routing bezpośredni, host networking

Overlay networks – kapsułkowanie i jego konsekwencje

Overlay to najczęstszy pierwszy wybór w środowiskach, gdzie administracja siecią fizyczną nie chce lub nie może ingerować w routing podów. Tunel (VXLAN, IP-in-IP, GRE, Geneve) buduje spójną „wirtualną podsieć podów” ponad istniejącą infrastrukturą L3.

Najważniejsze cechy overlay:

• kapsułkowanie – każdy pakiet poda jest opakowywany dodatkowym nagłówkiem (VXLAN, IPIP), co zmniejsza efektywny MTU i zwiększa obciążenie CPU,
• brak wymagań wobec sieci underlay poza L3 reachability między node’ami i odpowiednimi portami UDP/TCP,
• złożone ścieżki debugowania – analiza pakietów wymaga świadomości zarówno adresów podów, jak i IP node’ów oraz tuneli.

Typowy overlay w praktyce:

• Flannel w trybie VXLAN – uproszczony model, minimalna konfiguracja, ale brak natywnego network policy,
• Calico w trybie IP-in-IP – pods są routowane przez tunel IPIP; później możliwa migracja do BGP direct routing,
• Cilium z tunelami Geneve/VXLAN – duży nacisk na eBPF, obserwowalność i polityki L7.

Punkt kontrolny przy overlay: zespół musi mieć jasno zdefiniowaną wartość MTU na interfejsie pod (np. 1450) i na interfejsach fizycznych node’ów, z uwzględnieniem pełnego overheadu tunelu i ewentualnego dodatkowego enkapsulowania (np. VPN, IPSec). Brak tej kalkulacji to prosta droga do trudnych do powtórzenia „zacięć” TCP i losowego timeoutu po stronie klientów.

Jeśli analiza tcpdump na interfejsie poda i na interfejsie fizycznym node’a pokazuje różne wielkości pakietów i fragmentację na ścieżce, a zespół nie potrafi wyjaśnić przyczyny, overlay został wdrożony bez świadomości kosztów MTU i overheadu.

Routing bezpośredni (no-overlay) – BGP, static routing, chmurowe ENI

W modelu bez overlay każdy pod jest z routowalnym adresem IP w sieci underlay. Wymaga to współpracy z infrastrukturą sieciową, ale znacząco upraszcza ścieżkę pakietu i diagnostykę. Rozwiązanie typowe dla środowisk data center z kontrolą nad routerami oraz dla części CNI chmurowych.

Najczęstsze warianty direct routing:

• BGP peering z routerami brzegowymi (Calico, Cilium BGP addon) – każdy node ogłasza prefiks z pulą podów jako route BGP, routery dystrybuują trasy po sieci,
• static routing – konfiguracja tras podsieci podów per-node w routerach lub na bramie (rozwiązanie akceptowalne tylko dla małych klastrów),
• chmurowe CNI w trybie „ENI/IP per Pod” – np. AWS VPC CNI, Azure CNI; każdy pod otrzymuje IP z VPC/subnetu, a routing jest zarządzany przez kontroler chmurowy.

Korzyści z direct routing:

• brak tuneli i związanych z nimi problemów z MTU i overheadem,
• pakiety podów są widoczne „jak zwykły ruch IP” w narzędziach sieciowych (NetFlow, firewalle, TAP-y),
• prostszą integrację z istniejącymi systemami bezpieczeństwa opartymi na IP źródłowym.

Cena tego modelu to wyższy próg wejścia: zespół sieciowy musi zaakceptować, że routing w warstwie fizycznej będzie dynamicznie zmieniał się w zależności od stanu klastra, a liczba prefiksów i tras nie będzie stała. Sygnał ostrzegawczy: brak ograniczeń lub planu skalowania tablicy routingu (TCAM, FIB) na routerach, przy założeniu rosnącej liczby node’ów i prefiksów per node.

Jeżeli administratorzy routerów nie widzą w projektach informacji o planowanej liczbie prefiksów BGP z klastrów Kubernetes, to konfiguracja direct routing jest działaniem na ślepo – pierwsze problemy pojawią się przy rozbudowie klastra lub awarii, gdy liczba ogłaszanych tras wzrośnie skokowo.

Host networking – kiedy pod staje się procesem na hoście

Host networking oznacza, że pod używa namespace sieciowy node’a. Z perspektywy sieci to zwykły proces działający bezpośrednio na adresie IP node’a, z dostępem do tych samych interfejsów i tablic routingu. CNI nie musi wtedy tworzyć wirtualnego interfejsu ani przydzielać osobnego IP.

Typowe użycia host networking:

• pod kontrolujący sieć lub storage (np. CNI, CSI, monitoring), który musi widzieć ruch na interfejsach hosta,
• serwisy wymagające użycia portów „uprzywilejowanych” (np. 53/UDP dla DNS w specyficznych scenariuszach),
• komponenty infrastrukturalne o bardzo niskich wymaganiach na opóźnienia i bez NAT (np. niektóre load balancery L4).

Ten model jest wygodny, ale znacząco ogranicza izolację. Punkty ryzyka:

• kolizje portów pomiędzy podami hostNetwork i demonami na node’ach,
• omijanie network policy działających na poziomie podów, jeśli polityki nie obejmują ruchu host → host,
• większy wpływ pojedynczego poda na kondycję całego node’a (np. flood ruchu, błędna konfiguracja iptables/iproute2).

Jeśli środowisko zaczyna masowo używać hostNetwork: true jako „szybkiej naprawy problemów z siecią”, to jest to sygnał ostrzegawczy, że projekt sieci podów lub polityki bezpieczeństwa są nieadekwatne i obchodzone na skróty.

Porównanie modeli: kryteria wyboru dla audytu

Przy audycie istniejącego klastra lub projektowaniu nowego warto patrzeć nie na markę CNI, lecz na model sieciowy, jaki ten CNI realizuje. Zestaw podstawowych kryteriów:

• zależność od infrastruktury sieciowej:
  • overlay – minimalna, wystarczy pełna łączność L3 między node’ami,
  • direct routing – wysoka, wymaga integracji z routerami lub kontrolerami chmurowymi,
  • host networking – minimalna, ale za cenę utraty izolacji na poziomie IP.
• łatwość debugowania:
  • overlay – trudna, dwie przestrzenie adresowe i tunel,
  • direct routing – prostsza, ruch jak zwykły IP; wymaga jednak dostępu do routerów,
  • host networking – najprostsza dla sieci, najtrudniejsza dla bezpieczeństwa.
• wpływ na MTU i wydajność:
  • overlay – obniżony MTU, dodatkowy CPU na enkapsulację,
  • direct routing – pełny MTU pod warunkiem poprawnej konfiguracji underlay,
  • host networking – jak ruch hosta; potencjalnie najwyższa wydajność, ale częściej ograniczona innymi czynnikami.

Jeżeli środowisko wymaga przejrzystej integracji z istniejącymi firewallami i systemami DLP, a jednocześnie zespół nie ma wpływu na konfigurację routerów, overlay będzie kompromisem, ale z wyższym kosztem operacyjnym. Jeśli organizacja posiada silny zespół sieciowy i nowoczesną infrastrukturę L3, direct routing pozwala uprościć model i zyskać wymierne korzyści wydajnościowe.

Przegląd popularnych CNI – kryteria wyboru pod konkretne środowisko

Calico – BGP, IP-in-IP i network policy w jednym

Calico to jedno z najbardziej rozpowszechnionych rozwiązań CNI w środowiskach, gdzie kluczowe są: network policy, elastyczność wyboru modelu sieci (overlay vs direct routing) i integracja z istniejącym routingiem. Operuje głównie na poziomie L3/L4, ale w nowszych wersjach oferuje także funkcje oparte o eBPF.

Możliwe tryby pracy Calico:

• IP-in-IP / VXLAN – klasyczny overlay, sensowny na start, gdy zespół nie ma jeszcze dogadanej integracji z routerami,
• BGP direct routing – każdy node ogłasza podsieć podów przez BGP do routerów lub do innych node’ów (full-mesh lub route reflectors),
• eBPF dataplane – uproszczona ścieżka pakietu, mniejsza zależność od iptables, korzyści wydajnościowe i funkcje typu DSR.

Kryteria audytu dla Calico:

• czy jest jasno zdefiniowany datastore (etcd vs CRD Kubernetes) i kto odpowiada za jego backup,
• czy tryb enkapsulacji (IPIP/VXLAN) jest spójny we wszystkich klastrach i udokumentowany wraz z MTU,
• czy BGP jest skonfigurowane z pełną świadomością limitów routerów i topologii sieci (route reflectors, filtry, communities).

Jeśli w jednym środowisku występują klastry Calico w trybie IPIP, inne w VXLAN, a w dokumentacji nie ma ani jednej wzmianki o MTU i BGP, jest to sygnał ostrzegawczy, że rozwój kolejnych klastrów będzie napędzany lokalnymi decyzjami administratorów, a nie spójną strategią sieciową.

Cilium – eBPF, obserwowalność i polityki warstwy 7

Cilium opiera się na eBPF jako głównym mechanizmie realizacji polityk i ścieżki danych. Oferuje zarówno overlay (VXLAN/Geneve), jak i tryby z direct routingu, a także rozbudowany zestaw funkcji bezpieczeństwa (L3–L7), w tym polityki na poziomie HTTP, DNS i identyfikatorów usług zamiast samych adresów IP.

Kluczowe elementy Cilium z punktu widzenia audytu:

• dataplane eBPF – wymaga kernelów o odpowiedniej wersji i konfiguracji (m.in. BPF, XDP); stare systemy mogą wymagać aktualizacji lub ograniczonego trybu,
• wielowarstwowe polityki – możliwość pisania policy nie tylko po IP/portach, ale także po nazwach usług, metodach HTTP, nazwach DNS,
• Hubble – moduł obserwowalności z widocznością przepływów, przyczyn dropów i szczegółowym tracingiem sieciowym.

Punkty kontrolne przed wyborem Cilium:

• czy zespół systemowy zaakceptował wymagania kernelowe (wersja, konfiguracja, polityka aktualizacji),
• czy istnieje plan na monitoring eBPF (limity map BPF, pamięć, CPU) i integrację z istniejącym Prometheusem,
• czy organizacja ma proces tworzenia i review polityk L7 (HTTP, gRPC), czy też dotychczas wszystko opierało się wyłącznie na IP/portach.

Jeżeli decyzja o wdrożeniu Cilium jest motywowana wyłącznie „modą” na eBPF, a jednocześnie produkcyjne node’y działają na przestarzałych kernelach bez wsparcia wymaganych funkcji, projekt będzie od początku obciążony technicznym długiem i obejściami konfiguracji.

Flannel – prostota kosztem funkcji

Flannel to lekki, prosty plugin CNI, często używany w małych lub testowych klastrach oraz w dystrybucjach typu „all-in-one” (kubeadm, k3s w części trybów). Zapewnia podstawową łączność L3 między podami z wykorzystaniem kilku backendów (VXLAN, host-gw, UDP), ale nie oferuje własnego silnika network policy.

Charakterystyka Flannel:

• niski próg wejścia – minimum konfiguracji, sensowny wybór dla prostych środowisk bez złożonych wymagań bezpieczeństwa,
• brak natywnego wsparcia network policy – polityki trzeba realizować innym mechanizmem (np. dodatkowy plugin, rozwiązania hostowe),

Weave Net – prosty overlay z wbudowanym szyfrowaniem

Weave Net skupia się na prostocie wdrożenia i minimalnej ingerencji w infrastrukturę. Tworzy mesh między node’ami z wykorzystaniem własnego protokołu enkapsulacji (UDP/TCP), z opcjonalnym szyfrowaniem ruchu. Z punktu widzenia operatora jest to przede wszystkim overlay: każdy node dostaje swój zakres adresów podów, a Weave zajmuje się ich dystrybucją i tunelowaniem.

Charakterystyczne cechy Weave Net:

• proste uruchomienie – deployment jako DaemonSet, niewielka liczba parametrów startowych,
• mesh między node’ami – brak zależności od BGP lub centralnych routerów, wystarczy L3 connectivity,
• wbudowane szyfrowanie – możliwość włączenia IPsec-owego szyfrowania ruchu między node’ami bez dodatkowych komponentów,
• podstawowe wsparcie network policy – policy realizowane na poziomie Weave (iptables), nie tak rozbudowane jak w Calico czy Cilium.

Punkty kontrolne przy audycie Weave Net:

• czy szyfrowanie ruchu jest włączone i jaki ma wpływ na CPU node’ów przy typowym obciążeniu,
• jaka jest konfiguracja MTU w Weave i czy jest skoordynowana z ścieżką underlay (szczególnie w środowiskach z VPN/MPLS),
• czy liczba node’ów i ich rozmieszczenie (regiony, strefy) nie powodują tworzenia zbyt dużych meshów z wieloma hopami overlay,
• czy wymagania na network policy nie przekraczają realnych możliwości Weave (złożone reguły, integracja z narzędziami compliance).

Jeśli Weave jest wykorzystywany na dużą skalę, a jednocześnie brak jakiejkolwiek analizy wpływu szyfrowania na wydajność, to przy wzroście ruchu sieć stanie się niewidzialnym konsumentem CPU, trudnym do powiązania z konkretną zmianą konfiguracyjną.

Pluginy chmurowe (AWS VPC CNI, Azure CNI, GKE) – integracja z natywną siecią VPC/VNet

Natomiast w managed Kubernetes (EKS, AKS, GKE) lub w środowiskach budowanych ściśle pod konkretną chmurę publiczną, często wybierane są pluginy CNI dostarczane lub rekomendowane przez dostawcę. Ich głównym celem jest mapowanie podów bezpośrednio na adresy IP z VPC/VNet, co upraszcza integrację z istniejącymi security group, firewallami i systemami monitoringu ruchu.

Typowe cechy pluginów chmurowych:

• pod IP z puli VPC/VNet – brak dodatkowego overlay dla ruchu wewnątrz VPC, uproszczony model routingu,
• głęboka integracja z kontrolerami chmury – dynamiczne alokowanie ENI, adresów sekundarnych, route table,
• ograniczenia skali wynikające z platformy – limity ENI per instancja, liczba IP na interfejs, ograniczenia w liczbie tras,
• pełna widoczność ruchu w natywnych narzędziach (VPC Flow Logs, NSG Flow Logs), przydatna dla SOC i compliance.

Punkty kontrolne dla AWS VPC CNI, Azure CNI, GKE:

• czy policzono realny limit podów na node wynikający z liczby ENI/IP wspieranych przez typ maszyny,
• czy istnieje plan na zużycie adresacji VPC/VNet, zwłaszcza w środowiskach wieloklastrów,
• czy architektura zakłada ruch międzyklastrowy i w jaki sposób będzie on routowany (VPC peering, Transit Gateway, Private Link),
• czy team bezpieczeństwa rozumie, że polityki na poziomie Security Group/NSG działają na IP podów, a nie tylko node’ów.

Jeżeli w dużej organizacji każda aplikacja otrzymuje osobny klaster w tej samej VPC/VNet, a plugin CNI zużywa IP z tej samej puli co instancje, to brak długoterminowego planu adresacji jest prostą drogą do fragmentacji przestrzeni adresowej i blokady kolejnych projektów.

Multus i CNI wielokrotne – gdy jeden plugin to za mało

Multus CNI działa jako „meta-CNI”: pozwala przydzielać wiele interfejsów sieciowych do jednego poda, z różnymi pluginami CNI. Typowy scenariusz to aplikacje telco (5G), NFV lub środowiska z wymogiem oddzielnych sieci (np. zarządzania, storage, data plane) na poziomie samego poda.

Typowe zastosowania Multus:

• pod ma główne połączenie z siecią klastra (np. Calico, Cilium) oraz dodatkowy interfejs do sieci storage,
• aplikacje wymagające bezpośredniego dostępu do SR-IOV lub DPDK, z pominięciem standardowego stosu sieciowego hosta,
• wyraźne rozdzielenie ruchu „user plane” i „control plane” w aplikacjach krytycznych.

Punkty kontrolne dla środowisk z Multus:

• czy jest jednoznacznie zdefiniowany primary CNI dla ruchu klastra i czy jego polityki nie kolidują z dodatkowymi interfejsami,
• jak wygląda plan adresacji dla dodatkowych sieci i kto zarządza tymi pulami (zespół sieciowy, storage, aplikacyjny),
• czy zespół operacyjny ma procedury debugowania dla poda z wieloma interfejsami (tcpdump, iproute2, policy routing),
• czy monitoring (Prometheus, siem) zbiera metryki i logi z wszystkich interfejsów, a nie tylko domyślnego.

Jeżeli Multus został dodany „dla jednej aplikacji specjalnej”, a później kolejne zespoły zaczęły z niego korzystać bez centralnego nadzoru, w krótkim czasie powstanie trudno zarządzalne zoo sieci, w którym nawet proste pytanie „którędy idzie ruch X” przestaje mieć jednoznaczną odpowiedź.

Kryteria doboru CNI do środowiska – perspektywa audytu

Przy wyborze pluginu CNI warto od razu przyjąć perspektywę kilkuletniego horyzontu, a nie tylko pierwszego wdrożenia. Intuicyjne „działa – to wystarczy” często kończy się bolesną migracją sieci po osiągnięciu pewnej skali lub zmianie wymagań bezpieczeństwa.

Podstawowe kryteria doboru CNI:

• model integracji z infrastrukturą:
  • czy sieć ma być maksymalnie niezależna od routerów (overlay), czy ma się spinać bezpośrednio z istniejącym routingiem (BGP, VPC routing),
  • czy zespół sieciowy akceptuje, że routing podów będzie widoczny w infrastrukturze „pod spodem”,
  • jakie są ograniczenia organizacyjne: brak dostępu do routerów, zewnętrzny operator underlay, ścisłe reguły change management.
• wymagania bezpieczeństwa:
  • czy potrzebne są network policy L3/L4, czy również L7 (HTTP, DNS),
  • czy polityki mają być centralnie zarządzane (np. GitOps, dedykowany zespół) czy zostaną rozproszone po zespołach aplikacyjnych,
  • jakie są wymogi audytowe: rejestrowanie flow, integracja z SIEM, granularne logi dropów.
• dojrzałość zespołu i operacyjność:
  • czy zespół ma kompetencje BGP/eBPF, czy bardziej pasuje mu prosty overlay,
  • jak wyglądają procedury debugowania (on-call, runbooki) – czy obejmują warstwę sieciową klastra,
  • czy istnieje centralny owner sieci Kubernetes, czy odpowiedzialność jest rozmyta między wiele zespołów.
• ograniczenia techniczne:
  • wersje i konfiguracje kernelów na node’ach (eBPF, XDP, iptables/nftables),
  • limity TCAM/FIB na routerach, liczba tras BGP, możliwości route reflectorów,
  • pula adresowa w VPC/VNet i w sieci on-prem, polityka NAT, MPLS/VPN.
• koszt zmiany w przyszłości:
  • jak trudna jest migracja z danego CNI na inne (np. Flannel → Calico, overlay → BGP),
  • czy istnieje plan wycofania i testy pilotażowe migracji w mniejszym klastrze,
  • jak duże jest uzależnienie aplikacji od specyficznych funkcji danego CNI (np. zaawansowane L7 policy).

Jeżeli w dokumentacji projektu wyboru CNI dominują zapisy typu „bo jest domyślny w dystrybucji X” lub „bo w innym projekcie też użyliśmy”, a brakuje choćby prostego porównania na powyższych osiach, to jest to czytelny sygnał ostrzegawczy dla właścicieli ryzyka technicznego.

Minimalne wymagania na dokumentację i standardy sieci CNI

Niezależnie od wybranego pluginu CNI, kluczowa jest spójna dokumentacja i zbiór standardów, które będą stosowane w każdym klastrze. Brak formalnych ustaleń powoduje, że po kilku latach organizacja ma kilka–kilkanaście klastrów, z których każdy zbudowano inaczej, na podstawie lokalnych decyzji pojedynczych administratorów.

Lista elementów, które powinny być opisane co najmniej na poziomie organizacyjnym (nie tylko „w głowie admina”):

• wybrany CNI i tryb pracy:
  • overlay vs direct routing vs plugin chmurowy,
  • parametry: typ enkapsulacji (VXLAN/IPIP/Geneve), MTU, szyfrowanie.
• plan adresacji:
  • zakresy podCIDR na klaster i na node,
  • relacja do istniejących prefixów w LAN/WAN/VPC (brak kolizji, trasy zwrotne),
  • zasady przydzielania nowych zakresów przy kolejnych klastrach.
• integracja z infrastrukturą:
  • routery/VRF, z którymi łączą się klastry (BGP, static, VPC routing),
  • firewalle, przez które przechodzi ruch pod ↔ systemy zewnętrzne,
  • narzędzia monitoringu i logowania (NetFlow, VPC Flow Logs, Hubble, Calico flow logs).
• standardy network policy:
  • minimalny zestaw polityk „baseline” (blokada ruchu east–west, egress control),
  • konwencje nazewnicze i zasady review (kto zatwierdza zmiany policy),
  • powiązanie polityk z klasyfikacją informacji (strefy bezpieczeństwa, poziomy zaufania).
• procedury operacyjne:
  • runbooki debugowania typowych problemów (brak łączności pod–pod, pod–service, service–external),
  • zasady zmiany parametrów CNI (MTU, typ enkapsulacji, BGP peers) i ich testowania,
  • procedury awaryjne przy awarii datastore CNI (np. etcd/CRD dla Calico).

Jeżeli audyt ujawnia kilka klastrów tej samej organizacji z różnymi, niespójnymi konfiguracjami CNI oraz bez wspólnych standardów dokumentacyjnych, każdy kolejny incydent sieciowy będzie rozwiązywany ad hoc, a czas przywracania usług będzie zależał głównie od dostępności „lokalnego eksperta” dla danego klastra.

Typowe problemy operacyjne i wzorce antywzorów w sieci Kubernetes

Niezależnie od wyboru konkretnego CNI, w praktyce powtarza się określony zestaw błędów konfiguracyjnych i antywzorów projektowych. Stanowią one dobry punkt kontrolny przy przeglądzie istniejących klastrów.

Najczęściej spotykane problemy:

• ignorowanie MTU:
  • brak dostosowania MTU w overlay do underlay (szczególnie w środowiskach z VPN, IPsec, MPLS),
  • aplikacje korzystające z dużych MSS (np. bazy danych, replikacja) zaczynają doświadczać „dziwnych” timeoutów,
  • brak testów z pakietami o rozmiarze zbliżonym do MTU (ping -s, tracepath).
• ukryte zależności od iptables/nftables:
  • ręczne modyfikacje iptables na node’ach, które kolidują z regułami generowanymi przez CNI,
  • narzędzia bezpieczeństwa hosta (np. agent EDR) wstrzykujące własne reguły bez świadomości o CNI,
  • mieszanie różnych frameworków (iptables i nftables) bez pełnego zrozumienia ich interakcji.
• nadmierne użycie hostNetwork:
  • podstawowe serwisy aplikacyjne uruchamiane w hostNetwork, aby „ominąć problemy sieciowe”,