Parimad 10 Kubernetes'i näpunäidet ja nippi

Internetis on palju viidatud kirjandust, kuid mõnikord on kõige väärtuslikumad just kõige lihtsamad soovitused. Meeskond Mail.ru Kubernetes aaS tõlkis kümne näpunäite ja nipi kogumiku, mille autor koostas aasta jooksul, töötades Kubernetes'ega. Soovitused ei ole tähtsuse järgi järjestatud, kuid usume, et igaüks leiab siit midagi kasulikku endale.

Lihtsaim käsk Kubernetes'i kasutamises

Alustuseks on võib-olla kõige lihtsam ja kasulikum tegevus Kubernetes'i kasutamisel. Järgmine käsk aktiveerib käskude automaattäiendamise kubectl bash'i terminalis:

echo "source > ~/ .bashrc

Automaatne täiendamine kubectl salvestatakse .bashrc faili ja aktiveeritakse automaatselt igal korral, kui terminal käivitatakse. See kiirendab pikkade käskude ja parameetrite, nagu all-namespacesLisaks leiate bash'i Kubernetes'i dokumenteerimisest.

Mälu ja CPU õigused vaikimisi nimel

Kui rakendus on valesti kirjutatud, näiteks avab iga sekundi järel uue ühenduse andmebaasiga, kuid kunagi ei sulge seda, toimub klastris mälu lekke. Ja kui rakenduse juurutamisel pole määratud mälupiirangut, võib see põhjustada sõlme riket.

Ette vältimiseks võimaldab Kubernetes igas nimespetsiifiliselt määrata vaikimisi piirangud. Need kirjutatakse yml-faili, mis on seotud konkreetse nimespetsiifikaga. Siin on sellise faili näide:

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

Looge selline yml-fail ja rakendage see igas nimespetsiifikas. Näiteks nimespetsiifikas limit-example. Nüüd kehtib igasuguste konteinerite puhul, mis on üles seatud selles nimespetsiifikas, piiri väärtus 512Mi, välja arvatud juhul, kui antud konteinerile on määratud mõni muu individuaalne piir.

Prügipuhastus vanades Kubernetes'i versioonides

Kubelet alustab vaikimisi prügipuhastust, kui var/lib/docker moodustab 90% vabast ketta ruumidest. See on suurepärane, kuid Kubernetes'i versioonis 1.7 ei olnud vaikimisi piiri indekseeritud inode (faili indeksi) arvu jaoks, mis vastab failide arvule failisüsteemis.

Võimalik, et teie konteiner var/lib/docker saa kasutada ainult 50% kettaruumi, kuid samas võivad inode'id otsa lõppeda, mis põhjustab töötajate töös probleeme.

Vanadel kubelet'i versioonidel vahemikus 1.4 kuni 1.6 tuleb lisada järgmine lipp:

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

Versioonis 1.7 ja uuemates see lipp on vaikimisi seadistatud. Kuid varasemad versioonid ei jälginud inoodide piirangut.

Minikube… väike, aga võimas kohalik Kubernetes

Minikube on kõige lihtsam viis käivitada kohalik Kubernetes klaster. Seda saab alustada lihtsa käsuga:

minikube start

Selle käsu täitmisel töötab teie arvutis tõeline Kubernetes 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 arvutis, mitte klastris.

Kuna Docker'it sundida saatma pilti kohalikku Kubernetes klastrisse, antakse docker-machine'ile järgmine käsk:

eval $(minikube docker-env)

Nüüd saame koguda rakendusi kohalikus Kubernetes klastris.

Ärge jagage kubectl'i ligipääsu kõigile

See tundub ilmne, kuid kui mitu meeskonda kasutavad oma rakenduste jaoks ühte klastri (milleks Kubernetes on loodud), ei tasu lihtsalt anda ligipääsu kõigile. kubectl. Parim on jagada meeskonnad, määrates igale neist oma nimespetsiifilised ruumid ja piirates ligipääsu RBAC-poliitikatega.

Sa saad keeruliseks minna, määrates iga podi jaoks juurdepääsu, lugemise, loomise, kustutamise ja muud õigused. Kuid peamine on piirata ligipääsu saladustele, lubades selle ainult administraatoritele. Nii eristame need, kes saavad klastrit hallata, ja need, kes saavad vaid seal rakendusi käivitada.

Haldage podide eelarveid

