Det finnes mye referanselitteratur på Internett, men noen ganger er de enkleste rådene de mest verdifulle. Team oversatt , som forfatteren av artikkelen samlet etter et års arbeid med Kubernetes. Tipsene er ikke sortert etter viktighet, men vi tror at alle vil finne noe nyttig for seg selv.
Den enkleste kommandoen for å jobbe med Kubernetes
Til å begynne med, kanskje den enkleste og mest nyttige handlingen i arbeidet med Kubernetes. Følgende kommando aktiverer kommandofullføring kubectl i bash-skall:
echo "source <(kubectl completion bash)" >> ~/.bashrc
Autofullfør kubectl vil bli skrevet til .bashrc-filen og aktiveres automatisk hver gang skallet startes. Dette gir raskere skriving av lange kommandoer og parametere som f.eks all-namespaces. Flere detaljer i .
Standard minne- og CPU-grenser i et navneområde
Hvis applikasjonen er skrevet feil, for eksempel, åpner den en ny tilkobling til databasen hvert sekund, men lukker den aldri, da har klyngen en minnelekkasje. Og hvis applikasjonen ikke har en minnegrense satt under distribusjon, kan dette føre til en nodefeil.
For å forhindre dette lar Kubernetes deg angi standardbegrensninger per navneområde. De er skrevet i yaml-filen for et spesifikt navneområde. Her er et eksempel på en slik fil:
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
Lag en slik yaml og bruk på et hvilket som helst navneområde. For eksempel til navneområdet limit-example. Nå vil enhver beholder som er distribuert i dette navneområdet ha en grense på 512Mi, med mindre en annen individuell grense er satt i tillegg for denne beholderen.
Søppelinnsamling i eldre versjoner av Kubernetes
Kubelet starter som standard søppelinnsamling når var/lib/docker opptar 90 % av tilgjengelig diskplass. Dette er imidlertid flott, inntil Kubernetes 1.7 var det ingen standardgrense på antall inoder som ble brukt, som tilsvarer antall filer i filsystemet.
Potensielt din container var/lib/docker bruker kanskje bare 50 % av diskplassen, men kan gå tom for inoder, noe som vil forårsake problemer for arbeiderne.
I eldre versjoner av kubelet fra 1.4 til 1.6 må du legge til dette flagget:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
I 1.7 og nyere versjoner er dette flagget satt som standard. Tidligere versjoner overvåker imidlertid ikke inodegrensen.
Minikube... små, men kraftige lokale Kubernetes
Minikube er den enkleste måten å drive en lokal Kubernetes-klynge på. Den startes med en enkel kommando:
minikube start
Å kjøre denne kommandoen resulterer i en ekte Kubernetes-klynge som kjører på maskinen din.
Trikset er hvordan du bygger applikasjonen og kjører den lokalt på den klyngen. Med mindre det er spesifikt instruert, vil Docker-bildet bygges på datamaskinen din og ikke på klyngen.
For å tvinge Docker til å skyve bildet til den lokale Kubernetes-klyngen, får docker-maskinen følgende kommando:
eval $(minikube docker-env)
Nå kan vi bygge applikasjoner på en lokal Kubernetes-klynge.
Ikke gi kubectl tilgang til alle
Dette virker åpenbart, men hvis flere team bruker samme klynge for applikasjonene sine (som er det Kubernetes ble opprettet for), bør du ikke bare gi alle kubectl. Det er bedre å skille kommandoene, tildele hver av dem sitt eget navneområde og begrense tilgangen ved å bruke RBAC-policyer.
Du kan bli forvirret ved å tildele rettigheter til tilgang til, lese, opprette, slette og andre operasjoner for hver pod. Men det viktigste er å begrense tilgangen til hemmeligheter, slik at det bare tillater administratorer. På denne måten vil vi skille mellom de som kan administrere klyngen og de som ganske enkelt kan distribuere til den.
Administrer podbudsjetter
Hvordan sikre ingen nedetid for en applikasjon i en Kubernetes-klynge? PodDisruptionBudget og igjen PodDisruptionBudget.
Klynger oppdateres med jevne mellomrom og noder tømmes. Ingenting står stille, det er virkeligheten. Hver distribusjon med mer enn én forekomst bør inkludere en PDB (PodDisruptionBudget). Den er opprettet i en enkel yaml-fil som brukes på klyngen. Dekningsområdet til en bestemt PDB bestemmes av etikettvelgere.
Merk: PDB-budsjettet tas kun i betraktning når budsjettbruddet er reversibelt (). I situasjoner som maskinvarefeil vil ikke PDB fungere.
Eksempel PDB:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
De to hovedparametrene er matchLabels и minAvailable. Den første parameteren spesifiserer hvilke applikasjoner budsjettet gjelder. For eksempel hvis jeg har distribusjoner med etiketter app: app-a и app: app-b, da vil dette PDB bare gjelde for det første.
Parameter minAvailable tatt i betraktning ved tømming (rengjøring) av noden. For eksempel, i vårt eksempel, under tømming, blir alle instanser kastet ut app: app-a, bortsett fra to.
Dette lar deg kontrollere hvor mange forekomster av applikasjonen som skal kjøres til enhver tid.
Programhelseovervåking
Slik overvåking er mulig på to måter: ved å bruke beredskaps- eller liveness-tester.
Den første sonden (beredskap) bestemmer containerens beredskap til å motta trafikk.
Den andre (liveness) viser om beholderen er frisk eller må startes på nytt.
De relevante konfigurasjonene legges ganske enkelt til yaml for distribusjon. Der kan du angi timeouts, forsinkelsestider og antall gjenforsøk. Se flere detaljer om dem .
Tagger er overalt
Etiketter er et av de grunnleggende konseptene i Kubernetes. De lar objekter fritt kommunisere med hverandre, samt lage spørringer basert på etiketter. I Kubernetes kan du til og med gå til klienten og se hendelser for spesifikke tagger.
Du kan gjøre nesten hva som helst med tagger, men et godt eksempel ville være å lage flere miljøer for å kjøre programmer på samme klynge.
La oss si at du bruker samme klynge til dev и qa. Dette betyr at du kan ha en søknad app-a, jobber samtidig i begge miljøer qa и dev. I dette tilfellet kan vi separat få tilgang til applikasjonsforekomsten i et spesifikt miljø ved å spesifisere den aktuelle parameteren environment. For eksempel, app: app-a и environment: dev for ett miljø, og app: app-a и environment: qa for den andre.
Dette lar deg få tilgang til begge forekomstene av applikasjonen, for eksempel for å utføre testing samtidig.
Sett orden på ting
Kubernetes er et veldig kraftig system, men ethvert system kan til slutt bli fastlåst med for mange prosesser. Kubelet kjører alle prosessene og sjekkene du spesifiserer, så vel som sine egne.
En foreldreløs tjeneste vil selvfølgelig ikke bremse systemet, og Kubernetes er designet for å skalere fra grunnen av. Men hvis det dukker opp en million i stedet for én tjeneste, begynner kubelet å kvele.
Hvis du av en eller annen grunn sletter en distribusjon (beholder, bilde, hva som helst), bare sørg for å gjøre en fullstendig opprydding.
Møt Go
Vi lagret hovedrådet til sist. Lær Go-programmeringsspråket.
Kubernetes er utviklet i Go, alle utvidelser er skrevet i Go, og klient-go-klientbiblioteket støttes også offisielt.
Den kan brukes til forskjellige og interessante ting. For eksempel for å utvide Kubernetes-systemet etter din smak. Så du kan bruke dine egne programmer til å samle inn data, distribuere applikasjoner eller ganske enkelt rydde opp i containere.
Å lære Go-programmeringsspråket og mestre client-go er kanskje det viktigste rådet du kan gi til nye Kubernetes-brukere.
Hva annet å lese:
- .
- ?
- .
Kilde: www.habr.com