Sietovy model v kubernetes

1. Ing. Filip Pohronský, DITEC a.s.
Sieťový model v k8s
Ako komunikujú kontajnery, pody, a služby?

2. Sieťový model v Kubernetes
základné obmedzenia
• kubernetes robí rozhodnutia o tom, ako budú
prepojené Pody pomocou siete
• Predovšetkým Kubernetes predpisuje nasledujúce
požiadavky na akúkoľvek sieťovú komunikáciu:
• všetky Pody komunikujú so všetkými ostatnými
Podmi bez použitia prekladu sieťových adries
(NAT)
• všetky Nody (uzly) komunikujú so všetkými
Podmi bez protokolu NAT.
• IP adresa, ktorú vidí Pod je rovnaká IP, ako ju
vidia ostatní
Kubernetes bol vybudovaný na prevádzkovanie distribuovaných systémov na klástri mašín. Vďaka samotnej povahe distribuovaných systémov je zosieťovanie ústrednou
a nevyhnutnou súčasťou nasadzovania Kubernetes. Pochopenie sieťového modelu Kubernetes vám umožní správne spustenie, sledovanie a riešenie problémov s vašimi
aplikáciami bežiacimi na Kubernetes.
Kubernetes predpisuje nasledujúce požiadavky na akúkoľvek sieťovú komunikáciu. Pod s podom komunikuje bez prekladu IP adries, Všetky Nody komunikujú so
všetkými Podmi bez prekladu IP adries. IP adresa Podu je rovnaká, akú vidia ostatní.

3. Sieťový model v kubernetes
sieťové problémy na riešenie
• Na základe týchto obmedzení nám ostáva
vyriešiť nasledujúce štyri komunikačné a
sieťové problémy:
• komunikácia a spojenie Kontajnera s
Kontajnerom
• komunikácia a spojenie Podu s Podom
• komunikácia a spojenie Podu so Službou
• komunikácia a spojenie medzi
Internetom a Službou
Na základe týchto definovaných obmedzení nám ostáva vyriešiť nasledujúce štyri komunikačné a sieťové problémy. Komunikáciu medzi kontajnermi, medzi Podmi, medzi
Podom a Službou a medzi verejnou sieťou Internet a Službou.

4. Sieťovanie Kontajnera s Kontajnerom
• Linux
• network namespace
• logický sieťový stoh (stack)
• vlastné
• routes
• firewall pravidlá
• sieťové zariadenia
Zvyčajne vidíme sieťovú komunikáciu vo virtuálnej mašine, tak že virtuálna mašina priamo komunikuje s Ethernetovým zariadením.
V realite je situácia oveľa dômyselnejšia.
V Linuxe každý bežiaci proces komunikuje vrámci jedného sieťového menného priestoru (network namespace), ktorý poskytuje logický sieťový stoh s úplne oddelenými
vlastnými firewall pravidlami, smerovaním a sieťovými zariadeniami. V základe, sieťový menný priestor poskytuje celkom nový sieťový stoh pre všetky procesy vrámci
menného priestoru.

5. Sieťovanie Kontajnera s Kontajnerom
• v linuxe vytvárate menný priestor použitím príkazu ip.
• vytvorenie nového menného priestoru s názvom ns1:
• bod pripojenia pre menný priestor je /var/run/netns
• zobrazenie zoznamu všetkých menných priestorov v bode pripojenia /var/run/
netns:
$ ip netns add ns1
$ ls /var/run/netns
ns1
$ ip netns
ns1
Ako linuxový užívateľ, vytvárate menný priestor pomocou príkazu ip, napríklad takto vytvoríte nový menný priestor a pomenujete ho ns1.
[klik]
Keď je menný priestor vytvorený, jeho bod pripojenia sa nachádza pod /var/run/netns. To umožňuje zachovať menný priestor aj v čase, keď k nemu nie je pripojený
žiadny proces.
[klik]
Zoznam dostupných menných priestorov si viete zobraziť pomocou ip príkazu.

6. Sieťovanie Kontajnera s Kontajnerom
• koreňový sieťový menný priestor (Root Network Namespace)
Štandardne Linux priradí každý proces do koreňového sieťového menného priestoru, a tak poskytne prístup do vonkajšieho prostredia.

