🥇Zgjerimi dhe plotësimi i Kubernetes (rishikim dhe raport video)

8 Prill në konferencë Saint HighLoad++ 2019, si pjesë e seksionit "DevOps dhe Operacionet", u dha një raport "Zgjerimi dhe plotësimi i Kubernetes", në krijimin e të cilit morën pjesë tre punonjës të kompanisë Flant. Në të, ne flasim për situata të shumta në të cilat kemi dashur të zgjerojmë dhe plotësojmë aftësitë e Kubernetes, por për të cilat nuk kemi gjetur një zgjidhje të gatshme dhe të thjeshtë. Ne kemi zgjidhjet e nevojshme në formën e projekteve me kod të hapur, të cilëve u kushtohet edhe ky fjalim.

Sipas traditës, ne kemi kënaqësinë të prezantojmë video e raportit (50 minuta, shumë më informuese se artikulli) dhe përmbledhja kryesore në formë teksti. Shkoni!

Bërthama dhe shtesat në K8

Kubernetes po ndryshon industrinë dhe qasjet ndaj administratës që janë krijuar prej kohësh:

Falë tij abstraksione, ne nuk operojmë më me koncepte të tilla si vendosja e një konfigurimi ose ekzekutimi i një komande (Chef, Ansible...), por përdorim grupimin e kontejnerëve, shërbimeve, etj.
Ne mund të përgatisim aplikacione pa menduar për nuancat e faqe specifike, mbi të cilin do të lëshohet: metal i zhveshur, re e një prej ofruesve, etj.
Me K8 nuk keni qenë kurrë më i arritshëm praktikat më të mira mbi organizimin e infrastrukturës: teknikat e shkallëzimit, vetë-shërimi, toleranca ndaj gabimeve, etj.

Sidoqoftë, natyrisht, gjithçka nuk është aq e qetë: Kubernetes solli gjithashtu sfidat e veta të reja.

Kubernetes jo është një kombinat që zgjidh të gjitha problemet e të gjithë përdoruesve. Thelbi Kubernetes është përgjegjës vetëm për një sërë funksionesh minimale të nevojshme që janë të pranishme çdo grup:

Bërthama Kubernetes përcakton një grup bazë primitivësh për grupimin e kontejnerëve, menaxhimin e trafikut, etj. Ne folëm për to në mënyrë më të detajuar në raport 2 vite më parë.

Nga ana tjetër, K8s ofron mundësi të shkëlqyera për të zgjeruar funksionet e disponueshme, të cilat ndihmojnë në mbylljen e të tjerëve - specifike — nevojat e përdoruesve. Shtesat në Kubernetes janë përgjegjësi e administratorëve të grupimeve, të cilët duhet të instalojnë dhe konfigurojnë gjithçka që është e nevojshme për të marrë grupin e tyre "në formën e duhur" [për të zgjidhur problemet e tyre specifike]. Çfarë lloj shtesash janë këto? Le të shohim disa shembuj.

Shembuj të shtesave

Pasi të kemi instaluar Kubernetes, mund të habitemi që rrjeti që është aq i nevojshëm për ndërveprimin e pods brenda një nyje dhe midis nyjeve nuk funksionon më vete. Kerneli Kubernetes nuk garanton lidhjet e nevojshme; në vend të kësaj, ai përcakton rrjetin ndërfaqja (CNI) për shtesat e palëve të treta. Ne duhet të instalojmë një nga këto shtesa, e cila do të jetë përgjegjëse për konfigurimin e rrjetit.

Një shembull i afërt janë zgjidhjet e ruajtjes së të dhënave (disku lokal, pajisja e bllokut të rrjetit, Ceph...). Fillimisht ata ishin në thelb, por me ardhjen CSI situata ndryshon në diçka të ngjashme me atë të përshkruar tashmë: ndërfaqja është në Kubernetes dhe zbatimi i saj është në modulet e palëve të treta.

Shembuj të tjerë përfshijnë:

