🥇7 parimat praktikat konteinerite haldamiseks Google'i versioonis

Märk. tõlge.: Originaali artikli autor on Théo Chamley, Google'i pilvetehnoloogiate arhitekt. Selles Google Cloud'i blogi postituses tutvustas ta lühikest ülevaadet oma ettevõtte põhjalikumast juhendist, mille pealkiri on «Parimad praktikad konteinerite haldamiseks». Selles on Google'i spetsialistid kogunud parimaid praktikaid konteinerite haldamiseks Google Kubernetes Engine'i kasutamise kontekstis ja mujal, käsitledes erinevaid teemasid alates turvalisusest kuni jälgimise ja logimisega. Nii et millised praktikad konteineritega töötamisel on Google'i arvates kõige olulisemad?

Kubernetes Engine (Kubernetes'i põhjal loodud teenus konteineriseeritud rakenduste käitamiseks Google Cloud'is — kommentaar tõlkijalt.) — üks parimaid viise skaleeritavate töökoormuste käitamiseks. Kubernetes tagab probleemideta toimimise enamus rakendustest, kui need on konteineriseeritud. Kuid kui soovite, et rakendus oleks hõlpsasti hallatav ja tahaksite saada kõiki Kubernetes'e eeliseid, peate järgima parimaid praktikaid. Need lihtsustavad rakenduse haldamist, jälgimist ja tõrkeotsingut ning suurendavad ka turvalisust.

Selles artiklis vaatame üle, mida on oluline teada ja teha, et konteinerid Kuberneteses korralikult toimiksid. Neile, kes soovivad sügavamale sukelduda, tasub lugeda meie Parimad praktikad konteinerite haldamiseksning pöörata tähelepanu meie varasemale postitusele konteinerite koostamisest.

1. Kasutage konteinerite logimise natiivmehhanisme

Kui rakendus töötab Kubernetes klastris, ei vaja logid ei ole liiga palju. Tsentraliseeritud logimissüsteem on tõenäoliselt juba olemas kasutatavas klastris. Kubernetes Engine'i kasutamisel vastutab selle eest Stackdriver Logging. (Märk. tõlge.: Kui kasutate oma Kubernetes'i installatsiooni, soovitame vaadata meie Open Source lahendust — loghouse.) Ärge keerake endale elu raskeks ja kasutage konteinerite logimise natiivmehhanisme. Kirjutage logid stdout ja stderr — need saavad automaatselt kätte, salvestatakse ja indekseeritakse.

Soovi korral saate logisid kirjutada ka JSON formaadis. Selline lähenemine võimaldab hõlpsasti lisada neile metaanoteeringuid. Koos nendega ilmub Stackdriver Loggingisse logide otsimise võimalus, kasutades neid metaanoteeringuid.

2. Veenduge, et konteinerid oleksid state'less ja immutable

Kubernetesi klastris töötamiseks peavad konteinerid olema stateless ja immutable. Kui need tingimused on täidetud, saab Kubernetes oma tööd teha, luues ja hävitades rakendusolendeid siis ja seal, kus see vajalik on.

