Hallo, myn namme is Dmitry Krasnov. Foar mear as fiif jier haw ik Kubernetes-klusters administreare en komplekse mikroservicearsjitektueren boud. Oan it begjin fan dit jier lansearren wy in tsjinst foar it behearen fan Kubernetes-klusters basearre op Containerum. Troch dizze kâns te nimmen, sil ik jo fertelle wat Kubernetes is en hoe't yntegraasje mei in ferkeaper ferskilt fan iepen boarne.
Om te begjinnen, wat is . Dit is in systeem foar it behearen fan konteners op in grut oantal hosts. Ut it Gryksk, trouwens, wurdt it oerset as "piloat" of "rorsman". Oarspronklik ûntwikkele troch Google en doe skonken as technologybydrage oan 'e Cloud Native Computing Foundation, in ynternasjonale non-profit organisaasje dy't de liedende ûntwikkelders, ein brûkers en oanbieders fan kontenertechnology byinoar bringt.
Beheare in grut oantal konteners
Litte wy no útfine hokker soarte konteners dit binne. Dit is in applikaasje mei syn hiele omjouwing - benammen de biblioteken wêrfan it programma hinget. Dit alles wurdt ferpakt yn argiven en presintearre yn 'e foarm fan in ôfbylding dy't kin wurde útfierd nettsjinsteande it bestjoeringssysteem, hifke en mear. Mar d'r is in probleem - it behearen fan konteners op in grut oantal hosts is heul lestich. Dêrom is Kubernetes makke.
In kontenerôfbylding fertsjintwurdiget in applikaasje plus syn ôfhinklikens. De applikaasje, syn ôfhinklikens, en it OS-bestânsysteemôfbylding lizze yn ferskate dielen fan 'e ôfbylding, saneamde lagen. Lagen kinne opnij brûkt wurde foar ferskate konteners. Bygelyks kinne alle applikaasjes yn in bedriuw de Ubuntu-basislaach brûke. By it útfieren fan konteners is d'r gjin ferlet om meardere kopyen fan in inkele basislaach op 'e host te bewarjen. Hjirmei kinne jo ôfbylding opslach en levering optimalisearje.
As wy in applikaasje fanút in kontener wolle útfiere, wurde de nedige lagen op elkoar lein en wurdt in overlay-bestânsysteem foarme. In opname laach wurdt pleatst boppe, dat wurdt fuorthelle as de kontener stoppet. Dit soarget derfoar dat as de kontener rint, de applikaasje altyd deselde omjouwing sil hawwe, dy't net feroare wurde kin. Dit garandearret de reprodusearberens fan 'e omjouwing op ferskate host OS's. Oft it Ubuntu of CentOS is, de omjouwing sil altyd itselde wêze. Derneist is de kontener isolearre fan 'e host mei meganismen ynboud yn' e Linux-kernel. Applikaasjes yn in kontener sjogge gjin bestannen, prosessen fan 'e host en oanbuorjende konteners. Dizze isolaasje fan applikaasjes fan it host-OS leveret in ekstra laach fan feiligens.
D'r binne in protte ark beskikber om konteners op 'e host te behearjen. De populêrste fan har is Docker. It lit jo de folsleine libbenssyklus fan konteners leverje. It wurket lykwols mar op ien host. As jo konteners moatte beheare oer meardere hosts, kin Docker it libben hel meitsje foar yngenieurs. Dêrom is Kubernetes makke.
De fraach nei Kubernetes is krekt te tankjen oan de mooglikheid om groepen fan konteners op meardere hosts te behearjen as in soarte fan ienige entiteit. De populariteit fan it systeem biedt de kâns om DevOps of Development Operations te bouwen, wêryn Kubernetes wurdt brûkt om de prosessen fan dizze DevOps út te fieren.
figuer 1. Skematyske foarstelling fan hoe't Kubernetes wurket
Folsleine automatisearring
DevOps is yn prinsipe de automatisearring fan it ûntwikkelingsproses. Rûchwei sprutsen skriuwe ûntwikkelders koade dy't wurdt upload nei it repository. Dan kin dizze koade automatysk wurde sammele fuortendaliks yn in kontener mei alle bibleteken, testen en "útrôle" nei de folgjende poadium - Staging, en dan fuortendaliks nei produksje.
Tegearre mei Kubernetes lit DevOps jo dit proses automatisearje sadat it praktysk bart sûnder dielname fan 'e ûntwikkelders sels. Hjirtroch is de bou signifikant rapper, om't de ûntwikkelder dit net op syn kompjûter hoecht te dwaan - hy skriuwt gewoan in stikje koade, triuwt de koade nei it repository, wêrnei't de pipeline wurdt lansearre, dy't it proses kin befetsje fan bouwen, testen en útroljen. En dit bart mei elke commit, dus testen bart kontinu.
Tagelyk, mei help fan in kontener kinne jo der wis fan wêze dat de hiele omjouwing fan dit programma wurdt frijjûn yn produksje krekt yn 'e foarm wêryn it waard hifke. Dat is, d'r sille gjin problemen wêze lykas "d'r wiene guon ferzjes yn 'e test, oaren yn produksje, mar doe't wy se ynstalleare, foel alles." En sûnt hjoed wy hawwe in trend nei microservice arsjitektuer, as ynstee fan ien enoarme applikaasje binne d'r hûnderten lytse, om se mei de hân te behearjen, sil in enoarme meiwurkers fan meiwurkers nedich wêze. Dêrom brûke wy Kubernetes.
Pros, pros, pros
As wy prate oer de foardielen fan Kubernetes as platfoarm, dan hat it wichtige foardielen út it eachpunt fan it behearen fan in microservice-arsjitektuer.
- Behear fan meardere replika's. It wichtichste is it behearen fan konteners oer meardere hosts. Noch wichtiger, beheare meardere applikaasje replika's yn konteners as ien entiteit. Hjirmei hoege yngenieurs gjin soargen te meitsjen oer elke yndividuele kontener. As ien fan 'e konteners crasht, sil Kubernetes dit sjen en opnij starte.
- Cluster netwurk. Kubernetes hat ek in saneamd klusternetwurk mei in eigen adresromte. Hjirtroch hat elke pod syn eigen adres. In subpod wurdt begrepen as de minimale strukturele ienheid fan in kluster wêryn konteners direkt lansearre wurde. Dêrneist hat Kubernetes funksjonaliteit dy't kombinearret in load balancer en Service Discovery. Hjirmei kinne jo it hânmjittich IP-adresbehear kwytreitsje en dizze taak delegearje oan Kubernetes. En automatyske sûnenskontrôles sille helpe by it ûntdekken fan problemen en omliede ferkear nei wurkjende pods.
- Konfiguraasje behear. By it behearen fan in grut oantal applikaasjes wurdt it lestich om applikaasjekonfiguraasje te behearjen. Foar dit doel hat Kubernetes spesjale ConfigMap-boarnen. Se kinne jo konfiguraasjes sintraal opslaan en se bleatstelle oan pods by it útfieren fan applikaasjes. Dit meganisme lit ús de konsistinsje fan 'e konfiguraasje garandearje yn op syn minst tsien of hûndert applikaasje replika's.
- Persistente Volumes. Containers binne ynherinte ûnferoarlik en as de kontener wurdt stoppe, sille alle gegevens skreaun nei it bestânsysteem wurde ferneatige. Mar guon applikaasjes bewarje gegevens direkt op skiif. Om dit probleem op te lossen, hat Kubernetes in funksjonaliteit foar skiif opslachbehear - Persistente Volumes. Dit meganisme brûkt eksterne opslach foar gegevens en kin persistente opslach, blok of bestân, oerdrage yn konteners. Dizze oplossing lit jo gegevens apart fan arbeiders opslaan, wat se bewarret as dizze deselde arbeiders brekke.
- Load Balancer. Ek al beheare wy yn Kubernetes abstrakte entiteiten lykas Deployment, StatefulSet, ensfh., úteinlik rinne konteners op reguliere firtuele masines as hardware-tsjinners. Se binne net perfekt en kinne op elk momint falle. Kubernetes sil dit sjen en ynterne ferkear omliede nei oare replika's. Mar wat te dwaan mei ferkear dat fan bûten komt? As jo gewoan ferkear rjochtsje nei ien fan 'e arbeiders, as it crasht, sil de tsjinst net beskikber wurde. Om dit probleem op te lossen hat Kubernetes tsjinsten lykas Load Balancer. Se binne ûntworpen om automatysk in eksterne wolkbalanser te konfigurearjen foar alle arbeiders yn it kluster. Dizze eksterne balancer rjochtet eksterne ferkear nei arbeiders en kontrolearret har status sels. As ien of mear arbeiders net beskikber wurde, wurdt ferkear omlaat nei oaren. Hjirmei kinne jo heul beskikbere tsjinsten meitsje mei Kubernetes.
Kubernetes wurket it bêste by it útfieren fan mikroservicearsjitektueren. It is mooglik om it systeem te ymplementearjen yn klassike arsjitektuer, mar it is sinleas. As in applikaasje net kin rinne op meardere replika's, wat makket it dan ferskil - yn Kubernetes of net?
Iepen boarne Kubernetes
Iepen boarne Kubernetes is in geweldich ding: ik haw it ynstalleare en it wurket. Jo kinne it ynsette op jo eigen hardware-servers, op jo eigen ynfrastruktuer, masters en arbeiders ynstallearje wêrop alle applikaasjes sille rinne. En it wichtichste, dit alles is fergees. Lykwols, der binne nuânses.
- De earste is de fraach nei kennis en ûnderfining fan behearders en yngenieurs dy't dit alles sille ynsette en stypje. Om't de klant folsleine frijheid fan hanneljen yn it kluster krijt, is hy sels ferantwurdlik foar de útfiering fan it kluster. En it is heul maklik om hjir alles te brekken.
- De twadde is it gebrek oan yntegraasjes. As jo Kubernetes útfiere sûnder in populêr virtualisaasjeplatfoarm, krije jo net alle foardielen fan it programma. Lykas it brûken fan Persistente Volumes en Load balancer tsjinsten.
figuer 2. K8s arsjitektuer
Kubernetes fan de ferkeaper
Yntegraasje mei in wolkprovider biedt twa opsjes:
- As earste kin in persoan gewoan klikke op de knop "kluster meitsje" en in kluster krije dy't al is konfigureare en klear foar gebrûk.
- Twad, de ferkeaper sels ynstalleart it kluster en set yntegraasje mei de wolk op.
Hoe bart it hjir. De yngenieur dy't it kluster begjint, spesifisearret hoefolle arbeiders hy nedich is en mei hokker parameters (bygelyks 5 arbeiders, elk mei 10 CPU's, 16 GB RAM en bygelyks 100 GB skiif). Dêrnei krijt it tagong ta it al foarme kluster. Yn dit gefal wurde de arbeiders wêryn't de lading lansearre wurdt folslein oerdroegen oan 'e kliïnt, mar it heule behearplan bliuwt ûnder de ferantwurdlikens fan' e ferkeaper (as de tsjinst wurdt levere neffens it behearde tsjinstmodel).
Lykwols, dit skema hat syn neidielen. Fanwegen it feit dat it behear fleantúch bliuwt by de ferkeaper, de ferkeaper net jouwe folsleine tagong ta de klant, en dit ferleget fleksibiliteit yn wurkjen mei Kubernetes. Soms bart it dat in klant wol taheakje wat spesifike funksjonaliteit oan Kubernetes, Bygelyks, autentikaasje fia LDAP, mar it behear fleantúch konfiguraasje lit dit net.
figuer 3. Foarbyld fan in Kubernetes kluster fan in wolk provider
Wat te kiezen: iepen boarne as ferkeaper
Dus, is Kubernetes iepen boarne as ferkeaper spesifyk? As wy iepen boarne Kubernetes nimme, dan docht de brûker dêrmei wat er wol. Mar d'r is in grutte kâns om josels yn 'e foet te sjitten. Mei de ferkeaper is it dreger, om't alles is betocht en ynsteld foar it bedriuw. It grutste neidiel fan iepen boarne Kubernetes is de eask foar spesjalisten. Mei in ferkeaper-opsje wurdt it bedriuw befrijd fan dizze hoofdpijn, mar it sil beslute moatte oft it har spesjalisten as de ferkeaper betelje sil.
No, de foardielen binne fanselssprekkend, de neidielen binne ek bekend. Ien ding is konstant: Kubernetes lost in protte problemen op troch it automatisearjen fan it behear fan in protte konteners. En hokker te kiezen, iepen boarne of ferkeaper - elkenien makket har eigen beslút.
It artikel waard taret troch Dmitry Krasnov, liedende arsjitekt fan 'e Containerum-tsjinst fan' e #CloudMTS-oanbieder
Boarne: www.habr.com