🥇Kubernetes zabaldu eta osatu (berrikuspena eta bideo-erreportajea)

Apirilaren 8an, jardunaldietan Saint HighLoad++ 2019, “DevOps and Operations” atalaren barruan, “Kubernetes zabaldu eta osatu” txostena eman zen, eta horren sorreran Flant enpresako hiru langilek parte hartu zuten. Bertan, Kubernetes-en gaitasunak zabaldu eta osatu nahi genituen hainbat egoeraz hitz egiten dugu, baina ez genuen irtenbide prest eta sinplerik aurkitu. Beharrezko irtenbideak ditugu Open Source proiektuetan, eta hitzaldi hau ere haiei eskainia dago.

Tradizioz, pozik aurkezten dugu erreportajearen bideoa (50 minutu, artikulua baino askoz informazio gehiago) eta laburpen nagusia testu moduan. Joan!

Nukleoa eta gehiketak K8etan

Kubernetes aspaldi ezarrita dagoen industria eta administrazioaren ikuspegiak aldatzen ari da:

Eskerrik asko berari abstrakzioak, jada ez dugu konfigurazio bat konfiguratzea edo komando bat exekutatzea bezalako kontzeptuekin funtzionatzen (Chef, Ansible...), baizik eta edukiontziak, zerbitzuak, etab.
Aplikazioak presta ditzakegu ñabardurak pentsatu gabe gune zehatza, zeinetan jarriko den martxan: bare metal, hornitzaileetako baten hodeia, etab.
K8s-ekin ez zara inoiz irisgarriagoa izan praktika onenak azpiegiturak antolatzeari buruz: eskalatze teknikak, autosendatzea, akatsen tolerantzia, etab.

Hala ere, noski, dena ez da hain leuna: Kubernetes-ek ere erronka berriak ekarri zituen.

Kubernetes ez erabiltzaile guztien arazo guztiak konpontzen dituen konbinazioa da. Core Kubernetes-ek bertan dauden gutxieneko beharrezko funtzioen multzoaz soilik arduratzen da denek multzoa:

Kubernetesen nukleoak edukiontziak taldekatzeko, trafikoa kudeatzeko eta abar oinarrizko primitibo multzo bat definitzen du. Hauei buruz zehatzago hitz egin dugu txostena duela 2 urte.

Bestalde, K8s-ek aukera handiak eskaintzen ditu erabilgarri dauden funtzioak zabaltzeko, beste batzuk ixten laguntzen dutenak - espezifikoak — erabiltzailearen beharrak. Kubernetes-en gehiketak klusterreko administratzaileen ardura dira, eta horiek behar den guztia instalatu eta konfiguratu behar dute euren klusterra "forma egokian" [bere arazo zehatzak konpontzeko]. Zer-nolako gehigarriak dira hauek? Ikus ditzagun adibide batzuk.

Gehigarrien adibideak

Kubernetes instalatuta, harritu gintezke nodo baten barruan zein nodoen artean poden elkarrekintzarako hain beharrezkoa den sareak bere kabuz ez funtzionatzea. Kubernetes nukleoak ez ditu beharrezko konexioak bermatzen; horren ordez, sarea zehazten du interfazea (CNI) hirugarrenen gehigarrietarako. Gehigarri horietako bat instalatu behar dugu, sarearen konfigurazioaz arduratuko dena.

Adibide hurbil bat datuak biltegiratzeko irtenbideak dira (disko lokala, sare blokeatzeko gailua, Ceph...). Hasieran muinean zeuden, baina etorrerarekin batera CSI egoera lehendik deskribatutakoaren antzeko zerbaitera aldatzen da: interfazea Kubernetes-en dago, eta inplementazioa hirugarrenen moduluetan dago.

Beste adibide batzuk hauek dira:

