Ce este Kubernetes? Un ghid pentru containerizare și implementare

Publicat: 2022-03-11

Cu puțin timp în urmă, am folosit aplicația web monolit: baze de cod uriașe care au crescut în noi funcții și caracteristici până s-au transformat în giganți uriași, cu mișcare lentă și greu de gestionat. Acum, un număr tot mai mare de dezvoltatori, arhitecți și experți în DevOps vin la părerea că este mai bine să folosești microservicii decât un monolit gigant. De obicei, folosirea unei arhitecturi bazate pe microservicii înseamnă împărțirea monolitului în cel puțin două aplicații: aplicația front-end și o aplicație back-end (API-ul). După decizia de a utiliza microservicii, apare o întrebare: În ce mediu este mai bine să rulezi microservicii? Ce ar trebui să aleg pentru ca serviciul meu să fie stabil și ușor de gestionat și implementat? Răspunsul scurt este: Folosiți Docker!

În acest articol, vă voi prezenta containerele, vă voi explica Kubernetes și vă voi învăța cum să containerizați și să implementați o aplicație într-un cluster Kubernetes folosind CircleCI.

Docher? Ce este Docker?

Docker este un instrument conceput pentru a face DevOps (și viața ta) mai ușoară. Cu Docker, un dezvoltator poate crea, implementa și rula aplicații în containere . Containerele permit unui dezvoltator să împacheteze o aplicație cu toate părțile de care are nevoie, cum ar fi biblioteci și alte dependențe, și să le livreze pe toate ca un singur pachet.

Compararea aplicațiilor implementate la o gazdă cu o aplicație ambalată într-un container

Compararea aplicațiilor implementate la o gazdă cu o aplicație ambalată într-un container

Folosind containere, dezvoltatorii pot (re)implementa cu ușurință o imagine pe orice sistem de operare. Doar instalați Docker, executați o comandă și aplicația dvs. este în funcțiune. Ah, și nu vă faceți griji pentru orice inconsecvență cu noua versiune de biblioteci din sistemul de operare gazdă. În plus, puteți lansa mai multe containere pe aceeași gazdă - va fi aceeași aplicație sau alta? Nu contează.

Se pare că Docker este un instrument minunat. Dar cum și unde ar trebui să lansez containerele?

Există o mulțime de opțiuni pentru cum și unde să rulați containerele: AWS Elastic Container Service (AWS Fargate sau o instanță rezervată cu scalare automată orizontală și verticală); o instanță cloud cu imagine Docker predefinită în Azure sau Google Cloud (cu șabloane, grupuri de instanțe și scalare automată); pe propriul server cu Docker; sau, bineînțeles, Kubernetes! Kubernetes a fost creat special pentru virtualizare și containere de către inginerii Google în 2014.

Kubernetes? Ce este asta?

Kubernetes este un sistem open-source care vă permite să rulați containere, să le gestionați, să automatizați implementările, să scalați implementările, să creați și să configurați intrări, să implementați aplicații fără stat sau cu stare și multe alte lucruri. Practic, puteți lansa una sau mai multe instanțe și puteți instala Kubernetes pentru a le opera ca un cluster Kubernetes. Apoi obțineți punctul final API al clusterului Kubernetes, configurați kubectl (un instrument pentru gestionarea clusterelor Kubernetes) și Kubernetes este gata de difuzare.

Deci de ce ar trebui să-l folosesc?

Cu Kubernetes, puteți utiliza resursele de calcul la maximum. Cu Kubernetes, veți fi căpitanul navei (infrastructurii) dvs., cu Kubernetes umplendu-vă pânzele. Cu Kubernetes, serviciul tău va fi HA. Și cel mai important, cu Kubernetes, vei economisi o mulțime de bani.

Pare promițător! Mai ales dacă va economisi bani! Să vorbim mai mult despre asta!

Kubernetes câștigă popularitate zi de zi. Să mergem mai adânc și să investigăm ce se află sub capotă.

Under the Hood: Ce este Kubernetes?

Ce este Kubernetes? Componentele care alcătuiesc Kubernetes sub capotă

Componentele care alcătuiesc Kubernetes

Kubernetes este numele întregului sistem, dar, ca și mașina dvs., există multe piese mici care lucrează împreună în armonie perfectă pentru a face Kubernetes să funcționeze. Să învățăm care sunt.

