Kubernetes: open source versus venditore specificu

Hola, mi chjamu Dmitry Krasnov. Per più di cinque anni aghju amministratu clusters Kubernetes è custruendu architetture cumplesse di microservizi. À u principiu di questu annu, avemu lanciatu un serviziu per a gestione di clusters Kubernetes basatu annantu à Containerum. Pigliendu sta opportunità, vi dicu ciò chì hè Kubernetes è cumu l'integrazione cù un venditore difiere da open source.

Per principià, ciò chì hè Kubernetes. Questu hè un sistema per a gestione di cuntenituri nantu à un gran numaru d'ospiti. Da u grecu, per via, hè traduttu cum'è "pilotu" o "timoniere". Originariamente sviluppatu da Google è dopu donatu cum'è una cuntribuzione tecnologica à a Cloud Native Computing Foundation, una urganizazione internaziunale senza prufittu chì riunisce i principali sviluppatori di u mondu, utilizatori finali è fornitori di tecnulugia di container.

Kubernetes: open source versus venditore specificu

Gestisce un gran numaru di cuntenituri

Avà capimu chì tipu di cuntenituri sò questi. Questa hè una applicazione cù tuttu u so ambiente - soprattuttu e biblioteche da quale dipende u prugramma. Tuttu chistu hè imballatu in l'archivi è prisentatu in a forma di una maghjina chì pò esse eseguita indipendentemente da u sistema operatore, pruvatu è più. Ma ci hè un prublema - a gestione di cuntenituri in un gran numaru d'ospiti hè assai difficiule. Hè per quessa chì Kubernetes hè statu creatu.

Una maghjina di cuntainer rapprisenta una applicazione più e so dipendenze. L'applicazione, i so dependenzii, è l'imaghjini di u sistema di schedarii OS sò situati in diverse parti di l'imaghjini, cusì chjamati strati. I strati ponu esse riutilizzati per diversi cuntenituri. Per esempiu, tutte l'applicazioni in una cumpagnia puderanu aduprà a capa di basa Ubuntu. Quandu eseguite cuntenituri, ùn ci hè micca bisognu di almacenà parechje copie di una sola capa di basa nantu à l'ospite. Questu permette di ottimisà u almacenamentu di l'imaghjini è a consegna.

Quandu vulemu eseguisce una applicazione da un cuntinuu, i strati necessarii sò superposti l'un à l'altru è un sistema di file overlay hè furmatu. Una capa di registrazione hè posta nantu à a cima, chì hè eliminata quandu u cuntinuu si ferma. Questu assicura chì quandu u cuntinuu scorri, l'applicazione hà sempre u stessu ambiente, chì ùn pò micca esse cambiatu. Questu guarantisci a riproducibilità di l'ambiente nantu à i diversi OS d'ospiti. Ch'ella sia Ubuntu o CentOS, l'ambiente serà sempre u listessu. Inoltre, u cuntinuu hè isolatu da l'ospitu cù meccanismi integrati in u kernel Linux. L'applicazioni in un containeru ùn vedenu micca i schedari, i prucessi di l'ospiti è i cuntenituri vicini. Questu isolamentu di l'applicazioni da u SO di l'ospite furnisce una capa addiziale di sicurità.

Ci hè parechje strumenti dispunibuli per gestisce i cuntenituri in un host. U più populari di elli hè Docker. Permette di furnisce u ciclu di vita sanu di cuntenituri. Tuttavia, funziona solu nantu à un host. Se avete bisognu di gestisce i cuntenituri in parechje ospiti, Docker pò fà un infernu per l'ingegneri. Hè per quessa chì Kubernetes hè statu creatu.

A dumanda di Kubernetes hè precisamente a causa di a capacità di gestisce gruppi di cuntenituri nantu à parechji ospiti cum'è una sorta di una sola entità. A popularità di u sistema furnisce l'uppurtunità di custruisce DevOps o Operazioni di Sviluppu, in quale Kubernetes hè utilizatu per eseguisce i prucessi di questu DevOps.

Kubernetes: open source versus venditore specificu

Figura 1. Rappresentazione schematica di cumu travaglia Kubernetes

Automatizazione cumpleta

DevOps hè basicamente l'automatizazione di u prucessu di sviluppu. À pocu pressu, i sviluppatori scrivenu codice chì hè caricatu in u repository. Allora stu codice pò esse cullucatu in autumàticu immediatamente in un containeru cù tutte e biblioteche, pruvatu è "rolted out" à u prossimu stadiu - Staging, è dopu subitu à a Produzione.

