Ha a Linux szolgáltatást kívánja használni egy vállalkozás számára, ezeknek a szolgáltatásoknak biztonságosnak, rugalmasnak és méretezhetőnek kell lenniük. Szép szavak, de mit értünk velük?
‘biztonságos’ azt jelenti, hogy a felhasználók hozzáférhetnek a szükséges adatokhoz, legyen az írásvédett vagy írásos hozzáférés. Ugyanakkor egyetlen adatot sem szabad kitéve annak a félnek’nem jogosult látni. A biztonság megtévesztő: gondolhatja, hogy mindent megvéd, csak hogy később kiderüljön, vannak-e lyukak. Sokkal könnyebb megtervezni a biztonságot a projekt kezdetétől, mint később utólag felszerelni.
‘Rugalmas’ azt jelenti, hogy szolgálatai tolerálják az infrastruktúrán belüli hibákat. Hiba lehet egy kiszolgáló lemezvezérlője, amely már nem fér hozzá egyetlen lemezhez sem, így az adatok elérhetetlenné válnak. Vagy a hiba egy hálózati kapcsoló lehet, amely már nem teszi lehetővé két vagy több rendszer kommunikációját. Ebben az összefüggésben a “egyetlen meghibásodási pont” vagy SPOF egy hiba, amely hátrányosan befolyásolja a szolgáltatás elérhetőségét. A rugalmas infrastruktúra SPOF nélkül működik.
‘skálázható’ leírja a rendszerek azon képességét, hogy a kereslet tüskéit kecsesen kezeljék. Azt is diktálja, hogy a rendszereket milyen könnyen lehet megváltoztatni. Például új felhasználó hozzáadása, tárolási kapacitás növelése vagy infrastruktúra áthelyezése az Amazon Web Services szolgáltatásból a Google Cloud-ba – vagy akár házon belüli áthelyezése.
Amint az infrastruktúra kiszélesedik egy kiszolgálón, rengeteg lehetőség van a biztonság, rugalmasság és méretezhetőség növelésére. Mi’Megvizsgáljuk, hogyan oldottuk meg ezeket a problémákat hagyományosan, és milyen új technológia áll rendelkezésre, amely megváltoztatja a nagy alkalmazás-számítástechnika arcát.
Hogy megértsük mit’Ma lehetséges, hogy’Hasznos megnézni, hogy a technológiai projekteket hogyan hajtják végre hagyományosan. A régi időkben – azaz több mint tíz évvel ezelőtt – a vállalkozások hardvert vásárolnának vagy bérelnének, hogy alkalmazásuk összes elemét futtassák. Még a viszonylag egyszerű alkalmazások, például a WordPress webhely, több összetevőt tartalmaznak. A WordPress esetében MySQL adatbázisra van szükség, valamint egy webszerverre, például Apache, és a PHP kód kezelésére. Szóval ők’d építsen fel egy szervert, állítsa be az Apache-t, a PHP-t és a MySQL-t, telepítse a WordPress-t, és távolítsa el őket’d megy.
Összességében ez működött. Elég jól működött, hogy ma is nagyon sok kiszolgáló van pontosan így konfigurálva. De nem volt’t tökéletes, és két nagyobb probléma az ellenálló képesség és a méretezhetőség volt.
Az ellenálló képesség hiánya azt jelentette, hogy a szerver bármely jelentős problémája a szolgáltatás elvesztését eredményezheti. A katasztrófaes hiba nyilvánvalóan azt jelentené, hogy nincs weboldal, de nem volt hely a tervezett karbantartás elvégzésére anélkül, hogy a weboldalra lenne hatással. Még az rutin biztonsági frissítés telepítéséhez és az Apache aktiválásához néhány másodpercre lenne szükség’ a weboldal leállása.
A rugalmasság problémáját nagyrészt az építkezés oldotta meg ‘magas rendelkezésre állású klaszterek’. Az elv az volt, hogy két szerver működtesse a weboldalt, úgy konfigurálva, hogy egyikük sem sikerült’t eredményezheti a webhely leállítását. A nyújtott szolgáltatás rugalmas volt akkor is, ha az egyes szerverek nem voltak.
Absztrakt felhők
A Kubernetes hatalmának egy része az absztrakció, amelyet kínál. Egy fejlesztőtől’Perspektivikus szempontból fejlesztik az alkalmazást a Docker tárolóban való futtatáshoz. Docker nem’nem érdekli, hogy nem’Windows, Linux vagy más operációs rendszeren fut. Ugyanez a Docker tároló vehető a fejlesztőtől’s MacBook, és mindenféle módosítás nélkül futtassa a Kubernetes alatt.
Maga a Kubernetes telepítés egyetlen gép lehet. Természetesen a Kubernetes számos előnye nyert’t elérhető: nem lesz automatikus méretezés; ott’ez egy nyilvánvaló kudarcpont és így tovább. A tesztkörnyezet koncepciójának igazolására azonban működik.
Ha egyszer’Ha készen áll a termelésre, futtathat házon belül vagy Cloud szolgáltatón, például AWS vagy Google Cloud. A felhőszolgáltatóknak vannak beépített szolgáltatásai, amelyek elősegítik a Kubernetes futtatását, de ezek egyike sem szigorú követelmény. Ha a Google, az Amazon és a saját infrastruktúrája között szeretne mozogni, beállíthatja a Kubernetes-et, és átköltözhet. Az alkalmazások egyikének sem kell változnia.
És hol van a Linux? A Kubernetes Linuxon fut, de az operációs rendszer láthatatlan az alkalmazások számára. Ez az IT-infrastruktúrák érettségének és használhatóságának jelentős lépése.
A Slashdot-hatás
A skálázhatóság problémája kissé trükkösebb. enged’Azt mondják, hogy a WordPress webhely havonta 1000 látogatót vonz. Egy nap vállalkozását említik a Rádió 4 vagy a reggeli TV-n. Hirtelen több mint egy hónapod lesz’érdemes látogatók 20 perc alatt. Mi’mindannyian hallottunk a webhelyek történeteit ‘összeomlik’, és az’s általában miért: a skálázhatóság hiánya.
A rugalmasságot segítő két kiszolgáló nagyobb munkaterhelést tudott kezelni, mint egy kiszolgáló önmagában, de ez az’még mindig korlátozott. te’d az idő 100% -a fizet két szerverért, és a legtöbb idő mindkettő tökéletesen működött. Azt’Valószínűleg egyedül futtathatja webhelyét. Akkor John Humphrys megemlíti az Ön vállalkozását a Ma és Ön kapcsán’d 10 szerverre van szükség a rakomány kezeléséhez – de csak néhány órán keresztül.
A rugalmasság és a méretezhetőség problémájának jobb megoldása a felhőalapú számítástechnika volt. Állítson be egy vagy két szerverpéldányt – az alkalmazásokat futtató kis kiszolgálókat – az Amazon Web Services (AWS) vagy a Google Cloud szolgáltatásban, és ha az egyik példány valamilyen okból meghiúsul, akkor automatikusan újraindul. Helyesen állítsa be az automatikus méretezést, és amikor Humphrys miatt a webkiszolgáló-példányok terhelése gyorsan növekszik, akkor automatikusan további szerverpéldányok indulnak el a munkaterhelés megosztására. Később, amint a kamat csökken, ezek a további példányok leállnak, és csak azért fizet, amit használ. Tökéletes… vagy ez?
Noha a felhőmegoldás sokkal rugalmasabb, mint a hagyományos önálló kiszolgáló, továbbra is vannak problémák. Nem fut az összes futó felhőpéldány frissítése’t egyértelmű. A felhőre történő fejlesztésnek szintén kihívása van: a laptopja, amelyet a fejlesztők használnak, hasonló lehet a felhőpéldányhoz, de az’nem ugyanaz. Ha elkötelezi magát az AWS mellett, akkor a Google Cloudba való áttérés összetett feladat. Tegyük fel, hogy bármilyen okból egyszerűen nem adsz’Nem szeretné átadni számítástechnikáját az Amazon, a Google vagy a Microsoft számára?
A konténerek olyan eszközként alakultak ki, hogy az alkalmazásokat minden függőségükkel egyetlen csomagba csomagolhassák, amely bárhol futtatható. Konténerek, például a Docker, futtathatók a fejlesztőkön’ laptopok ugyanúgy, mint a felhőpéldányaikon futnak, de a konténerpark kezelése egyre nagyobb kihívást jelent a konténerek számának növekedésével.
A válasz a konténer hangszerkesztése. Ez a figyelem középpontjában jelentős változás. Korábban megbizonyosodtunk arról, hogy elegendő szerverünk van – legyen az fizikai vagy virtuális – hogy biztosítsuk a munkaterhelés kiszolgálását. A felhő szolgáltatók használata’ az autoszkálázás segített, de még mindig foglalkoztak példákkal. Kézi módon kellett konfigurálnunk a terheléselosztókat, a tűzfalakat, az adattárolást és a többi. A konténer hangszerkesztésével mindez (és még sok más) gondoskodik. Meghatározzuk a szükséges eredményeket, és a konténer-hangszerkesztő eszközöink megfelelnek a követelményeinknek. Megállapítottuk, hogy mit akarunk tenni, és nem azt, hogy mit akarunk.
A folyamatos integráció és a folyamatos telepítés jól működik a Kubernetes-rel. Itt’A Jenkins áttekintése egy Java alkalmazás létrehozásához és telepítéséhez
(Kép jóváírása: Jövő)
Legyen Kubernete
A Kubernetes (ku-ber-net-eez) a mai napig a vezető konténerhangszerkesztő eszköz, amelyet a Google-tól kapott. Ha valaki tudja, hogyan kell hatalmas informatikai infrastruktúrákat működtetni, a Google ezt teszi. Kubernetes eredete Borg, a Google belső projektje’továbbra is a Google legtöbb részét futtatta’alkalmazásai, beleértve a keresőmotorját, a Gmail, a Google Maps és még sok más. Borg titok volt, amíg a Google nem tett közzé róla egy papírt 2015-ben, ám a cikk világossá tette, hogy Borg volt a Kubernetes mögött álló legfontosabb inspiráció..
A Borg egy olyan rendszer, amely kezeli a Google számítási erőforrásait’adatközpontokban és megőrzi a Google-t’Az alkalmazások, mind a gyártás, mind egyéb módon, futnak a hardverhiba, az erőforrások kimerülése vagy más olyan problémák ellenére, amelyek egyébként esetleg leállást okoztak. Ezt úgy csinálja, hogy gondosan figyelemmel kíséri a Borg-ot alkotó csomópontok ezreit “sejt” és a rajta futó konténerek, valamint a konténerek indítása vagy leállítása a terhelés problémáira vagy ingadozására adott esetben.
Maga Kubernetes a Google-ban született’s GIFEE (‘Google’Infrastruktúra mindenki számára’) kezdeményezést, és úgy tervezték, hogy a Borg barátságosabb verziója legyen, amely a Google-n kívül is hasznos lehet. 2015-ben adományozták a Linux Alapítványnak a Cloud Native Computing Foundation (CNCF) létrehozásával..
A Kubernetes olyan rendszert biztosít, amelyben Ön “kijelent” a konténeres alkalmazásokat és szolgáltatásokat, és gondoskodik arról, hogy alkalmazásai az említett nyilatkozatok szerint működjenek. Ha a programjai külső erőforrásokat igényelnek, például tároló vagy terheléselosztókat, a Kubernetes ezeket automatikusan biztosítja. Lehet méretezni az alkalmazásokat felfelé vagy lefelé, hogy lépést tudjon tartani a terhelés változásaival, és szükség esetén akár az egész klaszter méretezhető. A programod’s komponensek don’még azt sem kell tudni, hogy hol vannak’újra fut: A Kubernetes belső elnevezési szolgáltatásokat nyújt az alkalmazások számára, hogy csatlakozhassanak “wp_mysql” és automatikusan csatlakozik a megfelelő erőforráshoz.’
A végeredmény egy olyan platform, amelyet fel lehet használni az alkalmazások futtatásához bármilyen infrastruktúrán, egyetlen gépről egy helyszíni rendszertáblán keresztül bármely nagy felhő-szolgáltatónál futó virtuális gépek felhőalapú flottájáig, mindegyik ugyanazt a tárolót használva és konfiguráció. A Kubernetes szolgáltató-agnosztikus: futtassa bárhol.
A Kubernetes hatékony eszköz, és szükségszerűen összetett. Mielőtt áttekintést kapnánk, be kell mutatnunk néhány, a Kubernetes-ben használt kifejezést. A konténerek egyetlen alkalmazást futtatnak, a fentiek szerint, és hüvelyekre vannak csoportosítva. A pod egy szorosan összekapcsolt tárolócsoport, amelyet ugyanazon a gazdagépen telepítenek, és megosztják bizonyos erőforrásokat. A tartályok a podban belül csapatként működnek: ők’Végezzen kapcsolódó funkciókat, például egy alkalmazás-tárolót és egy naplózási tárolót az alkalmazás speciális beállításaival.
A Kubernetes áttekintése, amely megmutatja a fő összetevőket és a két csomópontot. Vegye figyelembe, hogy a gyakorlatban a fő összetevők feloszthatók több rendszerre
(Kép jóváírása: Jövő)
Négy kulcsfontosságú Kubernetes-összetevő az API-kiszolgáló, az Ütemező, a Vezérlőkezelő és az elosztott konfigurációs adatbázis, az úgynevezett etcd. Az API szerver a Kubernetes középpontjában áll, és az összes felügyeleti kérés elsődleges végpontja. Ezeket különféle forrásokból lehet előállítani, beleértve a Kubernetes más összetevőit is, például az ütemezőt, az adminisztrátorokat parancssori vagy web alapú műszerfalakon keresztül, és magukat a tárolt alkalmazásokat. Érvényesíti az etcd-ben tárolt adatokat és frissíti azokat.
Az Ütemező meghatározza, hogy mely csomópontokon futnak a különféle pod-ok, figyelembe véve az olyan korlátozásokat, mint az erőforrás-követelmények, a hardver vagy a szoftver korlátozásai, a munkaterhelés, a határidők és egyebek.
A vezérlőkezelő figyeli a klaszter állapotát, és megpróbálja elindítani vagy leállítani a hüvelyeket, az API-kiszolgálón keresztül szükségszerűen, hogy a klaszter a kívánt állapotba kerüljön. Néhány belső kapcsolatot és biztonsági funkciót is kezel.
Minden csomópont fut egy Kubelet-folyamatot, amely kommunikál az API-kiszolgálóval, és tárolókat kezeli – általában Docker használatával -, valamint a Kube-Proxy, amely kezeli a hálózati proxyt és a terheléselosztást a fürtön belül.
Az etcd elosztott adatbázisrendszer neve a /stb mappa Linux rendszereken, amely a rendszerkonfigurációs információk és az utótag tárolására szolgál ‘d’, gyakran démon folyamat jelölésére használják. Az etcd célja a kulcsérték-adatok elosztott, következetes és hibatűrő módon történő tárolása.
Az API-kiszolgáló minden állapotát az etcd-ben tárolja, és sok példányt egyidejűleg futtathat. Az ütemezőnek és a vezérlőkezelőnek csak egy aktív példánya lehet, de bérleti rendszert használ annak meghatározására, hogy mely futó példány az elsődleges. Mindez azt jelenti, hogy a Kubernetes magas rendelkezésre állású rendszerként futhat egyetlen hibapont nélkül.
Összerakva mindent
Szóval hogyan használhatjuk ezeket az összetevőket a gyakorlatban? Az alábbiakban bemutatunk egy példát a WordPress webhely Kubernetes használatával történő beállítására. Ha valóban meg akartad csinálni, akkor te is’d valószínűleg egy előre definiált receptet használ, amelyet sisakdiagramnak hívnak. Számos általános alkalmazásban elérhetők, de itt mi’Megvizsgáljuk a WordPress webhely Kubernetes-en történő futtatásához szükséges lépések néhányát.
Az első feladat egy jelszó meghatározása a MySQL számára:
kubectl hozzon létre titkos általános mysql-pass –from-literal = jelszó = YOUR_PASSWORD
A kubectl beszélni fog az API szerverrel, amely érvényesíti a parancsot, majd a jelszót az etcd-ben tárolja. Szolgáltatásainkat YAML fájlok határozzák meg, és most szükségünk van némi tartós tárolásra a MySQL adatbázis számára.
apiVersion: v1kind: PersistentVolumeClaimmetadata: név: mysql-pv-pretenlabels: app: wordpressspec: accessModes: – ReadWriteOnceresources: kérések: storage: 20Gi
A specifikációnak többnyire magának kell lennie. A név és a címkék mezők hivatkoznak erre a tárolóra a Kubernetes más részeiből, ebben az esetben a WordPress tárolónkba.
Egyszer mi’definiálva egy tárolót, definiálhatunk egy MySQL példányt, az előre definiált tárolóra mutatva. Hogy’s követi magának az adatbázisnak a meghatározása. Az adatbázisnak nevét és címkét adunk a Kubernetes-en belüli egyszerű hivatkozáshoz.
Most szükségünk van egy másik tárolóra a WordPress futtatásához. A tároló telepítési specifikációjának része:
fajta: Telepítési metaadatok: név: wordpresslabels: app: wordpressspec: stratégia: type: Recreate
A stratégia típusa “Újraforgatás” azt jelenti, hogy ha az alkalmazásból álló kód megváltozik, akkor a futó példányok törlődnek és újra létrejönnek. Egyéb lehetőségek közé tartozik az új példányok ciklusának ciklusa és a meglévő példányok egyenkénti eltávolítása, amely lehetővé teszi a szolgáltatás futtatását a frissítés telepítése közben. Végül magának a WordPress-nek deklarálunk egy szolgáltatást, amely a PHP kódot és az Apache-t tartalmazza. A YAML fájl része, amely ezt deklarálja:
metaadatok: név: wordpresslabels: app: wordpressspec: portok: – port: 80selector: app: wordpresstier: frontendtype: LoadBalancer
Vegye figyelembe az utolsó sort, amely meghatározza a szolgáltatás típusát LoadBalancerként. Ez arra utasítja Kubernetes-t, hogy a szolgáltatást Kubernetes-en kívül tegye elérhetővé. Ezen vonal nélkül ez csupán belső “Csak Kubernetes” szolgáltatás. És az’s it. A Kubernetes most ezeket a YAML fájlokat használja a szükséges adatok deklarálására, és a fürt beillesztéséhez szükséges pods-kat, kapcsolatokat, tárolókat és így tovább állít fel. “kívánatos” állapot.
Az irányítópult nézetből áttekinthető összefoglalót kaphat a működő Kubernetes-ről
(Kép jóváírása: árokásás)
Ez feltétlenül csak a Kubernetes magas szintű áttekintése volt, és a rendszer sok részletét és funkcióját kihagyták. Mi’ve fel van tüntetve az automatikus skálázás (mind a hüvelyek, mind a fürtöt alkotó csomópontok), cron feladatok (tartályok indítása ütemezés szerint), Ingress (HTTP terheléselosztás, újraírás és SSL kirakodás), RBAC (szerepelapú hozzáférés-vezérlés), hálózat házirendek (tűzfal) és még sok más. A Kubernetes rendkívül rugalmas és rendkívül nagy teljesítményű: minden új informatikai infrastruktúrához komoly versenyzőnek kell lennie.
Erőforrások
Ha te’ha még nem ismeri a Dockert, kezdje itt: https://docs.docker.com/get-started.
Ott’Egy interaktív oktatóprogram az alkalmazás telepítéséhez és méretezéséhez itt: https://kubernetes.io/docs/tutorials/kubernetes-basics.
A fürt felépítését lásd a https://kubernetes.io/docs/setup/scratch oldalon.
Játszhat egy ingyenes Kubernetes-fürttel a https://tryk8s.com oldalon.
Végül megkóstolhatja egy hosszú, technikai dokumentumot, amely kiváló áttekintést nyújt a Google-ról’Borg használata és hogyan befolyásolta a Kubernetes kialakítását itt: https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43438.pdf.
Tudjon meg többet a Tiger Computing-ról.
- Legjobb 2019-es felhőalapú tárolás online: ingyenes, fizetős és üzleti lehetőségek
