Phenquestions
Egy korábbi cikkünkben egy Kubernetes-fürtöt telepítettünk egy fő és egy munkás csomópontgal. A Kubernetes-klaszterek főleg két dologról szólnak; Csomópontok és hüvelyek. A hüvelyek a fürtön telepíteni kívánt tárolt alkalmazások, a csomópontok pedig az egyes számítási kiszolgálók, amelyek felelősek a fürt kezeléséért vagy az alkalmazások futtatásáért. A dolgok egyszerűbbé tétele érdekében egy hontalan alkalmazással kezdjük, és különféle fogalmakat vezetünk be, például címkéket és szelektorokat, amelyek a hüvelyek egymáshoz kötésére szolgálnak.
Vannak más fontos fogalmak is, mint a replika készletek, szolgáltatások és telepítések, amelyeket mind megtanulunk ebben a cikkben.
Hagyományos alkalmazás telepítés
Ha a webalkalmazás telepítésének hagyományos megközelítését nézi, a skálázhatóságot érdemes figyelembe vennie, mielőtt elindulna. Ha a webes kezelőfelülettől különálló adatbázisra van szüksége, akkor jobb, ha ezt most csinálja, nem pedig később. Több webes alkalmazást tervez-e futtatni? Jobb előre konfigurálni a Reverse Proxy szervert.
A Kubernetes alkalmazásával a megközelítés megváltozott. A telepítés az aktuális igények figyelembevételével történhet, és később a vállalkozás növekedésével bővülhet. A tárolás lehetővé teszi a webszolgáltatások alapvető összetevőinek elkülönítését, még akkor is, ha azok egyetlen csomóponton futnak. Később, ha vízszintesen méretez (ami azt jelenti, hogy több szervert ad hozzá a környezetéhez), egyszerűen több tárolót kell felpörgetnie, és a Kubernetes ütemezi az Ön számára megfelelő csomópontokra. Fordított proxy? A Kubernetes szolgáltatásai be fognak jönni a probléma megoldására.
Hüvelyek
Első lépésként tekerjünk fel egy hüvelyt. Ehhez szükségünk lesz egy YAML fájlra, amely meghatározza a pod különféle attribútumait.
apiVersion: v1fajta: Pod
metaadatok:
név: nginx
specifikáció:
konténerek:
- név: nginx
kép: nginx: 1.7.9
portok:
- containerPort: 80
Adja hozzá a fenti tartalmat a hüvely.yaml fájlt, és mentse el. A fenti szöveget megnézve láthatja, hogy a kedves az általunk létrehozott erőforrás a hüvely. Elneveztük nginx, és a kép az nginx: 1.7.9 ami alapértelmezésben azt jelenti, hogy a Kubernetes lekéri a megfelelő nginx képet a Docker hub nyilvánosan elérhető képeiből.
Nagyszabású szervezetekben a K8 gyakran úgy van konfigurálva, hogy egy privát nyilvántartásra mutasson, ahonnan lehúzhatja a megfelelő tároló képeket.
Most kezdje el a pod futást:
$ kubectl create -f pod.yamlA fürtön kívülről nem érhető el a csomag. Még nincs kitéve, és csak magányos hüvelyként létezik. Annak biztosítása érdekében, hogy valóban telepítve legyen, futtassa:
$ kubectl kap hüvelyeket
Megszabadulni a megnevezett hüvelytől nginx, futtassa a parancsot:
$ kubectl törölje a pod nginx fájltTelepítések
Csak egy működő pod megszerzése nem a Kubernetes lényege, ideális esetben egy pod többszörös másolatát szeretnénk, amelyet gyakran különböző csomópontokra ütemeznek, így ha egy vagy több csomópont meghibásodik, a többi pod továbbra is ott lesz, hogy vegye növeli a további terhelést.
Ezenkívül fejlesztési szempontból szükségünk lenne valamilyen módon kialakítani a hüvelyeket a szoftver újabb verziójával, és a régebbi hüvelyeket alvóvá tenni. Abban az esetben, ha van egy probléma az újabb poddal, akkor visszagörgethetjük a régebbi podok visszahozásával és a sikertelen verzió törlésével. A telepítések lehetővé teszik ezt.
Az alábbiakban nagyon gyakran meghatározható a telepítés:
apiVersion: apps / v1beta1fajta: Telepítés
metaadatok:
név: nginx-telepítés
specifikáció:
másolatok: 2
sablon:
metaadatok:
címkék:
app: nginx
specifikáció:
konténerek:
- név: nginx
kép: nginx: 1.7.9
portok:
- containerPort: 80
Észre fogja venni többek között egy kulcs-érték párost:
címkék:
alkalmazás: nginx
A címkék fontosak a klaszterkezelés szempontjából, mivel segítenek nyomon követni az azonos feladattal rendelkező számos hüvely számát. A hüvelyeket a fő csomópont parancsára hozzák létre, és kommunikálnak a fő csomópontgal. Mindazonáltal még mindig szükségünk van egy hatékony módra, hogy beszéljenek egymással és csapatban működjenek együtt.
Szolgáltatások
Mindegyik podnak megvan a saját belső IP címe, és a Flannelhez hasonló kommunikációs réteg segíti a podokat egymással való kommunikációban. Ez az IP-cím azonban meglehetősen megváltozik, és végül is a sok hüvely meglétének lényege az, hogy eldobhatók legyenek. A hüvelyeket gyakran megölik és feltámadják.
A most felmerülő kérdés ez: Hogyan fognak a front-end podok beszélni a back-end podokkal, amikor a dolgok annyira dinamikusak a fürtben?
A szolgáltatások képbe kerülnek, hogy megoldják ezt a bonyolultságot. A szolgáltatás egy újabb csomag, amely terheléselosztóként viselkedik az alhálózatok egy részhalmaza és a Kubernetes-fürt többi része között. Megköti magát az összes podhoz, amelyhez külön címke van csatolva, például adatbázishoz, majd kiteszi őket a fürt többi részébe.
Például, ha van egy adatbázis-szolgáltatásunk 10 adatbázis-hüvellyel, az adatbázis-állományok egy része feljöhet vagy megölhető, de a szolgáltatás biztosítja, hogy a fürt többi része megkapja a 'szolgáltatást', amely egy adatbázis. A szolgáltatások arra is használhatók, hogy a kezelőfelületet tegyék ki az internet többi részének.
Itt van egy szolgáltatás tipikus meghatározása.
apiVersion: v1fajta: Szolgáltatás
metaadatok:
név: wordpress-mysql
címkék:
app: wordpress
specifikáció:
portok:
- kikötő: 3306
választó:
app: wordpress
szint: mysql
clusterIP: Nincs
A WordPress címkével ellátott, a megadott mysql réteggel rendelkező hüvelyeket veszi fel ez a szolgáltatás, és a webszerver hüvelyeinek teszik ki a Kubernetesen felépített tipikus WordPress számára.
Óvatosan
Egy óriási többszintű alkalmazás nagy fogyasztói bázisra történő telepítésekor nagyon csábítóvá válik sok szolgáltatás (vagy mikroszolgáltatás, mint közismert) megírása. Bár ez elegáns megoldás a legtöbb felhasználási esetre, a dolgok gyorsan kijuthatnak a kezükből.
A szolgáltatások, mint a hüvelyek, hajlamosak a kudarcra. Az egyetlen különbség az, hogy amikor egy szolgáltatás meghibásodik, sok, tökéletesen működőképes hüvely használhatatlanná válik. Következésképpen, ha nagymértékben összekapcsolja a szolgáltatásokat (mind a belső, mind a külső szolgáltatásokat), és valami nem sikerül, akkor a kudarc pontjának kiderítése lehetetlenné válik.
Alapszabályként, ha durva megjelenítéssel rendelkezik a fürtről, vagy ha olyan szoftvereket használhat, mint a pilótafülke, a fürt megtekintésére és értelmezésére, akkor a telepítése rendben van. A nap végén a Kubernetes célja a bonyolultság csökkentése, nem pedig fokozása.
