IP i kontenery: sieci w Dockerze i Kubernetesie, CNI, pod CIDR

Wraz z rosnącą rolą konteneryzacji w nowoczesnym tworzeniu aplikacji, zarządzanie adresami IP w środowiskach kontenerowych stało się kluczowym wyzwaniem wymagającym wiedzy i planowania. Efektywne IPAM w Docker i Kubernetes zapewnia skalowalność, bezpieczeństwo oraz wydajność w dynamicznym, efemerycznym środowisku, gdzie kontenery są często tworzone i usuwane. W odróżnieniu od tradycyjnych sieci, kontenery wymagają zautomatyzowanych, dynamicznych strategii przydzielania IP. Niniejszy materiał wyjaśnia, jak Docker i Kubernetes implementują IPAM, omawia standard Container Network Interface (CNI), mechanizmy alokacji pod CIDR oraz popularne wtyczki i podejścia sieciowe.

Architektura sieci Docker i zarządzanie adresami IP

Docker oferuje zestaw trybów i sterowników sieciowych, zarządzając adresami IP poprzez mechanizmy wbudowane lub zewnętrzne. Zrozumienie modelu Dockera jest fundamentem dla pojęcia, jak Kubernetes rozwiązuje to samo zagadnienie w większej skali. System sieciowy Dockera opiera się na Container Network Model (CNM).

Trzy elementy CNM i ich role przedstawiają się następująco:

• sandbox – izolowany stos sieciowy kontenera (interfejsy, routing, DNS);
• endpoint – wirtualny interfejs łączący sandbox z siecią;
• network – grupa endpointów mogących się ze sobą komunikować.

Te abstrakcje zapewniają elastyczność i pozwalają łączyć kontenery zgodnie z wymaganiami aplikacji.

Sieci bridge i przydzielanie adresów IP na pojedynczym hoście

Domyślny sterownik bridge ilustruje podstawowe zasady IPAM na pojedynczym hoście. Docker tworzy domyślną sieć bridge i automatycznie przydziela kontenerom adresy z zdefiniowanej podsieci. Dokumentacja zaleca jednak sieci bridge definiowane przez użytkownika.

Najważniejsze korzyści z sieci bridge definiowanych przez użytkownika to:

• automatyczna komunikacja oparta na DNS między kontenerami,
• lepsza izolacja dzięki segmentacji sieci,
• elastyczne dołączanie/odłączanie kontenerów bez ich zatrzymywania.

Tworząc własną sieć bridge, można określić podsieć w notacji CIDR, a wbudowany sterownik IPAM przydzieli adresy IP z tej puli. Np. polecenie docker network create --subnet=192.168.0.0/16 my_custom_network alokuje adresy z zakresu 192.168.0.0/16. Sterowniki IPAM definiują zakresy IP i zapobiegają konfliktom adresów, a wbudowany DNS eliminuje konieczność operowania „twardymi” adresami.

Tryby sieci host i none

Tryb host udostępnia stos sieciowy hosta, przez co kontener używa tego samego adresu IP co węzeł. Zwiększa to wydajność i upraszcza ekspozycję portów kosztem izolacji. Tryb none tworzy jedynie loopback, zapewniając pełną izolację — przydatne w zadaniach wsadowych lub gdy łączność realizuje proces zewnętrzny.

Sieci overlay do komunikacji między hostami

Sterownik overlay umożliwia łączność kontenerów na wielu hostach Dockera poprzez sieć wirtualną opartą o VXLAN. W klastrze Docker Swarm można tworzyć sieci overlay dla usług, a IPAM Dockera alokuje adresy z zadanej podsieci na wszystkich węzłach. Takie sieci zapewniają wbudowane odkrywanie usług, równoważenie obciążenia i szyfrowanie.

Zaawansowane sterowniki sieci Docker

Sterowniki ipvlan i macvlan przydzielają adresy z tej samej puli co host, dzięki czemu kontenery wyglądają jak urządzenia fizyczne w sieci. Ipvlan upraszcza routowanie bez mapowania portów, a macvlan nadaje unikalny adres MAC dla interfejsu kontenera. Korzyści wydajnościowe wymagają poprawnej konfiguracji i wsparcia po stronie infrastruktury.