Master Node – Un panou de control pentru întregul cluster Kubernetes. Componentele masterului pot fi rulate pe orice nod din cluster. Componentele cheie sunt:

  • Server API: punctul de intrare pentru toate comenzile REST, singura componentă a nodului principal care este accesibilă utilizatorului.
  • Magazin de date: stocare puternică, consecventă și foarte disponibilă, folosită de clusterul Kubernetes.
  • Programator: urmărește podurile nou create și le atribuie nodurilor. Implementarea podurilor și a serviciilor pe noduri are loc datorită planificatorului.
  • Manager controler: rulează toate controlerele care se ocupă de sarcinile de rutină din cluster.
  • Noduri de lucru: agent de nod primar, numit și noduri minion. Păstăile sunt rulate aici. Nodurile de lucru conțin toate serviciile necesare pentru a gestiona rețeaua dintre containere, a comunica cu nodul principal și a atribui resurse containerelor programate.
  • Docker: rulează pe fiecare nod de lucru și descarcă imagini și containere de pornire.
  • Kubelet: monitorizează starea unui pod și se asigură că containerele sunt în funcțiune. De asemenea, comunică cu depozitul de date, obținând informații despre servicii și scriind detalii despre cele nou create.
  • Kube-proxy: un proxy de rețea și echilibrator de încărcare pentru un serviciu pe un singur nod de lucru. Este responsabil pentru rutarea traficului.
  • Kubectl: Un instrument CLI pentru ca utilizatorii să comunice cu serverul API Kubernetes.

Ce sunt podurile și serviciile?

Podurile sunt cea mai mică unitate a clusterului Kubernetes, este ca o cărămidă în peretele unei clădiri uriașe. Un pod este un set de containere care trebuie să ruleze împreună și pot partaja resurse (spații de nume Linux, cgroups, adrese IP). Păstăile nu sunt destinate să trăiască mult.

Serviciile sunt o abstractizare pe deasupra unui număr de pod-uri, de obicei necesită un proxy pentru ca alte servicii să comunice cu acesta printr-o adresă IP virtuală.

Exemplu de implementare simplă

Cum interacționează diferitele părți interesate cu o aplicație alimentată de Kubernetes

Cum interacționează diferitele părți interesate cu o aplicație alimentată de Kubernetes

Voi folosi o aplicație simplă Ruby on Rails și GKE ca platformă pentru rularea Kubernetes. De fapt, puteți utiliza Kubernetes în AWS sau Azure sau chiar puteți crea un cluster în propriul hardware sau puteți rula Kubernetes local folosind minikube - toate opțiunile pe care le veți găsi pe această pagină.

Fișierele sursă pentru această aplicație pot fi găsite în acest depozit GitHub.

Pentru a crea o nouă aplicație Rails, executați:

 rails new blog

Pentru a configura conexiunea MySQL pentru producție în config/database.yml file :

 production: adapter: mysql2 encoding: utf8 pool: 5 port: 3306 database: <%= ENV['DATABASE_NAME'] %> host: 127.0.0.1 username: <%= ENV['DATABASE_USERNAME'] %> password: <%= ENV['DATABASE_PASSWORD'] %>

Pentru a crea un model de articol, un controler, vizualizări și o migrare, executați:

 rails g scaffold Article title:string description:text

Pentru a adăuga pietre prețioase la Gemfile:

 gem 'mysql2', '< 0.6.0', '>= 0.4.4' gem 'health_check'

Pentru a crea imaginea Docker, luați fișierul meu Docker și executați:

 docker build -t REPO_NAME/IMAGE_NAME:TAG . && docker push REPO_NAME/IMAGE_NAME:TAG

Este timpul să creați un cluster Kubernetes. Deschideți pagina GKE și creați cluster Kubernetes. Când cluster-ul este creat, faceți clic pe „Butonul Conectare” și copiați comanda - asigurați-vă că aveți instrumentul CLI gCloud (cum se face) și kubectl instalat și configurat. Executați comanda copiată pe computer și verificați conexiunea la clusterul Kubernetes; executați kubectl cluster-info .

Aplicația este gata să fie implementată în cluster-ul k8s. Să creăm o bază de date MySQL. Deschideți pagina SQL în consola gCloud și creați o instanță DB MySQL pentru aplicație. Când instanța este gata, creați utilizatorul și DB și copiați numele conexiunii instanței .