7. Sieťovanie Kontajnera s Kontajnerom
• Pod je skupina kontajnerov, ktoré zdieľajú jeden menný priestor
• kontajneri v jednom Pode
• komunikujú pomocou
• localhost
• Pre každý Pod môžeme vytvoriť
• jeden menný priestor
• kontajner sa pripája pomocou
• docker funcie
• -- net = container:
Pokiaľ ide o konštrukty Dockeru, Pod je modelovaný ako skupina kontajnerov Docker, ktoré zdieľajú sieťový menný priestor. Všetky kontajnery v jednom Pode majú
rovnakú IP adresu a rozsah portov (odkazujeme sa 4. vrstvu TCP/IP sieťového modelu) priradený prostredníctvom sieťového menného priestoru a ten je priradený práve
jednému Podu. Kontajneri sa môžu navzájom vyhľadávať prostredníctvom localhost, pretože sa nachádzajú v rovnakom mennom priestore.
Pre každý Pod na virtuálnej mašine môžeme vytvoriť sieťový menný priestor. Toto je implementované pomocou Dockeru ako „Pod pre kontajnery“, ktorý udržuje menný
priestor otvorený, zatiaľ čo „kontajnery s aplikáciami“ (veci, ktoré zadal používateľ) sa k tomuto mennému priestor pripojí pomocou funkcie v Dockeri –net = container:.
Obrázok ukazuje, ako je každý Pod zložený z viacerých kontajnerov Docker v zdieľanom mennom priestore.

8. Sieťovanie Podu s Podom
• V Kubernetes má každý Pod naozajstnú IP adresu a každý Pod komunikuje s
iným Podom s použitím tejto adresy
• na jednom fyzickom Node
• na rôznych fyzických Nodoch
V Kubernetes má každý Pod naozajstnú IP adresu a každý Pod komunikuje s iným Podom s použitím tejto adresy. Úlohou, ktorej sme sa zhostili je pochopiť ako
Kubernetes umožní komunikáciu jedného Podu s iným Podom použitím skutočných IP adries. A to, už či je Pod deplojnutý na rovnakom alebo rozdielnom fyzickom
Node v jednom klástri.

9. Sieťovanie Podu s Podom
• Pod existuje vo svojom mennom priestore
• S iným Podom komunikuje pomocou Linuxového Virtuálneho sieťového
zariadenia alebo veth
• veth pár pozostáva z dvoch virtuálnych rozhraní
Z pohľadu Podu, ten existuje vo svojom Ethernetovom mennom priestore, ktorý v prípade potreby komunikuje s inými mennými priestormi na rovnakom Node. Našťastie,
menné priestory sa vedia prepojiť pomocou Linuxového Virtuálneho sieťového zariadenia alebo skrátene veth.
Tento Veth pozostáva z dvoch virtuálnych rozhraní, ktoré môžu byť rozložené na viac menných priestorov.

10. Sieťovanie Podu s Podom
veth pár
• Pripojenie Podu
• prepojíme
• koreňový menný priestor a
• menný priestor Podu
• podobné patch káblu
Aby sme prepojili menný priestor Podu, môžeme priradiť jednu stranu veth páru na koreňový menný priestor a druhú stranu na menný priestor Podu.
Každý veth pár pracuje ako patch kábel, prepájajúc dve strany a umožňujúci dátam tiecť medzi nimi. Toto nastavenie sa môže replikovať pre také množstvo Podov, koľko
ich máme na stroji.
V tomto bode máme nastavené Pody, kde každý má svoj vlastný menný priestor a tak veria, že majú ich vlastné Ethernetové zariadenie a IP adresu a sú pripojené na
koreňový menný priestor Nodu.
A teraz potrebujeme aby sa Pody rozprávali navzájom pomocou Linuxového Ethernetového mostu (bridge).

11. Sieťovanie Podu s Podom
ethernetový most v linuxe
• Ethernetový most
• virtuálne zariadenie
• L2 vrstve ISO/OSI modelu
• MAC adresa
• Logika apl. na prij. rámec
• preposlať alebo zahodiť
• používa ARP
• udržuje vyhľadávaciu tabuľku
Ethernetový most v linuxe je virtuálne sieťové zariadenie, pracujúce na 2.vrstve ISO/OSI modelu. Zvyčajne sa používa na zlúčenie dvoch sietí dohromady.
Kód, ktorý zabezpečuje premostenie rozhoduje, či dáta premostí alebo zahodí. Robí to tak, že zisťuje jedinečnosť MAC adries na každej z prepojených sietí.
Mosty implementujú ARP protokol - Adress Resolution Protokol - na to aby objavili MAC adresu na linkovej vrstve asociovanú s pridelenou IP adresou. Keď je dátový
rámec prijatý do mostu, bridge broadcastuje - alebo zasiela tento rámec von všetkým pripojeným zariadeniam (až na ten smer, z ktorého rámec prišiel). To zariadenie,
ktoré na rámec odpovie je uložené vo vyhľadávacej tabuľke mostu .

