Në internet ka shumë literaturë referuese, por ndonjëherë këshillat më të vlefshme janë ato më të thjeshta. Ekipi përktheu , të cilat autori i artikullit i grumbulloi pas një viti pune me Kubernetes. Këshillat nuk janë renditur sipas rëndësisë, por mendojmë se çdo kush do të gjejë diçka të dobishme për vete.
Komanda më e thjeshtë në punën me Kubernetes
Për të filluar, ndoshta veprimi më i thjeshtë dhe më i dobishëm në punën me Kubernetes. Komanda në vijim aktivizon autoshkallëzimin e komandave kubectl në shell-in bash:
echo "source > ~/ .bashrc
Autoshkallëzimi kubectl do të regjistrohet në skedarin .bashrc dhe do të aktivizohet automatikisht çdo herë që hapet shell-i. Kjo përshpejton hyrjen e komandave dhe parametrave të gjatë, siç është all-namespaces. Më shumë në .
Kufizimet e paracaktuara për RAM dhe CPU në hapësirën emërore
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ë, atëherë ndodh një rrjedhje kujtese në klaster. Dhe nëse nuk është vendosur një kufi për kujtesën për aplikacionin gjatë deploy-it, kjo mund të çojë në dështimin e nodës.
Për të parandaluar një gjë të tillë, Kubernetes lejon vendosjen e kufizimeve të paracaktuara për çdo hapësirë emërore. Këto shkruhen në skedarin yaml për hapësirën emërore specifike. Këtu është një shembull i një skedari të 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 aplikoni në çdo hapësirë emërore. Për shembull, në hapësirën emërore limit-example. Tani, për çdo konteiner që do të shpërndahet në këtë hapësirë emërore, do të zbatohet kufiri 512Mi, nëse për këtë konteiner nuk është vendosur një kufi tjetër individual.
Pastrimi i mbeturinave në versionet e vjetra të Kubernetes
Kubelet përitë fillon pastrimin e mbeturinave kur var/lib/docker zë 90% të hapësirës diskore të disponueshme. Kjo është e shkëlqyer, megjithatë, deri në versionin 1.7 të Kubernetes nuk kishte kufi të paracaktuar për numrin e descriptorëve të indekseve inode të përdorur (inodet), të cilat korrespondonin me numrin e skedareve në sistemin e skedarëve.
Potencialisht konteneri juaj var/lib/docker mund të përdorë vetëm 50% të hapësirës diskore, por në të njëjtën kohë inodet mund të përfundojnë, çka do të shkaktonte probleme në funksionimin e punëtorëve.
Në versionet e vjetra të kubelet midis 1.4 dhe 1.6 do të duhet të shtoni një flamur të tillë:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
Në versionet 1.7 dhe më të reja, ky flamur është i vendosur si stopim të paracaktuar. Megjithatë, versionet e mëparshme nuk monitorojnë kufirin e inodëve.
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 niset me një komandë të thjeshtë:
minikube start
Si rezultat i ekzekutimit të kësaj komande, ju keni një klaster të vërtetë Kubernetes në kompjuterin tuaj.
Truku është se si të ndërtoni një aplikacion dhe ta nisni atë lokal në këtë klaster. Nëse nuk jepen udhëzime të veçanta, imazhi Docker do të ndërtohet në kompjuterin tuaj dhe jo në klaster.
Për të bërë që Docker të dërgojë imazhin në klasterin lokal Kubernetes, i jepet komandës docker-machine:
eval $(minikube docker-env)
Tani mund të ndërtojmë aplikacione në klasterin lokal Kubernetes.
Mos e ndani aksesin kubectl me çdo kush
Kjo duket e qartë, por nëse disa ekipe përdorin një klaster për aplikacionet e tyre (për atë që u krijua Kubernetes), nuk është e mençur ta jepni aksesin pa zgjidhje. kubectlMë mirë është të ndahen ekipet, duke i dhënë secilës hapësirën e saj emri dhe duke kufizuar aksesin me politika RBAC.
Mund të merret me të, duke specifikuar për çdo pod të drejtat e aksesit, leximit, krijimit, fshirjes dhe operacioneve të tjera. Por më e rëndësishmja është të kufizoni aksesin në sekretet, duke e lejuar atë vetëm administratoreve. Kështu ne do të ndajmë ata që mund të administrojnë klasterin dhe ata që mund të vendosen aty.
Menaxhoni buxhetet e podëve
Si të garanteoni mungesën e ndërprerjeve për aplikacionin në klasterin Kubernetes? PodDisruptionBudget dhe përsëri PodDisruptionBudget.
Klasteret pĂ«rditĂ«sohen herĂ« pas here, dhe nyjat zbrazin. AsgjĂ« nuk qĂ«ndron nĂ« vend, kĂ«shtu qĂ« Ă«shtĂ« realiteti. Ădo dispersim me mĂ« shumĂ« se njĂ« instancĂ« duhet tĂ« pĂ«rfshijĂ« patjetĂ«r PDB (PodDisruptionBudget). Ai krijohet nĂ« njĂ« skedĂ« tĂ« thjeshtĂ« yaml, e cila aplikohet nĂ« klaster. Rrethi i mbulimit tĂ« PDB tĂ« caktuar pĂ«rcaktohet nga selektorĂ«t e etiketave.
Vërejtje: Buxheti PDB merr parasysh vetëm në rastin e një shkeljeje të rikthyeshme të buxhetit (). Në situata si problemet harduerike, 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. Në parametrin e parë tregohet për cilat aplikacione zbatohet buxheti. Për shembull, nëse kam disa shpërndarje me etiketat app: app-a dhe app: app-b, atëherë ky PDB do të zbatohet vetëm për të parin.
Parametri minAvailable merr parasysh gjatë pastrimit të nyjës. Për shembull, në shembullin tonë gjatë pastrimit eliminohen të gjitha instancat app: app-a, përveç dy.
Kjo lejon kontrollin e numrit të instancave të aplikacionit që duhet të jenë aktive në çdo moment.
Monitorimi i shëndetësisë së aplikacionit
Ky monitorim është i mundur në dy mënyra: përmes probe-ve Readiness ose Liveness.
Prova e parë (readiness) përcakton gatishmërinë e kontejnerit për të pranuar trafik.
E dyta (liveness) tregon nëse kontejneri është në gjendje funksionimi apo duhet të riniset.
Konfigurimet përkatëse thjesht shtohen në yaml për shpërndarje. Aty mund të specifikoni kohët e skadencës, vonesat dhe numrin e provave. Më shumë detaje për to mund të gjeni në .
Etiketat kudo
Etiketat janë një nga konceptet themelore në Kubernetes. Ato lejojnë objektet të lidhen lirisht me njëra-tjetrën dhe gjithashtu të krijojnë kërkesa në bazë të etiketeve. Në Kubernetes, madje mund të kaloni te klienti dhe të shihni ngjarjet sipas etiketeve të caktuara.
Me etiketat mund të bëni gati gjithçka, por një shembull i mirë do të ishte krijimi i disa ambienteve për të ekzekutuar programe në një klaster të vetëm.
Supozoni 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, duke funksionuar në të dyja mjediset qa dhe dev. Në këtë rast, mund të drejtohemi veçmas për instancën e aplikacionit në mjedisin përkatës duke specifikuar parametrin përkatës mjedis. Për shembull, app: app-a dhe environment: dev për një ambient, dhe app: app-a dhe environment: qa për ambientin e dytë.
Kjo lejon qasjen në të dyja instancat e aplikacionit, për shembull, për të kryer testime njëkohësisht.
Rregulloni gjërat
Kubernetes është një sistem shumë i fuqishëm, por çdo sistem në fund të fundit është në gjendje të ngecë në një numër të madh procesesh. Kubelet nxit të gjithë proceset dhe kontrollet e specifikuara nga ju, si dhe të tijat.
Sigurisht, një shërbim në lënie të lirë nuk e ngadalëson sistemin, dhe Kubernetes është fillimisht i ndërtuar për të shkallëzuar. Por nëse në vend të një shërbimi shfaqen një milion, kubelet fillon të ngjitet.
Nëse për një arsye e hiqni zhvendosjen (kontejner, imazh, çfarëdo), thjesht sigurohuni që të jetë bërë pastrimi i plotë.
Njoftohuni me Go
Këshillën më të rëndësishme 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 për më tepër, biblioteka zyrtare e klientit client-go mbështetet.
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 suaj. Kështu, mund të përdorni programe të veta për mbledhjen e të dhënave, zhvendosjen e aplikacioneve ose thjesht pastrimin e kontejnerëve.
Të mësosh gjuhën e programimit Go dhe të zotërosh client-go mund të jetë këshilla më e rëndësishme që mund t'u jepet përdoruesve fillestarë të Kubernetes.
ĂfarĂ« tjetĂ«r tĂ« lexoni:
- .
- ?
- .
Burimi: habr.com
