Ko želite uporabljati Linux za zagotavljanje storitev podjetju, bodo te storitve morale biti varne, odporne in razširljive. Lepe besede, ampak kaj mislimo z njimi?
„Varno“ pomeni, da lahko uporabniki dostopajo do podatkov, ki jih potrebujejo, naj bo to samo bralni ali pisalni dostop. Hkrati nobena oseba ni izpostavljena nobeni stranki, ki ni pooblaščena za njihov vpogled. Varnost je zavajajoča: mislite lahko, da imate vse zaščiteno, da kasneje ugotovite, da obstajajo luknje. Varno načrtovanje od začetka projekta je veliko lažje, kot da bi ga kasneje posodobili.
„Odporna“ pomeni, da vaše storitve dopuščajo napake v infrastrukturi. Napaka je lahko krmilnik strežniškega diska, ki ne more več dostopati do nobenega diska, zaradi česar so podatki nedosegljivi. Ali pa je napaka morda omrežno stikalo, ki ne omogoča več komuniciranja dveh ali več sistemov. V tem kontekstu je "ena točka okvare" ali SPOF okvara, ki negativno vpliva na razpoložljivost storitve. Odporna infrastruktura je tista brez SPOF.
„Scalable“ opisuje sposobnost sistemov, da elegantno obvladujejo konice povpraševanja. Prav tako narekuje, kako enostavno je mogoče spreminjati sisteme. Na primer, dodajanje novega uporabnika, povečanje zmogljivosti shranjevanja ali selitev infrastrukture iz Amazonovih spletnih storitev v Google Cloud - ali celo njeno interno premestitev.
Takoj, ko se vaša infrastruktura razširi nad en strežnik, obstaja veliko možnosti za povečanje varnosti, odpornosti in razširljivosti. Ogledali si bomo, kako so se ti problemi reševali tradicionalno in katera nova tehnologija je na voljo, ki spreminja obraz velikega računalništva.
Pridobite več Linuxa!
Uživate v tem, kar berete? Želite več Linuxa in odprtokodne kode? Dostavimo lahko, dobesedno! Danes se naročite na Linux Format po ugodni ceni. Lahko dobite tiskane izdaje, digitalne izdaje ali zakaj ne oboje? Do vas dostavimo po vsem svetu za enostavno letno plačilo. Zato si olajšajte in olajšajte življenje, naročite se zdaj!
Da bi razumeli, kaj je danes mogoče, je koristno pogledati, kako se tradicionalno izvajajo tehnološki projekti. V starih časih - torej pred več kot 10 leti - so podjetja kupovala ali najemala strojno opremo za zagon vseh komponent svojih aplikacij. Tudi razmeroma preproste aplikacije, kot je spletno mesto WordPress, imajo več komponent. V primeru WordPressa je potrebna baza podatkov MySQL skupaj s spletnim strežnikom, kot je Apache, in načinom ravnanja s kodo PHP. Tako bi zgradili strežnik, nastavili Apache, PHP in MySQL, namestili WordPress in odšli.
Na splošno je to delovalo. Delovalo je dovolj dobro, da je še danes ogromno strežnikov, ki so konfigurirani točno na ta način. A ni bilo popolno, dva večja problema pa sta bila odpornost in razširljivost.
Pomanjkanje odpornosti je pomenilo, da bi katera koli pomembna težava na strežniku povzročila izgubo storitve. Jasno je, da katastrofalna okvara ne bi pomenila spletnega mesta, vendar tudi ni bilo prostora za izvedbo rednega vzdrževanja, ne da bi to vplivalo na spletno mesto. Tudi namestitev in aktivacija rutinske varnostne posodobitve za Apache bi zahtevala nekaj sekund izpada spletnega mesta.
Problem odpornosti je bil v veliki meri rešen z gradnjo "grozdov z visoko razpoložljivostjo". Načelo je bilo, da sta na spletnem mestu dva strežnika, ki sta konfigurirana tako, da zaradi neuspeha katerega koli od njih spletna stran ne deluje. Storitev, ki se je zagotavljala, je bila prožna, tudi če posamezni strežniki niso bili.
Abstraktni oblakiDel moči Kubernetesa je abstrakcija, ki jo ponuja. Z vidika razvijalca razvijajo aplikacijo za zagon v Dockerjevem vsebniku. Dockerja ne zanima, ali deluje v operacijskem sistemu Windows, Linux ali katerem drugem operacijskem sistemu. Isti vsebnik Docker lahko vzamete iz razvijalčevega MacBooka in ga brez sprememb spremenite v Kubernetes.
Sama namestitev Kubernetes je lahko en stroj. Veliko prednosti Kubernetesa seveda ne bo na voljo: ne bo samodejnega spreminjanja merila; očitno je ena sama točka neuspeha itd. Kot dokaz koncepta v testnem okolju pa deluje.
Ko ste pripravljeni na produkcijo, lahko zaženete interno ali pri ponudniku oblaka, kot sta AWS ali Google Cloud. Ponudniki v oblaku imajo nekaj vgrajenih storitev, ki pomagajo pri zagonu Kubernetesa, vendar nobena od njih ni težka. Če se želite premikati med Googlom, Amazonom in lastno infrastrukturo, nastavite Kubernetes in se pomaknite čez. Nobena od vaših aplikacij se na noben način ne sme spremeniti.
In kje je Linux? Kubernetes deluje v Linuxu, vendar je operacijski sistem za aplikacije neviden. To je pomemben korak v zrelosti in uporabnosti informacijske infrastrukture.
Učinek Slashdot
Problem razširljivosti je nekoliko bolj zapleten. Recimo, da vaše spletno mesto WordPress mesečno obišče 1000 obiskovalcev. Nekega dne je vaše podjetje omenjeno na radiu 4 ali televiziji z zajtrkom. Nenadoma v 20 minutah obiščete več kot mesec dni. Vsi smo že slišali zgodbe o "sesutjih" spletnih mest, zato je tipično zato: pomanjkanje razširljivosti.
Oba strežnika, ki sta pomagala pri odpornosti, bi lahko obvladovala večjo delovno obremenitev kot en strežnik, vendar je to še vedno omejeno. Za dva strežnika bi plačali 100 odstotkov časa in večino časa sta oba delovala odlično. Verjetno je, da bi samo vaš lahko vodil vaše spletno mesto. Potem John Humphrys omenja vaše podjetje danes in za obremenitev bi potrebovali 10 strežnikov, vendar le nekaj ur.
Boljša rešitev problema odpornosti in razširljivosti je bilo računalništvo v oblaku. Na spletnem mestu Amazon Web Services (AWS) ali Google Cloud nastavite en ali dva primera strežnika - majhna strežnika, na katerih se izvajajo vaše aplikacije, in če eden od primerov iz nekega razloga ne uspe, se samodejno znova zažene. Pravilno nastavite samodejno spreminjanje velikosti in ko gospod Humphrys povzroči hitro povečanje obremenitve na primerkih vašega spletnega strežnika, se samodejno zaženejo dodatni primerki strežnika, ki si delijo obremenitev. Kasneje, ko obresti popustijo, se ti dodatni primeri ustavijo in plačate samo za tisto, kar porabite. Popolno … ali pa je?
Čeprav je rešitev v oblaku veliko bolj prilagodljiva kot tradicionalni samostojni strežnik, še vedno obstajajo težave. Posodobitev vseh delujočih primerkov v oblaku ni enostavna. Tudi razvoj za oblak ima izzive: prenosnik, ki ga uporabljajo vaši razvijalci, je lahko podoben primerku oblaka, vendar ni enak. Če se zavežete k AWS, je prehod na Google Cloud zapleteno. Recimo, da iz kakršnega koli razloga preprosto ne želite predati računalništva Amazonu, Googlu ali Microsoftu?
Zabojniki so se pojavili kot sredstvo za zavijanje aplikacij z vsemi odvisnostmi v en paket, ki ga je mogoče zagnati kjer koli. Zabojniki, kot je Docker, se lahko na prenosnikih razvijalcev izvajajo na enak način kot na primerkih v oblaku, vendar upravljanje flote zabojnikov postaja vse večje izzive, ko število zabojnikov narašča.
Odgovor je orkestracija posode. To je pomemben premik v fokusu. Pred tem smo poskrbeli, da imamo dovolj strežnikov, naj bodo fizični ali navidezni, da bomo lahko servisirali delovno obremenitev. Uporaba samodejnega skaliranja ponudnikov v oblaku je pomagala, vendar smo še vedno imeli opravka s primerki. Ročno smo morali konfigurirati izravnalnike obremenitve, požarne zidove, shranjevanje podatkov in še več. Z orkestracijo posod je poskrbljeno za vse to (in še veliko več). Določimo rezultate, ki jih potrebujemo, in naša orodja za orkestracijo zabojnikov izpolnjujejo naše zahteve. Določimo, kaj želimo narediti, ne pa, kako želimo.
Postanite Kubernete
Kubernetes (ku-ber-net-eez) je danes vodilno orodje za orkestracijo zabojnikov, prišel pa je od Googla. Če kdo ve, kako voditi obsežne informacijske infrastrukture, Google to ve. Izvor Kubernetesa je Borg, interni Googlov projekt, ki se še vedno uporablja za zagon večine Googlovih aplikacij, vključno z njegovim iskalnikom, Gmailom, Google Zemljevidi in drugimi. Borg je bil skrivnost, dokler Google leta 2015 o tem ni objavil prispevka, vendar je zelo jasno pokazal, da je Borg glavni navdih za Kubernetesa.
Borg je sistem, ki upravlja računske vire v Googlovih podatkovnih centrih in ohranja Googlove aplikacije, tako produkcijske kot druge, delujoče kljub okvari strojne opreme, izčrpanosti virov ali drugim težavam, ki bi sicer lahko povzročile izpad. To naredi tako, da skrbno spremlja tisoče vozlišč, ki tvorijo Borgovo "celico", in zabojnike, ki se na njih izvajajo, in zažene ali ustavi zabojnike, kot je potrebno, kot odziv na težave ali nihanja obremenitve.
Tudi sam Kubernetes se je rodil iz Googlove pobude GIFEE ('Googlova infrastruktura za vse ostale') in je bil zasnovan kot prijaznejša različica Borga, ki bi bila lahko koristna zunaj Googla. Podeljena je bila Linux Foundation leta 2015 z ustanovitvijo Cloud Native Computing Foundation (CNCF).
Kubernetes ponuja sistem, s katerim "prijavite" svoje vsebinske programe in storitve ter poskrbi, da se vaše aplikacije izvajajo v skladu s temi izjavami. Če vaši programi zahtevajo zunanje vire, na primer izravnalnike za shranjevanje ali obremenitev, jih lahko Kubernetes samodejno zagotovi. Lahko spreminja vaše aplikacije navzgor ali navzdol, da sledi spremembam obremenitve, po potrebi pa lahko celo celotno gručo. Komponentam vašega programa niti ni treba vedeti, kje se izvajajo: Kubernetes ponuja notranje storitve poimenovanja aplikacij, da se lahko povežejo z “wp_mysql” in se samodejno povežejo s pravilnim virom. '
Končni rezultat je platforma, ki se lahko uporablja za zagon vaših aplikacij na kateri koli infrastrukturi, od enega računalnika prek lokalnega sistema sistemov do flote virtualnih računalnikov v oblaku, ki se izvajajo pri katerem koli večjem ponudniku oblaka, vsi pa uporabljajo iste vsebnike in konfiguracijo. Kubernetes je agnostik ponudnika: zaženite ga kjer koli želite.
Kubernetes je močno orodje in je nujno zapleteno. Preden začnemo pregled, moramo predstaviti nekaj izrazov, ki se uporabljajo v Kubernetesu. Kot je opisano zgoraj, zabojniki zaženejo posamezne programe in so združeni v pods. Pod je skupina tesno povezanih vsebnikov, ki so razporejeni skupaj na istem gostitelju in si delijo nekaj virov. Vsebniki znotraj podsistema delujejo kot skupina: izvajali bodo povezane funkcije, na primer vsebnik aplikacije in vsebnik dnevnika s posebnimi nastavitvami za aplikacijo.
Štiri ključne komponente Kubernetes so API Server, Scheduler, Controller Manager in porazdeljena baza konfiguracij, imenovana etcd. Strežnik API je v središču Kubernetesa in deluje kot primarna končna točka za vse zahteve za upravljanje. Te lahko generirajo različni viri, vključno z drugimi komponentami Kubernetes, kot so razporejevalnik, skrbniki prek nadzorne plošče v ukazni vrstici ali na spletu in sami zabojniki. Preverja zahteve in posodablja podatke, shranjene v etcd.
Načrtovalnik določi, na katerih vozliščih se bodo izvajali različni podsklopi, pri čemer upošteva omejitve, kot so zahteve po virih, morebitne omejitve strojne ali programske opreme, delovna obremenitev, roki in drugo.
Upravitelj krmilnika spremlja stanje gruče in bo poskušal po strežniku API strežnik zagnati ali ustaviti pods, da bo grozd pripeljal v želeno stanje. Upravlja tudi nekatere notranje povezave in varnostne funkcije.
Vsako vozlišče zažene postopek Kubelet, ki komunicira s strežnikom API in upravlja vsebnike - običajno z uporabo Dockerja - in Kube-Proxy, ki skrbi za omrežno proxy in uravnoteženje obremenitve znotraj gruče.
Sistem porazdeljene zbirke podatkov etcd izhaja iz / itd mapa v sistemih Linux, ki se uporablja za hranjenje informacij o konfiguraciji sistema, skupaj s pripono „d“, ki se pogosto uporablja za označevanje procesa demona. Cilji etcd so shranjevanje podatkov ključ-vrednost na porazdeljen, dosleden in odporen način.
Strežnik API hrani vse podatke o svojem stanju v etcd in lahko istočasno izvaja številne primerke. Upravitelj načrtovalnika in krmilnika ima lahko samo en aktiven primerek, vendar s sistemom zakupa določi, kateri delujoči primerek je glavni. Vse to pomeni, da lahko Kubernetes deluje kot visoko razpoložljiv sistem brez posameznih točk okvare.
Vse skupaj
Kako torej uporabiti te komponente v praksi? Sledi primer nastavitve spletnega mesta WordPress z uporabo Kubernetesa. Če bi to želeli resnično, potem bi verjetno uporabili vnaprej določen recept, ki se imenuje krmilna karta. Na voljo so za številne običajne aplikacije, tukaj pa si bomo ogledali nekaj korakov, potrebnih za vzpostavitev in delovanje spletnega mesta WordPress na Kubernetesu.
Prva naloga je določiti geslo za MySQL:
kubectl ustvari skrivno generično mysql-pass --from-literal = geslo = YOUR_PASSWORD
kubectl se bo pogovarjal s strežnikom API, ki bo preveril ukaz in nato geslo shranil v etcd. Naše storitve so definirane v datotekah YAML in zdaj potrebujemo trajno shrambo za bazo podatkov MySQL.
apiVersion: v1 kind: PersistentVolumeClaim metapodatki: ime: mysql-pv-label labels: app: wordpress spec: accessModes: - ReadWriteOnce viri: zahteve: shranjevanje: 20Gi
Specifikacija mora biti večinoma samoumevna. Polja z imenom in nalepkami se uporabljajo za sklicevanje na to shrambo iz drugih delov Kubernetesa, v tem primeru našega vsebnika WordPress.
Ko definiramo pomnilnik, lahko definiramo primerek MySQL in ga usmerimo na vnaprej določen pomnilnik. Sledi opredelitev same baze podatkov. Temu zbirki podatkov damo ime in oznako za lažje sklicevanje v Kubernetesu.
Zdaj potrebujemo še en vsebnik za zagon WordPressa. Del specifikacije za razmestitev vsebnika je:
vrsta: metapodatki o uvajanju: ime: nalepke wordpress: app: wordpress spec: strategija: vrsta: poustvari
Tip strategije »Ponovno ustvari« pomeni, da se bo katera koli koda, ki vsebuje aplikacijo, spremenila, nato pa bodo tekoči primerki izbrisani in ponovno ustvarjeni. Druge možnosti vključujejo zmožnost kroženja novih primerkov in odstranjevanje obstoječih primerkov enega za drugim, kar omogoča, da se storitev še naprej izvaja med uvajanjem posodobitve. Na koncu razglasimo storitev za WordPress, ki vključuje kodo PHP in Apache. Del datoteke YAML, ki to izjavlja, je:
metapodatki: ime: wordpress nalepke: app: wordpress spec: ports: - port: 80 izbirnik: app: wordpress tier: frontend type: LoadBalancer
Upoštevajte zadnjo vrstico, ki opredeljuje vrsto storitve kot LoadBalancer. To Kubernetesu naroča, naj storitev omogoči zunaj Kubernetesa. Brez te vrstice bi bila to zgolj notranja storitev samo za Kubernetes. In to je to. Kubernetes bo te datoteke YAML zdaj uporabil kot izjavo o tem, kaj je potrebno, in po potrebi postavil pods, povezave, pomnilnik in tako naprej, da grozd pripelje v "želeno" stanje.
To je bil nujno zgolj pregled Kubernetesov na visoki ravni, številne podrobnosti in značilnosti sistema pa so bile izpuščene. Prekrivali smo samodejno spreminjanje skale (tako pods kot vozlišča, ki sestavljajo gručo), opravila cron (zagon vsebnikov po urniku), Ingress (uravnoteženje obremenitve HTTP, prepisovanje in razkladanje SSL), RBAC (nadzor dostopa na podlagi vlog) , omrežne politike (požarni zid) in še veliko več. Kubernetes je izjemno prilagodljiv in izjemno zmogljiv: za vsako novo informacijsko infrastrukturo mora biti resen kandidat.
Viri
Če Dockerja ne poznate, začnite tukaj: https://docs.docker.com/get-started.
Tukaj je interaktivna vadnica o uvajanju in spreminjanju obsega aplikacije tukaj: https://kubernetes.io/docs/tutorials/kubernetes-basics.
In glejte https://kubernetes.io/docs/setup/scratch, kako zgraditi gručo.
Lahko se igrate z brezplačno gručo Kubernetes na https://tryk8s.com.
Za konec pa lahko tukaj objavite dolg tehničen članek z odličnim pregledom Googlove uporabe Borga in tega, kako je to vplivalo na oblikovanje Kubernetesa: https://storage.googleapis.com/pub-tools-public-publication-data/ pdf / 43438.pdf.
Izvedite več o računalništvu Tiger.
- Najboljše shranjevanje v oblaku do leta 2022-2023 v spletu: brezplačne, plačljive in poslovne možnosti
Uživate v tem, kar berete? Želite več Linuxa in odprtokodne kode? Dostavimo lahko, dobesedno! Danes se naročite na Linux Format po ugodni ceni. Lahko dobite tiskane izdaje, digitalne izdaje ali zakaj ne oboje? Do vas dostavimo po vsem svetu za enostavno letno plačilo. Zato si olajšajte in olajšajte življenje, naročite se zdaj!