12. Sieťovanie Podu s Podom
Život paketu: z Podu do iného Podu na rovnakom Node
• Pod1 pošle paket na vlastné eth0
zariadenie
• Pod1 je prepojený pomocou
virtuálneho Ethernet zariadenia na
koreňový menný priester veth0
• Most cbr0 je nakonfigurovaný s veth0
pripojeným do tohto segmentu
• V momente, keď paket príde na most,
je smerovaný do správneho sieťového
segmentu, cez veth1
• A paket je smerovaný priamo do
menného priestoru Pod2
Vzhľadom na sieťové menné priestory, ktoré izolujú každý Pod do vlastného sieťového stohu alebo stacku. A vzhľadom na virtuálne ethernetové zariadenia, ktoré
pripájajú každý menný priestor ku koreňovému mennému priestoru. [klik] A taktiež použitím mostu, ktorý spája menné priestory dohromady, sme konečne pripravení
odosielať dáta medzi Podmi na rovnakom uzle.
Počas tohto prenosu dát komunikuje každý Pod iba s doménou eth0 na serveri localhost a prevádzka je smerovaná do správneho Podu. Vývojár má očakávať. že táto
znalosť pri vývoji aplikácií s používaním siete je je štandardným správaním.

13. Sieťovanie Podu s Podom
Život paketu: z Podu do iného
Podu na naprieč Nodmi
• Pod1 pošle paket na vlastné eth0
zariadenie
• Avšak v tomto prípade posiela dáta do
Pod4 označený zelenou farbou
• Paket sa nakoniec objaví v koreňovom
mennom priestore
• ARP skončí s chybou, pretože žiadne
pripojené zariadenie nemá takú MAC
adresu
• Paket vstupuje do koreňového menného
priestoru cieľovej VM2, kde je smerovaný
na správne virtuálne ethernetové zariadenie
Keď sme zistili, ako smerovať pakety medzi Podmi na rovnakom Node, presunieme sa na smerovanie prenosu medzi Podmi na rôznych Nodoch. Sieťový model
Kubernetes vyžaduje, aby boli IP adresy Podu prístupné v celej sieti, ale nešpecifikuje, ako sa to musí urobiť. V praxi je to špecifické pre tú-ktorú sieť, avšak boli
zavedené niektoré vzory a predpisy, ktoré to uľahčujú. [klik]
Spravidla je každému uzlu vo vašom Klástri priradený blok CIDR (Classless Inter-Domain Routing) adries s uvedením IP adries dostupných pre Pody, ktoré bežia na
konkrétnom Node. Keď sa dátová prevádzka paketov určená pre blok CIDR dostane do Nodu, je na zodpovednosti Nodu presmerovanať túto dátovú prevádzku do
správneho Podu.
Každý Nód vie, ako doručiť pakety do Podov, ktoré bežia v rámci neho. V momente, ako paket sa paket dostane do cieľového Nodu, ďalšie pakety tečú rovnakou cestou
tak, ako to robia pri smerovaní prevádzky medzi Podmi na rovnakom Node.

14. Sieťovanie Podu s Podom
CNI - Container Network Plugin
• poskytuje možnosť komunikácie medzi Nodmi v prostedí Amazon VPC
• https://github.com/aws/amazon -vpc-cni-k8
• poskytuje spoločné API
• vyžaduje sa transparentnosť komunikácie
• poskytuje bezpečné a spravovateľné prostredie pomocou funkcií VPC, IAM a
Security Group
Počas výkladu sme zistili, ako funguje sieť pri smerovaní dát pomocou IP adresy na správny Node, ktorý je za tieto IP adresy zodpovedný. Toto môže byť rozdielne pre
každú jednu sieť, ale pohľad na konkrétny príklad poskytne určitý náhľad na príslušné problémy.
Napríklad spoločnosť AWS Amazon udržuje doplnkový sieťový plugin pre kubernetes, ktorý umožní komunikáciu medzi Nodmi a pracuje v prostredí Amazon VPC
pomocou CNI pluginu - Contajner Network Interface.
Tento plugin poskytuje spoločné API na pripojenie kontajnerov k vonkajšej sieti. Ako vývojári chceme vedieť, či Pod môže komunikovať so sieťou pomocou IP adries, a
chceme, aby bol mechanizmus tejto akcie transparentný. CNI plugin vyvinutý spoločnosťou AWS sa snaží vyhovieť týmto potrebám a zároveň poskytuje bezpečné a
spravovateľné prostredie prostredníctvom existujúcich funkcií špecifických pre Amazon Web Služby ako VPC, IAM a Security Group. Riešením je použitie elastických
sieťových rozhraní o ktorých si teraz nebudeme viac hovoriť.

