Az előző blogban , biztosan megértetted a Kubernetes-t. Ebben a blogban a Kubernetes hálózatról elsősorban a Kubernetes hálózatépítési koncepcióira fogok összpontosítani.
Ebben a Kubernetes Networking blogban a következő témákat fogja megérteni:
Mi az a Kubernetes?
Meghatározhatja a Kubernetes-t nyílt forráskódú tároló-hangszerelő eszközként, amely hordozható platformot biztosít a konténeres alkalmazások telepítésének automatizálásához.
Most bárkinek, aki a Kubernetesszel dolgozik, tisztában kell lennie a Kubernetes Klaszterrel, mivel ez segít megérteni a Kubernetes Hálózatot.
Kubernetes Klaszter
A Kubernetes platform a kívánt állapotmenedzsmentet kínálja, amely lehetővé teszi a fürtszolgáltatások futtatását, az összevont konfigurációt az infrastruktúrában. Hadd magyarázzam el egy példával.
Vegyünk egy YAML fájlt, amely tartalmazza az összes konfigurációs információt, amelyet be kell tölteni a fürt szolgáltatásaiba. Tehát ezt a fájlt betáplálják a fürtszolgáltatások API-jába, majd a fürtszolgáltatások feladata lesz kitalálni, hogyan kell ütemezni a csomagokat a környezetben. Tehát tegyük fel, hogy két tároló kép van az 1. hüvelyhez, három replikával, és egy tároló kép a 2. hüvelyhez, két replikával, a fürt szolgáltatásain múlik, hogy ezeket a pod-replika párokat kiosztja-e a dolgozóknak.
hogyan kell megtanulni pl sql
Lásd a fenti ábrát. Most, amint láthatja, hogy a fürtszolgáltatások az első munkást két pod replika párral, a második dolgozót egyetlen pod-replica párral és a harmadik munkást két pod replika párral osztották ki. Most a Kubelet folyamat a felelős a klaszterszolgáltatások kommunikációjával a dolgozókkal.
Tehát a klaszterszolgáltatások egésze és maguk a munkavállalók alkotják ezt Kubernetes-fürt !!
Hogyan, szerinted hogyan kommunikálnak egymással ezek az egyedileg kiosztott hüvelyek?
A válasz a Kubernetes Networkingben rejlik!
Iratkozzon fel youtube csatornánkra, hogy új frissítéseket kapjon ..!
A hálózati koncepciókkal főként 4 problémát kell megoldani.
- Konténer konténer kommunikációhoz
- Pod to pod kommunikáció
- Pod to service kommunikáció
- A szolgáltatáson kívüli kommunikáció
Most hadd mondjam el, hogyan oldják meg a fenti problémákat a Kubernetes Networking.
Kubernetes Networking
A podok, a szolgáltatások és a külső szolgáltatások közötti kommunikáció a fürtben lévőkkel bevezeti a Kubernetes hálózati fogalmát.
Tehát jobb megértése érdekében hadd osszam fel a fogalmakat a következőkre.
- Pods & Container Communication
- Szolgáltatások
- Külső csatlakoztatása a szolgáltatásokhoz az Ingress hálózaton keresztül
Pods & Container Communication
Mielőtt elmondanám, hogyan kommunikálnak a hüvelyek, hadd mutassam be, mi az a hüvely?
Hüvelyek
A hüvelyek a Kubernetes alkalmazások alapvető egységei, amelyek egy vagy több tárolóból állnak, ugyanazon a gazdagépen allokálva egy hálózati verem és más erőforrások megosztására. Tehát ez azt jelenti, hogy a csomagban lévő összes tároló elérheti másokat egy helyi gazdagépen.
Most hadd tájékoztassam, hogyan kommunikálnak ezek a hüvelyek?
Kétféle kommunikáció létezik. Az csomópontok közötti kommunikáció és a csomóponton belüli kommunikáció.
Tehát kezdjük a csomóponton belüli kommunikációval, de előtte hadd mutassam be Önnek a pod hálózat összetevőit.
Csomóponton belüli hálózat alatt
A csomóponton belüli pod hálózat alapvetően ugyanazon pod két különböző csomópontja közötti kommunikáció. Hadd magyarázzam el egy példával.
Tegyük fel, hogy egy csomag pod1-ről pod2-re megy.
- A csomag eth0-n hagyja a Pod 1 hálózatát, a veth0-nél lép be a gyökérhálózatba
- Ezután a csomag áthalad a Linux hídra (cbr0), amely egy ARP kérés segítségével fedezi fel a rendeltetési helyet
- Tehát, ha a veth1 rendelkezik IP-vel, akkor a híd már tudja, hová továbbítsa a csomagot.
Most hasonló módon hadd mondjak el a csomópontok közötti pod kommunikációról.
Érdekli a Kubernetes tanulása?Csomópontok a hálózat alatt
Tekintsünk két csomópontot, amelyek különféle hálózati névterekkel, hálózati interfészekkel és Linux-híddal rendelkeznek.
Tegyük fel, hogy egy csomag pod1-ből egy pod4-be utazik, amely egy másik csomóponton van.
- A csomag elhagyja az 1. pod hálózatot, és a veth0 címen lép be a gyökérhálózatba
- Ezután a csomag átkerül a Linux hídra (cbr0), amelynek feladata ARP kérés benyújtása a cél megtalálásához.
- Miután a híd rájött, hogy ennek a csomagnak nincs rendeltetési címe, a csomag visszatér az eth0 fő hálózati interfészhez.
- A csomag most elhagyja az 1 csomópontot, hogy megtalálja a másik csomópont célját, és belép az útvonal táblába, aki a csomagot arra a csomópontra irányítja, amelynek CIDR blokkja tartalmazza a pod4-et.
- Tehát, most a csomag eléri a 2. csomópontot, majd a híd átveszi azt a csomagot, amely ARP-kérést küld, hogy kiderítse, hogy a veth0-hez tartozó IP.
- Végül a csomag keresztezi a csőpárt és eléri a pod4-et.
Tehát a hüvelyek így kommunikálnak egymással. Most pedig lépjünk tovább, és nézzük meg, hogyan segítenek a szolgáltatások a hüvelyek kommunikációjában.
Szóval, mit gondolsz a szolgáltatásokról?
Szolgáltatások
Alapvetően a szolgáltatások olyan erőforrás-típusok, amelyek úgy konfigurálnak egy proxyt, hogy továbbítsák a kéréseket egy sor sorozathoz, amelyek forgalmat fogadnak és a választó határozza meg. A szolgáltatás létrehozása után hozzárendelt IP-címet kap, amely a porton fogadja a kéréseket.
Most számos olyan szolgáltatástípus létezik, amelyek lehetőséget nyújtanak arra, hogy egy szolgáltatást a fürt IP-címén kívül tegyenek ki.
Szolgáltatások típusai
Főként 4 típusú szolgáltatás létezik.
ClusterIP: Ez az alapértelmezett szolgáltatástípus, amely a fürt belső IP-jén tárja fel a szolgáltatást azzal, hogy a szolgáltatást csak a fürtön belül éri el.
NodePort: Ez statikus porton teszi ki a szolgáltatást az egyes csomópontok IP-jén. Mivel, a ClusterIP automatikusan létrejön a szolgáltatás, amelyre a NodePort szolgáltatás irányítani fog. A fürtön kívül kapcsolatba léphetünk a NodePort szolgáltatással.
Terhelés elosztó: Ez az a szolgáltatástípus, amely a szolgáltatást külsőleg tárja fel egy felhőszolgáltató terheléselosztójával. Tehát automatikusan létrejönnek a NodePort és a ClusterIP szolgáltatások, amelyekre a külső terheléselosztó irányítani fog.
ExternalName : Ez a szolgáltatástípus a szolgáltatást a externalName mező visszaadásával a CNAME rekord értékével.
Szóval, srácok, akik a szolgáltatásokról szóltak. Most arra lehet kíváncsi, hogy a külső szolgáltatások hogyan kapcsolódnak ezekhez a hálózatokhoz?
Nos, ez nem más, mint Ingress hálózat .
Ingress hálózat
Nos, az Ingress hálózat a szolgáltatások leghatékonyabb módja, mivel a bejövő kapcsolatokat lehetővé tevő szabályok gyűjteménye konfigurálható úgy, hogy az elérhető URL-eken keresztül külső szolgáltatásokat nyújtson. Tehát alapvetően a Kubernetes-fürt belépési pontjaként működik, amely kezeli a fürt szolgáltatásaihoz való külső hozzáférést.
Most hadd magyarázzam el egy példával az Ingress Network működését.
2 csomópontunk van, a pod és a root hálózati névterek Linux-híddal rendelkeznek. Ezen felül a gyökérhálózathoz hozzáadunk egy új virtuális Ethernet eszközt is, a flannel0 (hálózati plugin) nevet.
Most azt akarjuk, hogy a csomag az 1. és a 4. pod között folyjon.
- Tehát a csomag eth0-nél hagyja a pod1 hálózatát, és a veth0-nél lép be a gyökérhálózatba.
- Ezután továbbítja a cbr0-nak, amely az ARP-t kéri a cél megtalálásához, majd megtudja, hogy ezen a csomóponton senki sem rendelkezik a cél IP-címmel.
- Tehát a híd elküldi a csomagot a flannel0-nak, mivel a csomópont útvonaltáblája a flannel0-val van konfigurálva.
- Most a flanel démon beszél a Kubernetes API szerverével, hogy ismerje az összes pod IP-t és a hozzájuk tartozó csomópontokat, hogy hozzárendeléseket hozzon létre az IP csomópontok IP-jéhez.
- A hálózati plugin ezt a csomagot egy UDP csomagba csomagolja, további fejlécekkel, amelyek megváltoztatják a forrás és a cél IP-t a saját csomópontjaikra, és ezt az csomagot eth0-n keresztül küldi el.
- Mivel az útválasztási tábla már tudja, hogyan kell forgalmat irányítani a csomópontok között, elküldi a csomagot a cél csomópont2-nek.
- A csomag megérkezik a 2. csomópont eth0-re, és visszamegy a flannel0-hoz kapszulázni és visszaküldi a gyökér hálózati névtérbe.
- Ismét a csomag továbbításra kerül a Linux hídhoz, hogy ARP kérelmet küldjön a veth1-hez tartozó IP megismerésére.
- A csomag végül átlépi a gyökérhálózatot és eléri a Pod4 rendeltetési helyet.
Tehát így kapcsolódnak a külső szolgáltatások egy behatoló hálózat segítségével. Most, amikor a hálózati bővítményekről beszéltem, hadd mutassam be a rendelkezésre álló népszerű hálózati bővítmények listáját.
Most, hogy annyit elmondtam neked a Kubernetes Networkingről, hadd mutassak meg egy valós esettanulmányt.
Esettanulmány: Vagyonvarázsló a Kubernetes Networking használatával
A Wealth Wizards egy online pénzügyi tervezési platform, amely ötvözi a pénzügyi tervezést és az intelligens szoftver technológiát, hogy megfizethető áron nyújtson szakértői tanácsokat.
Kihívások
Most rendkívül fontos volt, hogy a vállalat gyorsan felfedezze és kiküszöbölje a biztonsági réseket a felhőkörnyezet teljes láthatósága mellett, de hozzáférési korlátozásokkal akarta irányítani a forgalmat.
Tehát a Kubernetes infrastruktúrát használták a fürtök kiépítésének és bevezetésének kezeléséhez olyan eszközök segítségével, amelyek a Kube-fürtökön keresztül történő mikroszolgáltatások telepítésének és konfigurálásának kezelésére irányultak.
A Kubernetes hálózati házirend-funkcióját is alkalmazták, hogy hozzáférési korlátozások révén irányítsák a forgalmat.
Most az volt a probléma, hogy ezek a házirendek alkalmazásorientáltak, és csak az alkalmazásokkal együtt fejlődhetnek, de nem volt olyan összetevő, amely ezeket a házirendeket érvényesítette.
Tehát az egyetlen megoldás, amelyet a vállalat találhatott erre, az egy hálózati plugin használata volt, ezért elkezdték használni a Weave Net-t.
Megoldás
Ez a hálózati plugin létrehoz egy virtuális hálózatot, amely rendelkezik hálózati házirend-vezérlővel a Kubernetes-szabályok kezeléséhez és érvényesítéséhez. Nem csak ez, hanem a Docker-tárolókat is összeköti több állomáson, és lehetővé teszi azok automatikus felfedezését.
Tehát tegyük fel, hogy van egy munkaterhelése a fürtben, és le akarja állítani a fürt bármely más munkaterhelését. Ezt úgy érheti el, hogy olyan hálózati házirendet hoz létre, amely korlátozza a hozzáférést és csak az adott port behatolási vezérlőjén keresztül engedi meg a behatolást.
Az egyes Kubernetes-csomópontokon történő telepítésével a plugin kezeli az inter-pod útválasztást, és hozzáféréssel rendelkezik az IPtable-szabályok manipulálására. Egyszerűbben fogalmazva, az egyes házirendek IPtable-szabályok gyűjteményévé konvertálódnak, amelyeket minden gépen összehangolnak és konfigurálnak a Kubernetes-címkék fordításához.
Rendben, most, hogy annyi elméletet éltél át a Kubernetes Networkingről, hadd mutassam meg, hogyan történik ez gyakorlatilag.
Hands-On
Tehát azzal a feltételezéssel, hogy mindannyian telepítettétek a Kubernetes-t a rendszeretekre, van egy bemutatandó forgatókönyvem.
Tegyük fel, hogy el akarja tárolni a termék nevét és a termék azonosítóját, ehhez szüksége lesz egy webalkalmazásra. Alapvetően egy tárolóra van szükség a webalkalmazásokhoz, és még egy tárolóra van szükség MySQL-ként a háttérprogram számára, és ezt a MySQL-tárolót össze kell kapcsolni a webalkalmazás-tárolóval.
Mi lenne, ha a fenti példát gyakorlatilag végrehajtanám.
Lássunk neki!
1. lépés: Hozzon létre egy mappát a kívánt könyvtárban, és módosítsa a munka könyvtár elérési útját erre a mappára.
mkdir HandsOn cd HandsOn /
2. lépés: Most hozzon létre YAML telepítési fájlokat a webalkalmazáshoz és a MySQL adatbázishoz.
3. lépés: A telepítési fájlok létrehozása után telepítse mindkét alkalmazást.
kubectl Apply -f webapp.yml kubectl Apply -f mysql.yml
3.1. Lépés: Ellenőrizze mindkét telepítést.
kubectl telepítést kap
4. lépés: Most mindkét alkalmazáshoz szolgáltatásokat kell létrehoznia.
kubectl Apply -f webservice.yml kubectl Apply -f sqlservice.yml
4.1 lépés: A szolgáltatások létrehozása után telepítse a szolgáltatásokat.
4.2 lépés: Ellenőrizze, hogy a szolgáltatásokat létrehozták-e vagy sem.
kubectl szolgáltatást kap
5. lépés: Most ellenőrizze a futó hüvelyek konfigurációját.
kubectl kap hüvelyeket
6. lépés: Menjen be a tárolóba a webapp podban.
kubectl exec -it container_id bash nano var / www / html / index.php
6.1. Lépés : Most változtassa meg a $ kiszolgálónév a localhost-tól az SQL szolgáltatás nevéig, amely webapp-sql1 ”Ebben az esetben, és $ jelszó tól-ig ' edureka ”. Ezenkívül töltse ki az összes szükséges adatbázis-részletet, és mentse el az index.php fájlt a billentyűparancs segítségével Ctrl + x és azután nyomja meg Y mentéshez és nyomja meg belép .
7. lépés: Most menjen be a podban lévő MySQL tárolóba.
kubectl exec it container_id bash
7.1. Lépés: Szerezzen hozzáférést a MySQL-tároló használatához.
mysql -u gyökér -p edureka
Ahol az -u a felhasználót, a -p pedig a számítógép jelszavát jelenti.
7.2. Lépés: Hozzon létre egy adatbázist a MySQL-ben, amelyet felhasználni fog a webappból származó adatok megszerzésére.
DATABÁZIS LÉTREHOZÁSA ProductDetails
7.3. Lépés: Használja a létrehozott adatbázist.
HASZNÁLJA a termék részleteit
7.4. Lépés: Hozzon létre egy táblázatot ebben az adatbázisban a MySQL-ben, amely felhasználásra kerül az adatok megszerzéséhez a webappból.
CREATE TABLE termékek (termék_neve VARCHAR (10), product_id VARCHAR (11))
7.5. Lépés: Most a parancs segítségével lépjen ki a MySQL-tárolóból is kijárat .
8. lépés: Ellenőrizze a portszámot, amelyen a webalkalmazás működik.
kubectl szolgáltatásokat kap
8.1 lépés: Most nyissa meg a webalkalmazást a kiosztott portszámmal.
9. lépés: Ha rákattint a gombra Küldje be a lekérdezést , lépjen arra a csomópontra, amelyben a MySQL szolgáltatása fut, majd menjen a tárolóba.
Ez megmutatja az összes listás termék kimenetét, amelyek kitöltésével megadta a részleteket.
Érdekli a Kubernetes tanulása?Ha relevánsnak találta ezt a Kubernetes Networking blogot, nézze meg a az Edureka, egy megbízható online tanulási vállalat, amelynek több mint 250 000 elégedett tanulóval rendelkező hálózata elterjedt az egész világon.