Kui soovite ettevõttele teenuste osutamiseks kasutada Linuxi, peavad need teenused olema turvalised, vastupidavad ja skaleeritavad. Toredad sõnad, aga mida me nende all mõtleme?
„Turvaline” tähendab, et kasutajad saavad juurdepääsu vajalikele andmetele, olgu need siis kirjutuskaitstud või kirjutusõigused. Samal ajal ei avaldata andmeid ühelegi osapoolele, kellel pole selleks volitusi. Turvalisus on petlik: võite arvata, et teil on kõik kaitstud ainult selleks, et hiljem teada saada, et seal on auke. Projekti algusest peale turvalisuse tagamine on palju lihtsam kui hiljem uuesti proovida.
Elastne tähendab, et teie teenused taluvad tõrkeid infrastruktuuris. Rike võib olla serveri kettakontroller, mis ei pääse enam ühele kettale juurde, muutes andmed kättesaamatuks. Või võib rike olla võrgulüliti, mis ei võimalda enam kahel või enamal süsteemil suhelda. Selles kontekstis on „üks ebaõnnestumispunkt” ehk SPOF rike, mis mõjutab negatiivselt teenuste kättesaadavust. Elastne infrastruktuur on selline, kus pole SPOF-e.
Mõiste „skaalautuv” kirjeldab süsteemide võimet nõudlusnähtudega graatsiliselt toime tulla. Samuti dikteerib see, kui lihtsalt saab süsteeme muuta. Näiteks uue kasutaja lisamine, salvestusmahu suurendamine või infrastruktuuri teisaldamine Amazon Web Servicesist Google Cloudi - või isegi ettevõtte sisemine teisaldamine.
Niipea kui teie infrastruktuur laieneb ühest serverist kaugemale, on turvalisuse, paindlikkuse ja mastaapsuse suurendamiseks palju võimalusi. Vaatame, kuidas neid probleeme on traditsiooniliselt lahendatud ja milline uus tehnoloogia on saadaval, mis muudab suurte rakenduste arvutamise nägu.
Hankige rohkem Linuxi!
Kas naudite seda, mida loete? Kas soovite rohkem Linuxi ja avatud lähtekoodiga? Saame sõna otseses mõttes toimetada! Telli Linuxi vorming täna soodsa hinnaga. Võite saada trükiseid, digitaalseid väljaandeid või miks mitte mõlemat? Tarnime teie ukseni kogu maailmas lihtsa aastatasu eest. Tehke oma elu paremaks ja lihtsamaks, tellige kohe!
Tänapäeval võimaliku mõistmiseks on kasulik vaadata, kuidas tehnoloogiaprojekte on traditsiooniliselt ellu viidud. Vanasti - see tähendab rohkem kui 10 aastat tagasi - ostsid või rentisid ettevõtted riistvara kõigi oma rakenduste komponentide käitamiseks. Isegi suhteliselt lihtsatel rakendustel, näiteks WordPressi veebisaidil, on mitu komponenti. WordPressi puhul on vajalik MySQL-i andmebaas koos veebiserveriga, näiteks Apache, ja viis PHP-koodi käsitsemiseks. Nii ehitasid nad serveri, seadistasid Apache, PHP ja MySQL, installisid WordPressi ja läksid minema.
Üldiselt see toimis. See toimis piisavalt hästi, et ka praegu on täpselt nii konfigureeritud tohutu arv servereid. Kuid see ei olnud täiuslik ning kaks suuremat probleemi olid vastupidavus ja mastaapsus.
Vastupanuvõime puudumine tähendas, et mis tahes olulised probleemid serveris toovad kaasa teenuse kaotuse. Katastroofiline rike ei tähenda ilmselgelt veebisaidi puudumist, kuid samuti ei olnud ruumi plaanipärase hoolduse tegemiseks ilma veebisaiti mõjutamata. Isegi Apache'i tavapärase turvavärskenduse installimine ja aktiveerimine nõuaks veebisaidi mõneks sekundiks katkestamist.
Vastupidavusprobleem lahendati suuresti suure kättesaadavusega klastrite loomisega. Põhimõtteks oli, et veebiserverit käitavad kaks serverit, mis on konfigureeritud nii, et kummagi rike ei põhjustanud veebisaidi katkemist. Pakutav teenus oli vastupidav ka siis, kui üksikud serverid seda ei teinud.
Abstraktsed pilvedOsa Kubernetese väest on abstraktsioon, mida see pakub. Arendaja seisukohast arendavad nad rakenduse Dockeri konteineris töötamiseks. Dockeril pole vahet, kas see töötab Windowsis, Linuxis või mõnes muus opsüsteemis. Sama Dockeri konteineri saab võtta arendaja MacBookist ja töötada Kubernetese all ilma muudatusteta.
Kubernetese install võib ise olla üks masin. Muidugi pole paljud Kubernetese eelised saadaval: ei toimu automaatset skaleerimist; seal on ilmselgelt üks ebaõnnestumispunkt jne. Kontseptsiooni tõestuseks testkeskkonnas see siiski töötab.
Kui olete tootmiseks valmis, saate töötada ettevõttes või pilveteenuse pakkujas, näiteks AWS või Google Cloud. Pilvepakkujal on mõned sisseehitatud teenused, mis aitavad Kubernetese käitamist, kuid ükski neist pole ranged nõuded. Kui soovite liikuda Google'i, Amazoni ja oma infrastruktuuri vahel, seadistate Kubernetese ja liigute üle. Ükski teie rakendus ei pea kuidagi muutuma.
Ja kus on Linux? Kubernetes töötab Linuxis, kuid opsüsteem on rakendustele nähtamatu. See on märkimisväärne samm IT-infrastruktuuride küpsuse ja kasutatavuse osas.
Slashdoti efekt
Mastaapsuse probleem on natuke keerulisem. Oletame, et teie WordPressi sait saab kuus 1000 külastajat. Ühel päeval mainitakse teie ettevõtet Raadio 4 või hommikusöögi teleris. Järsku saate 20 minutiga rohkem kui kuu külastajaid. Oleme kõik kuulnud lugusid veebisaitide „krahhidest“ ja tavaliselt sellepärast: mastaapsuse puudumine.
Kaks vastupanuvõimega serverit suudavad hallata suuremat töökoormust kui üks server üksi, kuid see on siiski piiratud. Maksate kahe serveri eest 100 protsenti ajast ja enamasti töötasid mõlemad suurepäraselt. Tõenäoliselt võib teie saiti juhtida ainult üks. Siis mainib John Humphrys täna teie ettevõtet ja teil on koormuse haldamiseks vaja 10 serverit - kuid ainult mõneks tunniks.
Parem lahendus nii vastupidavuse kui ka mastaapsuse probleemile oli pilvandmetöötlus. Seadistage Amazon Web Services (AWS) või Google Cloudi serveri eksemplar või kaks - väikesed serverid, mis teie rakendusi käitavad - ja kui mõni eksemplar mingil põhjusel ebaõnnestus, taaskäivitati see automaatselt. Seadistage automaatne skaleerimine õigesti ja kui Mr Humphrys põhjustab teie veebiserveri eksemplaride töökoormuse kiiret suurenemist, hakatakse töökoormust jagama automaatselt täiendavaid serveri eksemplare. Hiljem, kui huvi vaibub, peatatakse need täiendavad eksemplarid ja maksate ainult selle eest, mida kasutate. Täiuslik … või on see nii?
Kuigi pilvelahendus on palju paindlikum kui traditsiooniline eraldiseisev server, on siiski probleeme. Kõigi jooksvate pilveeksemplaride värskendamine pole lihtne. Ka pilve arendamisel on väljakutseid: sülearvuti, mida teie arendajad kasutavad, võib olla sarnane pilve eksemplariga, kuid see pole sama. Kui pühendute AWS-ile, on Google Cloudi üleminek keeruline ettevõtmine. Ja oletame, et mingil põhjusel ei taha te lihtsalt oma arvutit Amazonile, Google'ile või Microsoftile üle anda?
Konteinerid on kujunenud vahendiks pakkida rakendused koos kõigi nende sõltuvustega ühte paketti, mida saab käivitada kõikjal. Konteinerid, näiteks Docker, võivad töötada teie arendajate sülearvutites samamoodi nagu teie pilveeksemplarides, kuid konteineripargi haldamine muutub järjest keerukamaks, kui konteinerite arv kasvab.
Vastus on konteinerorkestratsioon. See on märkimisväärne fookuse nihe. Enne hoolitsesime selle eest, et meil oleks piisavalt töökeskkonda teenindavaid servereid, olgu need siis füüsilised või virtuaalsed. Pilvepakkujate automaatse skaleerimise kasutamine aitas, kuid tegelesime siiski eksemplaridega. Pidime käsitsi seadistama koormuse tasakaalustajad, tulemüürid, andmete salvestamise ja muu. Konteinerorkestratsiooni korral hoolitsetakse selle kõige (ja palju muu) eest. Täpsustame soovitud tulemused ja meie konteinerorkestratsiooni tööriistad vastavad meie nõuetele. Täpsustame, mida me tahame teha, mitte selle, kuidas me seda teha tahame.
Hakka Kuberneteks
Kubernetes (ku-ber-net-eez) on tänapäeval juhtiv konteinerorkestratsiooni tööriist ja see tuli Google'ilt. Kui keegi teab, kuidas tohutuid IT-infrastruktuure käitada, teeb seda Google. Kubernetes pärineb Borgist, sisemisest Google'i projektist, mida kasutatakse siiani enamiku Google'i rakenduste, sealhulgas otsingumootori, Gmaili, Google Mapsi ja muu käitamiseks. Borg oli saladus, kuni Google avaldas selle kohta 2015. aastal paberi, kuid see tegi väga selgeks, et Borg oli Kubernetese peamine inspiratsioon.
Borg on süsteem, mis haldab arvutuslikke ressursse Google'i andmekeskustes ja hoiab Google'i rakendusi nii tootmise kui ka muul viisil töös vaatamata riistvararikkele, ressursside ammendumisele või muudele probleemidele, mis võivad muidu põhjustada katkestuse. Ta teeb seda, jälgides hoolikalt Borgi „raku“ moodustavate tuhandete sõlmede ja nendel töötavate konteinerite olemasolu ning käivitades või peatades konteinereid vastavalt probleemidele või koormuse kõikumistele.
Kubernetes ise sündis Google'i algatusest GIFEE (‘Google’i infrastruktuur kõigile teistele’) ja oli kavandatud Borgi sõbralikumaks versiooniks, mis võiks olla kasulik väljaspool Google'i. See annetati Linuxi sihtasutusele 2015. aastal Cloud Native Computing Foundationi (CNCF) asutamise kaudu.
Kubernetes pakub süsteemi, mille abil „deklareerite“ oma konteinerirakendused ja -teenused, ning see tagab, et teie rakendused töötavad vastavalt nendele deklaratsioonidele. Kui teie programmid vajavad väliseid ressursse, näiteks salvestusruume või koormuse tasakaalustajaid, saab Kubernetes need automaatselt luua. See võib teie rakendusi suurendada või vähendada, et olla kursis koormuse muutustega, ja vajaduse korral võib seda ka kogu teie klastrit laiendada. Teie programmi komponendid ei pea isegi teadma, kus nad töötavad: Kubernetes pakub rakendustele sisemisi nimetamisteenuseid, et nad saaksid luua ühenduse saidiga „wp_mysql” ja olla automaatselt ühendatud õige ressursiga. ”
Lõpptulemus on platvorm, mida saab kasutada teie rakenduste käitamiseks mis tahes infrastruktuuris, alates ühest masinast kuni kohapealse süsteemiriiulini kuni pilvepõhiste virtuaalsete masinateni, mis töötavad mis tahes suuremas pilvepakkujas, kõik kasutavad samu konteinereid ja konfiguratsioon. Kubernetes on teenusepakkuja agnostiline: käitage seda seal, kus soovite.
Kubernetes on võimas tööriist ja on tingimata keeruline. Enne ülevaatesse jõudmist peame tutvustama Kubernetes kasutatavaid mõisteid. Konteinerid käitavad üksikuid rakendusi, nagu eespool arutletud, ja on rühmitatud kaunadeks. Pod on rühm tihedalt seotud konteinereid, mis on paigutatud koos sama hostiga ja jagavad mõnda ressurssi. Kauna konteinerid töötavad meeskonnana: nad täidavad seotud funktsioone, näiteks rakenduse konteiner ja logimiskonteiner koos rakenduse konkreetsete seadetega.
Neli võtmekomponenti Kubernetes on API server, ajakava, kontrollerihaldur ja hajutatud konfiguratsiooniandmebaas nimega etcd. API-server on Kubernetese keskmes ja see toimib kõigi haldustaotluste peamise tulemusnäitajana. Neid võib genereerida mitmesugustest allikatest, sealhulgas muudest Kubernetese komponentidest, näiteks ajastaja, administraatorid käsurea või veebipõhiste armatuurlaudade kaudu ja konteinerrakendused ise. See kinnitab taotlusi ja värskendab andmeid, mis on salvestatud jne.
Planeerija määrab, millistel sõlmedel erinevad kaustad töötavad, võttes arvesse piiranguid, nagu ressursinõuded, riist- või tarkvarapiirangud, töökoormus, tähtajad ja palju muud.
Kontrollerihaldur jälgib klastri olekut ja püüab klastreid soovitud olekusse viimiseks API serveri kaudu tingimata käivitada või peatada. Samuti haldab see mõnda sisemist ühendust ja turvaelemente.
Igal sõlmel töötab Kubelet protsess, mis suhtleb API serveriga ja haldab konteinereid - tavaliselt kasutatakse Dockerit - ja Kube-Proxy, mis tegeleb võrgu puhverserveri ja koormuse tasakaalustamisega klastris.
Hajutatud andmebaasi süsteem etc saab oma nime /jne kaust Linuxi süsteemides, mida kasutatakse süsteemi konfiguratsiooniteabe hoidmiseks, pluss järelliide d, mida sageli kasutatakse deemoni protsessi tähistamiseks. Jne eesmärk on salvestada põhiväärtusega andmeid hajutatud, järjepideval ja veataluval viisil.
API server hoiab kõiki olekiandmeid failis etcd ja suudab samaaegselt käivitada paljusid eksemplare. Planeerijal ja kontrollerihalduril võib olla ainult üks aktiivne eksemplar, kuid nad kasutavad rendisüsteemi, et teha kindlaks, milline töötav eksemplar on põhi. Kõik see tähendab, et Kubernetes saab töötada ülimalt kättesaadava süsteemina ilma ühegi rikkepunktita.
Kõike kokku panema
Niisiis, kuidas neid komponente praktikas kasutada? Järgnev on näide WordPressi veebisaidi seadistamisest Kubernetesega. Kui soovite seda päriselt teha, kasutaksite tõenäoliselt eelnevalt määratletud retsepti, mida nimetatakse roolitabeliks. Need on saadaval mitmete levinud rakenduste jaoks, kuid siin vaatame mõningaid samme, mis on vajalikud WordPressi saidi Kubernetes töötamiseks.
Esimene ülesanne on määratleda MySQL-i parool:
kubectl looge salajane üldine mysql-pass - from-literal = password = YOUR_PASSWORD
kubectl räägib API serveriga, mis kinnitab käsu ja salvestab seejärel parooli etcd-sse. Meie teenused on määratletud YAML-failides ja nüüd vajame MySQL-i andmebaasi jaoks püsivat salvestusruumi.
apiVersion: v1 liik: PersistentVolumeClaim metaandmed: nimi: mysql-pv-pretende sildid: rakendus: wordpress spec: accessModes: - ReadWriteKui ressursid: taotlused: salvestusruum: 20Gi
Spetsifikatsioon peaks olema enamasti iseenesestmõistetav. Nime ja siltide välju kasutatakse sellele Kubernetese muudest osadest, antud juhul meie WordPressi konteinerist, selle salvestusruumi viitamiseks.
Kui salvestusruum on määratletud, saame määratleda MySQL-i eksemplari, suunates selle eelnevalt määratletud salvestusruumi. Sellele järgneb andmebaasi enda määratlemine. Anname sellele andmebaasile Kubernetes hõlpsalt viitamiseks nime ja sildi.
Nüüd vajame WordPressi käitamiseks veel ühte konteinerit. Osa konteineri kasutuselevõtu spetsifikatsioonist on:
liik: juurutamise metaandmed: nimi: WordPress sildid: rakendus: WordPress spec: strateegia: tüüp: uuesti loomine
Strateegiatüüp „Taasta” tähendab, et kui mõni rakendust sisaldav kood muutub, siis töötavad eksemplarid kustutatakse ja taastatakse. Muud võimalused hõlmavad võimalust uute eksemplaride tsüklit ja olemasolevate eksemplaride ükshaaval eemaldamist, võimaldades teenusel jätkata töötamist värskenduse juurutamise ajal. Lõpuks kuulutame välja WordPressi teenuse, mis koosneb PHP-koodist ja Apache'ist. Osa seda deklareerivast YAML-failist on:
metaandmed: nimi: WordPress sildid: rakendus: WordPress spec: pordid: - port: 80 valija: rakendus: WordPress tase: esiosa tüüp: LoadBalancer
Pange tähele viimast rida, määrates teenuse tüübiks LoadBalancer. See annab Kubernetesele korralduse teenus kättesaadavaks teha väljaspool Kubernetes. Ilma selle reata oleks see lihtsalt sisemine teenus, mis hõlmab ainult Kubernetesid. Ja see ongi kõik. Kubernetes kasutab nüüd neid YAML-faile nõutava deklaratsioonina ning seab klotsid soovitud olekusse viimiseks vastavalt vajadusele kaustad, ühendused, salvestusruumi ja nii edasi.
See on tingimata olnud ainult kõrgetasemeline ülevaade Kubernetesest ning paljud süsteemi üksikasjad ja funktsioonid on välja jäetud. Oleme rõhutanud autoskaleerimist (nii jaotused kui ka klastri moodustavad sõlmed), croni töid (konteinerite käivitamine vastavalt ajakavale), sissetungimist (HTTP koormuse tasakaalustamine, ümberkirjutamine ja SSL-i mahalaadimine), RBAC-i (rollipõhised juurdepääsu kontroll) , võrgupoliitika (tulemüür) ja palju muud. Kubernetes on äärmiselt paindlik ja ülivõimas: iga uue IT-infrastruktuuri jaoks peab see olema tõsine võistleja.
Ressursid
Kui te pole Dockeriga tuttav, alustage siit: https://docs.docker.com/get-started.
Rakenduse juurutamise ja skaleerimise interaktiivne õpetus on siin: https://kubernetes.io/docs/tutorials/kubernetes-basics.
Klastri loomise kohta vaadake lehte https://kubernetes.io/docs/setup/scratch.
Tasuta Kubernetese klastriga saate mängida aadressil https://tryk8s.com.
Lõpuks saate tutvuda pika ja tehnilise dokumendiga, millel on suurepärane ülevaade Google'i Borgi kasutamisest ja kuidas see Kubernetese kujundust mõjutas: https://storage.googleapis.com/pub-tools-public-publication-data/ pdf / 43438.pdf.
Lisateave Tiger Computing kohta.
- Parim pilvesalvestus 2022-2023. aastal veebis: tasuta, tasulised ja ärivõimalused
Kas naudite seda, mida loete? Kas soovite rohkem Linuxi ja avatud lähtekoodiga? Saame sõna otseses mõttes toimetada! Telli Linuxi vorming täna soodsa hinnaga. Võite saada trükiseid, digitaalseid väljaandeid või miks mitte mõlemat? Tarnime teie ukseni kogu maailmas lihtsa aastatasu eest. Tehke oma elu paremaks ja lihtsamaks, tellige kohe!