15. Sieťovanie Podu so Službou
Prečo abstrahujeme od IP adresy Podu?
• Smerovanie z jedného Podu na iný Pod funguje výborne pokiaľ nedôjde ku zmene.
• IP adresa Podu nie je trvalá
• Príklady zmeny IP adresy Podu:
• zlyhanie aplikácie
• reštart Nodu
• podrobenie sa princípu škálovateľnosti oboma smermi
• Služby (angl. Services) adresujú tento problém
Ukázali sme si, ako smerovať tok dát medzi Podmi a im priradeným IP adresám. Toto smerovanie pracuje na výbornú pokiaľ sa nebudeme musieť potýkať so zmenu. IP
adresy Podu nie sú trvácne a IP adresa sa zjavuje či mizne ako odpoveď na škálovateľnosť smerom hore aj dolu, či na zlyhanie aplikácie alebo reštartu Nodu. Každá z
týchto udalostí spôsobí zmenu IP adresy Podu bez varovania. Na adresovanie a riešenie tohto problému v Kubernetes vznikla metóda Služby (angl. Services).

16. Sieťovanie Podu so Službou
Ako funguje Služba (Service) v Kubernetes
• Služby v Kubernetes:
• manažujú stav zostavy Podov,
• fungujú ako abstrakcia naprieč Podmi,
• prideľujú jedinú virtuálnu IP adresu množine
Podových IP adries.
• Smerovanie toku dát určeného skupine podov je
posielaný na jeho virtuálnu adresu.
• IP adresa Služby sa nemení.
Služby v Kubernetes manažujú stav množiny Podov, a umožňujú tak sledovať sadu IP adries pridelených Podu, ktoré sa v čase dynamicky menia. Služby fungujú ako
abstrakcia naprieč Podmi a prideľujú jedinú virtuálnu IP adresu skupine Podových IP adries. Akýkoľvek tok dát adresovaný na virtuálnu IP adresu Služby bude smerovaný
do množinu Podov, ktoré majú asociáciu s touto virtuálnou IP adresou. Toto umožňuje množine Podov asociovaných so Službou meniť sa kedykoľvek v čase - klient
potrebuje poznať iba virtuálnu IP adresu Služby, ktorá sa nemení.

17. Sieťovanie Podu so Službou
Ako funguje Služba (Service) v Kubernetes
• Vytvorením služby sa v Kubernetes vytvára aj virtuálna IP adresa
• taktiež sa nazýva IP adresa Klástra (cluster IP adress)
• Tok dát adresovaný na virtuálnu IP adresu bude vyvažovane
rozdeľovaný (load-balanced) na skupinu Podov asociovaných s touto
Službou
• Kubernetes automaticky vytvára a udržuje distribuovaný load-
balancer
• ten je súčasťou klástra
• rovnovomerne rozdľuje prevádzku existujúce zdravé Pody, ktoré
sú súčasťou Klástra, resp. Služby.
Keď v Kubernetes vytvárame novú Službu, je vo vašom mene vytvorená nová virtuálna IP adresa, taktiež známa ako IP adresa klástra. Kdekoľvek vrámci klástra, dátová
prevádzka adresovaná na virtuálnu IP adresu bude vyvažovane rozdeľovaná (load-balanced) na skupinu Podov asociovaných s touto Službou. V skutočnosti Kubernetes
automaticky vytvára a udržuje distribuovaný load balancer (vyrovnávač záťaže) vnorený v klástri, ktorý distribuuje dátovú prevádzku na zdravé a pridružené Pody
existujúce vrámci tejto Služby.

18. Sieťovanie Podu so Službou
netfilter a iptables
• netfilter
• sieťovo orientovaný framework z Linuxu
• využíva užívatľom definované handlery
• funkcie a operácie s paketmi
• filter
• preklad sieťových adries (NAT) a sieťových portov (PAT)
• iptables
• program z užívateľského prostredia z Linuxu
• konfigurované pomocou kube-proxy kontroléra
• prevádzka určená pre virtuálnu IP adresu služby je náhodne pridelná asociovanému Podu danej Služby
Na vykonávanie funkcie vyvažovania záťaže (load balancingu) vrámci Klástra sa Kubernetes spolieha na sieťový rámec, inak povedané sieťovú metódu resp. framework
zabudúvaný v Linuxe - netfilter. Netfilter je sieťovo orientovaný framework poskytovaný Linuxom, ktorý umožňuje implementáciu rôznych úkonov súvisiacich so sieťou vo
forme užívateľsky prispôsobených handleroch. Netfilter poskytuje viacero funkcií a operácií určených na filtráciu paketov, či preklad sieťových adries a sieťových portov.
Tieto funkcie sú potrebné na smerovanie paketov cez sieť, ako aj na poskytnutie možnosti zakázať paketom dosiahnuť citlivé miesta v počítačovej sieti.
iptables je program z užívateľského prostredia, poskytujúci tabuľkovo orientovaný systém a slúži na definovanie pravidiel pre manipuláciu a transformáciu paketov s
použitím netfilter frameworku.
V kubernetes sú pravidlá iptables konfigurované pomocou kube-proxy kontroléra, ktorý sleduje zmeny v Kubernetes API servri. Keď zmena Služby alebo Podu zmení
virtuálnu adresu Služby, alebo IP adresu Podu, potom iptables aktualizuje pravidlá a správne nasmeruje prevádzku na Službu alebo so službou asociovaný Pod.
Pravidlá iptables sledujú prevádzku určenú pre virtuálnu adresu Služby a pri zhode je vybraná náhodná IP adresa z množiny IP adries dostupných Podov.

