Vanilla Kubernetes

Prethodne lekcije izgradile su workload platformu: Pod je izvršna jedinica, Service daje stabilan identitet grupi promenljivih backend-a, a scheduler bira čvor na kome će novi Pod raditi. Od ovog trenutka pitanje više nije samo gde je Pod raspoređen, već kako dobija mrežni interfejs i adresu, kako paket stiže do drugog Poda i ko je odgovoran kada veza ne radi. Kubernetes definiše željeni mrežni model, ali njegov data plane ne implementira sam. Tu odgovornost preuzima mrežni dodatak, najčešće CNI-kompatibilno rešenje povezano sa container runtime-om i operativnim sistemom čvora.

Mreža klastera nije jedna funkcija niti jedan proces. Ona obuhvata network namespace Poda, virtuelne interfejse, IPAM, rute ili enkapsulaciju između čvorova, filtriranje saobraćaja, node firewall, fizičku ili virtuelnu underlay mrežu, DNS i odvojeni Service data plane. Zato poruka „CNI problem” nije dijagnoza. Odgovoran administrator najpre određuje ravan kvara, putanju paketa i granicu vlasništva, pa tek onda menja konfiguraciju.

Kubernetes mrežni model – ugovor koji implementacija mora da ispuni

Osnovni Kubernetes model polazi od toga da svaki Pod dobija jedinstvenu adresu u opsegu klastera i sopstveni network namespace. Svi aplikacioni kontejneri u istom Podu dele taj namespace, IP adresu, interfejse i tabelu ruta, pa međusobno razgovaraju preko localhost i moraju uskladiti portove. Između različitih podova očekuje se direktna IP komunikacija bez obaveze da aplikacija sama prevodi adrese. Node agenti i procesi na čvoru takođe moraju moći da komuniciraju sa podovima, uz izuzetke koje konkretna platforma dokumentuje.

Pod IP je identitet jedne instance, ne trajna adresa aplikacije. Kada Pod bude zamenjen, nova instanca može dobiti drugu adresu; stabilnost obezbeđuju Service i DNS, koji se detaljnije obrađuju u narednim lekcijama. Host-network Pod predstavlja svesno odstupanje: sa hostNetwork: true deli mrežni prostor čvora, nasleđuje njegovu površinu napada i može izazvati konflikt host portova. To nije univerzalni lek za neispravan CNI.

Od Pod sandbox-a do mrežnog interfejsa

Kubelet preko CRI-ja traži od container runtime-a da napravi Pod sandbox. Runtime kreira ili priprema network namespace i poziva konfigurisan CNI lanac. Plugin dobija operaciju, identitet kontejnera, putanju namespace-a, željeno ime interfejsa i mrežnu konfiguraciju. IPAM komponenta bira adresu i vraća adresu, gateway i rute; glavni plugin pravi ili priključuje interfejs, postavlja ga u namespace i programira potrebni lokalni data plane. Tek kada mrežna priprema uspe, sandbox može preći u spremno stanje i aplikacioni kontejneri mogu biti pokrenuti.

kubelet
  │  CRI: RunPodSandbox
  ▼
container runtime
  │  CNI ADD + JSON konfiguracija
  ▼
CNI lanac ──► IPAM ──► interfejs, IP adresa, gateway i rute
  │
  └────────► node/cluster data plane

Pri brisanju sandbox-a runtime poziva CNI DEL kako bi plugin uklonio mrežne resurse i oslobodio adresu. CNI specifikacija takođe definiše CHECK za proveru postojećeg stanja i VERSION za pregovaranje podržane verzije, ali podrška i stvarna upotreba CHECK operacije zavise od runtime-a i plugin-a. Ne treba je pretpostaviti kao univerzalni Kubernetes health check.

Na Linux čvorovima konfiguracije se često nalaze u /etc/cni/net.d, a izvršni plugin-i u /opt/cni/bin, ali obe putanje mogu biti promenjene runtime konfiguracijom ili načinom instalacije. Redosled i izbor konfiguracije takođe pripadaju runtime implementaciji. Zbog toga se fajlovi ne menjaju ručno dok se ne utvrdi ko ih održava: kubeadm dodatak, paket menadžer, operator, Helm release, GitOps kontroler ili image-based node konfiguracija.

CNI specifikacija i odgovornost mrežnog dodatka