De asemenea, trebuie să creăm o cheie de cont de serviciu în pagina API & Services pentru a accesa o bază de date MySQL dintr-un container sidecar. Puteți găsi mai multe informații despre acest proces aici. Redenumiți fișierul descărcat în service-account.json . Vom reveni mai târziu la acel dosar.

Suntem gata să implementăm aplicația noastră în Kubernetes, dar mai întâi ar trebui să creăm secrete pentru aplicația noastră - un obiect secret în Kubernetes creat pentru stocarea datelor sensibile. Încărcați fișierul service-account.json descărcat anterior:

 kubectl create secret generic mysql-instance-credentials \ --from-file=credentials.json=service-account.json

Creați secrete pentru aplicație:

 kubectl create secret generic simple-app-secrets \ --from-literal=username=$MYSQL_PASSWORD \ --from-literal=password=$MYSQL_PASSWORD \ --from-literal=database-name=$MYSQL_DB_NAME \ --from-literal=secretkey=$SECRET_RAILS_KEY

Nu uitați să înlocuiți valorile sau să setați variabilele de mediu cu valorile dvs.

Înainte de a crea o implementare, să aruncăm o privire la fișierul de implementare. Am concatenat trei fișiere într-unul singur; prima parte este un serviciu care va expune portul 80 și va redirecționa toate conexiunile care vin la portul 80 la 3000. Serviciul are un selector cu care serviciul știe către ce pod-uri ar trebui să transmită conexiunile.

Următoarea parte a fișierului este implementarea, care descrie strategia de implementare - containere care vor fi lansate în interiorul podului, variabile de mediu, resurse, sonde, monturi pentru fiecare container și alte informații.

Ultima parte este Horizontal Pod Autoscaler. HPA are o configurație destul de simplă. Rețineți că, dacă nu setați resurse pentru container în secțiunea de implementare, HPA nu va funcționa.

Puteți configura Vertical Autoscaler pentru clusterul dvs. Kubernetes în pagina de editare GKE. De asemenea, are o configurație destul de simplă.

Este timpul să-l expediați către clusterul GKE! În primul rând, ar trebui să rulăm migrarea prin job. A executa:

kubectl apply -f rake-tasks-job.yaml – Acest job va fi util pentru procesul CI/CD.

kubectl apply -f deployment.yaml – pentru a crea serviciu, implementare și HPA.

Și apoi verificați podul dvs. executând comanda: kubectl get pods -w

 NAME READY STATUS RESTARTS AGE sample-799bf9fd9c-86cqf 2/2 Running 0 1m sample-799bf9fd9c-887vv 2/2 Running 0 1m sample-799bf9fd9c-pkscp 2/2 Running 0 1m

Acum să creăm o intrare pentru aplicație:

  1. Creați un IP static: gcloud compute addresses create sample-ip --global
  2. Creați intrarea (fișierul): kubectl apply -f ingress.yaml
  3. Verificați dacă intrarea a fost creată și luați IP-ul: kubectl get ingress -w
  4. Creați domeniul/subdomeniul pentru aplicația dvs.

CI/CD

Să creăm o conductă CI/CD folosind CircleCI. De fapt, este ușor să creați o conductă CI/CD folosind CircleCI, dar rețineți că un proces de implementare complet automatizat și murdar fără teste de acest fel va funcționa pentru proiecte mici, dar vă rugăm să nu faceți acest lucru pentru nimic serios, deoarece , dacă vreun cod nou are probleme în producție, veți pierde bani. De aceea, ar trebui să vă gândiți la proiectarea unui proces de implementare robust, să lansați sarcini Canary înainte de lansarea completă, să verificați erorile din jurnale după ce a început canary și așa mai departe.

În prezent, avem un proiect mic și simplu, așa că haideți să creăm un proces de implementare CI/CD complet automatizat, fără testare. În primul rând, ar trebui să integrați CircleCI cu depozitul dvs. - puteți găsi toate instrucțiunile aici. Apoi ar trebui să creăm un fișier de configurare cu instrucțiuni pentru sistemul CircleCI. Configurația pare destul de simplă. Principalele puncte sunt că există două ramuri în depozitul GitHub: master și production .

  1. Ramura principală este pentru dezvoltare, pentru codul proaspăt. Când cineva trimite cod nou în ramura principală, CircleCI pornește un flux de lucru pentru ramura principală - codul de compilare și testare.
  2. Ramura de producție este pentru implementarea unei noi versiuni în mediul de producție. Fluxul de lucru pentru ramura de producție este următorul: împingeți cod nou (sau și mai bine, deschideți PR din ramura principală în producție) pentru a declanșa un nou proces de construire și implementare; în timpul construcției, CircleCI creează noi imagini Docker, le împinge în GCR și creează o nouă lansare pentru implementare; dacă lansarea eșuează, CircleCI declanșează procesul de rollback.