19. Sieťovanie Podu so Službou
IPVS
• IP Virtual Server (IPVS)
• uvedený v Kubernetes v1.11
• slúži na vyrovávanie záťaže v klástri
• postavená nad netfiltrom
• implementuje rozloženie záťaže transportnej (L4) vrstvy
• prirodzené riešenie pre Služby v Kubernetes
IPVS (IP Virtual Server) je taktiež postavený nad netfiltrom a implementuje rozloženie záťaže transportnej (L4) vrstvy ako súčasť jadra Linuxu. IPVS je začlenený do LVS
(Linux Virtual Server), kde beží na hostiteľovi a funguje ako nástroj na vyrovnávanie záťaže skutočných hardvérových serverov. IPVS môže smerovať požiadavky založené
na TCP a UDP portoch smerom na skutočné servre a umožniť, aby sa služby skutočných serverov javili ako virtuálne služby na jednej IP adrese. Vďaka tomu je IPVS
prirodzeným riešením pre Kubernetes Services.
Pri deklarovaní služby Kubernetes môžete určiť, či chcete, aby sa vyvažovanie záťaže v klastri uskutočňovalo pomocou iptables alebo pomocou IPVS. IPVS je špeciálne
navrhnutý pre rozloženie záťaže a využíva efektívnejšie dátové štruktúry (hašovacie tabuľky), čo umožňuje takmer neobmedzený rozsah v porovnaní s iptables. Dnes je
možné taktiež využiť nginx load balancer. Pozrime sa ako to vyzerá v praxi.

20. Sieťovanie Podu so Službou
život paketu pri komunikácii Podu so Službou
• 1. z eth0 na veth0 (štandard)
• 2. z veth0 do cbr0 (štandard)
• 3. cbr0 nepozná destináciu, posiela na
default route
• 4. paket filtrovaný pomocou iptables
prepíše cieľovú IP adresu.
• paket je smerovaný na IP Pod4
• a nie na IP adresu Služby
• na zapamätanie voľby iptables
používajú nástroj conntrack
Keď prebieha smerovanie paketu medzi Podom a Službou, cesta začína rovnako ako predtým. Na začiatku paket opustí Pod cez rozhranie eth0, ktorý je pripojený na
menný priestor Podu. [klik] Potom cestuje cez virtuálne ethernetové zariadenie do mostu. ARP protokol bežiaci na moste nevie nič o Službe a tak sa paket pošle na
default route - eth0 (3). A až tu nastane nečo iné. Ešte pred tým ako je paket prijatý na eth0, je paket filtrovaný cez iptables. Iptables použijú pravidlá nainštalované na
Nod z kube-proxy ako odpovedať na udalosti Služby alebo Podu a prepíše cieľ paketu z IP adresy Služby na špecifickú IP adresu Podu. V tejto chvíli je paket smerovaný
do cieľa na Pod4.
Iptables využívanú nástroj conntrack linuxového jadra, pomocou neho si pamätajú voľbu Podu, ktorá bola spravená a tak v búdúci tok dát je smerovaný na rovnaký Pod.
Samozrejme ak abstrahujeme od udalosti škálovania, ktorá mohla medzičasom nastať.
V základe iptables spravili load-balancing vrámci klástra priamo na Node.

21. Sieťovanie Podu so Službou
život paketu pri komunikácii Služby s Podom
• 1. Pod identifikuje paket ako ten,
ktorý odosielal.
• 2.iptables využije conntrack na
prepísanie zdrojovej adresy na IP
virtuálnu adresu Služby.
• 3. paket je smerovaný cez most na
virtuláne ethernetové zariadenie
asociované s menný priestorom
Podu.
• 4. už známa cesta k Podu1.
Pri ceste späť, zo Služby do Podu, Pod ktorý príjme tento paket odpovie tým, že identifikuje zdrojovú IP adresu ako svoju vlastnú a cieľovú adresu ako adresu Podu,
ktorý pôvodne paket odoslal. [klik] Pri vstupe paket cestuje cez iptables, ktorý použije funkciu conntrack, ktorá si pamätá rozhodnutie už spravené pri odosielaní
pôvodného paketu a prepíše zdroj paketu z Pod4 adresy na IP adresu Služby. Následne už paket cestuje rovnako ako sme si už povedali v predchádzajúcich slajdoch.