Standard i specyfikacja Container Network Interface (CNI)

Container Network Interface (CNI) standaryzuje interfejs między runtime kontenerów a wtyczkami sieciowymi. Runtime deleguje zadania sieciowe do zewnętrznych wtyczek, co przyspiesza innowacje i pozwala dobrać rozwiązanie pod konkretne potrzeby.

CNI definiuje trzy kluczowe aspekty, które warto mieć na uwadze:

• format konfiguracji sieci (JSON) oraz dyrektywy dla runtime i wtyczek,
• protokół wywoływania wtyczek i przekazywania parametrów,
• jasny podział odpowiedzialności, dzięki któremu runtime’y pozostają agnostyczne wobec implementacji.

Architektura CNI i typy wtyczek

Wtyczki CNI dzielą się na wtyczki network (łączność, routing, bridge/overlay) i wtyczki IPAM (alokacja puli, śledzenie adresów, unikanie kolizji). Protokół CNI wywołuje binaria wtyczek; konfiguracja trafia przez stdin, parametry przez zmienne środowiskowe, a wynik jako JSON na stdout. Niektóre projekty (np. Calico) dostarczają pełen zestaw: łączność + IPAM, inne (np. Flannel) skupiają się na łączności.

Kluczowe zmienne środowiskowe przekazywane do wtyczek to:

• CNI_COMMAND – typ operacji (ADD/DEL),
• CNI_CONTAINERID – identyfikator kontenera,
• CNI_NETNS – ścieżka do przestrzeni nazw sieci,
• CNI_IFNAME – nazwa interfejsu w kontenerze.

Konfiguracja CNI i parametry czasu wykonywania

Statyczna konfiguracja CNI zawiera cniVersion, name, type oraz sekcję ipam z zasadami alokacji adresów. Dzięki spójności interfejsu każdy runtime zgodny z CNI (Docker z obsługą CNI, containerd, CRI-O, Kubernetes) może używać dowolnej wtyczki.

Podstawy sieci Kubernetes i wielowarstwowe zarządzanie adresami IP

Kubernetes zarządza adresacją IP na wielu warstwach i w skali wielu węzłów, jednocześnie zapewniając prosty model łączności.

Fundamentalne wymagania modelu sieci Kubernetes są następujące:

• wszystkie pody komunikują się ze wszystkimi innymi podami bez NAT,
• węzły komunikują się ze wszystkimi podami na węźle bez NAT,
• adres IP widziany przez poda jest spójny z tym, co widzą inne pody i węzły,
• komunikacja między podami odbywa się bezpośrednio po ich adresach IP.

Kubernetes deleguje implementację do wtyczek CNI, a sam zarządza trzema odrębnymi pulami IP: węzłów, podów i usług. Zakresy te nie mogą się pokrywać — ich planowanie ma krytyczne znaczenie dla stabilności klastra.

Pod CIDR – alokacja, konfiguracja i łączność między węzłami

Pod CIDR to globalny zakres dla adresów IP podów. Ustalany np. przy inicjalizacji klastra kubeadm init --pod-network-cidr=192.168.0.0/16, zwykle w prywatnych zakresach RFC 1918. Poprawna konfiguracja pod CIDR decyduje o komunikacji pod–pod.

Globalny pod CIDR dzieli się na mniejsze podsieci przypisywane poszczególnym węzłom (np. 10.1.0.0/16 → węzły: 10.1.1.0/24, 10.1.2.0/24). Podziałem zarządza zwykle kube-controller-manager wraz z wtyczką CNI, zapewniając unikalność bloków. Rozmiar bloku zależy od limitu podów na węzeł (np. przy ~110 podach na węzeł typowe są bloki /24).

Strategie alokacji pod CIDR i ograniczenia

Gęstość podów na węźle wpływa na rozmiar podsieci i pojemność całego klastra. Większe bloki (np. /23) zwiększają gęstość na węźle, ale zmniejszają maksymalną liczbę węzłów, co wymaga świadomego kompromisu.

Najczęstsze błędy planistyczne, których warto unikać:

• nakładanie się pod CIDR z siecią infrastruktury lub łączami międzydomenowymi,
• zbyt małe bloki per węzeł względem docelowej gęstości podów,
• pokrywanie się zakresów pod CIDR, service CIDR i adresacji węzłów.