Înainte de a rula orice versiune, ar trebui să configurați un proiect în CircleCI. Creați un nou cont de serviciu în API și o pagină Servicii în GCloud cu aceste roluri: acces complet la GCR și GKE, deschideți fișierul JSON descărcat și copiați conținutul, apoi creați o nouă variabilă de mediu în setările proiectului în CircleCI cu numele GCLOUD_SERVICE_KEY și inserați conținutul fișierului de cont de serviciu ca valoare. De asemenea, trebuie să creați următoarele variante de mediu: GOOGLE_PROJECT_ID (o puteți găsi pe pagina de pornire a consolei GCloud), GOOGLE_COMPUTE_ZONE (o zonă pentru clusterul dvs. GKE) și GOOGLE_CLUSTER_NAME (numele clusterului GKE).

Ultimul pas (implementare) la CircleCI va arăta astfel:

 kubectl patch deployment sample -p '{"spec":{"template":{"spec":{"containers":[{"name":"sample","image":"gcr.io/test-d6bf8/simple:'"$CIRCLE_SHA1"'"}]}}}}' if ! kubectl rollout status deploy/sample; then echo "DEPLOY FAILED, ROLLING BACK TO PREVIOUS" kubectl rollout undo deploy/sample # Deploy failed -> notify slack else echo "Deploy succeeded, current version: ${CIRCLE_SHA1}" # Deploy succeeded -> notify slack fi deployment.extensions/sample patched Waiting for deployment "sample" rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment "sample" rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment "sample" rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment "sample" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "sample" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "sample" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "sample" rollout to finish: 2 of 3 updated replicas are available... Waiting for deployment "sample" rollout to finish: 2 of 3 updated replicas are available... deployment "sample" successfully rolled out Deploy succeeded, current version: 512eabb11c463c5431a1af4ed0b9ebd23597edd9

Concluzie

Se pare că procesul de creare a noului cluster Kubernetes nu este atât de greu! Și procesul CI/CD este cu adevărat minunat!

Da! Kubernetes este minunat! Cu Kubernetes, sistemul tău va fi mai stabil, mai ușor de gestionat și te va face căpitanul sistemului tău. Ca să nu mai vorbim, Kubernetes gamifică puțin sistemul și va oferi +100 de puncte pentru marketingul tău!

Acum că aveți elementele de bază jos, puteți merge mai departe și puteți transforma acest lucru într-o configurație mai avansată. Plănuiesc să acopăr mai multe într-un articol viitor, dar, între timp, iată o provocare: creați un cluster Kubernetes robust pentru aplicația dvs. cu o bază de date cu stare situată în interiorul clusterului (inclusiv Pod sidecar pentru a face copii de rezervă), instalați Jenkins în interiorul același cluster Kubernetes pentru conducta CI/CD și lăsați Jenkins să folosească pod-uri ca sclavi pentru versiuni. Utilizați certmanager pentru a adăuga/obține un certificat SSL pentru intrarea dvs. Creați un sistem de monitorizare și alertă pentru aplicația dvs. utilizând Stackdriver.

Kubernetes este grozav pentru că se extinde cu ușurință, nu există nicio blocare a furnizorului și, din moment ce plătiți pentru instanțe, economisiți bani. Cu toate acestea, nu toată lumea este un expert Kubernetes sau are timp să înființeze un nou cluster - pentru o vedere alternativă, colegul Toptaler Amin Shah Gilani argumentează să folosească Heroku, GitLab CI și o cantitate mare de automatizare pe care și-a dat seama deja. pentru a scrie mai mult cod și a face mai puține sarcini de operare în Cum să construiți o conductă de implementare inițială eficientă .

Legate de:
  • Faceți matematica: scalarea automată a aplicațiilor de microservicii cu orchestratori
  • K8s/Kubernetes: AWS vs. GCP vs. Azure
  • O comparație cu rețele de servicii Kubernetes