22. Sieťovanie Podu so Službou
DNS
• pomáha obísť konfigurácie pevnej IP adresy Klástra do aplikácie.
• beží ako služba Kubernetes
• Konfiguruje kubelety bežiace na každom Node
• kontajnery používali IP službu DNS na rozlíšenie mien DNS
• Každá služba definovaná v klastri (vrátane samotného servera DNS) má
priradený názov DNS.
• na pomenovanie portov pre spustené služby používam SRV záznam
Kubernetes môže voliteľne používať DNS, aby ste sa vyhli nutnosti kódovania IP adresy Klastra do vašej aplikácie. Kubernetes DNS beží ako bežná služba Kubernetes,
ktorá je schedulovaná (plánovaná) v Klástri. Konfiguruje kubelety bežiace na každom Node tak, aby kontajnery používali IP službu DNS na rozlíšenie mien DNS. Každá
služba definovaná v klastri (vrátane samotného servera DNS) má priradený názov DNS. Záznamy DNS prekladajú názvy DNS na IP adresu klastra, resp. Služby alebo IP
adresu Podu, podľa vašich požiadaviek. Záznamy SRV sa používajú na určenie konkrétnych pomenovaných portov pre spustenie služieb.

23. Sieťovanie Podu so Službou
DNS Pod
• DNS Pod sa skladá z troch samostatných kontajnerov:
• kubedns: sleduje zmeny v Službách a koncových bodoch Kubernetes mástra a
udržiava vyhľadávacie štruktúry v pamäti, aby poskytoval odpovede na DNS požiadavky
• dnsmasq: na zvýšenie výkonu pridáva ukladenie do DNS cache medzipamäte.
• sidecar: poskytuje jediný koncový bod pre opakované kontroly stavu
• a vykonáva kontroly stavu pre dnsmasq a kubedns.
• CoreDNS pracuje podobne ako kubedns ale je vybudovaný plugin architektúrou, čo to ho
robí oveľa viac flexiblnou. CoreDNS je štandardnou DNS implementáciou pre Kubernetes
(od verzie 1.11)
DNS Pod sám o sebe je vystavený ako Kubernetes Služba so statickou IP adresou Klástra, ktorá je predaná každému bežiacemu kontajneru už pri štarte a teda každý
kontajner vie vyriešiť DNS požiadavky na vstupe.

24. Sieťovanie Internetu so Službou
Egress - smerovanie do Internetu
• Smerovanie dátovej prievádzky je zviazané na vlastnosti siete, ktorou tieto
dáta pretekajú.
• V AWS Kubernetes Kláster beží vrámci VPC (Virtual Private Cloud)
• každý Node má pridelenú privátnu IP adresu s ktorou komuniku vrámci
tohto Klástra.
• Pripojenie internetovej brány (Internet Gateway) umožní komunikáciu do
Klástra z vonku.
• NAT preklad je zodpovedný za zmenu internej IP adresy Nodu na externú IP
adresu, dostupnú vo verejnej sieti Internet
Smerovanie dátovej prevádzky z Nodu do verejnej siete Internet je špecificky orientované na použitú sieť, prostredie a skutočne závisí na tom ako je vaša sieť
nakonfigurovaná pre zverejňovanie dátovej prevádzky. Aby som túto časť spravil konkrétnejšiu, použijem AWS VPC.
V Amazon Web Services je to Virtuálny Privátny Cloud. Kubernetes Kláster beží vrámci VPC, kde každému Node je pridelená privátna IP adresa, ktorá je dostupná vrámci
Kubernetes klástra. Aby sme umožnili komunikáciu do Klástra zvonku, musíme do VPC pripojiť Internetovú bránu (Internet gateway). Internetová brána služi na dvom
účelom: slúži ako cieľ v routovacej tabuľke vášho VPC pre dátový tok smerovaný do Internetu a vybavuje Preklad IP adries (NAT) pre inštancie, ktorým bola priradená
verejná IP adresa.
NAT preklad je zodpovedný za zmenu internej IP adresy Nodu, ktorá je v Klástri privátna na externú IP adresu, ktorá je dostupná vo verejnej sieti Internet.

