Der is in soad referinsjeliteratuer op it ynternet, mar soms is it ienfâldichste advys it meast weardefol. Ploech oerset , dy't de skriuwer fan it artikel sammele nei in jier fan wurkjen mei Kubernetes. De tips binne net sortearre op belang, mar wy tinke dat elkenien sil fine wat nuttich foar himsels.
It ienfâldichste kommando om te wurkjen mei Kubernetes
Om te begjinnen, miskien de ienfâldichste en meast brûkbere aksje yn wurkjen mei Kubernetes. It folgjende kommando makket it foltôgjen fan kommando mooglik kubectl in bash shell:
echo "source <(kubectl completion bash)" >> ~/.bashrc
Autofolslein kubectl sil skreaun wurde nei it .bashrc-bestân en sil automatysk aktivearre wurde elke kear as de shell begon is. Dit fersnelt it typen fan lange kommando's en parameters lykas all-namespaces. Lês mear yn .
Standert ûnthâld en CPU grinzen yn in nammeromte
As de applikaasje bygelyks ferkeard skreaun is, iepenet it elke sekonde in nije ferbining mei de databank, mar slút it noait, dan hat it kluster in ûnthâldlek. En as de applikaasje hat gjin ûnthâld limyt ynsteld tidens ynset, dit kin liede ta in knooppunt flater.
Om dit foar te kommen, lit Kubernetes jo standert beheiningen ynstelle op in per-nammeromte basis. Se wurde skreaun yn it yaml-bestân foar in spesifike nammeromte. Hjir is in foarbyld fan sa'n triem:
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
Meitsje sa'n yaml en tapasse op elke nammeromte. Bygelyks nei de nammeromte limit-example. No sil elke kontener ynset yn dizze nammeromte in limyt hawwe fan 512Mi, útsein as in oare yndividuele limyt ek ynsteld is foar dizze kontener.
Garbage collection yn âldere ferzjes fan Kubernetes
Kubelet begjint standert garbage collection wannear var/lib/docker nimt 90% fan beskikbere skiifromte yn. Dit is lykwols geweldich, oant Kubernetes 1.7 wie der gjin standertlimyt op it oantal brûkte ynoden, dy't oerienkomme mei it oantal bestannen yn it bestânsysteem.
Potinsjeel jo kontener var/lib/docker meie allinnich brûke 50% fan de skiif romte, mar kin rinne út inodes, dat sil feroarsaakje problemen foar arbeiders.
Yn âldere ferzjes fan kubelet fan 1.4 oant 1.6 moatte jo dizze flagge tafoegje:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
Yn 1.7 en letter ferzjes is dizze flagge standert ynsteld. Foarige ferzjes kontrolearje de inode-limyt lykwols net.
Minikube ... lytse mar machtige lokale Kubernetes
Minikube is de maklikste manier om in lokale Kubernetes-kluster út te fieren. It wurdt lansearre mei in ienfâldich kommando:
minikube start
It útfieren fan dit kommando resulteart yn in echte Kubernetes-kluster dy't op jo masine rint.
De trúk is hoe't jo de applikaasje bouwe en it lokaal útfiere op dat kluster. Behalven as spesifyk ynstruearre, sil de Docker-ôfbylding wurde boud op jo kompjûter en net op it kluster.
Om Docker te twingen om de ôfbylding nei it lokale Kubernetes-kluster te triuwen, wurdt de docker-masine it folgjende kommando jûn:
eval $(minikube docker-env)
No kinne wy applikaasjes bouwe op in lokale Kubernetes-kluster.
Jou kubectl gjin tagong foar elkenien
Dit liket fanselssprekkend, mar as meardere teams itselde kluster brûke foar har applikaasjes (wêrfoar is Kubernetes makke), moatte jo net allinich elkenien jaan kubectl. It is better om de kommando's te skieden, elk fan har in eigen nammeromte te jaan en tagong te beheinen mei RBAC-belied.
Jo kinne betize wurde troch it tawizen fan rjochten foar tagong, lêzen, oanmeitsjen, wiskjen en oare operaasjes foar elke pod. Mar it wichtichste is om tagong ta geheimen te beheinen, wêrtroch it allinich foar behearders kin. Op dizze manier sille wy ûnderskied meitsje tusken dejingen dy't it kluster kinne beheare en dejingen dy't it gewoan kinne ynsette.
Behear Pod budzjetten
Hoe kinne jo gjin downtime soargje foar in applikaasje yn in Kubernetes-kluster? PodDisruptionBudget en nochris PodDisruptionBudget.
Klusters wurde periodyk bywurke en knooppunten wurde leech. Neat stiet stil, dat is de realiteit. Elke ynset mei mear dan ien eksimplaar moat in PDB (PodDisruptionBudget) befetsje. It is makke yn in ienfâldige yaml-bestân dat wurdt tapast op it kluster. It dekkingsgebiet fan in bepaalde PDB wurdt bepaald troch labelselektors.
Tink derom: De budzjet fan it POB wurdt allinich yn rekken brocht as de begrutting oertreding omkearber is (). Yn situaasjes lykas hardware mislearrings, PDB sil net wurkje.
Foarbyld PDB:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
De twa wichtichste parameters binne matchLabels и minAvailable. De earste parameter spesifiseart op hokker applikaasjes it budzjet jildt. Bygelyks, as ik ynset ha mei labels app: app-a и app: app-b, dan sil dit PDB allinich jilde foar de earste.
Parameter minAvailable rekken holden by it leegjen (skjinmeitsjen) fan de knoop. Bygelyks, yn ús foarbyld, by it leegjen, wurde alle gefallen útset app: app-a, útsein twa.
Hjirmei kinne jo kontrolearje hoefolle eksimplaren fan 'e applikaasje op elk momint rinne moatte.
Applikaasje sûnensmonitoring
Sokke tafersjoch is mooglik op twa manieren: mei help fan Readiness of Liveness tests.
De earste probe (reewilligens) bepaalt de reeheid fan 'e kontener om ferkear te ûntfangen.
De twadde (leftigens) lit sjen oft de kontener sûn is of opnij opstarte wurde moat.
De oanbelangjende konfiguraasjes wurde gewoan tafoege oan de yaml foar ynset. Dêr kinne jo time-outs, fertragingstiden en it oantal opnij besykjen opjaan. Sjoch mear details oer harren .
Tags binne oeral
Labels binne ien fan 'e fûnemintele begripen yn Kubernetes. Se tastean objekten frij mei elkoar te kommunisearjen, en ek fragen meitsje op basis fan labels. Yn Kubernetes kinne jo sels nei de klant gean en eveneminten besjen foar spesifike tags.
Jo kinne hast alles dwaan mei tags, mar in goed foarbyld soe meardere omjouwings meitsje om programma's op itselde kluster út te fieren.
Litte wy sizze dat jo itselde kluster brûke foar dev и qa. Dit betsjut dat jo in applikaasje hawwe kinne app-a, tagelyk wurkjen yn beide omjouwings qa и dev. Yn dit gefal kinne wy apart tagong krije ta de applikaasje-eksimplaar yn in spesifike omjouwing troch de passende parameter op te jaan environment. Bygelyks app: app-a и environment: dev foar ien omjouwing, en app: app-a и environment: qa foar de twadde.
Hjirmei kinne jo tagong krije ta beide eksimplaren fan 'e applikaasje, bygelyks om tagelyk testen út te fieren.
Organisearre wurde
Kubernetes is in heul krêftich systeem, mar elk systeem kin úteinlik bedarre wurde mei te folle prosessen. De Kubelet rint alle prosessen en kontrôles dy't jo oantsjutte, lykas har eigen.
Fansels sil ien weestsjinst it systeem net fertrage, en Kubernetes is ûntworpen om fan 'e grûn ôf te skaaljen. Mar as ynstee fan ien tsjinst in miljoen ferskynt, begjint de kubelet te choke.
As jo om ien of oare reden in ynset wiskje (container, ôfbylding, wat dan ek), soargje derfoar dat jo in folsleine skjinmeitsjen dwaan.
Moetsje Go
Wy hawwe it haadadvys foar it lêst bewarre. Learje de Go-programmearringstaal.
Kubernetes is ûntwikkele yn Go, alle útwreidingen binne skreaun yn Go, en de client-go client bibleteek wurdt ek offisjeel stipe.
It kin brûkt wurde foar ferskate en nijsgjirrige dingen. Bygelyks om it Kubernetes-systeem út te wreidzjen nei jo smaak. Dat, jo kinne jo eigen programma's brûke om gegevens te sammeljen, applikaasjes yn te setten, of gewoan konteners op te romjen.
It learen fan de Go-programmearringtaal en it behearjen fan client-go is miskien it wichtichste advys dat jo kinne jaan oan nije Kubernetes-brûkers.
Wat oars te lêzen:
- .
- ?
- .
Boarne: www.habr.com