CNI je specifikacija poziva i formata konfiguracije, a ne naziv jedne Kubernetes mreže. Ona opisuje kako runtime izvršava plugin-e i kako oni vraćaju rezultat; ne propisuje da li će klaster koristiti bridge, BGP, VXLAN, Geneve, eBPF ili cloud-native rutiranje. Produkciono „CNI rešenje” obično je širi sistem: node agent, kontroleri, CRD objekti, IPAM, policy engine, observability i ponekad zamena za kube-proxy. Njegove mogućnosti nisu jednake samoj CNI specifikaciji.

Konfiguraciona lista može ulančati više plugin-a: jedan obezbeđuje osnovni interfejs, drugi podešava port mapping ili bandwidth capability, a IPAM se poziva kao delegirani plugin. Polje cniVersion mora biti kompatibilno sa runtime-om i svim elementima lanca. Primer je ilustrativan; ne kopira se preko konfiguracije produkcionog dodatka:

{
  "cniVersion": "1.0.0",
  "name": "lab-network",
  "plugins": [
    {
      "type": "bridge",
      "bridge": "cni0",
      "isGateway": true,
      "ipMasq": true,
      "ipam": {
        "type": "host-local",
        "ranges": [[{"subnet": "10.244.1.0/24"}]],
        "routes": [{"dst": "0.0.0.0/0"}]
      }
    },
    {
      "type": "portmap",
      "capabilities": {"portMappings": true}
    }
  ]
}

Produkcioni dodatak treba instalirati isključivo njegovim podržanim postupkom i verzijom sertifikovanom za ciljnu Kubernetes, kernel i runtime kombinaciju. Dva primarna CNI rešenja ne smeju nekontrolisano upravljati istim default Pod interfejsom. Migracija menja data plane čitavog klastera i zahteva dokumentovan redosled po čvorovima, drain, proveru postojećih podova i povratni plan; prosta zamena fajla u /etc/cni/net.d može ostaviti čvor sa mešanim stanjem.

IPAM, Pod CIDR i sprečavanje preklapanja

IP Address Management dodeljuje i oslobađa Pod adrese. U čestom modelu svaki Node dobija sopstveni spec.podCIDR, a lokalni IPAM izdaje adrese iz tog opsega. Drugi dodaci koriste centralizovani pool, cloud subnet, CRD blokove ili više pool-ova. Prisustvo spec.podCIDR zato ne dokazuje da ga aktivni dodatak zaista koristi. Izvor istine utvrđuje se iz zvanične konfiguracije konkretnog rešenja.

# Read-only: API pogled na dodeljene Node Pod CIDR opsege
kubectl get nodes \
  -o custom-columns='NODE:.metadata.name,POD_CIDR:.spec.podCIDR,POD_CIDRS:.spec.podCIDRs'

# Read-only: stvarne adrese podova i čvorovi na kojima rade
kubectl get pods -A -o wide

# Read-only: Service CIDR se ne zaključuje iz Pod CIDR-a
kubectl get svc kubernetes -n default -o wide

Pod CIDR, Service CIDR, Node/LAN opsezi, VPN, data-centar, cloud VPC/VNet, administratorske mreže i mreže povezanih klastera ne smeju se preklapati. Preklapanje stvara ambivalentne rute, pogrešan NAT i kvarove koji zavise od odredišta. Opsezi se zato biraju pre izgradnje klastera i vode u IPAM/CMDB sistemu. Naknadna promena cluster CIDR-a često nije običan in-place zahvat i može zahtevati migraciju ili izgradnju novog klastera.

Iscrpljen IP pool se manifestuje kao neuspešno kreiranje Pod sandbox-a, iako CPU i memorija postoje. Brisanje nasumičnih CNI state fajlova nije bezbedan recovery: može duplirati adresu. Najpre se proveravaju pool kapacitet, curenje alokacija, neuspešni DEL pozivi, broj Podova po čvoru i ograničenje maxPods, pa se stanje usaglašava postupkom koji podržava konkretan IPAM.

Rutiranje između podova – overlay, underlay i native pristup

Na istom Linux čvoru Pod je često povezan parom virtuelnih Ethernet interfejsa: jedan kraj ulazi u namespace Poda, drugi ostaje na hostu i povezuje se na bridge, rutu ili programski data plane. Za drugi čvor paket mora preći fizičku ili virtuelnu mrežu. Dva glavna pristupa razlikuju se po tome da li underlay poznaje Pod prefikse.