Ingress-kontrolatzaileak (ikusi haien iritzia atalean gure azken artikulua).
cert-kudeatzailea:
Operadore gehigarrien klase oso bat da (aipatutako cert-kudeatzailea barne hartzen duena), primitiboak eta kontrolatzaileak definitzen dituzte. Haien lanaren logika gure irudimenak soilik mugatzen du eta prest dauden azpiegitura osagaiak (adibidez, DBMS bat) primitibo bihurtzeko aukera ematen digu, askoz errazagoa baita lan egiteko (edukiontzi multzo batekin eta haien ezarpenekin baino). Operadore kopuru handi bat idatzi da; horietako asko oraindik produkziorako prest ez badaude ere, denbora kontua da:
Metrikak - Kubernetes-ek interfazea (Metrics API) inplementaziotik (Prometheus egokitzailea, Datadog kluster-agentea... bezalako hirugarrenen gehigarriak...) nola bereizi zuen.
For jarraipena eta estatistikak, non praktikan ez bakarrik beharrezkoak diren Prometeo eta Grafana, baina baita kube-state-metrics, node-exporter, etab.

Eta hau ez da gehigarrien zerrenda osoa... Adibidez, gaur egun instalatzen dugun Flant enpresan 29 gehikuntza (guztiek 249 Kubernetes objektu sortzen dituzte guztira). Besterik gabe, ezin dugu kluster baten bizitza ikusi gehigarririk gabe.

automatizazioa

Operadoreak egunero aurkitzen ditugun ohiko eragiketak automatizatzeko diseinatuta daude. Hona hemen benetako adibideak, zeinen operadore bat idaztea irtenbide bikaina izango litzatekeen:

Erregistro pribatu bat dago (hau da, saioa hasteko eskatzen duena) aplikaziorako irudiekin. Suposatzen da pod bakoitzari erregistroan autentifikazioa ahalbidetzen duen sekretu berezi bat esleitzen zaiola. Gure zeregina sekretu hori izen-espazioan aurkitzen dela ziurtatzea da, pods-ek irudiak deskargatu ditzaten. Aplikazio asko egon daitezke (bakoitzak sekretu bat behar du), eta komenigarria da sekretuak aldian-aldian eguneratzea, beraz, sekretuak eskuz ezartzeko aukera ezabatzen da. Hortik dator operadorea erreskatean: izen-espazioa agertu arte itxarongo duen kontroladore bat sortzen dugu eta, gertaera horretan oinarrituta, sekretu bat gehituko dio izen-espazioari.
Lehenespenez, debekatuta dago podetatik Internetera sarbidea. Baina batzuetan beharrezkoa izan daiteke: logikoa da sarbide-baimen-mekanismoak besterik gabe funtzionatzea, trebetasun zehatzik eskatu gabe, adibidez, etiketa jakin bat izen-eremuan egoteagatik. Nola lagundu gaitzake operadoreak hemen? Kontrolagailu bat sortzen da, etiketa izen-espazioan agertu arte zain eta Interneterako sarbiderako politika egokia gehitzen duena.
Antzeko egoera: demagun jakin bat gehitu behar genuela kutsatu, antzeko etiketa badu (aurrizki moduko batekin). Operadorearekin egindako ekintzak agerikoak dira...

Edozein klusteretan, ohiko zereginak konpondu behar dira, eta behar bezala hau operadoreak erabiliz egin daiteke.

Deskribatutako istorio guztiak laburbilduz, ondorioztatu genuen behar duzun Kubernetes-en lan erosoa egiteko: A) instalatu gehigarriak, b) operadoreak garatzea (eguneroko administrazio-zereginak konpontzeko).

Nola idatzi adierazpen bat Kubernetesentzat?

Oro har, eskema sinplea da:

... baina gero hauxe da:

Kubernetes APIa gauza ez-trivial samarra da, menperatzeko denbora asko behar duena;
programazioa ere ez da guztiontzat (Go hizkuntza aukeratu zen hizkuntza hobetsi gisa, horretarako marko berezi bat dagoelako - SDK eragilea);
Egoera antzekoa da markoarekin berarekin.