Inseme cù Kubernetes, DevOps vi permette di automatizà stu prucessu in modu chì si faci cù praticamenti senza participazione da i sviluppatori stessi. A causa di questu, a custruzzione hè significativamente più veloce, postu chì u sviluppatore ùn hà micca bisognu di fà questu nantu à u so urdinatore - simpricimenti scrive un pezzu di codice, spinge u codice à u repository, dopu chì u pipeline hè lanciatu, chì pò include u prucessu. di custruzzione, teste, è roll out. È questu succede cù ogni impegnu, cusì a prova passa continuamente.

À u listessu tempu, l'usu di un cuntinuu permette di esse sicuru chì l'ambiente tutale di stu prugramma serà liberatu in a produzzione esattamente in a forma in quale hè statu pruvatu. Vale à dì, ùn ci sarà micca prublemi cum'è "ci era alcune versioni in a prova, altre in produzzione, ma quandu l'avemu installatu, tuttu hè cascatu". E postu chì oghje avemu una tendenza versu l'architettura di microserviziu, quandu invece di una applicazione enormosa ci sò centinaie di picculi, per amministrallu manualmente, serà necessariu un grande staffu di l'impiegati. Hè per quessa chì usemu Kubernetes.

Pro, pro, pro


Se parlemu di i vantaghji di Kubernetes cum'è una piattaforma, allora hà vantaghji significativi da u puntu di vista di gestisce una architettura di microserviziu.

  • Gestisce parechje repliche. A cosa più impurtante hè a gestione di cuntenituri in parechje host. A più impurtante, gestisce parechje repliche di l'applicazioni in cuntenituri cum'è una sola entità. Grazie à questu, l'ingegneri ùn anu micca da preoccupassi di ogni cuntainer individuale. Se unu di i cuntenituri crash, Kubernetes vi vede questu è riavviarà.
  • Rete di cluster. Kubernetes hà ancu una rete chjamata cluster cù u so propiu spaziu di indirizzu. Grazie à questu, ogni poda hà u so propiu indirizzu. Un subpod hè intesu cum'è l'unità strutturale minima di un cluster in quale i cuntenituri sò direttamente lanciati. Inoltre, Kubernetes hà funziunalità chì combina un bilanciatore di carica è Service Discovery. Questu permette di sguassà a gestione manuale di l'indirizzu IP è delegate stu compitu à Kubernetes. È i cuntrolli di salute automatichi aiutanu à detectà i prublemi è redirige u trafficu à i pods di travagliu.
  • Gestione di a cunfigurazione. Quandu gestisce un gran numaru di applicazioni, diventa difficiule di gestisce a cunfigurazione di l'applicazione. Per questu scopu, Kubernetes hà risorse speciale ConfigMap. Permettenu di almacenà cunfigurazioni cintrali è espone à i pods quandu eseguite l'applicazioni. Stu mekanismu ci permette di guarantiscia a coherenza di a cunfigurazione in almenu dece o centu rèpliche di l'applicazione.
  • Volumi persistenti. I cuntenituri sò intrinsecamente immutabili è quandu u cuntinuu hè firmatu, tutti i dati scritti à u sistema di fugliale seranu distrutti. Ma alcune applicazioni guardanu dati direttamente nantu à u discu. Per risolve stu prublema, Kubernetes hà una funziunalità di gestione di almacenamiento di discu - Volumi persistenti. Stu mekanismu usa l'almacenamiento esternu per e dati è pò trasferisce un almacenamentu persistente, bluccatu o fugliale, in cuntenituri. Sta suluzione vi permette di almacenà e dati separatamente da i travagliadori, chì li salva si sti stessi travagliadori si rompenu.
  • Load Balancer. Ancu s'è in Kubernetes gestionemu entità astratte cum'è Deployment, StatefulSet, etc., infine i cuntenituri funzionanu nantu à e macchine virtuali regulari o servitori hardware. Ùn sò micca perfetti è ponu cascà in ogni mumentu. Kubernetes vi vede questu è redirige u trafficu internu à altre repliche. Ma chì fà cù u trafficu chì vene da fora ? Se simpricimenti diretta u trafficu à unu di i travagliadori, s'ellu si crash, u serviziu diventerà indisponibile. Per risolve stu prublema, Kubernetes hà servizii cum'è Load Balancer. Sò pensati per cunfigurà automaticamente un equilibratore di nuvola esterna per tutti i travagliadori in u cluster. Stu equilibriu esternu dirige u trafficu esternu à i travagliadori è monitoreghja u so statu stessu. Se unu o più travagliadori diventanu indisponibili, u trafficu hè ridirettu à l'altri. Questu permette di creà servizii altamente dispunibili cù Kubernetes.