U oba modela povratna putanja je jednako važna kao odlazna. Asimetrično rutiranje može aktivirati reverse-path filter, stateful firewall ili policy kontrolu i stvoriti jednostrani kvar. Encapsulation portovi moraju biti dopušteni između svih relevantnih čvorova, a BGP susedstva i cloud route tabele moraju biti konvergentne. Kubernetes Node status Ready ne potvrđuje automatski da je svaki Pod CIDR međusobno dostupan.

MTU – granica koja često stvara „misteriozne” kvarove

Maximum Transmission Unit određuje najveći IP paket koji interfejs može poslati bez fragmentacije na tom linku. Overlay dodaje spoljne IP, UDP i tunelske headere, pa Pod interfejs obično mora imati MTU manji od underlay interfejsa. Tačan overhead zavisi od enkapsulacije i porodice adresa; zato se vrednost ne bira napamet formulom preuzetom iz drugog okruženja, već prema dokumentaciji dodatka i najmanjem MTU-u cele fizičke putanje.

Prevelik MTU može dozvoliti male ping i TCP SYN pakete, a blokirati veće odgovore, TLS handshake, image registry ili DNS odgovor sa više zapisa. Path MTU Discovery zavisi od povratnih ICMP poruka: za IPv4 je važna poruka „fragmentation needed”, a za IPv6 „Packet Too Big”. Firewall koji ih odbacuje stvara PMTUD black hole. Smanjivanje MTU-a može ublažiti simptom, ali trajna mera mora uskladiti underlay, tunel, Pod interfejs i ICMP politiku.

# Read-only na Linux čvoru: interfejsi, MTU i rute
ip -details link show
ip -4 route show
ip -6 route show

# Read-only iz dijagnostičkog Poda: otkrivanje najvećeg IPv4 paketa bez fragmentacije
# -M do zabranjuje fragmentaciju; -s je ICMP payload, ne ukupan IP paket
ping -4 -M do -s 1472 POD_IP_NA_DRUGOM_CVORU
ping -4 -M do -s 1400 POD_IP_NA_DRUGOM_CVORU

# Read-only: prikaz procenjenog path MTU-a ako je tracepath dostupan
tracepath POD_IP_NA_DRUGOM_CVORU

Vrednost 1472 odgovara payload-u uz 20 bajtova IPv4 i 8 bajtova ICMP zaglavlja na putanji MTU 1500; nije univerzalna preporuka za Pod mrežu. IPv6 ima drugačije zaglavlje i ne oslanja se na rutere da fragmentiraju paket. Test se radi u oba smera, preko iste klase odredišta koja pokazuje simptom, a nalaz se potvrđuje packet capture-om i brojačima interfejsa. Promena MTU-a na živom CNI-ju je cluster-wide promena: novi i postojeći podovi mogu privremeno imati različite vrednosti, pa je potreban kontrolisani restart workload-a ili node rollout prema uputstvu dodatka.

IPv4, IPv6 i dual-stack dizajn

Kubernetes podržava IPv4 single-stack, IPv6 single-stack i dual-stack. Dual-stack je stabilan od Kubernetes 1.23 i zahteva usklađene Pod i Service CIDR parove, dual-stack node/underlay podršku i mrežni dodatak koji tu funkciju stvarno implementira. Polje status.podIPs može sadržati obe adrese, dok status.podIP ostaje kompatibilni primarni prikaz. Redosled porodica utiče na primarnu porodicu i Service politiku; nije dovoljno samo dodati drugi CIDR posle izgradnje klastera.

# Read-only: obe porodice adresa po Podu
kubectl get pods -A \
  -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,NODE:.spec.nodeName,IPS:.status.podIPs[*].ip'

# Read-only: Node adrese i dodeljeni Pod CIDR parovi
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.podCIDRs}{"\t"}{.status.addresses}{"\n"}{end}'

NetworkPolicy, egress, NAT, monitoring i testovi moraju obuhvatiti obe porodice; uspešan IPv4 test ne dokazuje IPv6 putanju. Windows čvorovi imaju posebna HNS/HCS ograničenja, a podržane kombinacije overlay-a i dual-stack-a zavise od verzije Windows-a i dodatka. Mešoviti Linux/Windows klaster projektuje se prema matrici podrške konkretnog dobavljača, ne prema pretpostavci da svi CNI modovi rade identično.

