Hallo, my naam is Dmitri Krasnov. Ek administreer al meer as vyf jaar Kubernetes-klusters en bou komplekse mikrodiensargitekture. Aan die begin van hierdie jaar het ons 'n diens bekendgestel vir die bestuur van Kubernetes-klusters gebaseer op Containerum. Deur hierdie geleentheid te gebruik, sal ek jou vertel wat Kubernetes is en hoe integrasie met 'n verskaffer verskil van oopbron.
Om mee te begin, wat is . Dit is 'n stelsel vir die bestuur van houers op 'n groot aantal gashere. Uit Grieks word dit terloops vertaal as “vlieënier” of “stuurman”. Oorspronklik deur Google ontwikkel en toe geskenk as 'n tegnologiebydrae aan die Cloud Native Computing Foundation, 'n internasionale nie-winsgewende organisasie wat die wêreld se voorste ontwikkelaars, eindgebruikers en houertegnologieverskaffers bymekaarbring.
Bestuur 'n groot aantal houers
Laat ons nou uitvind watter soort houers dit is. Dit is 'n toepassing met sy hele omgewing - hoofsaaklik die biblioteke waarvan die program afhanklik is. Dit alles word in argiewe verpak en in die vorm van 'n beeld aangebied wat ongeag die bedryfstelsel uitgevoer kan word, getoets en meer. Maar daar is 'n probleem - die bestuur van houers op 'n groot aantal gashere is baie moeilik. Dis hoekom Kubernetes geskep is.
'n Houerbeeld verteenwoordig 'n toepassing plus sy afhanklikhede. Die toepassing, sy afhanklikhede en die OS-lêerstelselbeeld is in verskillende dele van die beeld geleë, sogenaamde lae. Lae kan vir verskillende houers hergebruik word. Byvoorbeeld, alle toepassings in 'n maatskappy kan die Ubuntu-basislaag gebruik. As u houers gebruik, hoef u nie veelvuldige kopieë van 'n enkele basislaag op die gasheer te stoor nie. Dit laat jou toe om beeldberging en aflewering te optimaliseer.
Wanneer ons 'n toepassing vanaf 'n houer wil laat loop, word die nodige lae op mekaar geplaas en 'n oorleglêerstelsel word gevorm. ’n Opnamelaag word bo-op geplaas, wat verwyder word wanneer die houer stop. Dit verseker dat wanneer die houer loop, die toepassing altyd dieselfde omgewing sal hê, wat nie verander kan word nie. Dit waarborg die reproduceerbaarheid van die omgewing op verskillende gasheer-bedryfstelsels. Of dit nou Ubuntu of CentOS is, die omgewing sal altyd dieselfde wees. Daarbenewens word die houer van die gasheer geïsoleer deur gebruik te maak van meganismes wat in die Linux-kern ingebou is. Toepassings in 'n houer sien nie lêers, prosesse van die gasheer en naburige houers nie. Hierdie isolasie van toepassings vanaf die gasheerbedryfstelsel bied 'n bykomende laag sekuriteit.
Daar is baie gereedskap beskikbaar om houers op 'n gasheer te bestuur. Die gewildste van hulle is Docker. Dit laat jou toe om die volle lewensiklus van houers te verskaf. Dit werk egter net op een gasheer. As jy houers oor verskeie gashere moet bestuur, kan Docker die lewe hel maak vir ingenieurs. Dis hoekom Kubernetes geskep is.
Die vraag na Kubernetes is juis te danke aan die vermoë om groepe houers op verskeie gashere te bestuur as 'n soort enkele entiteit. Die gewildheid van die stelsel bied die geleentheid om DevOps of Development Operations te bou, waarin Kubernetes gebruik word om die prosesse van hierdie einste DevOps uit te voer.
Figuur 1. Skematiese voorstelling van hoe Kubernetes werk
Volle outomatisering
DevOps is basies die outomatisering van die ontwikkelingsproses. Ontwikkelaars skryf rofweg kode wat na die bewaarplek opgelaai word. Dan kan hierdie kode outomaties onmiddellik in 'n houer met al die biblioteke versamel word, getoets en "uitgerol" word na die volgende stadium - Staging, en dan onmiddellik na Produksie.
Saam met Kubernetes laat DevOps jou toe om hierdie proses te outomatiseer sodat dit feitlik sonder deelname van die ontwikkelaars self plaasvind. As gevolg hiervan is die bou aansienlik vinniger, aangesien die ontwikkelaar dit nie op sy rekenaar hoef te doen nie - hy skryf bloot 'n stukkie kode, stoot die kode na die bewaarplek, waarna die pyplyn geloods word, wat die proses kan insluit van bou, toets en uitrol. En dit gebeur met elke commit, so toetsing vind voortdurend plaas.
Terselfdertyd laat die gebruik van 'n houer jou toe om seker te wees dat die hele omgewing van hierdie program in produksie vrygestel sal word presies in die vorm waarin dit getoets is. Dit wil sê, daar sal geen probleme wees soos "daar was sommige weergawes in die toets, ander in produksie, maar toe ons dit geïnstalleer het, het alles geval." En aangesien ons vandag 'n neiging het na mikrodiensargitektuur, wanneer daar in plaas van een groot toepassing honderde kleintjies is, om dit met die hand te administreer, sal 'n groot personeel personeel benodig word. Dit is hoekom ons Kubernetes gebruik.
Voordele, voordele, voordele
As ons praat oor die voordele van Kubernetes as 'n platform, dan het dit aansienlike voordele uit die oogpunt van die bestuur van 'n mikrodiensargitektuur.
- Bestuur veelvuldige replikas. Die belangrikste ding is om houers oor verskeie gashere te bestuur. Nog belangriker, bestuur veelvuldige toepassingsreplikas in houers as 'n enkele entiteit. Danksy dit hoef ingenieurs nie oor elke individuele houer bekommerd te wees nie. As een van die houers ineenstort, sal Kubernetes dit sien en dit weer herbegin.
- Cluster netwerk. Kubernetes het ook 'n sogenaamde cluster-netwerk met sy eie adresruimte. Danksy dit het elke peul sy eie adres. 'n Subpod word verstaan as die minimum strukturele eenheid van 'n groep waarin houers direk gelanseer word. Daarbenewens het Kubernetes funksionaliteit wat 'n lasbalanseerder en Service Discovery kombineer. Dit laat jou toe om van handmatige IP-adresbestuur ontslae te raak en hierdie taak aan Kubernetes te delegeer. En outomatiese gesondheidsondersoeke sal help om probleme op te spoor en verkeer na werkende peule te herlei.
- Konfigurasiebestuur. Wanneer 'n groot aantal toepassings bestuur word, word dit moeilik om toepassingkonfigurasie te bestuur. Vir hierdie doel het Kubernetes spesiale ConfigMap-hulpbronne. Dit laat jou toe om konfigurasies sentraal te stoor en dit aan peule bloot te stel wanneer toepassings uitgevoer word. Hierdie meganisme stel ons in staat om die konsekwentheid van die konfigurasie in ten minste tien of honderd toepassingsreplikas te waarborg.
- Aanhoudende volumes. Houers is inherent onveranderlik en wanneer die houer gestop word, sal alle data wat na die lêerstelsel geskryf is, vernietig word. Maar sommige toepassings stoor data direk op skyf. Om hierdie probleem op te los, het Kubernetes 'n skyfbergingbestuurfunksie - Persistent Volumes. Hierdie meganisme gebruik eksterne berging vir data en kan aanhoudende berging, blok of lêer, na houers oordra. Hierdie oplossing laat jou toe om data apart van werkers te stoor, wat hulle stoor as dieselfde werkers breek.
- Load Balancer. Alhoewel ons in Kubernetes abstrakte entiteite soos Deployment, StatefulSet, ens. bestuur, loop houers uiteindelik op gewone virtuele masjiene of hardewarebedieners. Hulle is nie perfek nie en kan enige tyd val. Kubernetes sal dit sien en interne verkeer na ander replikas herlei. Maar wat om te doen met verkeer wat van buite af kom? As jy bloot verkeer na een van die werkers stuur, as dit ineenstort, sal die diens onbeskikbaar word. Om hierdie probleem op te los, het Kubernetes dienste soos Load Balancer. Hulle is ontwerp om outomaties 'n eksterne wolkbalanseerder vir alle werkers in die groepering op te stel. Hierdie eksterne balanseerder rig eksterne verkeer na werkers en monitor hul status self. As een of meer werkers onbeskikbaar raak, word verkeer na ander herlei. Dit laat jou toe om hoogs beskikbare dienste te skep deur Kubernetes te gebruik.
Kubernetes werk die beste wanneer mikrodiensargitekture uitgevoer word. Dit is moontlik om die stelsel in klassieke argitektuur te implementeer, maar dit is nutteloos. As 'n toepassing nie op veelvuldige replikas kan loop nie, watter verskil maak dit dan - in Kubernetes of nie?
Oopbron Kubernetes
Oopbron Kubernetes is 'n wonderlike ding: ek het dit geïnstalleer en dit werk. Jy kan dit op jou eie hardeware-bedieners, op jou eie infrastruktuur ontplooi, meesters en werkers installeer waarop alle toepassings sal loop. En die belangrikste, dit alles is gratis. Daar is egter nuanses.
- Die eerste is die vraag na kennis en ervaring van administrateurs en ingenieurs wat dit alles sal ontplooi en ondersteun. Aangesien die kliënt volkome vryheid van optrede in die kluster ontvang, is hy self verantwoordelik vir die prestasie van die kluster. En dit is baie maklik om alles hier te breek.
- Die tweede is die gebrek aan integrasies. As jy Kubernetes sonder 'n gewilde virtualiseringsplatform bestuur, sal jy nie al die voordele van die program kry nie. Soos die gebruik van aanhoudende volumes en laaibalanseerderdienste.
Figuur 2. k8s argitektuur
Kubernetes van die verkoper
Integrasie met 'n wolkverskaffer bied twee opsies:
- Eerstens kan 'n persoon eenvoudig op die "skep groepering"-knoppie klik en 'n groepering kry wat reeds gekonfigureer en gereed is vir gebruik.
- Tweedens installeer die verkoper self die cluster en stel integrasie met die wolk op.
Hoe dit hier gebeur. Die ingenieur wat die groepie begin, spesifiseer hoeveel werkers hy benodig en met watter parameters (byvoorbeeld 5 werkers, elk met 10 SVE's, 16 GB RAM en, sê, 100 GB skyf). Daarna kry dit toegang tot die reeds gevormde groepering. In hierdie geval word die werkers waarop die vrag geloods word, heeltemal na die kliënt oorgedra, maar die hele bestuursvlak bly onder die verantwoordelikheid van die verkoper (indien die diens volgens die bestuurde diensmodel gelewer word).
Hierdie skema het egter sy nadele. As gevolg van die feit dat die bestuursvlak by die verkoper bly, gee die verkoper nie volle toegang tot die kliënt nie, en dit verminder buigsaamheid om met Kubernetes te werk. Soms gebeur dit dat 'n kliënt een of ander spesifieke funksionaliteit by Kubernetes wil voeg, byvoorbeeld verifikasie via LDAP, maar die bestuursvlakkonfigurasie laat dit nie toe nie.
Figuur 3. Voorbeeld van 'n Kubernetes-kluster van 'n wolkverskaffer
Wat om te kies: oopbron of verskaffer
Dus, is Kubernetes open source of verskaffer spesifiek? As ons oopbron Kubernetes neem, dan doen die gebruiker wat hy wil daarmee. Maar daar is 'n groot kans om jouself in die voet te skiet. Met die verkoper is dit moeiliker, want alles is deurdink en gekonfigureer vir die maatskappy. Die grootste nadeel van open source Kubernetes is die vereiste vir spesialiste. Met 'n verkoper-opsie word die maatskappy van hierdie kopseer bevry, maar hy sal moet besluit of hy sy spesialiste of die verkoper moet betaal.
Wel, die voordele is voor die hand liggend, die nadele is ook bekend. Een ding is konstant: Kubernetes los baie probleme op deur die bestuur van baie houers te outomatiseer. En watter een om te kies, oopbron of verskaffer - elkeen maak sy eie besluit.
Die artikel is voorberei deur Dmitri Krasnov, toonaangewende argitek van die Containerum-diens van die #CloudMTS-verskaffer
Bron: will.com