Kubernetes funziona megliu quandu esegue architetture di microservizi. Hè pussibule implementà u sistema in l'architettura classica, ma hè inutile. Se una applicazione ùn pò micca eseguisce nantu à parechje repliche, allora chì differenza face - in Kubernetes o micca?

Kubernetes open source


Open source Kubernetes hè una grande cosa: l'aghju stallatu è funziona. Pudete implementà nantu à i vostri servitori di hardware, nantu à a vostra propria infrastruttura, installà maestri è travagliadori nantu à quale tutte l'applicazioni saranu. È più impurtante, tuttu questu hè liberu. Tuttavia, ci sò sfumature.

  • U primu hè a dumanda di cunniscenza è sperienza di amministratori è ingegneri chì implementanu è sustenenu tuttu questu. Siccomu u cliente riceve una libertà completa d'azzione in u cluster, ellu hà a rispunsabilità per u rendiment di u cluster stessu. È hè assai faciule di rompe tuttu quì.
  • U sicondu hè a mancanza di integrazioni. Se eseguite Kubernetes senza una piattaforma di virtualizazione populari, ùn uttene micca tutti i benefici di u prugramma. Cume l'usu di volumi persistenti è servizii di bilanciu di carica.

Kubernetes: open source versus venditore specificu

Figura 2. architettura k8s

Kubernetes da u venditore


L'integrazione cù un fornitore di nuvola furnisce duie opzioni:

  • Prima, una persona pò simpricimenti cliccà nantu à u buttone "creà cluster" è uttene un cluster digià cunfiguratu è prontu per l'usu.
  • Siconda, u vinditore stessu stalla u cluster è stabilisce l'integrazione cù u nuvulu.

Cumu succede quì. L'ingegnere chì principia u cluster specifica quanti travagliadori hà bisognu è cù quale paràmetri (per esempiu, 5 travagliadori, ognunu cù 10 CPU, 16 GB di RAM è, dì, 100 GB di discu). Dopu à quessa, accede à u cluster già furmatu. In questu casu, i travagliadori nantu à quale a carica hè lanciata sò completamente trasferiti à u cliente, ma tuttu u pianu di gestione resta sottu à a rispunsabilità di u venditore (se u serviziu hè furnitu secondu u mudellu di serviziu amministratu).

Tuttavia, stu schema hà i so inconvenienti. A causa di u fattu chì u pianu di gestione resta cù u venditore, u venditore ùn dà micca accessu sanu à u cliente, è questu reduce a flessibilità in u travagliu cù Kubernetes. A volte succede chì un cliente vole aghjunghje una funziunalità specifica à Kubernetes, per esempiu, l'autentificazione via LDAP, ma a cunfigurazione di u pianu di gestione ùn permette micca questu.

Kubernetes: open source versus venditore specificu

Figura 3. Esempiu di un cluster Kubernetes da un fornitore di nuvola

Cosa à sceglie: open source o venditore


Allora, hè Kubernetes open source o venditore specificu? Se pigliamu Kubernetes open source, allora l'utilizatore faci ciò chì vole cun ellu. Ma ci hè una grande chance di sparà in u pede. Cù u venditore hè più difficiule, perchè tuttu hè pensatu è cunfiguratu per a cumpagnia. U più grande svantaghju di Kubernetes open source hè u requisitu per i specialisti. Cù una opzione di vinditore, a cumpagnia hè liberata da stu mal di testa, ma duverà decide di pagà i so specialisti o u vinditore.

Kubernetes: open source versus venditore specificu

Kubernetes: open source versus venditore specificu

Ebbè, i pros sò evidenti, i contra sò ancu cunnisciuti. Una cosa hè custante: Kubernetes risolve assai prublemi automatizendu a gestione di parechji cuntenituri. E quale sceglite, open source o venditore - ognunu face a so propria decisione.

L'articulu hè statu preparatu da Dmitry Krasnov, architettu principali di u serviziu Containerum di u fornitore #CloudMTS.

Source: www.habr.com

Add a comment