Beheko lerroa: kontrolagailu bat idazteko (operadore) behar du baliabide garrantzitsuak gastatzea materiala aztertzeko. Hau operadore "handientzat" justifikatuko litzateke, esate baterako, MySQL DBMSrako. Baina goian azaldutako adibideak gogoratzen baditugu (sekretuak zabaltzea, Interneterako pod-ak sartzea...), guk ere behar bezala egin nahi ditugunak, orduan ulertuko dugu egindako esfortzuak orain behar dugun emaitza baino handiagoa izango dela:

Oro har, dilema bat sortzen da: baliabide asko gastatu eta adierazpenak idazteko tresna egokia aurkitu, edo antzinako erara egin (baina azkar). Hori konpontzeko -mutur horien arteko konpromisoa aurkitzeko- gure proiektua sortu genuen: shell-operadore (ikusi ere bere azken iragarpena ardatzean).

Shell-operatzailea

Nola egiten du lan? Klusterrak Go binario bat daukan shell-operadore batekin dauka. Haren ondoan multzo bat dago amuak (Haiei buruzko xehetasun gehiago - ikusi behean). Shell-operadoreak berak harpidetzen du zenbait garapenak Kubernetes APIan, eta hori gertatzen denean dagozkion amuak abiarazten ditu.

Nola daki shell-operadoreak zein amu dei zein gertaeratan? Informazio hori kakoek beraiek transmititzen diote shell-operadoreari, eta oso erraz egiten dute.

Hook Bash script bat edo argumentu bakarra onartzen duen beste edozein fitxategi exekutagarri bat da --config eta JSON-rekin erantzuten du. Azken honek zehazten du zein objektu diren interesatzen zaizkion eta zein gertaerari (objektu horiei dagokienez) erantzun behar zaien:

Gure adibideetako baten shell-operadorearen inplementazioa ilustratuko dut: aplikazioen irudiekin erregistro pribatu batera sartzeko sekretuak deskonposatzea. Bi etapa ditu.

Praktikatu: 1. Idatzi amu bat

Lehenik eta behin, prozesatu egingo dugun amuan --config, izen-espazioak interesatzen zaizkigula adieraziz, eta zehazki, haien sorreraren unea:

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

Nolakoa izango litzateke logika? Nahiko sinplea ere:

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

Lehenengo urratsa zein izen-espazio sortu den jakitea da, eta bigarrena erabiliz sortzea da kubectl izen-espazio honen sekretua.

Praktika: 2. Irudia muntatzea

Sortutako amua shell-operadoreari pasatzea besterik ez da geratzen - nola egin? Shell-operadorea bera Docker irudi gisa dator, beraz, gure zeregina kakoa gehitzea da irudi honetako direktorio berezi batean:

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

Muntatu eta bultzatzea besterik ez da geratzen:

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

Azken ukitua irudia klusterera zabaltzea da. Horretarako, idatzi dezagun Inplementazio:

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

Erreparatu beharreko bi puntu daude:

sortu berri den irudiaren adierazpena;
Kubernetes-eko ekitaldietara harpidetzeko eta izen-espazioetara sekretuak esleitzeko (gutxienez) eskubideak behar dituen sistema-osagai bat da, beraz, ServiceAccount (eta arau multzo bat) sortzen dugu kakoarentzat.

Emaitza - gure arazoa konpondu dugu senideak Kubernetesentzat sekretuak deskonposatzeko operadore bat sortzen duen moduan.

Shell-operadorearen beste ezaugarri batzuk

Kakoak lan egingo dituen aukeratutako motako objektuak mugatzeko, iragazi daitezke, etiketa batzuen arabera hautatuz (edo erabiliz matchExpressions):

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

Emanda deduplikatzeko mekanismoa, zeinak - jq iragazkia erabiliz - JSON objektu handiak txiki bihurtzeko aukera ematen dizu, non aldaketak kontrolatu nahi ditugun parametro horiek bakarrik geratzen diren.

Amu bati deitzen zaionean, shell-operadoreak pasatzen du objektuaren datuak, edozein beharretarako erabil daitekeena.

