Parimad 10 nippi ja nõuannet Kubernetesest

Internetis on palju viidatud kirjandust, kuid mõnikord on kõige väärtuslikumad hoopis kõige lihtsamad nõuanded. Meeskond Kubernetes aaS Mail.ru-lt tõlkis kogumi kümnest nipist ja soovitusest, mille autor koostas pärast aastast tööd Kubernetesega. Soovitused pole järjestatud olulisuse järgi, kuid usume, et igaüks leiab endale midagi kasulikku.

Lihtsaim käsk Kubernetesega töötamiseks

Alustuseks on ilmselt kõige lihtsam ja kasulikum tegevus Kubernetesega töötamisel. Järgmine käsk lubab käskude automaatset täiendamist kubectl bash'i keskkonnas:

echo "source > ~/.bashrc

Automaatne täiendamine kubectl salvestatakse failisse .bashrc ja aktiveeritakse automaatselt iga kord, kui keskkond avatakse. See kiirendab pikkade käskude ja parameetrite, nagu all-namespaces, sisestamist. Täiendavad üksikasjad leiate Kubernetes bash'i abist..

Vaikimisi mälu ja CPU piirangud nimede ruumis

Kui rakendus on valesti kirjutatud, näiteks avab iga sekundi järel andmebaasi uue ühenduse, kuid kunagi ei sulge seda, siis toimub klastris mälu leke. Ja kui rakendusele ei ole deponeerimisel määratud mälu piirangut, võib see põhjustada sõlme kokkuvarisemise.

Sellise olukorra ennetamiseks võimaldab Kubernetes iga nimede ruumi vaikimisi piirangute seadmist. Need määratakse konkreetses nimede ruumi yaml-failis. Siin on näide sellisest failist:

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
spec:
  limits:
  - default:
      memory: 512Mi
    defaultRequest:
      memory: 256Mi
    type: Container

Looge selline yaml ja rakendage see mis tahes nimede ruumi. Näiteks nimede ruumile limit-example. Nüüd kehtib iga selle nimede ruumis käivitunud konteineri jaoks 512Mi piirang, kui sellele konteinerile ei ole määratud eraldi piiri.

Reostuse puhastamine vanades Kubernetes versioonides

Kubelet alustab vaikimisi reostuse puhastamist, kui var/lib/docker kasutab 90 % saadaval olevast kettaruumist. See on suurepärane, kuid Kubernetes 1.7 versioonini ei olnud vaike piirangut inode deskriptorite (failisüsteemi failide arvu) kasutamise arvule.

Teie konteiner võib kasutada ainult 50 % kettaruumist, kuid samal ajal võivad inode'd otsa saada, mis põhjustab probleeme tööprotsesside töös. var/lib/docker võib kasutada ainult 50% ketta ruumist, kuid sellegipoolest võivad inodid otsa saada, mis tekitab töötajate töös probleeme.

Vanades kubelet'i versioonides alates 1.4 kuni 1.6 tuleb lisada järgmine lipp:

--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%

Versioonides 1.7 ja uuemates on see lipp vaikimisi seadistatud. Kuid varasemad versioonid ei jälgi inoodide limiiti.

Minikube… väike, kuid võimas kohaliku Kubernetes'e lahendus

Minikube on kõige lihtsam viis käivitada kohalik Kubernetes'e klaster. See käivitub lihtsa käsklusega:

minikube start

Selle käsu täitmise tulemusel töötab teie arvutis tõeline Kubernetes'e klaster.

Illustratsiooni allikas

Nipp seisneb selles, kuidas rakendust koguda ja seda kohalikus klastris käivitada. Kui ei anta erilisi juhiseid, kogutakse Docker'i pilt teie arvutisse, mitte klastrisse.

Kuna Docker tuleb suunata pildi saatmiseks kohalikku Kubernetes'e klastrisse, antakse docker-masinale järgmine käsk:

eval $(minikube docker-env)

Nüüd saame rakendusi kohalikus Kubernetes'e klastris koguda.

Ärge jagage kubectl'i pääsmeid kõikidele

See tundub iseenesestmõistetav, kuid kui mitu meeskonda kasutavad oma rakenduste jaoks ühte klastrit (milleks Kubernetes on loodud), ei tasu lihtsalt kõikidele õigusi anda. kubectl. Parem on jagada meeskonnad, määrates igaühele oma nimeruumi ja piirates juurdepääsu RBAC poliitikatega.

Saate end vaevata, kirjutades iga pod'i jaoks juurdepääsuõigust, lugemist, loomist, kustutamist ja muid toiminguid. Kuid peamine on piirata juurdepääsu saladustele, lubades seda vaid administraatoritele. Nii eristame me neid, kes saavad klastrit administreerida, ja neid, kes saavad seal lihtsalt seadmeid paigaldada.

Haldage pod'i eelarveid