Bezbednost i dostupnost mrežnog data plane-a

Pod mreža bez NetworkPolicy enforcement-a u osnovi nudi povezanost, ne mikrosegmentaciju. Kubernetes API može prihvatiti NetworkPolicy objekat čak i kada aktivni plugin ne sprovodi pravila; postojanje YAML-a zato nije dokaz zaštite. Enforcement se potvrđuje dokumentacijom dodatka i pozitivnim i negativnim testovima. NetworkPolicy ne zamenjuje zaštitu node management mreže, cloud security groups, firewall između čvorova niti kontrolu izlaska ka spoljnim servisima.

CNI agent je privilegovana komponenta koja često upravlja host interfejsima, rutama, eBPF mapama ili netfilter pravilima. Njegov image, RBAC, hostPath mount-ovi, Linux capabilities i upgrade kanal predstavljaju bezbednosnu granicu. Agent se obično isporučuje kao DaemonSet, ali kontrolni deo može biti Deployment. Visoka dostupnost zato zahteva kompatibilnu verziju na svakom čvoru, nadzor kontrolera i zaštitu IPAM state-a. Restart node agenta nije bezazlen kada dodatak ne podržava hitless reconciliation.

Enkripcija Pod saobraćaja nije automatska osobina Kubernetes modela. Neki dodaci nude WireGuard, IPsec ili drugu enkripciju, uz CPU trošak, MTU overhead, upravljanje ključevima i ograničenja offload-a. Zahtev „traffic encrypted in transit” mora navesti obim: Pod–Pod, Node–Node tunel, izlaz iz klastera ili aplikacioni TLS. Mrežna enkripcija i aplikacioni identitet nisu ista kontrola.

Inventar, posmatranje i dokazivanje putanje paketa

Pre incidenta treba dokumentovati: aktivni dodatak i verziju, način instalacije, CNI konfiguracioni direktorijum, Pod/Service CIDR, IPAM pool-ove, encapsulation mod i portove, BGP/cloud rute, MTU na svakom sloju, NetworkPolicy podršku, kube-proxy ili njegovu zamenu, dual-stack stanje i vlasnike underlay mreže. Bez ovog inventara troubleshooting počinje nagađanjem.

# Read-only: runtime, Pod CIDR i osnovni Node inventar
kubectl get nodes -o wide
kubectl describe node NODE_NAME

# Read-only: kandidati za mrežne DaemonSet-ove i njihove image verzije
kubectl get daemonsets -A -o wide
kubectl get pods -A -o wide
kubectl get daemonset -n CNI_NAMESPACE CNI_DAEMONSET \
  -o jsonpath='{range .spec.template.spec.containers[*]}{.name}{"\t"}{.image}{"\n"}{end}'

# Read-only na Linux čvoru sa administrativnim privilegijama
sudo ls -la /etc/cni/net.d /opt/cni/bin
sudo crictl info
ip -br address
ip route show table all

Naziv namespace-a i DaemonSet-a zavise od izabranog dodatka, pa se ne unose napamet. crictl mora biti usmeren na odgovarajući CRI endpoint. Sadržaj konfiguracionih fajlova može otkriti interne opsege ili parametre, zato se prikuplja u kontrolisani incident zapis i ne objavljuje bez redakcije.

Packet capture je dokaz, ali i privilegovana operacija koja može zabeležiti osetljiv payload. Najpre se koriste API stanje, events, rute, brojači i sintetički testovi. Tek zatim se u odobrenom vremenskom prozoru snima uski filter na tačnom interfejsu:

# Read-only, ali bezbednosno osetljivo: ograničen capture na Linux čvoru
sudo tcpdump -ni any -c 100 'host POD_IP and (icmp or tcp port 443)'

# Read-only: greške i drop brojači interfejsa
ip -s link show

# Read-only: kubelet i runtime događaji u relevantnom vremenskom prozoru
sudo journalctl -u kubelet --since '-15 min' --no-pager
sudo journalctl -u containerd --since '-15 min' --no-pager

Sistematičan troubleshooting mrežnog incidenta