25. Sieťovanie Internetu so Službou
Egress - smerovanie z Nodu do Internetu
• 3. ip tables prerobí paket pomocou
NAT prepíše zdrojovú IP adresu
• 4. Paket opúšťa VM cez eth0
smerom k Internetovej Bráne.
• 5. Paket príde do Internetovej brány.
• IB prepíše pomocou NAT
zdrojovú IP adresu na externú.
• 6. Paket opúšťa IB smerom do
Internetu
Cestu paketu po bod 3 poznáme. Paket úríde z cbr0 cez default gateway smerom na eth0 koreňového menného priestoru. [klik] Avšak, ešte pred tým, ako sa paket
dostane do koreňového menného priestoru (bod 3), iptables prerobí tento paket. V tomto prípade zdrojová IP adresa paketu je Pod, a ak by sme ponechali Pod ako zdroj,
Internetová brána by ho odmietla, pretože NAT brány rozumie IP adresám, ktoré sú pripojené do Virtuálnej Mašiny (VM). Riešením je, že iptables vykoná NAT na zdroji -
zmenou zdrojovej IP adresy - takže paket bude vyzerať, že prichádza z Virtuálnej Mašiny a nie z Podu. So prepísanou správnou zdrojovou IP adresou môže teraz paket
opustiť Virtuálnu Mašinu (bod 4) a dobehnúť až do Internetovej Brány (5).
Internetová Brána vykoná preklad adresy pomocou NAT a prepíše zdrojovú adresu z internej adresy Virtuálnej Mašiny na externú IP adresu. A nakoniec paket dobehne do
verejnej siete Internet. (6).
Na ceste späť paket nasleduje rovnakú cestu a ľubovoľná zdrojová IP adresa, ktorá bola prerobená je upravená späť a tak každá vrstva systému príjme takú IP adresu,
ktorej rozumie.

26. Sieťovanie Internetu so Službou
Ingress - smerovanie z Internetu do Kubernetu
• Príjem paketov z internetu
• je prekvapivo zložitý problém, ktorý treba vyriešiť.
• špecifické podľa použitej siete
• Problém je rozdelený na dve časti:
• Service LoadBalancer
• Ingress Controller
Tok dát z Internetu do vášho klastra - je prekvapivo zložitý problém, ktorý je potrebné vyriešiť. Toto je opäť špecifické pre sieť, ktorú používate, ale vo všeobecnosti je
Ingress rozdelený na dve riešenia, ktoré fungujú na rôznych častiach sieťového zásobníka: (1) Service LoadBalancer a (2) Ingres kontrolér.

27. Sieťovanie Internetu so Službou
Ingress - Load Balancer na 4 vrstve
• Pri vytváraní služby môžete špecifikovať Load Balancer - nástroj na
vyrovnávanie zaťaženia.
• Cloudový kontrolér
• vytvorí load balancer pre vašu službu.
• V tomto momente môžete začať komunikovať s vašou službou smerovaním
dát na IP adresu load balancera.
Keď v Kubernetes vytvoríte Službu, voliteľne môžete špecifikovať Load Balancer, ktorý sa bude používať. Implementácia LoadBalancera je poskytnutá cloudovým
kontrolérom, ktorý už vie ako vytvoriť load balancer pre vašu Službu. V momente, keď sa vytvorí Služba, oznámi IP adresu load balancera. Ako koncový užívateľ môžete
začať smerovať prevádzku dát na load balaner, čim začnete komunikovať s vašou Službou.

28. Sieťovanie Internetu so Službou
Život paketu - z Load Balancera na Službu
• 1. Load Balancer vytvorený
vaším poskytovateľom služieb
• 2. Load Balancer distribuuje
tok dát smerom na VM vášho
Klástra
• 3. iptables vykoná správny
NAT
• 4. iptables preposiela paket
ďalej do správneho Podu
Pozrime sa ako funguje v praxi. V momente keď nasadíte svoju Službu, váš poskytovateľ cloudových služieb vytvorí pre vás nový load balancer (1). Pretože load balancer
nie je informovaný o kontajneroch, akonáhle sa dátová prevádzka dostane do load balancera, je distribuovaný na virtuálne mašiny, ktoré tvoria váš Kláster (2). Pravidlá
iptables umiestnené na každej virtuálnej mašine nasmerujú prichádzajúci prenos z load balancera do správneho Podu (3) - ide o rovnaké pravidlá IP tabuliek, ktoré boli
vložené do iptables počas vytvárania služby a o ktorých som už skôr hovoril. Odpoveď Podu klientovi sa vráti s adresou IP Podu, ale klient musí mať IP adresu load
balancera. iptables and conntrack sa používa na správne prepísanie IP adries na spiatočnej ceste, ako ste už videli na predchádzajúcich slajdoch. V tomto príklade
pravidlá v iptables bežiace na Virtuálnej Mašine nasmerujú paket na správny Pod pomocou pravidiel interného load balancera nainštalovaného do Klástra pomocou
kube-proxy. iptables vykoná správny NAT a preposiela paket ďalej do správneho Podu (4).