Hook abiarazten dituzten gertaerak ez dira Kuberneteseko gertaeretara mugatzen: shell-operadoreak laguntza eskaintzen du. denboraren arabera amuak deitzen (crontab-en antzera ohiko programatzaile batean), baita ekitaldi berezi bat ere onStartup. Gertaera hauek guztiak konbinatu eta kako berean eslei daitezke.

Eta shell-operadorearen beste bi ezaugarri:

Badabil modu asinkronikoan. Kubernetes-eko gertaera bat (sortzen ari den objektu bat, esaterako) jaso zenetik, beste gertaera batzuk (esaterako, ezabatzen ari den objektu bera) gerta litezke klusterrean, eta hookek kontutan hartu behar dute. Hook errore batekin exekutatu bada, lehenespenez hala izango da berriro deitu arrakastaz amaitu arte (portaera hori alda daiteke).
Esportatzen du metrikak Prometheus-erako, zeinarekin shell-operadorea funtzionatzen ari den uler dezakezun, jakin amu bakoitzeko errore kopurua eta uneko ilararen tamaina.

Txostenaren zati hau laburbiltzeko:

Gehigarriak instalatzen

Kubernetesekin lan erosoa izateko, gehigarriak instalatzeko beharra ere aipatu zen. Horren berri emango dizut orain nola egiten dugun gure konpainiak duen ibilbidearen adibidea erabiliz.

Kubernetesekin lanean hasi ginen hainbat klusterrekin, eta horren osagarri bakarra Ingress zen. Kluster bakoitzean modu ezberdinean instalatu behar zen, eta YAML konfigurazio batzuk egin genituen ingurune ezberdinetarako: bare metal, AWS...

Kluster gehiago zeudenez, konfigurazio gehiago zeuden. Horrez gain, konfigurazio hauek beraiek hobetu genituen, eta ondorioz nahiko heterogeneo bihurtu ziren:

Dena ordenatzeko, gidoi batekin hasi ginen (install-ingress.sh), zeinak argumentu gisa zabalduko dugun kluster mota hartu zuen, beharrezko YAML konfigurazioa sortu zuen eta Kubernetesera zabaldu zuen.

Laburbilduz, gure bidea eta harekin lotutako arrazoibideak honako hauek izan ziren:

YAML konfigurazioekin lan egiteko, txantiloi-motor bat behar da (lehen faseetan hau sed sinplea da);
kluster kopurua handituz gero, eguneratze automatikoaren beharra etorri zen (lehenengo irtenbidea scripta Git-en jartzea izan zen, cron erabiliz eguneratzea eta exekutatu);
antzeko gidoia behar zen Prometeorentzat (install-prometheus.sh), hala ere, nabarmentzekoa da sarrerako datu askoz gehiago behar dituelako, baita haien biltegiratzea ere (modu onean - zentralizatua eta cluster batean), eta datu batzuk (pasahitz) automatikoki sor daitezkeela:
gero eta kluster kopurura zerbait okerra zabaltzeko arriskua etengabe hazten ari zen, beraz, instalatzaileak konturatu ginen (hau da, bi gidoi: Ingress eta Prometheus-erako) eszenifikazioa behar zen (hainbat adar Git-en, hainbat cron dagokienean eguneratzeko: egonkorrak edo proba-kluster);
с kubectl apply lan egitea zaila egin da, ez delako deklaratiboa eta objektuak soilik sor ditzakeelako, baina ez haien egoerari buruzko erabakirik hartu/ezabatu;
Une hartan inplementatu ez genituen funtzio batzuk falta zitzaizkigun:
- kluster eguneratzeen emaitzen kontrol osoa,
- Parametro batzuk automatikoki zehaztea (instalazio-scriptetarako sarrera) clusterretik lor daitezkeen datuetan oinarrituta (aurkikuntza),
- bere garapen logikoa etengabeko aurkikuntza moduan.

Metatutako esperientzia hori guztia gure beste proiektuaren esparruan ezarri genuen - gehigarri-eragile.

Gehigarri-eragilea

Lehen aipatutako shell-operadorean oinarritzen da. Sistema osoa honelakoa da:

Honako hau gehitzen da shell-operadorearen kakoetan:

baloreen biltegiratzea,
Helm taula,
osagai hori balioen biltegia kontrolatzen du eta - aldaketaren bat izanez gero - diagrama berriro ateratzeko eskatuko dio Helm-i.

Horrela, Kubernetes-en gertaera baten aurrean erreakzionatu, kako bat abiarazi eta kako honetatik biltegian aldaketak egin ditzakegu, eta ondoren grafikoa berriro deskargatuko da. Lortutako diagraman, kakoen multzoa eta diagrama osagai batean bereizten ditugu, deitzen duguna modulua:

Modulu asko egon daitezke, eta horiei amu globalak gehitzen dizkiegu, balio global denda bat eta denda global hau kontrolatzen duen osagai bat.

Orain, Kubernetesen zerbait gertatzen denean, erreakzionatu dezakegu amu global bat erabiliz eta denda globalean zerbait alda dezakegu. Aldaketa hau nabarituko da eta klusterreko modulu guztiak zabalduko dira:

Eskema honek goian adierazitako gehigarriak instalatzeko baldintza guztiak betetzen ditu:

Helm txantiloiak eta deklarazioaz arduratzen da.
Eguneratze automatikoaren arazoa kako global bat erabiliz ebatzi zen, erregistrora programazio batean doa eta, bertan sistemaren irudi berri bat ikusten badu, zabaltzen du (hau da, "bere").
Ezarpenak klusterrean gordetzea erabiliz inplementatzen da ConfigMap, biltegietarako lehen datuak biltzen dituena (abiaraztean biltegietan kargatzen dira).
Pasahitzak sortzeko, aurkikuntza eta etengabeko aurkikuntza arazoak kakoen bidez konpondu ziren.
Eszenaratzea Docker-ek kutxatik kanpo onartzen dituen etiketari esker lortzen da.
Emaitza kontrolatzen da egoera ulertzeko neurrien bidez.

Sistema osoa Go-n bitar bakar baten moduan inplementatzen da, gehigarri-operadore deritzona. Honek diagrama errazagoa egiten du:

Diagrama honetako osagai nagusia modulu multzo bat da (behean grisez nabarmenduta). Orain beharrezkoa den gehigarrirako modulu bat idatz dezakegu esfortzu txiki batekin eta ziurtatu kluster bakoitzean instalatuko dela, eguneratuko dela eta klusterrean behar dituen gertaerei erantzungo diela.

"Flant" erabilerak gehigarri-eragile 70 Kubernetes kluster baino gehiagotan. Egungo egoera - alfa bertsioa. Orain beta kaleratzeko dokumentazioa prestatzen ari gara, baina oraingoz biltegian eskuragarri dauden adibideak, eta horren arabera zure gehigarria sortu dezakezu.

Non lor ditzaket gehigarri-operadorearen moduluak? Gure liburutegia argitaratzea da guretzat hurrengo etapa; hau udan egiteko asmoa dugu.

Bideoak eta diapositibak

Emanaldiko bideoa (~50 minutu):

Txostenaren aurkezpena:

PS

Beste erreportaje batzuk gure blogean:

«Datu-baseak eta Kubernetes»; (Dmitry Stolyarov; 8ko azaroaren 2018a HighLoad++-n);
«Monitorizazioa eta Kubernetes»; (Dmitry Stolyarov; 28ko maiatzaren 2018an RootConf-en);
«CI/CD praktika onak Kubernetes eta GitLab-ekin»; (Dmitry Stolyarov; 7ko azaroaren 2017a HighLoad++-n);
«Gure esperientzia Kubernetesekin proiektu txikietan»; (Dmitry Stolyarov; 6ko ekainaren 2017an RootConf-en).

Ondorengo argitalpenetan ere interesa izan zaitezke:

«Shell-operator aurkezten: Kubernetes-erako operadoreak sortzea errazagoa da'.

Iturria: www.habr.com

Kubernetes zabaltzea eta osatzea (berrikuspena eta bideo-txostena)