Incident se najpre klasifikuje: da li Pod nema IP, da li ne radi samo komunikacija na istom čvoru, samo između čvorova, samo prema spolja, samo jedna porodica adresa, samo veliki paketi ili samo Service ime/VIP. Testiranje matrice izvor–odredište–protokol–veličina–IP porodica brzo razdvaja CNI, DNS, Service i aplikacioni problem.

1. Sačuvati obim i vreme. Zabeležiti pogođene namespace-e, podove, čvorove, IP adrese, početak simptoma i poslednju promenu. Ne restartovati CNI agent pre prikupljanja dokaza.
2. Proveriti API i sandbox događaje. Pod u ContainerCreating sa FailedCreatePodSandBox ukazuje na runtime/CNI ADD tok; Pod u Running stanju sa neuspešnom vezom zahteva data-plane analizu.
3. Izolovati lokalnu i udaljenu putanju. Porediti Pod–Pod test na istom i različitim čvorovima, zatim Pod–Node i Pod–spoljno odredište. Koristiti stvarni Pod IP da bi se DNS i Service sloj privremeno izuzeli.
4. Proveriti adresu, interfejs i rute. Uporediti Pod status, namespace interfejs, host route i IPAM evidenciju. Duplikat adrese i odsutna povratna ruta imaju različite korektivne mere.
5. Proveriti policy i underlay. Utvrditi da li je paket odbačen u NetworkPolicy data plane-u, host firewall-u, cloud kontroli ili fizičkoj mreži. Kod overlay-a proveriti tunel port i endpoint; kod routable modela BGP/cloud rutu.
6. Testirati MTU i obe porodice. Ako mali paketi rade, a veći tokovi zastaju, proveriti PMTUD i ICMP. Dual-stack testirati odvojeno za IPv4 i IPv6.
7. Potvrditi hipotezu minimalnom promenom. Bezbedna privremena mera može biti preusmeravanje workload-a sa jednog pogođenog čvora posle potvrde uzroka. Masovno brisanje podova samo seli simptom i može povećati incident.
8. Validirati oporavak i osnovni uzrok. Ponoviti identične testove, proveriti nove sandbox-e, povratnu putanju, metrike/drop brojače i stabilnost posle rollout-a. Dokumentovati tehnički uzrok, osnovni procesni uzrok i trajnu meru.

Praktikum – mapiranje i dokazivanje Pod mreže bez promene CNI-ja

Cilj i kontekst. Administrator treba da utvrdi aktivnu mrežnu implementaciju, mapira Pod CIDR i MTU, napravi dva bezopasna testna workload-a na različitim čvorovima, dokaže direktnu Pod komunikaciju, razlikuje DNS/Service problem od Pod mreže i izvede kontrolisanu MTU dijagnostiku. Praktikum namerno ne instalira, ne menja niti restartuje CNI: takva promena je platform-specifična i neprihvatljiva za generičku laboratoriju.

Topologija i preduslovi. Potreban je izolovan klaster sa najmanje dva Linux worker čvora, funkcionalnim postojećim CNI-jem, kubectl pristupom koji može da kreira namespace, Deployment/Pod i Service objekte, kao i odobren pristup jednom čvoru za read-only ip, journalctl i po potrebi tcpdump. Image registry.k8s.io/e2e-test-images/agnhost:2.53 mora biti dostupan; ako ciljna organizacija koristi interni registry, unapred mirror-ovati image i zameniti referencu. Proveriti zvaničnu aktuelnu verziju image-a pre produkcionog ponavljanja.

Rizik. Namespace-scoped testni objekti su nizak rizik. tcpdump zahteva root i može obuhvatiti osetljive podatke; koristi se samo sa uskim filterom. Nikakva promena fajlova u /etc/cni/net.d, ruta, MTU-a, firewall-a, CNI DaemonSet-a ili node konfiguracije nije deo vežbe.

1. Početni inventar i change dokaz. Komande su read-only. Sačuvati aktivni kontekst, verzije, runtime, Node Pod CIDR i postojeće mrežne DaemonSet-ove.

   kubectl config current-context
   kubectl version
   kubectl get nodes -o wide
   kubectl get nodes \
     -o custom-columns='NODE:.metadata.name,RUNTIME:.status.nodeInfo.containerRuntimeVersion,POD_CIDR:.spec.podCIDR,POD_CIDRS:.spec.podCIDRs'
   kubectl get daemonsets -A -o wide
   kubectl get events -A --sort-by=.metadata.creationTimestamp | tail -n 40

   Validacija: svi planirani čvorovi su Ready, runtime i Kubernetes verzije su zabeleženi, a operator može da navede koji DaemonSet predstavlja aktivni mrežni agent. Ako identitet dodatka nije jasan, zaustaviti promene i proveriti cluster build dokumentaciju.
