Az üzembe helyezett Kubernetes működése
A drónkövető alkalmazás több olyan összetevővel rendelkezik, amelyek egymástól elkülönítve vannak üzembe helyezve. Az Ön feladata, hogy konfigurálja ezeknek az összetevőknek az üzembe helyezését a fürtön. Itt áttekintheti az összetevők üzembe helyezéséhez rendelkezésre álló üzembe helyezési lehetőségek némelyikét.
Üzembe helyezési lehetőségek podokkal
A kubectl használatakor több lehetőség áll rendelkezésre a podok Kubernetes-fürtön történő üzembe helyezésére. A következő lehetőségek közül választhat:
- Podsablonok
- Replikációs vezérlők
- Replikakészletek
- Deployments
A négy Kubernetes-objektumtípus-definíció bármelyikét használhatja podok vagy podok üzembe helyezéséhez. Ezek a fájlok a YAML használatával írják le az üzembe helyezendő podok vagy podok kívánt állapotát.
Mi az a podsablon?
Egy podsablonnal az üzembe helyezni kívánt pod konfigurációja definiálható. A sablon olyan információkat tartalmaz, mint a tárolórendszerkép neve és a rendszerképek lekéréséhez használandó tárolóregisztrációs adatbázis. A sablon futásidejű konfigurációs információkat is tartalmaz, például a használandó portokat. A sablonok ugyanúgy definiálhatók YAML használatával, mint Docker-fájlok létrehozásakor.
Sablonok használatával manuálisan helyezhet üzembe podokat. A manuálisan üzembe helyezett podok azonban nem lesznek újraindítva meghibásodás, törlés vagy leállás után. Egy pod életciklusának kezelésére magasabb szintű Kubernetes-objektumot kell létrehoznia.
Mi az a replikációs vezérlő?
A replikációs vezérlő podsablonokat használ, és meghatározza a kötelezően futtatni kívánt podok számát. A vezérlő segítségével több példányban futtathatja ugyanazt a podot, és gondoskodhat arról, hogy a podok mindig fussanak a fürt egy vagy több csomópontján. A vezérlő új podokkal cseréli le a futó podokat, ha azok meghibásodnak, törlődnek vagy leállnak.
Tegyük fel például, hogy telepíti a drónkövetés előtérbeli webhelyét, és a felhasználók elkezdenek hozzáférni a webhelyhez. Ha bármilyen okból az összes pod leáll, a webhely nem lesz elérhető a felhasználók számára, csak ha új podokat indít. Replikációs vezérlő segítségével biztosíthatja, hogy a webhely mindig rendelkezésre álljon.
Mi az a replikakészlet?
Replikálási vezérlő helyett javasolt replikakészletek használatával elvégezni a replikák üzembe helyezését. A replikakészletek ugyanazokat a funkciókat tartalmazzák, mint a replikációvezérlők, de egy további konfigurációs lehetőséggel is rendelkezik, amely egy választóértéket is tartalmaz.
A szelektor teszi lehetővé, hogy a replikakészlet az alatta futó összes podot azonosítsa. Ezzel a funkcióval kezelhetők a szelektorértékkel megegyező értékkel címkézett, de nem a replikált készlettel létrehozott podok.
Mi az az üzembe helyezés?
Az üzembe helyezés egy replikakészletnél magasabb szintű felügyeleti objektumot hoz létre, és lehetővé teszi a podok frissítéseinek üzembe helyezését és kezelését egy fürtben.
Tegyük fel, hogy az alkalmazás öt példánya van üzembe helyezve a fürtben. Az alkalmazás 1.0.0 verzióját öt pod futtatja.
Ha úgy dönt, hogy manuálisan frissíti az alkalmazást, eltávolíthatja az összes podot, majd elindíthatja az alkalmazás 2.0.0-s verzióját futtató új podokat. Ezzel a stratégiával az alkalmazás leállást tapasztal.
Ehelyett egy olyan gördülő frissítést szeretne végrehajtani, amelyben a podokat az alkalmazás új verziójával indítja el, mielőtt eltávolítja a régebbi alkalmazásverziójú podokat. A gördülő frissítések egyszerre egy podot indítanak el ahelyett, hogy egyszerre levenni az összes régebbi podot. Az üzembe helyezések figyelembe veszik a replikáknak a replikakészletek adatait leíró szakaszban konfigurált számát. Fenntartja a replikakészletben megadott podok számát, mivel a régi podokat új podokra cseréli.
Az üzembe helyezések alapértelmezés szerint működés közbeni frissítési stratégiát biztosítanak a podok frissítésekor. Újbóli létrehozási stratégiát is alkalmazhat. Ez a stratégia az új podok elindítása előtt leállítja a podokat.
Az üzembe helyezések egy visszaállítási stratégiát is biztosítanak, amelyet a kubectl használatával lehet végrehajtani.
Az üzembe helyezések YAML-alapú definíciós fájlokat használnak, és megkönnyítik az üzemelő példányok kezelését. Ne feledje, hogy az üzembe helyezések lehetővé teszik bármilyen módosítás alkalmazását a fürtökre. Például telepítheti az alkalmazások új verzióit, frissítheti a címkéket és futtathatja a podok más replikáit.
A kubectl szintaxisával egyszerűen elvégezhető az automatikus üzembe helyezés, ha a kubectl run parancsot használja a pod üzembe helyezéséhez. Ez a parancs egy üzemelő példányt hoz létre a szükséges replikakészlettel és podokkal. A parancs azonban nem hoz létre definíciós fájlt. Ajánlott eljárás az összes üzembe helyezés központi telepítési definíciós fájlokkal való kezelése és a módosítások nyomon követése verziókövetési rendszer használatával.
Deployment considerations
A Kubernetes a fürt hálózatkezelésének és tárolásának konfigurálására vonatkozó konkrét követelményekkel rendelkezik. Ennek a két aspektusnak a konfigurálása befolyásolja, hogy milyen döntéseket hozhat az alkalmazásoknak a fürt hálózatán való elérhetővé tételéhez és az adatok tárolásához.
A drónkövető alkalmazás egyes szolgáltatásainak például speciális követelményei vannak a felhasználói hozzáférésre, a folyamatok közötti hálózati hozzáférésre és az adattárolásra vonatkozóan. Most tekintse meg a Kubernetes-fürtök ezen aspektusait, és hogy ezek hogyan befolyásolják az alkalmazások üzembe helyezését.
Kubernetes-hálózatkezelés
Tegyük fel, hogy olyan fürttel rendelkezik, amelyhez egy vezérlősík és két csomópont tartozik. Ha csomópontokat ad hozzá a Kuberneteshez, a rendszer automatikusan hozzárendel egy IP-címet az egyes csomóponthoz egy belső magánhálózat-tartományból. Tegyük fel például, hogy a helyi hálózati tartománya 192.168.1.0/24.
A rendszer az összes telepített podhoz hozzárendel egy IP-címet az IP-címkészletből. Tegyük fel például, hogy a konfiguráció a 10.32.0.0/12 hálózati tartományt használja az alábbi képen látható módon.
Alapértelmezés szerint a különböző IP-címtartományokat használó podok és a csomópontok nem tudnak kommunikálni egymással.
A helyzet ráadásul még bonyolultabb, hiszen a podok átmenetiek. A podok IP-címe ideiglenes, és nem használható egy újonnan létrehozott podhoz való újrakapcsolódáshoz. Ez a konfiguráció hatással van arra, hogy az alkalmazás hogyan kommunikál a belső összetevőivel, és hogy Ön és a szolgáltatások hogyan kommunikálnak vele külsőleg.
A kommunikáció egyszerűsítése érdekében a Kuberneteshez a hálózatkezelést úgy kell konfigurálnia, hogy:
- A podok hálózati címfordítás (NAT) nélkül kommunikálhassanak egymással a csomópontok között.
- A csomópontok NAT nélkül kommunikálhassanak az összes poddal és viszont.
- A csomópontokon lévő ügynökök kommunikálhassanak az összes csomóponttal és poddal
A Kubernetes számos hálózatkezelési megoldást kínál, amelyeket telepíthet a hálózatkezelés konfigurálásához. Ilyen például az Antrea, a Cisco Application Centric Infrastructure (ACI), a Cilium, a Flannel, a Kubenet, a VMware NSX-T és a Weave Net.
A felhőszolgáltatók saját hálózati megoldásokat is biztosítanak. Az Azure Kubernetes Service (AKS) például támogatja az Azure Virtual Network tárolóhálózati adaptert (CNI), a Kubenetet, a Flannelt, a Ciliumot és az Antreát.
Kubernetes-szolgáltatások
A Kubernetes-szolgáltatások olyan Kubernetes-objektumok, amelyek stabil hálózatkezelést biztosítanak a podokhoz. A Kubernetes-szolgáltatások teszik lehetővé a csomópontok, podok és (belső és külső) alkalmazásfelhasználók fürttel való kommunikációját.
A Kubernetes hozzárendel egy IP-címet a szolgáltatáshoz annak létrehozásakor, ugyanúgy, mint egy csomóponthoz vagy podhoz. Ezek a címek egy szolgáltatásfürt IP-címtartományából lesznek hozzárendelve; például: 10.96.0.0/12. A szolgáltatás emellett DNS-nevet is kap a szolgáltatásnév és az IP-port alapján.
A drónkövető alkalmazásban a hálózati kommunikáció a következő:
A webhely és a RESTful API a fürtön kívüli felhasználók számára is elérhető.
A memóriában tárolt gyorsítótár és az üzenetsor szolgáltatás elérhető az előtér illetve a RESTful API számára, de a külső felhasználók számára nem.
Az üzenetsor hozzáférést igényel az adatfeldolgozási szolgáltatáshoz, de a külső felhasználókhoz nem.
A NoSQL-adatbázis elérhető a memóriában tárolt gyorsítótár és az adatfeldolgozási szolgáltatás számára, de a külső felhasználók számára nem.
Ezeknek a forgatókönyveknek a támogatásához háromféle szolgáltatást konfigurálhat az alkalmazás összetevőinek közzététele érdekében.
| Szolgáltatás | Leírás |
|---|---|
| ClusterIP | Egy szolgáltatáshoz rendelt cím, amely a szolgáltatást a fürtön belüli szolgáltatások számára teszi elérhetővé. Például az alkalmazás előtér- és háttérösszetevői közötti kommunikáció. |
| NodePort | A Kubernetes vezérlősík által a szolgáltatáshoz hozzárendelt 30000 és 32767 közötti csomópontport; például 192.169.1.11 fürtökön01. Ezután konfigurálja a szolgáltatást a podon egy olyan célport használatával, amelyet közzé szeretne tenni. Konfigurálhatja például a 80-as portot az előterek egyikét futtató podon. Most már elérheti az előteret egy csomóponti IP-címmel és portcímmel. |
| LoadBalancer | Az a terheléselosztó, amely lehetővé teszi a terhelés elosztását az alkalmazást futtató csomópontok között és a pod elérhetővé tételét nyilvános hálózati hozzáféréssel. A terheléselosztók általában a felhőalapú szolgáltatók használatakor konfigurálhatók. Ebben az esetben a külső terheléselosztóból érkező forgalmat a rendszer az alkalmazást futtató podokra irányítja. |
A drónkövető alkalmazásban dönthet úgy, hogy a nyomkövetési webhelyet és a RESTful API-t egy LoadBalancerrel és az adatfeldolgozási szolgáltatással teszi elérhetővé egy ClusterIP használatával.
A podok csoportosítása
A podok IP-cím szerinti kezelése nem praktikus. A pod IP-címei változnak, miközben a vezérlők újra létrehozzák őket, és tetszőleges számú podot futtathat.
A szolgáltatásobjektumok szelektorcímkék használatával teszik lehetővé a fürt adott podjának megcélzását és kezelését. A szelektorcímkét a szolgáltatás definíciójában állíthatja be úgy, hogy megegyezzen a pod definíciós fájljában megadott podcímkével.
Tegyük fel például, hogy sok futó podja van. Ezen podok közül csak néhány van az előtérben, és Ön olyan terheléselosztó-szolgáltatást szeretne beállítani, amely csak az előtérbeli podokat célozza meg. A szolgáltatást alkalmazhatja úgy, hogy közzétegye ezeket a podokat a pod címkéjére szelektorértékként való hivatkozással a szolgáltatás definíciós fájljában. A szolgáltatás csak a címkének megfelelő podokat csoportosítja. Ha egy podot eltávolítanak és újra létrehoznak, az új pod a megfelelő címkével automatikusan hozzáadódik a szolgáltatási csoporthoz.
Kubernetes-tár
A Kubernetes ugyanazt a tárkötet fogalmat használja, amely a Docker esetében is használatos. A Docker-kötetek kevésbé felügyeltek, mint a Kubernetes-kötetek, mivel a Docker-kötetek élettartama nem felügyelt. A Kubernetes-kötet élettartama egy explicit élettartam, amely megfelel a pod élettartamának. Ez az élettartam-egyezés azt jelenti, hogy a kötet túléli a podon futó tárolókat. Ha azonban a podot eltávolítja, akkor a kötet is el lesz távolítva.
A Kubernetes lehetőségeket kínál az állandó tár PersistentVolumes használatával való kiépítésére. A PersistentVolumeClaims használatával adott tárterületet is igényelhet a podokhoz.
A megőrzött tárterületet (például üzenetsorokat és adatbázisokat) igénylő alkalmazás-összetevők telepítése során mindkét megfontolást figyelembe kell vennie.
Felhőalapú integrációs megfontolások
A Kubernetes nem írja elő a natív felhőalkalmazáshoz használandó technológiai eszközöket. Egy felhőalapú környezetben, például az Azure-ban a Kubernetes-fürtön kívül számos szolgáltatást használhat.
Korábban már volt szó arról, hogy a Kubernetes az alábbi szolgáltatások egyikét sem nyújtja:
- Közbenső szoftver
- Adatfeldolgozási keretrendszerek
- Databases
- Gyorsítótárak
- Fürttárolási rendszerek
Ebben a drónkövető megoldásban három szolgáltatás biztosítja a köztes szoftver funkcióit: egy NoSQL-adatbázist, egy memóriabeli gyorsítótár szolgáltatást és egy üzenetsort. Választhatja a MongoDB Atlast a NoSQL-megoldáshoz, a Redist a memóriabeli gyorsítótár kezeléséhez, a RabbitMQ-t vagy a Kafkát az üzenetsor igényeitől függően.
Felhőalapú környezet, például az Azure használata esetén ajánlott eljárás a Kubernetes-fürtön kívüli szolgáltatások használata. Ez a döntés egyszerűsítheti a fürt konfigurációját és felügyeletét. Használhatja például az Azure Cache for Redist a memóriában tárolt gyorsítótárazási szolgáltatásokhoz, az Azure Service Bus-üzenetkezelést az üzenetsorhoz, valamint az Azure Cosmos DB-t a NoSQL-adatbázishoz.