Der er mange referencebøger på internettet, men nogle gange er de mest enkle råd de mest værdifulde. Teamet har oversat , som forfatteren til artiklen har samlet efter et års arbejde med Kubernetes. Rådene er ikke sorteret efter vigtighed, men vi tror, at hver enkelt vil finde noget nyttigt for sig selv.
Den enkleste kommando til at arbejde med Kubernetes
For at starte med, er måske den enkleste og mest nyttige handling i arbejdet med Kubernetes. Den følgende kommando aktiverer autoudfyldning af kommandoer kubectl i bash-skallen:
echo "source > ~/ .bashrc
Autoudfyldning kubectl vil blive skrevet til .bashrc-filen og aktiveres automatisk hver gang skallen startes. Dette fremskynder indtastningen af lange kommandoer og parametre, såsom all-namespaces. Læs mere i .
Standardbegrænsninger for hukommelse og CPU i navnerum
Hvis en applikation er skrevet forkert, for eksempel åbner en ny forbindelse til databasen hvert sekund, men aldrig lukker den, så opstår der et hukommelseslækage i klyngen. Og hvis der ikke er sat en hukommelsesgrænse ved udsendelsen af applikationen, kan det føre til, at noden fejler.
For at forhindre dette tillader Kubernetes at sætte standardbegrænsninger for hvert navnerum. De skrives i yaml-filen for det specifikke navnerum. Her er et eksempel på en sådan fil:
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
Opret en sådan yaml og anvend den på et hvilket som helst navnerum. For eksempel på navnerummet limit-example. Nu vil en grænse på 512Mi gælde for enhver container, der udrulles i dette navnerum, medmindre der er sat en anden individuel grænse for den aktuelle container.
Rydning af affald i gamle versioner af Kubernetes
Kubelet starter som standard rydning af affald, når var/lib/docker optager 90 % af det tilgængelige diskplads. Dette er fint, men indtil version 1.7 af Kubernetes var der ingen standardgrænse for antallet af anvendte inode-indekser, der svarer til antallet af filer i filsystemet.
Potentialt kan din container var/lib/docker kun bruge 50 % af diskpladsen, men indoderne kan løbe tør, hvilket vil forårsage problemer for arbejderne.
I gamle versioner af kubelet fra 1.4 til 1.6 skal du tilføje en sådan flag:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
I version 1.7 og nyere er denne flag sat som standard. Men tidligere versioner overvåger ikke inode-grænsen.
Minikube… lille, men kraftfuld lokal Kubernetes
Minikube er den nemmeste måde at starte et lokalt Kubernetes-cluster på. Det startes med en enkel kommando:
minikube start
Som resultat af denne kommando kører der et rigtigt Kubernetes-cluster på din computer.
Tricket er at samle applikationen og køre den lokalt i dette cluster. Uden specifikke instrukser vil Docker-billedet blive bygget på din computer og ikke i clustret.
For at få Docker til at sende billedet til det lokale Kubernetes-cluster, gives denne kommando til docker-maskinen:
eval $(minikube docker-env)
Nu kan vi bygge applikationer på det lokale Kubernetes-cluster.
Giv ikke kubectl-adgang til alle
Det virker indlysende, men hvis flere teams bruger ét cluster til deres applikationer (hvilket Kubernetes er designet til), bør du ikke bare give adgang til alle. kubectlDet er bedre at opdele teams, ved at give hver deres eget namespace og begrænse adgangen med RBAC-politikker.
Man kan gøre en indsats for at definere adgangen, læsning, oprettelse, sletning og andre operationer for hver pod. Men det vigtigste er at begrænse adgangen til hemmeligheder, så kun administratorer har adgang. Sådadan skelner vi mellem dem, der kan administrere clustret, og dem, der blot kan anvende det.
Styr pod-budgets
Hvordan sikrer man, at der ikke opstår nedetid for applikationen i Kubernetes-clusteret? PodDisruptionBudget og endnu engang PodDisruptionBudget.
Clustrene opdateres periodisk, og noderne tømmes. Intet står stille, sådan er virkeligheden. Hver deployment med mere end én instans skal nødvendigvis inkludere PDB (PodDisruptionBudget). Den oprettes i en simpel yaml-fil, der anvendes til clustret. Dækningen for den specifikke PDB defineres af labels-selektorer.
Bemærk: PDB-budgettet tages kun i betragtning ved frivillig forstyrrelse (). I situationer som hardwarefejl vil PDB ikke fungere.
Eksempel PDB:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
De to primære parametre er matchLabels og minAvailableI den første parameter angiver du, hvilke applikationer budgettet gælder for. For eksempel, hvis jeg har implementeringer med mærker app: app-a og app: app-b, så vil dette PDB kun blive anvendt på den første.
Parameter minAvailable tages i betragtning ved rydning af noden. For eksempel, i vores eksempel under rydning bliver alle instanser app: app-a, undtagen to.
Dette giver mulighed for at kontrollere, hvor mange eksemplarer af applikationen der skal være kørende på et givent tidspunkt.
Overvågning af applikationens tilstand
Sådan overvågning er mulig på to måder: ved hjælp af Readiness eller Liveness checks.
Den første check (readiness) bestemmer, om containeren er klar til at modtage trafik.
Den anden (liveness) viser, om containeren fungerer korrekt, eller om den skal genstartes.
De relevante konfigurationer tilføjes blot i yaml-filen til implementeringen. Her kan du angive timeouts, forsinkelsestider og antallet af gentagelseschecks. Læs mere om dem i .
Labels overalt
Labels er et af de grundlæggende begreber i Kubernetes. De muliggør, at objekter kan knyttes frit sammen samt skabe forespørgsler baseret på labels. I Kubernetes kan man endda gå til klienten og overvåge begivenheder ved specifikke labels.
Gennem labels kan man gøre næsten alt, men et godt eksempel ville være at oprette flere miljøer til at køre programmer i et enkelt cluster.
Lad os sige, at du bruger det samme cluster til dev og qa. Det betyder, at du kan have en applikation app-a, der kører samtidigt i begge miljøer. qa og dev. I dette tilfælde kan vi henvise til et specifikt eksemplar af applikationen i det givne miljø ved at angive den relevante parameter environment. For eksempel, app: app-a og environment: dev for det ene miljø, og app: app-a og environment: qa for det andet.
Dette giver mulighed for at tilgå begge eksemplarer af applikationen, for eksempel til at udføre test samtidigt.
Få styr på det
Kubernetes er et meget kraftfuldt system, men ethvert system kan til slut blive overvældet af et stort antal processer. Kubelet kører alle de processer og checks, du har angivet, samt sine egne.
Selvfølgelig vil en overset service ikke bremse systemet, og Kubernetes er oprindeligt designet til skalering. Men hvis der i stedet for én service kommer en million, begynder kubelet at blive overbelastet.
Hvis du af en eller anden grund sletter en deployment (container, image, hvad som helst), så sørg for at få det helt renset.
Mød Go
Vi gemte det bedste råd til sidst. Lær programmeringssproget Go.
Kubernetes er bygget med Go, alle udvidelser er skrevet i Go, og der er desuden officielt understøttede client-go biblioteker.
Det kan bruges til mange forskellige og interessante ting. For eksempel til at tilpasse Kubernetes-systemet som du ønsker. Så du kan bruge dine egne programmer til dataindsamling, deployment af applikationer eller simpelthen til at rydde op i containere.
At lære programmeringssproget Go og mestre client-go er måske det vigtigste råd, man kan give til nye brugere af Kubernetes.
Hvad mere kan man læse:
- .
- ?
- .
Kilde: habr.com