2. Kreiranje izolovanog prostora i serverskog workload-a. Sledeće operacije menjaju samo namespace cni-lab.

   apiVersion: v1
   kind: Namespace
   metadata:
     name: cni-lab
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: net-server
     namespace: cni-lab
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: net-server
     template:
       metadata:
         labels:
           app: net-server
       spec:
         topologySpreadConstraints:
           - maxSkew: 1
             topologyKey: kubernetes.io/hostname
             whenUnsatisfiable: DoNotSchedule
             labelSelector:
               matchLabels:
                 app: net-server
         containers:
           - name: server
             image: registry.k8s.io/e2e-test-images/agnhost:2.53
             args: ["netexec", "--http-port=8080", "--udp-port=8081"]
             ports:
               - name: http
                 containerPort: 8080
             resources:
               requests:
                 cpu: 10m
                 memory: 16Mi
               limits:
                 cpu: 100m
                 memory: 64Mi
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: net-server
     namespace: cni-lab
   spec:
     selector:
       app: net-server
     ports:
       - name: http
         port: 8080
         targetPort: http

   Sačuvati kao cni-lab-server.yaml, pa primeniti i proveriti rollout:

   kubectl apply -f cni-lab-server.yaml
   kubectl rollout status deployment/net-server -n cni-lab --timeout=180s
   kubectl get pods -n cni-lab -o wide
   kubectl get service,endpointslice -n cni-lab -o wide

   Očekivani rezultat: dve replike rade na različitim hostname domenima. Ako klaster nema dva podobna čvora, druga ostaje Pending; ne ublažavati pravilo naslepo, već dokumentovati ograničenje topologije i za ovu laboratoriju koristiti jedan server ili obezbediti drugi čvor.
3. Klijent i direktan Pod-to-Pod test.

   kubectl run net-client -n cni-lab \
     --image=registry.k8s.io/e2e-test-images/agnhost:2.53 \
     --restart=Never --command -- sleep 3600
   kubectl wait -n cni-lab --for=condition=Ready pod/net-client --timeout=120s
   
   kubectl get pods -n cni-lab -o wide
   SERVER_IP=$(kubectl get pods -n cni-lab -l app=net-server \
     -o jsonpath='{.items[0].status.podIP}')
   kubectl exec -n cni-lab net-client -- /agnhost connect "$SERVER_IP:8080" --protocol http
   kubectl exec -n cni-lab net-client -- /agnhost connect net-server:8080 --protocol http

   Validacija: oba poziva vraćaju uspešan odgovor. Prvi dokazuje osnovnu Pod IP putanju; drugi dodaje DNS i Service sloj. Ako prvi radi, a drugi ne, osnovni CNI transport ne proglašava se uzrokom bez dodatnih dokaza.
4. Dokaz lokalne i među-nodalne putanje. Utvrditi čvor klijenta i izabrati po jedan server na istom i, ako postoji, drugom čvoru.

   CLIENT_NODE=$(kubectl get pod net-client -n cni-lab -o jsonpath='{.spec.nodeName}')
   kubectl get pods -n cni-lab -o custom-columns='POD:.metadata.name,NODE:.spec.nodeName,IP:.status.podIP'
   
   kubectl exec -n cni-lab net-client -- ip -br address
   kubectl exec -n cni-lab net-client -- ip route
   kubectl exec -n cni-lab net-client -- cat /etc/resolv.conf

   Za svaki zabeleženi server IP ponoviti direktan HTTP test. Kriterijum: komunikacija radi bez obzira na Node. Ako samo udaljeni server ne radi, prikupiti rute i capture na oba čvora pre bilo kakvog restarta.