Kuidas tagada, et Kubernetes'e klastris pole rakendusele seiskamisi? PodDisruptionBudget ja veel kord PodDisruptionBudget.

Klastrite pidev uuendamine ja sõlmede tühjendamine on reaalne olukord. Igas juurutuses, millel on rohkem kui üks instants, tuleks kindlasti sisaldada PDB (PodDisruptionBudget). See luuakse lihtsas yaml failis, mis rakendatakse klastrile. Konkreetse PDB ulatus määratakse märgiste valijate abil.

Märkus: PDB eelarvet arvestatakse ainult tagasihoidliku eelarve rikkumise korral (voluntary disruption). Näiteks riistvara rikete korral PDB ei töötaks.

Näide PDB-st:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: app-a-pdb
spec:
  minAvailable: 2
  selector:
      matchLabels:
        app: app-a

Kaks peamist parameetrit on matchLabels ja minAvailable. Esimeses parameetris määratakse, milliste rakenduste jaoks eelarve kehtib. Näiteks, kui mul on juurutamised siltega app: app-a ja app: app-b, siis seda PDB-d rakendatakse ainult esimesele.

Parameeter minAvailable arvesse võetakse sõlme tühjendamisel. Näiteks meie näites tühjendamise ajal kõrvaldatakse kõik instantsid app: app-a, välja arvatud kaks.

See võimaldab kontrollida, kui palju rakenduse eksemplare peaks olema igal ajahetkel käimas.

Rakenduse töökindluse jälgimine

Selline jälgimine on võimalik kahel viisil: valmisoleku- või elujõudluskatsete kaudu.

Esimene proov (valmidus) määrab konteineri valmisoleku liikluse vastuvõtmiseks.

Teine (elujõudlus) näitab, kas konteiner on töökorras või tuleks see taaskäivitada.

Seotud konfiguratsioonid lisatakse lihtsalt yaml-i juurutamiseks. Seal saab määrata ajasid, viivitusi ja kordusproovide arvu. Rohkem teavet nende kohta leiate Kubernetes dokumentatsioonist.

Sildid igal pool

Sildid on Kuberneteses üks põhimõttelisi mõisted. Need võimaldavad objektidel vabalt üksteisega siduda ning luua päringuid siltide alusel. Kuberneteses saab isegi kliendile liikuda ja jälgida konkreetsete siltide põhiseid sündmusi.

Siltide abil saab teha praktiliselt kõike, kuid hea näide oleks mitme keskkonna loomine programmide käitamiseks ühes klastris.

Oletame, et kasutate sama klastrit dev ja qa. See tähendab, et teil võib olla rakendus app-a, mis töötab samaaegselt mõlemas keskkonnas qa ja dev. Sel juhul saame pöörduda eraldi rakenduse eksemplari poole konkreetses keskkonnas, määrates vastava parameetri keskkond. Näiteks, app: app-a ja environment: dev ühe keskkonna jaoks ja app: app-a ja environment: qa teise jaoks.

See võimaldab ligipääsu mõlema rakenduse eksemplaridele, näiteks testimise samaaegset läbiviimist.

Hoia asjad korras

Kubernetes on väga võimas süsteem, kuid iga süsteem suudab lõpuks kinni jääda paljude protsesside tõttu. Kubelet käivitab kõik, mida olete määranud, ja kontrollib omaenda.

Muidugi ei aeglusta ühe üksuse puudumine süsteemi, ja Kubernetes on algselt loodud skaleerimiseks. Kuid kui ühe asemel tekib miljon teenust, hakkab kubelet upuma.

Kui te mingil põhjusel kustutate rakenduse (konteineri, pildi, mida iganes), veenduge, et kõik oleks täielikult kustutatud.

Tutvuge Go programmikeelega

Peamine nõuanne, mille oleme lõpetuseks jätnud. Uurige Go programmikeelt.

Kubernetes on kirjutatud Go's, kõik laiendused on kirjutatud Go's ning ametlikult toetatakse ka kliendiraamatukogu client-go.

Seda saab kasutada erinevate ja huvitavate asjade jaoks. Näiteks Kubernetes'i süsteemi kohandamiseks oma äranägemise järgi. Näiteks võite kasutada oma programme andmete kogumiseks, rakenduste juurutamiseks või konteinerite lihtsaks puhastamiseks.

Go programmikeele õppimine ja client-go omandamine on ilmselt kõige tähtsam nõuanne, mida algetappides Kubernetes'i kasutajatele anda.

Tõlgitud Mail.ru Cloud Solutionsi toetusel

Mida veel lugeda:

1. Kubernetes'is on kolm automaatskaalumise taset ja kuidas neid tõhusalt kasutada.
2. Kubernetes'i töönod: palju väikeseid või vähe suuri?
3. 25 kasulikku tööriista Kubernetes'i juurutamiseks ja haldamiseks.

Allikas: habr.com