Në internet ka shumë literaturë referuese, por ndonjëherë këshillat më të thjeshta bëhen më të vlefshëm. Ekipi përktheu , që autori i artikullit i ka mbledhur pas një viti pune me Kubernetes. Këshillat nuk janë renditur sipas rëndësisë, por mendoj se çdo njeri do të gjejë diçka të dobishme për veten e tij.
Komanda më e thjeshtë në punën me Kubernetes
Për fillim, ndoshta veprimi më i thjeshtë dhe më i dobishëm në punën me Kubernetes. Komanda e ardhshme aktivizon autocompletion për komandat kubectl në shell-in bash:
echo "source > ~/\.bashrc
Autocompletion kubectl do të regjistrohet në skedarin .bashrc dhe do të aktivizohet automatikisht çdo herë kur hapet shell-i. Kjo përshpejton shkruarjen e komandave dhe parametrave të gjata, si të all-namespaces. Më shumë në .
Kufizimet e paracaktuara për memorandum dhe CPU në hapësirën e emrit
Nëse aplikacioni është shkruar gabimisht, për shembull, hap një lidhje të re me bazën e të dhënave çdo sekondë, por kurrë nuk e mbyll, atëherë ndodh një rrjedhje memorje në klaster. Dhe nëse për aplikacionin, gjatë ndërlidhjes, nuk vendoset një kufizim për memorien, kjo mund të çojë në dështimin e nodit.
Për të parandaluar diçka të tillë, Kubernetes lejon vendosjen e kufizimeve të paracaktuara për çdo hapësirë emri. Ato regjistrohen në skedarin yaml për hapësirën e konkret. Ja një shembull i tillë:
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
Krijoni një të tillë yaml dhe aplikojeni për çdo hapësirë emri. Për shembull, për hapësirën e emrit limit-example. Tani, për çdo konteiner që është vendosur në këtë hapësirë emri, do të ketë një limit prej 512Mi, nëse për këtë konteiner nuk është vendosur ndonjë limit tjetër individual.
Pastrimi i mbeturinave në versionet e vjetra të Kubernetes
Kubelet, si parazgjedhje, fillon pastrimin e mbeturinave kur var/lib/docker zë 90 % të hapësirës së disponueshme të diskut. Kjo është e shkëlqyer, megjithatë, deri në versionin 1.7 të Kubernetes, nuk kishte kufizim të paracaktuar për numrin e indeksit të dhënave inode (inodes), të cilat përputhen me numrin e skedarëve në sistemin e skedareve.
Potencialisht, konteineri juaj var/lib/docker mund të përdorë vetëm 50 % të hapësirës së diskut, por në të njëjtën kohë inodes mund të përfundojnë, gjë që do të shkaktojë probleme në funksionimin e punonjësve.
Në versionet e vjetra të kubelet nga 1.4 deri në 1.6, do të duhet të shtoni këtë flag:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
Në 1.7 dhe versionet më të reja, ky flag është vendosur si parazgjedhje. Megjithatë, versionet e mëparshme nuk i përshtaten kufizimit të inode.
Minikube⊠i vogël, por i fuqishëm Kubernetes lokal
Minikube është mënyra më e thjeshtë për të nisur një klaster lokal Kubernetes. Ai fillon me një komandë të thjeshtë:
minikube start
Si rezultat i ekzekutimit të kësaj komande, në kompjuterin tuaj funksionon një klaster i vërtetë Kubernetes.
Truku është se si të ndërtoni një aplikacion dhe ta nisin atë lokal në këtë klaster. Nëse nuk jepni udhëzime speciale, imazhi Docker do të ndërtohet në kompjuterin tuaj dhe jo në klaster.
Për të detyruar Docker që të dërgojë imazhin në klasterin lokal Kubernetes, në makinat docker jepet komanda e mëposhtme:
eval $(minikube docker-env)
Tani mund të ndërtojmë aplikacionet në klasterin lokal Kubernetes.
Mos jepni akses kubectl për çdo njeri
Kjo duket e qartë, por nëse disa ekipe përdorin të njëjtin klaster për aplikacionet e tyre (për këtë është krijuar Kubernetes), nuk duhet thjesht të jepni akses çdo njeriu kubectl. Më mirë është të ndani ekipet, duke i dhënë secilës hapësirën e vet të emrit dhe duke ndarë aksesin me politikat RBAC.
Mund të shqetësoheni duke caktuar të drejtat e aksesit për çdo pod, për lexim, krijim, fshirje dhe operacione të tjera. Por e rëndësishme është të kufizoni aksesin në sekretet, duke e lejuar atë vetëm për administratorët. Kështu do të ndajmë ata që mund të administrojnë klasterin nga ata që mund të vendosen thjesht në të.
Menaxhoni buxhetet e podëve
Si të garantoni se nuk ka ndërprerje për aplikacionin në klasterin Kubernetes? PodDisruptionBudget dhe prapë PodDisruptionBudget.
Klasterët përditësohen herë pas here dhe nodet shkatërrohen. Asgjë nuk qëndron në vend, kjo është realiteti. Në çdo ndërlidhje me më shumë se një instancë duhet patjetër të përfshihet PDB (PodDisruptionBudget). Ai krijohet në një skedar të thjeshtë yaml, i cili aplikohet në klaster. Zona e mbulimit të një PDB të caktuar përcaktohet nga selektorët e etiketimeve.
Shënim: Buxheti PDB merret parasysh vetëm në ndërprerjet e zëvendësueshme (). Në situata si defekti i pajisjeve, PDB nuk do të funksionojë.
Shembulli i PDB:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
Dy parametrat kryesorë janë matchLabels dhe minAvailable. Parametri i parë përcakton se për cilat aplikacione do të zbatohet buxheti. Për shembull, nëse kam dislokime me etiketa app: app-a dhe app: app-b, atëherë ky PDB do të zbatohet vetëm për të parin.
Parametri minAvailable merr në konsideratë gjatë pastrimit të nodit. Për shembull, në shembullin tonë gjatë pastrimit, të gjitha instancat app: app-a, përveç dy, do të zhbllokohen.
Kjo lejon të kontrollohet se sa instanca të aplikacionit duhet të jenë aktive në çdo moment.
Monitorimi i shëndetit të aplikacionit
Ky monitorim mund të bëhet në dy mënyra: përmes testeve Readiness ose Liveness.
Testi i parë (readiness) përcakton gatishmërinë e konteinerit për të pranuar trafik.
Të dyti (liveness) tregon nëse konteineri është në rregull ose nëse duhet ta riçelni.
Konfigurimet përkatëse thjesht shtohen në yaml për dislokimin. Aty mund të specifikohen kohët e pritjes, vonesat dhe numri i provave të ripërsëritura. Më shumë detaje rreth tyre mund të gjeni në .
Etiketat kudo
Etiketat janë njohuri të domosdoshme në Kubernetes. Ato lejojnë objekteve të lidhen lirisht me njëra-tjetrën dhe gjithashtu të krijojnë kërkesa bazuar në etiketa. Në Kubernetes është e mundur madje të kalosh te klienti dhe të observosh ngjarjet sipas etiketa specifike.
Me anë të etiketave mund të bësh praktikisht gjithçka, por një shembull i mirë do të ishte krijimi i disa mjediseve për ekzekutimin e programeve në një klaster.
Le të themi se po përdorni të njëjtin klaster për dev dhe qa. Kjo do të thotë se mund të keni një aplikacion app-a, që funksionon njëkohësisht në të dy mjediset. qa dhe devNë këtë rast, mund të adresoheni veçmas te instanca e aplikacionit në një mjedis të caktuar duke specifikuar parameterin përkatës environment. Për shembull, app: app-a dhe environment: dev për një mjedis dhe app: app-a dhe environment: qa për të dytin.
Kjo lejon që të adresoheni të dy instancave të aplikacionit, për shembull, për të kryer teste njëkohësisht.
Ruani rendin
Kubernetes është një sistem shumë i fuqishëm, por çdo sistem në fund mund të ngecë në një numër të madh procesesh. Kubelet nis të gjitha proceset dhe kontrollimet që ju keni specifikuar, si dhe ato të tijat.
Sigurisht, një shërbim i braktisur nuk do ta ngadalësojë sistemin, dhe Kubernetes është fillimisht i projektuar për të shkallëzuar. Por nëse në vend të një shërbimi shfaqen një milion, kubelet fillon të mbytët.
Nëse për ndonjë arsye e hiqni dislokimin (konteiner, imazh, çfarëdo), sigurohuni që të pastroni plotësisht.
Njehuni me Go
Këshilla kryesore e kemi lënë për në fund. Mësoni gjuhën e programimit Go.
Kubernetes është zhvilluar në Go, të gjitha zgjerimet janë shkruar në Go, dhe gjithashtu mbështetet zyrtarisht biblioteka klienti client-go.
Ajo mund të përdoret për gjëra të ndryshme dhe interesante. Për shembull, për të zgjeruar sistemin Kubernetes sipas dëshirës tuaj. Kështu, mund të përdorni programet tuaja për mbledhjen e të dhënave, dislokimin e aplikacioneve ose thjesht pastrimin e konteinerëve.
Të mësosh gjuhën e programimit Go dhe të zotërosh client-go është ndoshta këshilla më e rëndësishme që mund t'i japësh përdoruesve të rinj të Kubernetes.
ĂfarĂ« tjetĂ«r tĂ« lexoni:
- .
- ?
- .
Burimi: habr.com