5. MTU i PMTUD provera. U image-u možda nisu dostupni ping ili tracepath; tada se koristi odobreni interni troubleshooting image sa tim alatima, bez instaliranja paketa u produkcioni Pod. Najpre pročitati MTU:

   kubectl exec -n cni-lab net-client -- ip link show
   
   # Samo ako troubleshooting image sadrži iputils ping
   kubectl exec -n cni-lab net-client -- \
     ping -4 -M do -c 3 -s 1400 "$SERVER_IP"

   Postepeno povećavati payload samo do dokumentovane granice. Tumačenje: neuspeh velikog DF paketa uz uspešan mali paket podržava MTU/PMTUD hipotezu, ali je ne dokazuje sam. Potvrda zahteva ICMP capture, Pod/host MTU poređenje i tačnu enkapsulaciju.
6. Kontrolisani incident bez kvarenja mreže. Simulirati DNS grešku korišćenjem nepostojećeg imena, a zatim dokazati da direktna IP putanja i dalje radi.

   kubectl exec -n cni-lab net-client -- \
     /agnhost connect ne-postoji.cni-lab.svc.cluster.local:8080 --protocol http || true
   kubectl exec -n cni-lab net-client -- \
     /agnhost connect "$SERVER_IP:8080" --protocol http
   kubectl get events -n cni-lab --sort-by=.metadata.creationTimestamp

   Incident zapis: simptom je neuspešna rezolucija jednog imena; obim je klijent/ime; posledica je nemoguć pristup preko tog FQDN-a; neposredni uzrok je nepostojeći DNS zapis; osnovni uzrok je namerna laboratorijska greška. Nema razloga za restart CNI-ja. Trajna mera u realnom incidentu bila bi korekcija imena ili DNS/Service konfiguracije potvrđena ponovnim testom.
7. Node-side korelacija. Na čvoru klijenta, sa odobrenim read-only administratorskim pristupom, prikupiti:

   ip -br address
   ip -details link show
   ip route show table all
   sudo journalctl -u kubelet --since '-15 min' --no-pager
   sudo journalctl -u containerd --since '-15 min' --no-pager

   Ako runtime nije containerd, koristiti odgovarajuću systemd jedinicu. Plugin-specifične logove čitati preko kubectl logs iz tačno identifikovanog CNI Poda na pogođenom čvoru, uz --since i odgovarajući container naziv. Ne navoditi generički naziv koji možda ne postoji.
8. Rollback i cleanup. Brisanje namespace-a je destruktivno samo za laboratorijske objekte. Pre komande potvrditi njegov sadržaj.

   kubectl get all -n cni-lab
   kubectl delete namespace cni-lab
   kubectl wait --for=delete namespace/cni-lab --timeout=180s
   kubectl get namespace cni-lab

   Poslednja komanda treba da vrati NotFound. Nisu menjani CNI, Node rute, firewall, MTU, IPAM ni cluster-scoped objekti; dodatni rollback nije potreban.

Kriterijumi prihvatanja praktikuma

• Aktivni runtime, mrežni dodatak, njegove image verzije i način instalacije identifikovani su dokazima.
• Node Pod CIDR inventar i stvarne Pod adrese su zabeleženi bez pretpostavke da dodatak nužno koristi spec.podCIDR.
• Dve serverske replike rade na različitim čvorovima ili je dokumentovano zašto topologija to ne dopušta.
• Direktna Pod IP komunikacija proverena je odvojeno od DNS i Service komunikacije.
• Lokalna i među-nodalna putanja upoređene su istim protokolom.
• MTU vrednosti su očitane, a DF test je protumačen bez proglašavanja jednog pinga konačnom dijagnozom.
• Namerni DNS incident pravilno je klasifikovan i nije pogrešno pripisan CNI-ju.
• Node i Pod dokazi pokrivaju isti vremenski prozor i isti tok.
• Cleanup je uklonio samo namenski laboratorijski namespace i nije menjao cluster data plane.

Administratorske prakse

Mrežni dizajn kao deo cluster lifecycle-a. Pod i Service CIDR, Node mreže, dual-stack redosled, encapsulation, route distribucija, MTU i potrebni portovi odobravaju se pre instalacije. Vode se u IPAM-u i CMDB-u zajedno sa vlasnikom i granicama odgovornosti. Promena bilo kog od ovih elemenata prolazi staging i failure test, jer posledice mogu obuhvatiti sve workload-e.

Kompatibilnost i kontrolisan upgrade. Kubernetes, CNI, kernel, runtime i operativni sistem imaju proverenu matricu verzija. Upgrade se izvodi podržanim mehanizmom dodatka, sa unapred definisanim health signalima, node redosledom i rollback pragom. Mešovite verzije dozvoljene su samo u dokumentovanom upgrade prozoru.