W środowiskach korporacyjnych spójność i brak kolizji zakresów ma krytyczne znaczenie dla łączności z systemami legacy.

Service CIDR i alokacja adresów ClusterIP

Oddzielny service CIDR służy do alokacji wirtualnych adresów IP obiektów Service. Konfiguruje się go parametrem --service-cluster-ip-range w kube-apiserver. Adresy usług są wewnętrzne i służą do równoważenia ruchu na pody zaplecza. Alokacja dzieli zakres na pasmo statyczne i dynamiczne, co ułatwia bezkolizyjne rezerwacje.

Od Kubernetes 1.33 rodziny adresów usług odzwierciedla obiekt ServiceCIDR o nazwie kubernetes, który musi być spójny we wszystkich instancjach kube-apiserver. Zmiana service CIDR to operacja złożona i może wymagać ponownej numeracji usług, w tym kubernetes.default.

Popularne wtyczki CNI i ich podejścia do zarządzania adresami IP

Ekosystem Kubernetes oferuje wiele wtyczek CNI o różnych kompromisach między prostotą, wydajnością, politykami i integracją z chmurą. Dobór rozwiązania powinien wynikać z wymagań aplikacji i środowiska.

Flannel – prosta i przystępna sieć warstwy 3

Flannel tworzy nakładkową sieć IPv4 (warstwa 3), przydzielając każdemu węzłowi podsieć dla podów. Ruch między węzłami jest enkapsulowany (np. w VXLAN), a na tym samym hoście pody komunikują się przez lokalny bridge. Flannel słynie z prostoty wdrożenia (pojedynczy flanneld) i niskiego progu wejścia.

To dobre rozwiązanie dla małych i średnich klastrów, gdzie liczy się prostota i mała złożoność operacyjna. Nie zapewnia jednak tak rozbudowanych polityk i wydajności, jak bardziej zaawansowane wtyczki.

Calico – zaawansowane polityki i routowanie z BGP

Calico oferuje bogate polityki sieciowe, segmentację i elastyczne opcje trasowania (w tym BGP). Dostarcza wtyczki sieciowe i IPAM, integruje się z chmurami (AWS, Azure, Google Cloud). W trybie routowanym (bez enkapsulacji) może zapewniać lepszą wydajność niż overlay, jeśli sieć na to pozwala.

Calico sprawdza się w dużych, wymagających środowiskach z rygorystycznymi politykami. Obsługuje tryb overlay i bez-overlay oraz może selektywnie enkapsulować ruch między podsieciami. Zaawansowane możliwości wymagają większego doświadczenia operacyjnego.

Weave, Canal i inne rozwiązania

Weave Net buduje siatkę overlay z komponentami routującymi na każdym węźle i dynamicznym uczeniem topologii. Canal łączy prostotę Flannel z politykami Calico, stanowiąc kompromis między łatwością użycia a funkcjonalnością.

Coraz popularniejsze jest Cilium z eBPF (wysoka wydajność i obserwowalność) oraz wtyczki chmurowe: AWS VPC CNI, Azure CNI, Google Cloud CNI, które integrują adresację podów z natywną siecią chmury.

Dla szybkiego porównania najważniejszych cech wybranych wtyczek zobacz poniższą tabelę:

Wtyczka	Podejście	IPAM	Polityki sieciowe	Wydajność	Najlepiej do
Flannel	Overlay (VXLAN)	Prosty, wbudowany	Brak (samodzielnie)	Średnia	Małe/średnie klastry, prostota
Calico	Routed L3 (BGP) lub overlay	Wbudowany lub zewnętrzny	Zaawansowane (NetworkPolicy/GlobalPolicy)	Wysoka (zwł. bez overlay)	Duże klastry, silne bezpieczeństwo
Weave Net	Overlay (siatka)	Wbudowany	Podstawowe	Średnia	Elastyczne topologie, łatwość wdrożenia
Cilium	eBPF (routed/overlay)	Wbudowany	Zaawansowane + obserwowalność	Wysoka	Wydajność, widoczność ruchu
AWS VPC CNI	Natywna sieć VPC (bez overlay)	Natywny (ipamd)	Przez Security Groups	Bardzo wysoka	Klastry w Amazon EKS