Kuidas tagada, et Kubernetes'i klastris ei esineks ootamatuid seisakuid? PodDisruptionBudget ja veel kord PodDisruptionBudget.

Klastrid uuendatakse perioodiliselt ja sõlmed tühjendatakse. Miski ei seisa paigal, see on reaalsus. Iga mitme instantsiga rakenduse juurutamisel peab kindlasti olema kaasatud PDB (PodDisruptionBudget). See luuakse lihtsas yaml-failis, mis rakendatakse klastri peale. Konkreetse PDB katvuse määravad märgise valikud.

Märkus: PDB eelarvet arvestatakse ainult pöörduva eelarve rikkumise korral (voluntary disruption). Näiteks riistvarahäirete korral PDB ei tööta.

PDB näide:

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, millistele rakendustele eelarve kehtib. Näiteks, kui mul on juurutamised siltidega app: app-a ja app: app-b, siis kehtib see PDB ainult esimesele.

Parameeter minAvailable arvesse võetakse sõlme tühjendamisel (puhastamisel). 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 hetkel käimas.

Rakenduse töökorralduse jälgimine

Seda jälgimist saab teostada kahel viisil: Readiness või Liveness kontrollide abil.

Esimene kontroll (readiness) määrab, kas konteiner on valmis liiklust vastu võtma.

Teine (liveness) näitab, kas konteiner on töökindel või tuleb see taaskäivitada.

Vastavad konfiguratsioonid lisatakse lihtsalt yaml-sissekandes. Seal saab määrata ajutisi, ooteaegu ja kordusproove. Täiendava informatsiooni saamiseks vaadake Kubernetes dokumentatsiooni.

Sildid igal pool

Sildid on üks Kubernetes'i põhikontsepte. Need võimaldavad objektidel vabalt omavahel suhelda ja luua päringuid siltide alusel. Kuberneteses saab isegi minna kliendi juurde ja jälgida sündmusi konkreetsete siltide põhjal.

Siltide abil on võimalik teha praktiliselt kõike, kuid hea näitena võiks tuua mitme keskkonna loomise programmide käitamiseks ühes klastris.

Oletame, et kasutate sama klastri dev ja qa. See tähendab, et teie käsutuses on rakendus app-a, mis töötab samal ajal kahes keskkonnas qa ja dev. Sel juhul saame eraldi pöörduda rakenduse eksemplari poole konkreetses keskkonnas, määrates sobiva parameetri environment. Näiteks, app: app-a ja environment: dev ühe keskkonna jaoks ja app: app-a ja environment: qa teise jaoks.

See võimaldab pöörduda mõlema rakenduse eksemplari poole, näiteks testimise läbiviimiseks samal ajal.

Tee järjestikuste toimingute korralduslikuks

Kubernetes on väga võimas süsteem, kuid iga süsteem võib lõpuks ummistuda paljude protsessidega. Kubelet käivitab kõik määratud protsessid ja kontrollid, samuti oma omad.

Loomulikult ei aeglusta ükski üksik teenus süsteemi ning Kubernetes on algselt loodud skaleerimiseks. Kuid kui ühe teenuse asemel on miljon, hakkab kubelet sinne upuma.

Kui mingil põhjusel kustutate juurutuse (konteineri, pildi, mis iganes), veenduge, et kõik oleks täielikult puhastatud.

Tutvuge Go'ga

Peamine nõuanne jätsime lõppu. Õppige programmeerimiskeelt Go.

Kubernetes on kirjutatud Go's, kõik laiendused on kirjutatud Go'd, ja ametlikult toetatakse klientteeki client-go.

Seda saab kasutada igasuguste huvitavate asjade tegemiseks. Näiteks saate Kubernetes'e süsteemi laiendamiseks enda maitse järgi. Nii saate kasutada enda programme andmete kogumiseks, rakenduste juurutamiseks või lihtsalt konteinerite puhastamiseks.

Go programmeerimiskeele õppimine ja client-go omandamine on tõenäoliselt kõige olulisem nõuanne, mida algetaotajatele Kubernetes'e kohta anda.

Tõlgitud Mail.ru Cloud Solutions'i toetusel

Mida veel lugeda:

1. Kuberneteses on kolm taset automaatset skaleerimist ja kuidas neid tõhusalt kasutada.
2. Kubernetes töötlusüksused: palju väikeseid või vähe suuri?
3. 25 kasulikku tööriista Kubernetes'e juurutamiseks ja haldamiseks.

Allikas: habr.com