Kapacitet IPAM-a. Prate se slobodne adrese, zauzeće po pool-u/subnetu, neuspešne alokacije, broj podova po čvoru i stopa kreiranja sandbox-a. Alarm se postavlja pre iscrpljenja, uz rezervu za rollout surge, autoscaling i incidentni failover. Ručno brisanje state-a nije standardna mera oporavka.

MTU i sintetička dostupnost. Dokumentuje se MTU underlay-a, tunela i Pod interfejsa. Sintetički testovi obuhvataju isti i drugi čvor, male i velike pakete, TCP i po potrebi UDP, IPv4 i IPv6. Promena fizičke mreže, VPN-a ili enkripcije automatski pokreće ponovnu MTU validaciju.

Observability bez gubitka granica. CNI agent/controller health, IPAM, drop counters, route/BGP stanje, policy verdict-i i sandbox latency korelišu se sa kubelet/runtime događajima i infrastrukturnim monitoringom. DNS, Service i aplikacioni SLO ostaju posebni signali kako naziv „mreža” ne bi sakrio konkretan sloj kvara.

Bezbednost privilegovanog data plane-a. CNI RBAC, service account, image digest/signatura, capabilities, hostPath mount-ovi, policy funkcije i pristup konfiguraciji periodično se revidiraju. Packet capture i support bundle imaju vremensko ograničenje, kontrolisan pristup, redakciju i rok čuvanja.

Završna kontrolna tačka

• Objašnjena je razlika između Kubernetes mrežnog modela, CNI specifikacije i punog mrežnog rešenja.
• Za svaki Pod može se povezati sandbox, network namespace, interfejs, IPAM alokacija, gateway i putanja do drugog čvora.
• Pod, Service, Node i povezani infrastrukturni CIDR opsezi su poznati i ne preklapaju se.
• Izbor overlay, native ili cloud-native rutiranja ima dokumentovane zahteve prema underlay mreži.
• Efektivni MTU uračunava enkapsulaciju i enkripciju, a ICMP potreban za PMTUD nije blokiran bez opravdanja.
• Dual-stack je potvrđen kroz CNI, Node, Pod, Service, policy i monitoring sloj, ne samo kroz API konfiguraciju.
• NetworkPolicy enforcement je funkcionalno testiran ako se koristi; samo postojanje objekta nije prihvaćeno kao dokaz.
• Postoje dashboard i alarmi za CNI agent/controller, IPAM kapacitet, sandbox greške, drop-ove i route/tunel stanje.
• Troubleshooting polazi od obima i direktnog Pod IP testa, a zatim razdvaja CNI, DNS, Service i aplikacioni sloj.
• Upgrade, migracija, MTU promena i recovery imaju staging dokaz, change zapis i proverljiv rollback.

Zaključak

Kubernetes mrežni model je ugovor o povezivosti, a CNI je standardizovana granica preko koje runtime traži mrežnu pripremu sandbox-a. Stvarni dodatak bira kako će napraviti interfejs, dodeliti adresu, programirati lokalni data plane i preneti paket između čvorova. Overlay, native routing i cloud-native pristupi mogu ispuniti isti model, ali imaju različite zahteve prema underlay-u, MTU-u, rutama, kvotama i operativnim veštinama.

Nakon ove lekcije administrator treba da ume da prati put od PodSpec-a do network namespace-a, razlikuje IPAM od transporta, objasni povratnu rutu, izmeri MTU bez pogrešnog tumačenja payload-a, prepozna PMTUD black hole i odvoji direktnu Pod mrežu od Service i DNS ravni. Jednako važno, treba da zna šta CNI ne radi automatski: ne garantuje NetworkPolicy enforcement, DNS, Service proxy, enkripciju, ispravnu fizičku mrežu niti neograničen IP kapacitet.

Odgovoran rad počinje inventarom i dokazima. Verzije, CIDR opsezi, rute, tuneli, MTU, policy mogućnosti i granice vlasništva moraju biti poznati pre incidenta. Kada kvar nastane, najmanje invazivna matrica testova—isti/drugi čvor, IP/ime/Service, mali/veliki paket, IPv4/IPv6—pretvara neodređeni „mrežni problem” u proverljivu hipotezu i bezbednu korektivnu meru.