Mayroong maraming sanggunian na literatura sa Internet, ngunit kung minsan ang pinakasimpleng payo ay ang pinakamahalaga. Koponan isinalin , na nakolekta ng may-akda ng artikulo pagkatapos ng isang taon ng pakikipagtulungan sa Kubernetes. Ang mga tip ay hindi pinagsunod-sunod ayon sa kahalagahan, ngunit sa tingin namin na ang lahat ay makakahanap ng isang bagay na kapaki-pakinabang para sa kanilang sarili.
Ang pinakasimpleng utos para magtrabaho kasama ang Kubernetes
Upang magsimula, marahil ang pinakasimple at pinakakapaki-pakinabang na aksyon sa pakikipagtulungan sa Kubernetes. Ang sumusunod na command ay nagbibigay-daan sa pagkumpleto ng command kubectl sa bash shell:
echo "source <(kubectl completion bash)" >> ~/.bashrc
Autofill kubectl ay isusulat sa .bashrc file at awtomatikong isaaktibo sa tuwing sinisimulan ang shell. Pinapabilis nito ang pag-type ng mahahabang command at parameter tulad ng all-namespaces. Higit pang mga detalye sa .
Default na memory at mga limitasyon ng CPU sa isang namespace
Kung ang application ay naisulat nang hindi tama, halimbawa, nagbubukas ito ng bagong koneksyon sa database bawat segundo ngunit hindi ito isinara, kung gayon ang cluster ay may memory leak. At kung ang application ay walang limitasyon sa memorya na itinakda sa panahon ng pag-deploy, maaari itong humantong sa pagkabigo ng node.
Upang maiwasan ito, pinapayagan ka ng Kubernetes na magtakda ng mga default na paghihigpit sa bawat namespace na batayan. Ang mga ito ay nakasulat sa yaml file para sa isang partikular na namespace. Narito ang isang halimbawa ng naturang file:
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
Lumikha ng gayong yaml at ilapat sa anumang namespace. Halimbawa, sa namespace limit-example. Ngayon, ang anumang container na naka-deploy sa namespace na ito ay magkakaroon ng limitasyon na 512Mi, maliban kung may karagdagang indibidwal na limitasyon para sa container na ito.
Pagkolekta ng basura sa mga mas lumang bersyon ng Kubernetes
Ang Kubelet bilang default ay magsisimula ng pangongolekta ng basura kapag var/lib/docker sumasakop sa 90% ng magagamit na espasyo sa disk. Ito ay mahusay, gayunpaman, hanggang sa Kubernetes 1.7 ay walang default na limitasyon sa bilang ng mga inode na ginamit, na tumutugma sa bilang ng mga file sa file system.
Posibleng ang iyong lalagyan var/lib/docker maaari lamang gumamit ng 50% ng espasyo sa disk, ngunit maaaring maubusan ng mga inode, na magdudulot ng mga problema para sa mga manggagawa.
Sa mga mas lumang bersyon ng kubelet mula 1.4 hanggang 1.6 kakailanganin mong idagdag ang flag na ito:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
Sa 1.7 at mas bagong mga bersyon ang flag na ito ay itinakda bilang default. Gayunpaman, hindi sinusubaybayan ng mga nakaraang bersyon ang limitasyon ng inode.
Minikube... maliliit ngunit makapangyarihang lokal na Kubernete
Ang Minikube ay ang pinakamadaling paraan upang magpatakbo ng lokal na cluster ng Kubernetes. Ito ay inilunsad gamit ang isang simpleng utos:
minikube start
Ang pagpapatakbo ng command na ito ay nagreresulta sa isang tunay na Kubernetes cluster na tumatakbo sa iyong makina.
Ang trick ay kung paano buuin ang application at patakbuhin ito nang lokal sa cluster na iyon. Maliban kung partikular na itinuro, ang imahe ng Docker ay bubuo sa iyong computer at hindi sa cluster.
Upang pilitin ang Docker na itulak ang imahe sa lokal na Kubernetes cluster, ang docker machine ay binibigyan ng sumusunod na command:
eval $(minikube docker-env)
Ngayon ay maaari na tayong bumuo ng mga application sa isang lokal na Kubernetes cluster.
Huwag bigyan ang kubectl ng access sa lahat
Mukhang halata ito, ngunit kung maraming mga koponan ang gumagamit ng parehong kumpol para sa kanilang mga aplikasyon (na kung saan nilikha ang Kubernetes), hindi mo dapat ibigay ang lahat kubectl. Mas mainam na paghiwalayin ang mga utos, italaga ang bawat isa sa kanila ng sarili nitong namespace at nililimitahan ang pag-access gamit ang mga patakaran ng RBAC.
Maaari kang malito sa pamamagitan ng pagtatalaga ng mga karapatang mag-access, magbasa, gumawa, magtanggal at iba pang mga operasyon para sa bawat pod. Ngunit ang pangunahing bagay ay upang limitahan ang pag-access sa mga lihim, na pinapayagan lamang ito sa mga administrator. Sa ganitong paraan, makikilala natin ang mga taong maaaring mangasiwa sa cluster at ang mga maaaring mag-deploy dito.
Pamahalaan ang Mga Badyet ng Pod
Paano masisigurong walang downtime para sa isang application sa isang Kubernetes cluster? PodDisruptionBudget at muli PodDisruptionBudget.
Ang mga cluster ay pana-panahong ina-update at ang mga node ay walang laman. Walang tumatayo, iyon ang katotohanan. Ang bawat deployment na may higit sa isang instance ay dapat may kasamang PDB (PodDisruptionBudget). Ito ay nilikha sa isang simpleng yaml file na inilapat sa cluster. Ang saklaw na lugar ng isang partikular na PDB ay tinutukoy ng mga tagapili ng label.
Tandaan: Ang badyet ng PDB ay isinasaalang-alang lamang kapag ang paglabag sa badyet ay nababaligtad (). Sa mga sitwasyon tulad ng mga pagkabigo sa hardware, hindi gagana ang PDB.
Halimbawa ng PDB:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
Ang dalawang pangunahing mga parameter ay matchLabels ΠΈ minAvailable. Tinutukoy ng unang parameter kung sa aling mga application nalalapat ang badyet. Halimbawa, kung mayroon akong mga deployment na may mga label app: app-a ΠΈ app: app-b, pagkatapos ang PDB na ito ay malalapat lamang sa una.
Parametro minAvailable isinasaalang-alang kapag tinatanggalan ng laman (paglilinis) ang node. Halimbawa, sa aming halimbawa, sa panahon ng pag-alis ng laman, lahat ng pagkakataon ay pinaalis app: app-a, maliban sa dalawa.
Binibigyang-daan ka nitong kontrolin kung gaano karaming mga pagkakataon ng application ang dapat tumakbo sa anumang oras.
Pagsubaybay sa kalusugan ng aplikasyon
Ang ganitong pagsubaybay ay posible sa dalawang paraan: gamit ang Readiness o Liveness tests.
Tinutukoy ng unang probe (kahandaan) ang kahandaan ng lalagyan na tumanggap ng trapiko.
Ang pangalawa (liveness) ay nagpapakita kung ang lalagyan ay malusog o kailangang i-restart.
Ang mga nauugnay na configuration ay idinaragdag lamang sa yaml para sa pag-deploy. Doon maaari mong tukuyin ang mga timeout, mga oras ng pagkaantala at ang bilang ng mga muling pagsubok. Tingnan ang higit pang mga detalye tungkol sa kanila .
Ang mga tag ay nasa lahat ng dako
Ang mga label ay isa sa mga pangunahing konsepto sa Kubernetes. Pinapayagan nila ang mga bagay na malayang makipag-usap sa isa't isa, gayundin ang paglikha ng mga query batay sa mga label. Sa Kubernetes, maaari ka ring pumunta sa kliyente at manood ng mga kaganapan para sa mga partikular na tag.
Magagawa mo ang halos anumang bagay gamit ang mga tag, ngunit ang isang magandang halimbawa ay ang paglikha ng maraming kapaligiran upang magpatakbo ng mga programa sa parehong kumpol.
Sabihin nating ginagamit mo ang parehong cluster para sa dev ΠΈ qa. Nangangahulugan ito na maaari kang magkaroon ng aplikasyon app-a, sabay na gumagana sa parehong mga kapaligiran qa ΠΈ dev. Sa kasong ito, maaari naming hiwalay na ma-access ang instance ng application sa isang partikular na kapaligiran sa pamamagitan ng pagtukoy ng naaangkop na parameter environment. Halimbawa app: app-a ΠΈ environment: dev para sa isang kapaligiran, at app: app-a ΠΈ environment: qa para sa pangalawa.
Binibigyang-daan ka nitong ma-access ang parehong mga pagkakataon ng application, halimbawa, upang magsagawa ng pagsubok nang sabay-sabay.
Ayusin ang mga bagay
Ang Kubernetes ay isang napakalakas na sistema, ngunit ang anumang sistema ay maaaring tuluyang mabalaho sa napakaraming proseso. Pinapatakbo ng Kubelet ang lahat ng proseso at mga pagsusuri na iyong tinukoy, pati na rin ang sarili nito.
Siyempre, hindi magpapabagal sa system ang isang orphaned na serbisyo, at ang Kubernetes ay idinisenyo upang masukat mula sa simula. Ngunit kung sa halip na isang serbisyo ay lumitaw ang isang milyon, ang kubelet ay nagsisimulang mabulunan.
Kung sa ilang kadahilanan ay nagde-delete ka ng deployment (lalagyan, larawan, anuman), siguraduhin lang na gumawa ng kumpletong paglilinis.
Kilalanin si Go
Nai-save namin ang pangunahing payo para sa huling. Alamin ang Go programming language.
Ang Kubernetes ay binuo sa Go, ang lahat ng extension ay nakasulat sa Go, at ang client-go client library ay opisyal ding sinusuportahan.
Maaari itong magamit para sa iba't ibang at kawili-wiling mga bagay. Halimbawa, upang palawakin ang sistema ng Kubernetes sa iyong panlasa. Kaya, maaari mong gamitin ang sarili mong mga program para mangolekta ng data, mag-deploy ng mga application, o maglinis lang ng mga container.
Ang pag-aaral ng Go programming language at pag-master ng client-go ay marahil ang pinakamahalagang payo na maibibigay mo sa mga bagong user ng Kubernetes.
Kung anu-ano pang babasahin:
- .
- ?
- .
Pinagmulan: www.habr.com