Hyrje-kontrolluesit (shih rishikimin e tyre në artikulli ynë i fundit).
cert-menaxher:
Операторы është një klasë e tërë e shtesave (e cila përfshin menaxherin e përmendur të certifikatës), ata përcaktojnë primitive(et) dhe kontrollues(et). Logjika e punës së tyre kufizohet vetëm nga imagjinata jonë dhe na lejon t'i kthejmë komponentët e gatshëm të infrastrukturës (për shembull, një DBMS) në primitivë, me të cilët është shumë më e lehtë të punosh (se sa me një grup kontejnerësh dhe cilësimet e tyre). Janë shkruar një numër i madh operatorësh - edhe nëse shumë prej tyre nuk janë ende gati për prodhim, është vetëm çështje kohe:
Metrikë - një ilustrim tjetër se si Kubernetes ndau ndërfaqen (Metrics API) nga zbatimi (shtesat e palëve të treta si përshtatësi Prometheus, agjenti i grupimit Datadog...).
Për monitorimi dhe statistikat, ku në praktikë jo vetëm nevojiten Prometeu dhe Grafana, por edhe kube-state-metrics, node-exporter etj.

Dhe kjo nuk është një listë e plotë e shtesave... Për shembull, në kompaninë Flant që instalojmë aktualisht 29 shtesa (të gjitha këto krijojnë gjithsej 249 objekte Kubernetes). E thënë thjesht, ne nuk mund ta shohim jetën e një grupi pa shtesa.

automatizim

Operatorët janë krijuar për të automatizuar operacionet rutinë që hasim çdo ditë. Këtu janë shembuj të jetës reale për të cilët shkrimi i një operatori do të ishte një zgjidhje e shkëlqyer:

Ekziston një regjistër privat (d.m.th. që kërkon një hyrje) me imazhe për aplikacionin. Supozohet se çdo pod i është caktuar një sekret i veçantë që lejon vërtetimin në regjistër. Detyra jonë është të sigurojmë që ky sekret të gjendet në hapësirën e emrave në mënyrë që pods të mund të shkarkojnë imazhe. Mund të ketë shumë aplikacione (secila prej të cilave ka nevojë për një sekret), dhe është e dobishme të përditësoni rregullisht vetë sekretet, kështu që opsioni i paraqitjes së sekreteve me dorë eliminohet. Këtu operatori vjen në shpëtim: ne krijojmë një kontrollues që do të presë që hapësira e emrave të shfaqet dhe, bazuar në këtë ngjarje, do të shtojë një sekret në hapësirën e emrave.
Lejoni si parazgjedhje qasja nga pods në internet është e ndaluar. Por ndonjëherë mund të kërkohet: është logjike që mekanizmi i lejes së hyrjes të funksionojë thjesht, pa kërkuar aftësi specifike, për shembull, nga prania e një etikete të caktuar në hapësirën e emrave. Si mund të na ndihmojë operatori këtu? Krijohet një kontrollues që pret që etiketa të shfaqet në hapësirën e emrave dhe shton politikën e duhur për hyrjen në internet.
Një situatë e ngjashme: supozoni se duhej të shtonim një të caktuar turp, nëse ka një etiketë të ngjashme (me një lloj parashtese). Veprimet me operatorin janë të dukshme...

Në çdo grup, detyrat rutinë duhet të zgjidhen, dhe korrekt kjo mund të bëhet duke përdorur operatorë.

Duke përmbledhur të gjitha historitë e përshkruara, arritëm në përfundimin se për punë të rehatshme në Kubernetes ju nevojitet: A) instaloni shtesa, b) zhvillojnë operatorë (për zgjidhjen e detyrave të përditshme të administratorit).

Si të shkruani një deklaratë për Kubernetes?

Në përgjithësi, skema është e thjeshtë:

... por më pas rezulton se:

Kubernetes API është një gjë jo e parëndësishme që kërkon shumë kohë për ta zotëruar;
programimi gjithashtu nuk është për të gjithë (gjuha Go u zgjodh si gjuha e preferuar sepse ekziston një kornizë e veçantë për të - Operatori SDK);
Situata është e ngjashme me vetë kornizën.

Bottom line: për të shkruar një kontrollues (operatori) duhet shpenzojnë burime të konsiderueshme për të studiuar materiale. Kjo do të justifikohej për operatorët "të mëdhenj" - të themi, për MySQL DBMS. Por nëse kujtojmë shembujt e përshkruar më sipër (shpalosja e sekreteve, qasja në internet...), të cilat ne gjithashtu duam ta bëjmë saktë, atëherë do të kuptojmë se përpjekja e shpenzuar do të jetë më e madhe se rezultati që na nevojitet tani:

Në përgjithësi, lind një dilemë: shpenzoni shumë burime dhe gjeni mjetin e duhur për të shkruar deklarata, ose bëjeni në mënyrën e vjetër (por shpejt). Për ta zgjidhur atë - për të gjetur një kompromis midis këtyre ekstremeve - ne krijuam projektin tonë: shell-operator (shih gjithashtu të tijën njoftimi i fundit në qendër).

Shell-operator

Si punon ai? Grup ka një pod që përmban një Go binar me një operator shell. Pranë tij është një grup i grepa (më shumë detaje rreth tyre - shih më poshtë). Vetë operatori i guaskës pajtohet me disa Zhvillimet në Kubernetes API, me ndodhjen e së cilës lëshon grepa përkatëse.

Si e di operatori i guaskës se cilat grepa duhet të thërrasë në cilat ngjarje? Ky informacion i transmetohet operatorit të guaskës nga vetë grepa, dhe ata e bëjnë atë shumë thjesht.

Një goditje është një skrip Bash ose çdo skedar tjetër i ekzekutueshëm që pranon një argument të vetëm --config dhe përgjigjet me JSON. Kjo e fundit përcakton se cilat objekte janë me interes për të dhe cilat ngjarje (për këto objekte) duhet t'u përgjigjen:

Unë do të ilustroj zbatimin në operatorin guaskë të një prej shembujve tanë - zbërthimi i sekreteve për të hyrë në një regjistër privat me imazhe aplikacioni. Ai përbëhet nga dy faza.

Praktikoni: 1. Shkruani një grep

Para së gjithash, në grep do të përpunojmë --config, duke treguar se ne jemi të interesuar për hapësirat e emrave, dhe konkretisht, momentin e krijimit të tyre:

[[ $1 == "--config" ]] ; then
  cat << EOF
{
  "onKubernetesEvent": [
    {
      "kind": "namespace",
      "event": ["add"]
    }
  ]
}
EOF
…

Si do të dukej logjika? Gjithashtu mjaft e thjeshtë:

…
else
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  kubectl create -n ${createdNamespace} -f - << EOF
Kind: Secret
...
EOF
fi

Hapi i parë është të zbuloni se cila hapësirë e emrave është krijuar dhe e dyta është ta krijoni atë duke përdorur kubectl sekret për këtë hapësirë emri.

Praktikoni: 2. Montimi i imazhit

E tëra që mbetet është të kaloni grepin e krijuar te operatori i guaskës - si ta bëni këtë? Vetë operatori i guaskës vjen si një imazh Docker, kështu që detyra jonë është të shtojmë grepin në një drejtori të veçantë në këtë imazh:

FROM flant/shell-operator:v1.0.0-beta.1
ADD my-handler.sh /hooks

E tëra që mbetet është ta montoni dhe ta shtyni:

$ docker build -t registry.example.com/my-operator:v1 .
$ docker push registry.example.com/my-operator:v1

Prekja e fundit është vendosja e imazhit në grup. Për ta bërë këtë, le të shkruajmë shpërndarje:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1 # 1
      serviceAccountName: my-operator              # 2

Ka dy pika për t'u kushtuar vëmendje:

treguesi i imazhit të krijuar rishtazi;
Ky është një komponent i sistemit që (në minimum) ka nevojë për të drejta për t'u abonuar në ngjarjet në Kubernetes dhe për të shpërndarë sekretet në hapësirat e emrave, kështu që ne krijojmë një llogari shërbimi (dhe një grup rregullash) për grepin.

Rezultati - ne e zgjidhëm problemin tonë të afërmit për Kubernetes në një mënyrë që krijon një operator për zbërthimin e sekreteve.

Karakteristika të tjera të operatorit të guaskës

Për të kufizuar objektet e llojit tuaj të zgjedhur me të cilët do të punojë grepi, ato mund të filtrohen, duke zgjedhur sipas etiketave të caktuara (ose duke përdorur matchExpressions):

"onKubernetesEvent": [
  {
    "selector": {
      "matchLabels": {
        "foo": "bar",
       },
       "matchExpressions": [
         {
           "key": "allow",
           "operation": "In",
           "values": ["wan", "warehouse"],
         },
       ],
     }
     …
  }
]

Me kusht mekanizmi i dedulikimit, i cili - duke përdorur një filtër jq - ju lejon të konvertoni objekte të mëdha JSON në të vogla, ku mbeten vetëm ato parametra që duam t'i monitorojmë për ndryshime.