Stateless tähendab, et kõik olekud (püsivad andmed igas vormis) salvestatakse konteinerist väljapoole. Selleks võivad erinevad tüüpi välised salvestussüsteemid vastavalt vajadustele olla kaasatud: Cloud Storage, Persistent Disks, Redis, Cloud SQL või teised hallatavad andmebaasid. (Märk. tõlge.: Lisainfot leiate ka meie artiklist „Operaatorid Kubernetes'e jaoks: kuidas käivitada stateful-rakendusi».)

Immutable tähendab, et konteinerit ei muudeta selle eluea jooksul: pole värskendusi, parandusi, konfiguratsiooni muudatusi. Kui peate rakenduskoodi värskendama või plaastrit rakendama, looge uus pilt ja paigaldage see. Soovitav on viia konteineri konfiguratsioon (kuulamisport, täitev keskkonna valikud jne) välja — Secrets ja ConfigMaps. Neid on võimalik uuendada ilma, et oleks vajalik uut konteinerit kokku panna. Lihtsaks piltide koostamise voogude loomiseks võib kasutada Cloud Build. (Märk. tõlge.: Me kasutame nende eesmärkide jaoks Open Source tööriista dapp.)

Kubernetesi deployementi konfiguratsiooni uuendamise näide ConfigMap'i abil, mis on seotud pod'idega konfiguratsioonina

3. Vältige privileegitud konteinerite kasutamist

Te ei käita ju oma serverites rakendusi root'i õigustes, eks? Kui häkker pääseb rakendusse, pääseb ta ka root õigustega. Samad kaalutlused kehtivad ka privileegitud konteinerite käitamise vältimise kohta. Kui hosti seadistusi on vaja muuta, saab konteinerile anda konkreetsed võimed kasutades valikut securityContext Kubernetesis. Kui on vaja muuta sysctls, Kubernetesel on eriline annotatsioon selle jaoks. Üldiselt proovige võimalikult palju kasutada init- ja sidecar-konteinereid sarnaste privileegitud toimingute tegemiseks. Need ei vaja juurdepääsu ei sise- ega välist liiklust.

Kui te haldate klastrit, saate kasutada Pod Security Policy piirangute seadmiseks privileegitud konteinerite kasutamisele.

4. Vältige käitamist root'i all

Privileegitud konteineritest on juba räägitud, kuid oleks veel parem, kui te ei käivitaks konteineri sees rakendusi root-kasutaja õigustes. kui kurjategija leiab rakendusest, millel on root-õigused, kaugjuhtimise haavatavuse, mis võimaldab koodi täita, ja suudab seejärel välja pääseda konteineri piiridest seni teadmata haavatavuse kaudu, siis saavutab ta root-õigused hostis.

Parim viis selle vältimiseks on esmajoones mitte käivitada midagi root-kasutaja õigustes. Selleks võib kasutada direktiivi USER ühes Dockerfile või runAsUser Kuberneteses. Klastri administraator võib samuti seadistada sundkäitumise kaudu Pod Security Policy.

5. Tee rakendus jälgimiseks lihtsaks

Nagu logimine, on ka jälgimine lahutamatu osa rakenduse haldamisest. Populaarne lahendus Kubernetes kogukonnas jälgimiseks on Prometheus — süsteem, mis tuvastab automaatselt podid ja teenused, mis vajavad jälgimist. (Märk. tõlge.: Vaata ka meie äratarkust monitoorimise teemal Prometheuse ja Kubernetesega.) Stackdriver suudab jälgida Kubernetes klastreid ja sisaldab oma versiooni Prometheusest rakenduste jälgimiseks.

Kubernetesi juhtpaneel Stackdriveris

Prometheus eeldab, et rakendus edastab mõõdikud HTTP lõpp-punkti. Selleks on saadaval Prometheuse klienditeegid. Sarnast formaati kasutavad ka teised tööriistad, nagu OpenCensus ja Istio.

6. Tehke rakenduse terviseseisund kergesti kättesaadavaks

Rakenduse juhtimiseks tootmisrežiimis on abiks selle võime teavitada kogu süsteemi oma seisundist. Kas rakendus on töös? Kas see on korras? Kas see on valmis liiklust vastu võtma? Kuidas see käitub? Üks levinumaid viise selle probleemiga tegelemiseks on tervisekontrollide rakendamine (health checks). Kubernetesel on nende kahe tüübi kontrollid: elulisuse ja valmisoleku kontrollid.

Elulisuse kontrolli puhul rakendus peab olema varustatud HTTP lõpp-punktiga, mis tagastab vastuse "200 OK", kui see toimib ja selle põh sõltuvused on rahuldatud. Valmisoleku kontrolli puhul rakendus peab omama HTTP lõppu, mis tagastab vastuse „200 OK“, kui see töötab ja selle peamised sõltuvused on rahuldatud. Valmiduse kontrollimiseks (valmiduse kontrollimine) rakendus peab omama teistsugust HTTP lõpp-punkti, mis tagastab vastuse „200 OK”, kui rakendus on heas seisundis, algatamisprotsessid on lõpetatud ja mis tahes korrektne päring ei põhjusta viga. Kubernetes suunab liikluse konteinerisse ainult rakenduse valmiduse olemasolul nende kontrollide kohaselt. Kaks lõpp-punkti võivad olla ühendatud, kui elujõudluse (liveness) ja valmiduse (readiness) seisundite vahel ei ole erinevust.

Lisaks sellele saab lugeda vastavast artiklist, mille on kirjutanud Sandeep Dinesh, Google'i arendaja esindaja: „Kubernetesi parimad tavad: tervisekontrollide seadistamine valmiduse ja elujõudluse uuringutega».

7. Valige hoolikalt pildi versioon

Enamik avalikke ja privaate pilte kasutavad sildistamissüsteemi, mis sarnaneb kirjeldatule Parimad tavad konteinerite loomisel. Kui pilt rakendab süsteemi, mis on lähedane semantilisest versioonimisest, tuleb arvesse võtta sildistamise eripära. Näiteks võib silt latest tihti üle liikuda ühest pildist teise — sellele ei saa toetuda, kui vajate prognoositavaid ja korduvaid kogusid ja installatsioone.

Võite kasutada silti X.Y.Z (need on peaaegu alati muutumatud), kuid sellisel juhul jälgige kõiki plaastrite ja uuenduste jaoks, mis on seotud pildiga. Kui kasutataval pildil on silt X.Y, on see hea kullasüstem. Selle valimisel saad automaatselt plaastrid ja toetud samas rakenduse stabiilsele versioonile.