Daar is baie verwysingsliteratuur op die internet, maar soms is die eenvoudigste raad die waardevolste. Span vertaal , wat die skrywer van die artikel versamel het na 'n jaar van werk met Kubernetes. Die wenke word nie volgens belangrikheid gesorteer nie, maar ons dink dat almal iets nuttigs vir hulself sal vind.
Die eenvoudigste opdrag om met Kubernetes te werk
Om mee te begin, miskien die eenvoudigste en nuttigste aksie om met Kubernetes te werk. Die volgende opdrag maak opdragvoltooiing moontlik kubectl in bash dop:
echo "source <(kubectl completion bash)" >> ~/.bashrc
Outovoltooi kubectl sal na die .bashrc-lêer geskryf word en sal outomaties geaktiveer word elke keer as die dop begin word. Dit versnel die tik van lang opdragte en parameters soos all-namespaces. Lees meer in .
Verstek geheue en SVE limiete in 'n naamruimte
As die toepassing byvoorbeeld verkeerd geskryf is, maak dit elke sekonde 'n nuwe verbinding met die databasis oop, maar maak dit nooit toe nie, dan het die cluster 'n geheuelek. En as die toepassing nie 'n geheuelimiet het wat tydens ontplooiing gestel is nie, kan dit lei tot 'n knooppuntfout.
Om dit te voorkom, laat Kubernetes jou toe om verstekbeperkings op 'n per-naamruimte-basis in te stel. Hulle word in die yaml-lêer geskryf vir 'n spesifieke naamruimte. Hier is 'n voorbeeld van so 'n lêer:
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
Skep so 'n yaml en pas dit toe op enige naamruimte. Byvoorbeeld, na die naamruimte limit-example. Nou sal enige houer wat in hierdie naamruimte ontplooi word 'n limiet van 512Mi hê, tensy 'n ander individuele limiet addisioneel vir hierdie houer gestel word.
Vullisversameling in ouer weergawes van Kubernetes
Kubelet begin by verstek vullisversameling wanneer var/lib/docker beslaan 90% van beskikbare skyfspasie. Dit is egter wonderlik, tot Kubernetes 1.7 was daar geen versteklimiet op die aantal inodes wat gebruik word nie, wat ooreenstem met die aantal lêers in die lêerstelsel.
Moontlik jou houer var/lib/docker mag slegs 50% van die skyfspasie gebruik, maar kan uit inodes opraak, wat probleme vir werkers sal veroorsaak.
In ouer weergawes van kubelet van 1.4 tot 1.6 sal jy hierdie vlag moet byvoeg:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
In 1.7 en later weergawes is hierdie vlag by verstek gestel. Vorige weergawes monitor egter nie die inodelimiet nie.
Minikube... klein maar kragtige plaaslike Kubernetes
Minikube is die maklikste manier om 'n plaaslike Kubernetes-kluster te bestuur. Dit word geloods met 'n eenvoudige opdrag:
minikube start
As u hierdie opdrag uitvoer, word 'n regte Kubernetes-kluster op u masjien uitgevoer.
Die truuk is hoe om die toepassing te bou en dit plaaslik op daardie groepie uit te voer. Tensy spesifiek opdrag gegee word, sal die Docker-prent op u rekenaar gebou word en nie op die groep nie.
Om Docker te dwing om die prent na die plaaslike Kubernetes-kluster te stoot, kry die docker-masjien die volgende opdrag:
eval $(minikube docker-env)
Nou kan ons toepassings op 'n plaaslike Kubernetes-kluster bou.
Moenie kubectl toegang aan almal gee nie
Dit lyk voor die hand liggend, maar as verskeie spanne dieselfde groep vir hul toepassings gebruik (dit is waarvoor Kubernetes geskep is), moet jy nie net vir almal gee nie kubectl. Dit is beter om die opdragte te skei, elkeen van hulle sy eie naamruimte toe te ken en toegang te beperk deur RBAC-beleide te gebruik.
Jy kan verward raak deur regte toe te ken vir toegang, lees, skep, uitvee en ander bewerkings vir elke pod. Maar die belangrikste ding is om toegang tot geheime te beperk, sodat dit slegs aan administrateurs toegelaat word. Op hierdie manier sal ons onderskei tussen diegene wat die groepering kan administreer en diegene wat eenvoudig daarheen kan ontplooi.
Bestuur Pod-begrotings
Hoe om te verseker dat geen stilstandtyd vir 'n toepassing in 'n Kubernetes-kluster is nie? PodDisruptionBudget en weer PodDisruptionBudget.
Klusters word periodiek opgedateer en nodusse word leeggemaak. Niks staan stil nie, dit is die werklikheid. Elke ontplooiing met meer as een geval moet 'n PDB (PodDisruptionBudget) insluit. Dit word geskep in 'n eenvoudige yaml-lêer wat op die groep toegepas word. Die dekkingsgebied van 'n spesifieke VOB word deur etiketkiesers bepaal.
Let wel: Die VOB-begroting word slegs in ag geneem wanneer die begrotingsoortreding omkeerbaar is (). In situasies soos hardeware mislukkings, sal PDB nie werk nie.
Voorbeeld PDB:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
Die twee hoofparameters is matchLabels и minAvailable. Die eerste parameter spesifiseer op watter toepassings die begroting van toepassing is. Byvoorbeeld, as ek ontplooiings met etikette het app: app-a и app: app-b, dan sal hierdie VOB slegs op die eerste een van toepassing wees.
Parameter minAvailable in ag geneem word wanneer die nodus leeggemaak (skoonmaak). Byvoorbeeld, in ons voorbeeld, tydens leegmaak, word alle gevalle uitgesit app: app-a, behalwe twee.
Dit laat jou toe om te beheer hoeveel gevalle van die toepassing op enige gegewe tydstip moet loop.
Toepassingsgesondheidsmonitering
Sulke monitering is op twee maniere moontlik: deur gebruik te maak van gereedheids- of lewendigheidstoetse.
Die eerste sonde (gereedheid) bepaal die houer se gereedheid om verkeer te ontvang.
Die tweede (lewendigheid) wys of die houer gesond is of herbegin moet word.
Die relevante konfigurasies word eenvoudig by die yaml gevoeg vir ontplooiing. Daar kan jy time-outs, vertragingstye en die aantal herproewe spesifiseer. Sien meer besonderhede oor hulle .
Merkers is oral
Etikette is een van die fundamentele konsepte in Kubernetes. Hulle laat voorwerpe toe om vryelik met mekaar te kommunikeer, asook skep navrae gebaseer op etikette. In Kubernetes kan jy selfs na die kliënt gaan en gebeure vir spesifieke etikette kyk.
Jy kan byna enigiets met etikette doen, maar 'n goeie voorbeeld sou wees om verskeie omgewings te skep om programme op dieselfde groep te laat loop.
Kom ons sê jy gebruik dieselfde cluster vir dev и qa. Dit beteken dat jy 'n aansoek kan hê app-a, werk gelyktydig in beide omgewings qa и dev. In hierdie geval kan ons afsonderlik toegang tot die toepassingsinstansie in 'n spesifieke omgewing verkry deur die toepaslike parameter te spesifiseer environment. Byvoorbeeld, app: app-a и environment: dev vir een omgewing, en app: app-a и environment: qa vir die tweede een.
Dit laat jou toe om toegang te verkry tot beide gevalle van die toepassing, byvoorbeeld om toetse gelyktydig uit te voer.
Word georganiseer
Kubernetes is 'n baie kragtige stelsel, maar enige stelsel kan uiteindelik vasgeval word met te veel prosesse. Die Kubelet loop al die prosesse en kontroles wat jy spesifiseer, sowel as sy eie.
Natuurlik sal een weesdiens nie die stelsel vertraag nie, en Kubernetes is ontwerp om van die grond af te skaal. Maar as in plaas van een diens 'n miljoen verskyn, begin die kubelet verstik.
As jy om een of ander rede 'n ontplooiing uitvee (houer, prent, wat ook al), maak net seker dat jy 'n volledige skoonmaak doen.
Ontmoet Go
Ons het die hoofraad vir laaste gebêre. Leer die Go-programmeertaal.
Kubernetes is in Go ontwikkel, alle uitbreidings is in Go geskryf, en die kliënt-go-kliëntbiblioteek word ook amptelik ondersteun.
Dit kan vir verskillende en interessante dinge gebruik word. Byvoorbeeld, om die Kubernetes-stelsel na jou smaak uit te brei. So, jy kan jou eie programme gebruik om data in te samel, toepassings te ontplooi, of bloot houers skoon te maak.
Om die Go-programmeertaal te leer en kliënt-go te bemeester, is miskien die belangrikste raad wat jy aan nuwe Kubernetes-gebruikers kan gee.
Wat anders om te lees:
- .
- ?
- .
Bron: will.com