Phenquestions
- A Kubernetes-fürtön telepített alkalmazás gyűjteményként működik.
- A hüvelyek lényegében több csomópontra ütemezett tárolók.
- A csomópontok lehetnek fizikai kiszolgálók vagy virtuális gépek, amelyeket a tárhelyszolgáltató kínál. Nyilvánvaló, hogy Kuberneteseket helyszíni szerveren is használhatja, ha úgy kívánja.
- Minden Pod egyedi IP-címmel rendelkezik.
- Az alkalmazás sok alkomponensre van felosztva, amelyeket gyakran mikroszolgáltatásnak neveznek.
- Az alkalmazás minden egyes mikroszolgáltatásához rendelkezzen megfelelő szolgáltatással a Kubernetesben.
- A Kubernetes összefüggésében a Szolgáltatás a hüvelyek gyűjteményét egyetlen absztrakciónak teszi ki a fürt többi része előtt. Egyetlen virtuális IP.
- Ez segít az alkalmazás egyik szolgáltatásának kommunikálni egy másik szolgáltatással. Ez egy absztrakció, amely lehetővé teszi a podok gyűjteményének címzését ahelyett, hogy megadná a pod IP-címét, bármikor, amikor beszélni szeretne vele.
- A Kubernetes szolgáltatás terheléselosztóként is működik az általa képviselt összes csomag számára. A forgalom egyenletesen oszlik el az összes csomóponton.
Eddig jó. Minden szolgáltatás beszélhet egy másik szolgáltatással. Ez a kommunikáció az egész Kubernetes-fürtön lehetséges
Szolgáltatások bemutatása
„Ha egy fa leesik egy erdőben, és senki nincs a közelben, hogy meghallja, hangot ad-e?”
Hasonló megjegyzés: ha az alkalmazás nem a Kubernetes fürtön kívüli célt szolgál, akkor valóban számít-e, hogy a fürt jól van-e felépítve? Valószínűleg nem.
Konkrét példaként tegyük fel, hogy van egy klasszikus webalkalmazásunk, amely egy Nodejs-be írt kezelőfelületből és egy Python-ba írt háttérből áll, amely MySQL adatbázist használ. Két megfelelő szolgáltatást telepít a Kubernetes-fürtjére.
Készít egy Dockerfile-t, amely meghatározza, hogyan kell csomagolni a frontend szoftvert egy konténerbe, és hasonlóképpen csomagolja a háttérprogramot is. Ezután a Kubernetes-fürtben két szolgáltatást telepít, amelyek mindegyike egy sor podot futtat maga mögött. A webszolgáltatás képes kommunikálni az adatbázis-fürttel és fordítva.
A Kubernetes azonban nem tárja fel ezen szolgáltatások (amelyek elengedhetetlen HTTP-végpontok) egyikét sem a világ többi részének. A hivatalos dokumentumok szerint:
„A szolgáltatásokat feltételezzük, hogy a virtuális IP-k csak a fürt hálózaton belül irányíthatók”
Ez biztonsági szempontból teljesen ésszerű, a szolgáltatásai képesek egymással beszélgetni, de a fürt nem engedi, hogy külső entitások közvetlenül beszéljenek a szolgáltatásokkal. Például csak a webes kezelőfelülete tud beszélni az adatbázis-szolgáltatással, és senki más nem is küldhet kéréseket az adatbázis-szolgáltatáshoz.
A probléma akkor merül fel, ha megvizsgáljuk a frontend szolgáltatás használatát. Ki kell tennie a többi nyilvánosság számára, hogy a végfelhasználók használhassák az alkalmazást. Az ilyen szolgáltatásokat a Kubernetes Ingress segítségével tesszük elérhetővé.
Kubernetes Ingress
Az Ingress a fürtön kívülről a fürtön belüli szolgáltatások felé tárja a HTTP és HTTPS útvonalakat. Az útválasztási szabályokat a Kubernetes Ingress erőforrás meghatározásával vezérelheti. De ennél sokkal többet tesz. Egyetlen szolgáltatás kitettsége elérhető más alternatívák, például a NodePort vagy a Terheléselosztók használatával, de ezek a szolgáltatások nem rendelkeznek olyan funkciókkal, amelyek elég kifinomultak egy modern webalkalmazáshoz.
Olyan funkciók, mint több alkalmazás egy IP-n való megjelenítése, útvonalak meghatározása stb.
Tehát értsük meg a cikk hátralévő részében ezeket a funkciókat:
Egyetlen szolgáltatás behatolása
Ez a legegyszerűbb változata egyetlen szolgáltatásnak, például egy webes felületnek IP-vel (vagy tartománynévvel), valamint az alapértelmezett HTTP és HTTPS portokkal (i.e, 80 és 443).
Egyetlen Fanout
Ez egy behatolási beállítás, amely lehetővé teszi, hogy a bejövő forgalmat egyetlen IP-re engedélyezze, és több szolgáltatáshoz irányítsa.
A következőkből áll:
- A behatolási erőforrás a hosztnévből áll.rúd.com
- Azon utak listája, ahol a forgalmat foo-módon fogják irányítani.rúd.com / admin foo.rúd.com / home foo.rúd.com / sso
Az egyetlen fanout az az eset, amikor egyetlen IP-t használnak több szolgáltatáshoz. A szolgáltatások különböző utakon lehetnek az URI-ban, például foo.rúd.A com / admin szolgáltatás lehet az adminisztrátorok és a foo számára.rúd.A com / home lehet az a szolgáltatás, amely minden felhasználó honlapját létrehozza.
A behatolási port mindig 80 vagy 443 lesz, de az a port, ahol a szolgáltatások futnak (a fürtön belül), meglehetősen eltérhet.
Ez a fajta behatolás segít minimalizálni a terheléselosztók számát a fürtben, mivel lényegében úgy működik, mint egy.
Név alapú virtuális tárhely
A nyilvános IP-címek végesek. Ezek is meglehetősen drágák. A névalapú virtuális tárhely ötlete régebbi, mint a Kubernetes. Ennek lényege, hogy a különböző webhelyek, például a ww1 DNS-rekordjait mutatja meg.példa.com és ww2.példa.com ugyanarra az IP-címre. Az az IP-címen futó kiszolgáló látni fogja a bejövő kérést, és ha a kérelemben említett gazdagép neve ww1.példa.com, akkor az Ön webhelyét szolgálja, és ha ww2.példa.com-t kérik, akkor azt kiszolgálják.
A Kubernetes összefüggésében két olyan szolgáltatást futtathatunk, amelyek mondjuk a 80-as porton futnak, és mindkettőt egyetlen IP-címre tesszük ki, a 80-as port behatolásával is. A bejutási ponton a ww1 forgalma.példa.com elválik a ww2 forgalmától.példa.com. Ezért a név alapú virtuális tárhely kifejezés.
Következtetés
A Kubernetes behatolása meglehetősen kifinomult, hogy egyetlen bejegyzéssel foglalkozzon vele. Különböző felhasználási esetek léteznek számára, és számos olyan Ingress vezérlő, amelyek hozzáadják az Ingress funkcionalitást a fürtjéhez. Azt javaslom, hogy kezdje az Nginx Ingress Controller-rel.
További részletekért és specifikációkért kövesse a hivatalos dokumentációt is.
