🥇7 parimat praktikat konteinerite haldamiseks Google'i versioonis

Märkus tõlke kohta.: Originaali artikli autor on Théo Chamley, Google'i pilveehitusarhitekt. Selles Google Cloud'i blogipostituses esitleb ta lühikokkuvõtte oma ettevõtte pikemast juhendist, pealkirjaga "Parimad praktikud konteinerite haldamiseks». Selles on Google'i ekspertide poolt kokku kogutud parimad praktikud konteinerite kasutamiseks Google Kubernetes Engine'i kontekstis ja mitte ainult, käsitledes laia teemade spektrit: alates turvalisusest kuni jälgimise ja logimise. Nii et millised konteinerite haldamise praktikud on Google'i arvates kõige olulisemad?

Kubernetes Engine (Kubernetesil põhinev teenus konteineriseeritud rakenduste käitamiseks Google Cloud'is — märkus tõlke kohta.) on üks parimaid viise skaleerimist vajavate töökoormuste käitamiseks. Kubernetes tagab enamikku rakendustest probleemivaba toimimise, kui need on konteineriseeritud. Kuid kui soovite, et rakenduse haldamine oleks lihtne ja soovite kasutada kõiki Kubernetes'e eeliseid, tuleb järgida parimaid praktikaid. Need lihtsustavad rakenduse haldamist, selle jälgimist ja tõrkeotsingut ning suurendavad ka turvalisust.

Selles artiklis vaatame üle, mida on oluline teada ja teha, et tagada konteinerite tõhus toimimine Kuberneteses. Kes soovib süvitsi minna, peaks lugema materjali Parimad praktikud konteinerite haldamiseks, samuti pöörama tähelepanu meie varasemale postitusele konteinerite ehitamisest.

1. Kasutage konteinerite logimise natiivmehhanisme

Kui rakendus käib Kubernetes'e klastris, siis logide jaoks ei ole vajalik palju. Tsentraliseeritud logimise süsteem on tõenäoliselt juba sisse ehitatud kasutatavasse klastrisse. Kui kasutate Kubernetes Engine'i, vastutab selle eest Stackdriver Logging. (Märkus tõlke kohta.: Kui kasutate oma Kubernetes'e installatsiooni, soovitame tutvuda meie avatud lähtekoodiga lahendusega — loghouse.) Ärge keerake endale elu raskeks ja kasutage konteinerite logimise natiivmehhanisme. Kirjutage logid stdout ja stderr — need saadetakse automaatselt, salvestatakse ja indekseerivad.

Soovi korral saate logisid kirjutada ka JSON formaadis. Selline lähenemine võimaldab hõlpsasti lisada neile metaandmeid. Koos nendega ilmub Stackdriver Logging'is võimalus otsida logisid nende metaandmete abil.

2. Veenduge, et konteinerid oleksid stateful ja immutable

Kubernetesi klastris töötavate konteinerite korrektseks funktsioneerimiseks peavad need olema stateless ja immutable. Kui need tingimused on täidetud, saab Kubernetes oma ülesandeid täita, luues ja hävitades rakenduse üksusi, kui ja kus see on vajalik.

Stateless tähendab, et kõik olekud (kõikvõimalikud püsivad andmed) talletatakse konteinerist väljaspool. Selleks, sõltuvalt vajadustest, võivad olla kaasatud erinevad välised ladustamisvõimalused: Pilvelaadimise teenus, Püsivad kettad, Redis, Cloud SQL või muud haldatud andmebaasid. (Märkus tõlke kohta.: Lisainformatsiooni selle kohta lugege ka meie artiklist „Kubernetes'i operaatorid: kuidas käivitada stateful-rakendusi».)

Immutable tähendab, et konteinerit ei muudetaks elu jooksul: ei mingit uuendamist, plaastrite rakendamist ega konfiguratsiooni muutmist. Kui peate rakenduse koodi uuendama või plaastri rakendama, looge uus pilt ja juurutage see. Soovitav on konteineri konfiguratsioon (kuulamisport, käituskeskkonna valikud jne) asetada väljapoole — Saladused ja ConfigMaps. Neid saab uuendada, ilma et oleks vajalik uut konteineripilti luua. Pilti kogumispipeline'ide lihtsaks loomiseks saab kasutada Cloud Build. (Märkus tõlke kohta.: Me kasutame nende jaoks avatud lähtekoodiga tööriista dapp.)

Näide Deployment konfiguratsiooni uuendamisest Kubernetesis ConfigMap'i kaudu, mis on monteeritud podidesse konfiguraatorina

3. Välistage privileege sisaldavad konteinerid

Te ei käivita ju oma serverites rakendusi root'ina, eks? Kui ründaja pääseb rakendusse, saab ta root'i õigused. Samad kaalutlused kehtivad ka privileege sisaldavate konteinerite käivitamise keelamisele. Kui hostis seadistusi muuta on vaja, saab konteinerile anda kindlad capabilities kasutades valikut securityContext Kubernetesis. Kui on vaja muuta sysctls, siis Kubernetesil on erinev annotatsioon selle jaoks. Üldiselt püüdke teha maksimaalselt kasutust init- ja sidecar-konteineritele sarnaste privileegide toimingute jaoks. Need ei vaja kättesaadavust ei sisetu trafikus, ega välises.

Kui haldate klastrit, võite kasutada Pod Security Policy privilegeeritud konteinerite rakendamise piirangute jaoks.

4. Vältige käivitamist root'al

O privileeritud konteinerite kohta on juba räägitud, kuid olukord paraneb veelgi, kui te lisaks sellele ei käivita konteineri sees rakendusi root õigustega. Kui kurjategija leiab rakenduses, mis töötab root õigustes, kaugjuhtimise haavatavuse koodide täitmiseks, ja suudab seejärel lahkuda konteineri piiridest tundmatute haavatavuste kaudu, saavutab ta hostil root õigused.

Parim viis selle vältimiseks on kõigepealt mitte käivitada midagi root õigustes. Selleks saab kasutada direktiivi KASUTAJA ja Dockerfile või runAsUser Kuberneteses. Klastri administraator saab samuti seadistada sundimist, kasutades Pod Security Policy.

5. Tehke rakendus jälgimiseks lihtsaks

Nagu logimine, on jälgimine rakenduse haldamise lahutamatu osa. Populaarne lahendus Kubernetese kogukonnas jälgimiseks on Prometheus — süsteem, mis avastab automaatselt podid ja teenused, mis vajavad jälgimist. (Märkus tõlke kohta.: Vaadake ka meie üldist aruannet teemal jälgimine Prometheuse ja Kubernetese abil.) Stackdriver on suuteline jälgima Kubernetese klastreid ja sisaldab oma versiooni Prometheusest rakenduste jälgimiseks.

Kubernetese jälgimise paneel Stackdriveris

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

6. Tehke rakenduse tervislik olek kergesti kättesaadavaks

Rakenduse haldamisel tootmises aitab selle suutlikkus teatada oma olekust kogu süsteemile. Kas rakendus on käivitatud? Kas see on korras? Kas see on valmis liiklust vastu võtma? Kuidas see käitub? Kõige levinum viis selle probleemi lahendamiseks on elujõudude kontrollide rakendamine (health checks). Kubernetese jaoks on nende kahe tüüpi kontrollid: elujõud ja valmisoleku kontrollid.

Elujõu kontrolli jaoks (liveness probe) peab rakendusel olema HTTP lõpp-punkt, mis tagastab '200 OK' vastuse, kui see töötab ja selle põh sõltuvused on rahuldatud. Valmiduse kontrolli jaoks (readiness probe) Rakendus peab omama teist HTTP lõppu, mis tagastab vastuse „200 OK“, kui rakendus on tervislik, initsialiseerimise sammud on lõpetatud ja kõik kehtivad päringud ei põhjusta viga. Kubernetes suunab liikluse konteinerisse ainult rakenduse valmisoleku tingimuste järgi, mis on defineeritud nende kontrollide kohaselt. Kaks lõppu võivad olla ühendatud, kui elujõudmise (liveness) ja valmisoleku (readiness) olekute vahel pole erinevust.

Lisateavet selle kohta leiate vastavast artiklist Sandeep Dineshilt, Google'i arendajate kaitsjalt: „Kubernetesi parimad praktikad: tervisekontrollide seadistamine valmisoleku ja elujõudmise kontrollidega».

7. Valige hoolikalt pildi versioon

Enamik avalikke ja privaatsed pilte kasutavad sildistamise süsteemi, mis on sarnane kirjeldatud süsteemiga Parimad praktikad konteinerite ehitamiseks. Kui pilt rakendab süsteemi, mis on lähedane semantilisele versioonimisel, tuleb arvesse võtta sildistamise spetsiifikat. Näiteks võib silt latest tavaliselt liikuda pildilt pildile - sellele ei saa toetuda, kui vajate ettearvatavaid ja korduvaid ehitusi ja installatsioone.

Saate kasutada silti X.Y.Z (need on peaaegu alati muutumatud), kuid sel juhul jälgige kõiki patche ja värskendusi pildi kohta. Kui kasutatava pildi silt on X.Y, on see hea keskmine variant. Valides selle, saate automaatselt kõik patchid ja toetute samal ajal rakenduse stabiilsele versioonile.