29. Sieťovanie Internetu so Službou
Ingress na 7. vrstve: Ingress Controller
• Ingress na 7. vrstve
• používa rozhas protokolu HTTP / HTTPS
• postavený na úplnom vrchu stohu Služieb
• Ak nastavíte typu služby NodePort
• Kubernetes master pridelí port z Vami definovaného rozsahu
• Každý Node bude robiť proxy pre tento port
Ingress na siedmej vrstve funguje na rozsahoch protokolu HTTP / HTTPS a je postavený úplnom vrchu stohu navrstvených Službieb. Prvým krokom k povoleniu Ingress
je otvorenie portu na vašej službe pomocou NodePort Služby v Kubernetes. Ak nastavíte pole Typ služby na NodePort, Kubernetes master pridelí port z rozsahu, ktorý
určíte, a každý Node bude robiť proxy tohto portu (rovnaké číslo portu na každom Node) vo vašej Službe. To znamená, že akákoľvek prevádzka smerovaná na port Nodu
bude ďalej smerovaná pomocou pravidiel iptables do Služby. Smerovanie tejto Služby na Pody sa riadi rovnakým interným vzorom load balancera klastra, o ktorom sme
už hovorili pri smerovaní prenosu zo služieb na Pody.

30. Sieťovanie Internetu so Službou
Život paketu - z Ingresu na Službu
• 1. IngressLoad Balancer
vytvorený vaším
poskytovateľom služieb
• 2. Load Balancer distribuuje
tok dát smerom na VM vášho
Klástra
• 3. iptables vykoná správny NAT
• 4. iptables preposiela paket
ďalej do správneho Podu
Život paketu pretekajúceho cez Ingress je veľmi podobný životu cez LoadBalancer. Kľúčové rozdiely spočívajú v tom, že Ingress vie o ceste URL adresy (umožňuje a
môže smerovať prenosy dát na Služby na základe návrhu svojej cesty) a že počiatočné spojenie medzi Ingressom a Nodom je cez port vystavený na Node pre každú
jednu Službu.
Pozrime sa, ako to funguje v praxi. Po nasadení vašej Služby vám cloudový provider, s ktorým pracujete, vytvorí nový Ingress load balancer (1). Pretože load balancer nie
je informovaný o kontajneroch, akonáhle sa dátová prevádzka dostane do load balancera, distribuuje sa medzi virtuálne mašiny, ktoré tvoria Váš klaster (2), cez
inzerovaný port pre vašu službu. Pravidlá iptables na každej virtuánej mašine nasmerujú prichádzajúci prenos z load balancera do správneho modulu Pod (3) - ako sme
už videli predtým. Odpoveď Podu klientovi sa vráti s IP adresou Podu, ale klient musí vedieť IP adresu load balancera. Ako sme už skôr videli, iptables and conntrack sa
používa na správne prepísanie adries IP na spiatočnej ceste.

31. Sieťový model v Kubernetes
sieťové problémy na riešenie - zhrnutie
• Na základe týchto znalostí sme vyriešili nasledujúce štyri komunikačné a
sieťové problémy:
• komunikácia a spojenie Kontajnera s Kontajnerom
• komunikácia a spojenie Podu s Podom
• komunikácia a spojenie Podu so Službou
• komunikácia a spojenie medzi Internetom a Službou
• Zdroj prezentácie a inšpirácie: Kevin Sookocheff: A Guide to the Kubernetes
Networking Model - blog
Dúfam, že som vám pomohol ukázať základy pre pochopenie sieťového modelu v Kubernetes a princíp akým sa realizujú bežné sieťové úlohy.
Oblasť vytvárania sietí je široká aj hlboká a nie je možné v tejto prezentácii pokryť všetko. Snažil som sa vám poskytnúť východiskový bod.

32. Ing. Filip Pohronský, DITEC a.s.
• twitter: @filippohronsky
• e-mail: pohronsky@ditec.sk
Sieťový model v k8s
Ako komunikujú kontajnery, pody, a služby?
Ďakujem za pozornosť
Ponorte sa do tém, ktoré vás zaujímajú a o ktorých chcete vedieť viac. Kedykoľvek sa zaseknete, využite dokumentáciu ku Kubernetes a našu Kubernetes komunitu,
ktorá vám pomôže zorientovať sa. Ďakujem za vašu pozornosť.