Kur thirret një goditje, operatori i guaskës e kalon atë të dhënat e objektit, i cili mund të përdoret për çdo nevojë.

Ngjarjet që shkaktojnë grepa nuk janë të kufizuara në ngjarjet e Kubernetes: operatori i guaskës ofron mbështetje për duke thirrur grepa nga koha (i ngjashëm me crontab në një planifikues tradicional), si dhe një ngjarje e veçantë ne fillim. Të gjitha këto ngjarje mund të kombinohen dhe të caktohen në të njëjtën goditje.

Dhe dy veçori të tjera të operatorit të guaskës:

Punon në mënyrë asinkrone. Meqenëse një ngjarje Kubernetes (siç është një objekt që po krijohet) është marrë, ngjarje të tjera (si p.sh. i njëjti objekt që po fshihet) mund të kenë ndodhur në grup dhe grepat duhet të japin llogari për këtë. Nëse grepa është ekzekutuar me një gabim, atëherë si parazgjedhje do të jetë ri-thirrni deri në përfundimin me sukses (kjo sjellje mund të ndryshohet).
Ajo eksporton metrikë për Prometheus, me të cilin mund të kuptoni nëse operatori i guaskës është duke punuar, zbuloni numrin e gabimeve për çdo goditje dhe madhësinë aktuale të radhës.

Për të përmbledhur këtë pjesë të raportit:

Instalimi i shtesave

Për punë të rehatshme me Kubernetes, u përmend gjithashtu nevoja për të instaluar shtesa. Unë do t'ju tregoj për këtë duke përdorur shembullin e rrugës së kompanisë sonë se si e bëjmë atë tani.

Ne filluam të punojmë me Kubernetes me disa grupime, e vetmja shtesë në të cilën ishte Ingress. Duhej të instalohej ndryshe në çdo grup, dhe ne bëmë disa konfigurime YAML për mjedise të ndryshme: metal i zhveshur, AWS...

Meqenëse kishte më shumë grupime, kishte më shumë konfigurime. Për më tepër, ne i përmirësuam vetë këto konfigurime, si rezultat i të cilave ato u bënë mjaft heterogjene:

Për të vendosur gjithçka në rregull, filluam me një skenar (install-ingress.sh), i cili mori si argument llojin e grupit në të cilin do të vendosim, gjeneroi konfigurimin e nevojshëm YAML dhe e shpërndau në Kubernetes.

Shkurtimisht, rruga jonë e mëtejshme dhe arsyetimi i lidhur me të ishin si më poshtë:

për të punuar me konfigurimet YAML, kërkohet një motor shabllon (në fazat e para kjo është sed e thjeshtë);
me rritjen e numrit të grupimeve, erdhi nevoja për përditësim automatik (zgjidhja më e hershme ishte vendosja e skriptit në Git, përditësimi i tij duke përdorur cron dhe ekzekutimi i tij);
një skenar i ngjashëm kërkohej për Prometheun (install-prometheus.sh), megjithatë, dallohet për faktin se kërkon shumë më tepër të dhëna hyrëse, si dhe ruajtjen e tyre (në një mënyrë të mirë - të centralizuar dhe në një grup), dhe disa të dhëna (fjalëkalime) mund të gjenerohen automatikisht:
rreziku i përhapjes së diçkaje të gabuar në një numër në rritje grupesh po rritej vazhdimisht, kështu që ne kuptuam se instaluesit (d.m.th. dy skenarë: për Ingress dhe Prometheus) ishte e nevojshme vendosja në skenë (disa degë në Git, disa krone për t'i përditësuar ato në grupet përkatëse: stabile ose testuese);
с kubectl apply është bërë e vështirë të punosh me të, sepse nuk është deklarative dhe mund të krijojë vetëm objekte, por jo të marrë vendime për statusin/fshirjen e tyre;
Na mungonin disa funksione që nuk i kishim zbatuar fare në atë kohë:
- kontroll të plotë mbi rezultatin e përditësimeve të grupimeve,
- përcaktimi automatik i disa parametrave (hyrje për skriptet e instalimit) bazuar në të dhënat që mund të merren nga grupi (zbulimi),
- zhvillimin logjik të tij në formën e zbulimit të vazhdueshëm.

Ne e zbatuam të gjithë këtë përvojë të grumbulluar në kuadër të projektit tonë tjetër - shtesë-operator.

Operator shtesë

Ai bazohet në operatorin shell të përmendur tashmë. I gjithë sistemi duket si ky:

E mëposhtme u shtohet grepave të operatorit të guaskës:

ruajtjen e vlerave,
Tabela e helmetit,
komponent që monitoron ruajtjen e vlerave dhe - në rast të ndonjë ndryshimi - i kërkon Helm-it të ri-rrotullojë tabelën.

Kështu, ne mund të reagojmë ndaj një ngjarjeje në Kubernetes, të lëshojmë një goditje dhe nga kjo goditje mund të bëjmë ndryshime në hapësirën ruajtëse, pas së cilës grafiku do të rishkarkohet. Në diagramin që rezulton, ne ndajmë grupin e grepave dhe grafikun në një komponent, të cilin ne e quajmë modul:

Mund të ketë shumë module, dhe atyre u shtojmë grepa globale, një dyqan të vlerave globale dhe një komponent që monitoron këtë dyqan global.

Tani, kur diçka ndodh në Kubernetes, ne mund të reagojmë ndaj saj duke përdorur një goditje globale dhe të ndryshojmë diçka në dyqanin global. Ky ndryshim do të vërehet dhe do të bëjë që të gjitha modulet në grup të hapen:

Kjo skemë plotëson të gjitha kërkesat për instalimin e shtesave që u përmendën më lart:

Helm është përgjegjës për shabllonin dhe deklarimin.
Çështja e përditësimit automatik u zgjidh duke përdorur një goditje globale, e cila shkon në regjistër sipas një plani dhe, nëse sheh një imazh të ri të sistemit atje, e nxjerr atë (d.m.th. "vetë").
Ruajtja e cilësimeve në grup zbatohet duke përdorur ConfigMap, i cili përmban të dhënat primare për memoriet (në fillim ato ngarkohen në depo).
Problemet me gjenerimin e fjalëkalimit, zbulimin dhe zbulimin e vazhdueshëm u zgjidhën duke përdorur grepa.
Skenimi arrihet falë etiketave, të cilat Docker i mbështet jashtë kutisë.
Rezultati monitorohet duke përdorur metrikë me anë të të cilave mund të kuptojmë statusin.

I gjithë ky sistem zbatohet në formën e një binar të vetëm në Go, i cili quhet addon-operator. Kjo e bën diagramin të duket më i thjeshtë:

Komponenti kryesor në këtë diagram është një grup modulesh (e theksuar në gri më poshtë). Tani mund të shkruajmë një modul për shtesën e kërkuar me pak përpjekje dhe të jemi të sigurt që do të instalohet në çdo grup, do të përditësohet dhe do t'i përgjigjet ngjarjeve që i nevojiten në grup.

Përdorimet "flant". shtesë-operator në mbi 70 grupe Kubernetes. Statusi aktual - version alfa. Tani po përgatisim dokumentacionin për lëshimin e beta, por tani për tani në depo shembuj të disponueshëm, në bazë të së cilës mund të krijoni shtesën tuaj.

Ku mund t'i marr modulet për operator shtesë? Publikimi i bibliotekës sonë është faza tjetër për ne; ne planifikojmë ta bëjmë këtë në verë.

Video dhe sllajde

Video nga performanca (~50 minuta):

Prezantimi i raportit:

PS

Raporte të tjera në blogun tonë:

«Bazat e të dhënave dhe Kubernetes"? (Dmitry Stolyarov; 8 nëntor 2018 në HighLoad++);
«Monitorimi dhe Kubernetes"? (Dmitry Stolyarov; 28 maj 2018 në RootConf);
«Praktikat më të mira të CI/CD me Kubernetes dhe GitLab"? (Dmitry Stolyarov; 7 nëntor 2017 në HighLoad++);
«Përvoja jonë me Kubernetes në projekte të vogla"? (Dmitry Stolyarov; 6 qershor 2017 në RootConf).

Ju gjithashtu mund të jeni të interesuar në botimet e mëposhtme:

«Prezantimi i operatorit guaskë: krijimi i operatorëve për Kubernetes sapo u bë më i lehtë'.

Burimi: www.habr.com

Zgjerimi dhe plotësimi i Kubernetes (rishikim dhe raport video)