Amazon VPC CNI – zintegrowane z chmurą zarządzanie adresami IP

Amazon VPC CNI przydziela adresy IP bezpośrednio z VPC, dzięki czemu pody mają natywne adresy routowalne w sieci chmurowej. Wtyczka składa się z binarium CNI oraz demona ipamd, który zarządza ENI i utrzymuje „ciepłe” pule slotów IP. Prealokacja przyspiesza start podów i stabilizuje zmiany w regułach ruchu.

Najważniejsze korzyści w praktyce:

• natywne adresy IP w VPC dla podów (brak dodatkowych warstw overlay),
• możliwość przypisywania Security Groups do podów,
• łatwa integracja z routingiem i obserwowalnością VPC.

Rozmiary podsieci i limity ENI/slotów na typ instancji determinują maksymalną liczbę podów na węzeł, co wymaga starannego doboru puli adresów.

Polityki sieciowe i bezpieczeństwo w zarządzaniu adresami IP

Polityki sieciowe pozwalają precyzyjnie kontrolować ruch do/od podów na poziomie adresów IP i portów, realizując segmentację opartą na aplikacjach. Domyślnie (bez polityk) cały ruch jest dozwolony; często stosuje się wzorzec default-deny i selektywne zezwolenia.

Wsparcie polityk zależy od wtyczki CNI. Reguły mogą wykorzystywać selektory etykiet podów/przestrzeni nazw oraz bloki CIDR dla adresów zewnętrznych. Polityki oparte na selektorach są odporne na efemeryczność adresów IP, bo odnoszą się do etykiet, a nie wartości IP.

DNS i odnajdywanie usług w kontenerowych sieciach IP

Kubernetes dostarcza CoreDNS do rozwiązywania nazw usług i podów, dzięki czemu aplikacje nie muszą znać konkretnych IP. Przykładowe nazwy: usługa my-svc.my-namespace.svc.cluster.local, pod pod-ip-address.my-namespace.pod.cluster.local. Warstwa DNS oddziela aplikacje od adresów IP, upraszczając skalowanie i migracje podów.

Lista wyszukiwania DNS uwzględnia przestrzeń nazw poda oraz domenę klastra, co ułatwia odwołania krótkimi nazwami w obrębie namespace i FQDN między przestrzeniami.

Zaawansowane scenariusze sieciowe i zagadnienia multiklastrowe

Coraz częściej wdrożenia obejmują wiele klastrów i wymagają koordynacji łączności ponad granicami. Federacja Kubernetes porządkuje zarządzanie, ale każdy klaster utrzymuje własną infrastrukturę sieciową.

Najczęstsze podejścia do łączności wieloklastrowej obejmują:

• rozszerzenie możliwości CNI na wiele klastrów (np. Cilium ClusterMesh),
• wykorzystanie bram wyjściowych (egress gateway) i zaawansowanego trasowania między lokalnym DC a chmurami,
• zastosowanie SNAT, gdy zakresy pod CIDR nie są globalnie routowalne.

Praktyczne kwestie zarządzania adresami IP

Sukces IPAM zaczyna się od planowania zakresów i gęstości podów oraz świadomego wyboru wtyczki CNI. Zakresy pod CIDR nie mogą kolidować z infrastrukturą; service CIDR powinien przewidywać wzrost liczby usług; a wybrana wtyczka CNI musi odpowiadać wymaganiom wydajności i bezpieczeństwa.

Lista kontrolna przy projektowaniu adresacji w klastrze:

• uzgodnij z zespołem sieciowym niekolidujące zakresy pod CIDR, service CIDR i adresację węzłów,
• dobierz limit podów na węzeł i wynikowy rozmiar bloku per węzeł,
• zapewnij zapas adresów dla pików obciążenia i rolloutów,
• wybierz wtyczkę CNI pod kątem polityk, wydajności i integracji z chmurą,
• wdroż monitoring puli adresów i alerty przed wyczerpaniem.

Efemeryczność adresów IP podów wymaga projektowania aplikacji pod odkrywanie usług, a nie „twarde” IP. Narzędzia obserwowalności powinny śledzić alokacje i proaktywnie wykrywać zbliżające się wyczerpanie puli.