Der er meget referencelitteratur på internettet, men nogle gange er de enkleste råd de mest værdifulde. Hold oversat , som forfatteren til artiklen indsamlede efter et års arbejde med Kubernetes. Tipsene er ikke sorteret efter vigtighed, men vi tror, at alle vil finde noget brugbart for sig selv.
Den enkleste kommando til at arbejde med Kubernetes
Til at begynde med, måske den enkleste og mest nyttige handling i arbejdet med Kubernetes. Følgende kommando aktiverer kommandofuldførelse kubectl i bash shell:
echo "source <(kubectl completion bash)" >> ~/.bashrc
Autofuldførelse kubectl vil blive skrevet til .bashrc-filen og vil automatisk blive aktiveret hver gang shellen startes. Dette gør det hurtigere at skrive lange kommandoer og parametre som f.eks all-namespaces. Flere detaljer i .
Standard hukommelse og CPU-grænser i et navneområde
Hvis applikationen for eksempel er skrevet forkert, åbner den en ny forbindelse til databasen hvert sekund, men lukker den aldrig, så har klyngen en hukommelseslækage. Og hvis applikationen ikke har en hukommelsesgrænse indstillet under implementeringen, kan dette føre til en knudefejl.
For at forhindre dette giver Kubernetes dig mulighed for at indstille standardbegrænsninger på basis af et navneområde. De er skrevet i yaml-filen for et specifikt navneområde. 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 på ethvert navneområde. For eksempel til navneområdet limit-example. Nu vil enhver container, der er implementeret i dette navneområde, have en grænse på 512Mi, medmindre der yderligere er angivet en anden individuel grænse for denne container.
Affaldsopsamling i ældre versioner af Kubernetes
Kubelet starter som standard indsamling af skrald, når var/lib/docker optager 90 % af tilgængelig diskplads. Dette er dog fantastisk, indtil Kubernetes 1.7 var der ingen standardgrænse på antallet af anvendte inoder, som svarer til antallet af filer i filsystemet.
Potentielt din container var/lib/docker bruger muligvis kun 50% af diskpladsen, men kan løbe tør for inoder, hvilket vil forårsage problemer for arbejderne.
I ældre versioner af kubelet fra 1.4 til 1.6 skal du tilføje dette flag:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
I 1.7 og senere versioner er dette flag indstillet som standard. Tidligere versioner overvåger dog ikke inodegrænsen.
Minikube... lille, men kraftfuld lokale Kubernetes
Minikube er den nemmeste måde at køre en lokal Kubernetes-klynge på. Det startes med en simpel kommando:
minikube start
Kørsel af denne kommando resulterer i en rigtig Kubernetes-klynge, der kører på din computer.
Tricket er, hvordan man bygger applikationen og kører den lokalt på den klynge. Medmindre det er specifikt instrueret, vil Docker-billedet blive bygget på din computer og ikke på klyngen.
For at tvinge Docker til at skubbe billedet til den lokale Kubernetes-klynge, får docker-maskinen følgende kommando:
eval $(minikube docker-env)
Nu kan vi bygge applikationer på en lokal Kubernetes-klynge.
Giv ikke kubectl adgang til alle
Dette virker indlysende, men hvis flere teams bruger den samme klynge til deres applikationer (hvilket er hvad Kubernetes blev skabt til), bør du ikke bare give alle kubectl. Det er bedre at adskille kommandoerne, tildele hver af dem sit eget navneområde og begrænse adgangen ved hjælp af RBAC-politikker.
Du kan blive forvirret ved at tildele rettigheder til at få adgang til, læse, oprette, slette og andre handlinger for hver pod. Men det vigtigste er at begrænse adgangen til hemmeligheder, så det kun tillader administratorer. På denne måde vil vi skelne mellem dem, der kan administrere klyngen, og dem, der blot kan implementere den.
Administrer Pod-budgetter
Hvordan sikrer man ingen nedetid for en applikation i en Kubernetes-klynge? PodDisruptionBudget og igen PodDisruptionBudget.
Klynger opdateres med jævne mellemrum, og noder tømmes. Intet står stille, det er virkeligheden. Enhver implementering med mere end én forekomst bør indeholde et PDB (PodDisruptionBudget). Den er oprettet i en simpel yaml-fil, der anvendes på klyngen. Dækningsområdet for et bestemt PDB bestemmes af etiketvælgere.
Note: FBF-budgettet tages kun i betragtning, når budgetovertrædelsen er reversibel (). 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 hovedparametre er matchLabels и minAvailable. Den første parameter angiver, hvilke applikationer budgettet gælder for. For eksempel hvis jeg har implementeringer med etiketter app: app-a и app: app-b, så vil dette FBF kun gælde for det første.
Parameter minAvailable tages i betragtning ved tømning (rengøring) af noden. For eksempel, i vores eksempel, under tømning, bliver alle instanser smidt ud app: app-a, undtagen to.
Dette giver dig mulighed for at kontrollere, hvor mange forekomster af applikationen skal køre på et givet tidspunkt.
Applikationssundhedsovervågning
Sådan overvågning er mulig på to måder: ved hjælp af Readiness- eller Liveness-tests.
Den første sonde (beredskab) bestemmer containerens beredskab til at modtage trafik.
Den anden (liveness) viser, om beholderen er sund eller skal genstartes.
De relevante konfigurationer tilføjes blot til yaml'en til implementering. Der kan du angive timeouts, forsinkelsestider og antallet af genforsøg. Se flere detaljer om dem .
Tags er overalt
Etiketter er et af de grundlæggende begreber i Kubernetes. De giver objekter mulighed for frit at kommunikere med hinanden, samt oprette forespørgsler baseret på etiketter. I Kubernetes kan du endda gå til klienten og se begivenheder for specifikke tags.
Du kan gøre næsten alt med tags, men et godt eksempel ville være at skabe flere miljøer til at køre programmer på den samme klynge.
Lad os sige, at du bruger den samme klynge til dev и qa. Det betyder, at du kan have en ansøgning app-aarbejder samtidigt i begge miljøer qa и dev. I dette tilfælde kan vi separat få adgang til applikationsforekomsten i et specifikt miljø ved at angive den relevante parameter environment. For eksempel app: app-a и environment: dev for ét miljø, og app: app-a и environment: qa for det andet.
Dette giver dig adgang til begge forekomster af applikationen, for eksempel for at udføre test samtidigt.
Bliv organiseret
Kubernetes er et meget kraftfuldt system, men ethvert system kan i sidste ende blive hængende med for mange processer. Kubelet kører alle de processer og kontroller, du angiver, såvel som sine egne.
Selvfølgelig vil én forældreløs tjeneste ikke bremse systemet, og Kubernetes er designet til at skalere fra bunden. Men hvis der i stedet for én tjeneste dukker en million op, begynder kubelet at kvæle.
Hvis du af en eller anden grund sletter en implementering (container, billede, hvad som helst), skal du bare sørge for at foretage en fuldstændig oprydning.
Mød Go
Vi gemte hovedrådet til sidst. Lær Go-programmeringssproget.
Kubernetes er udviklet i Go, alle udvidelser er skrevet i Go, og klient-go klientbiblioteket er også officielt understøttet.
Det kan bruges til forskellige og interessante ting. For eksempel at udvide Kubernetes-systemet til din smag. Så du kan bruge dine egne programmer til at indsamle data, implementere applikationer eller blot rydde op i containere.
At lære Go-programmeringssproget og mestre client-go er måske det vigtigste råd, du kan give til nye Kubernetes-brugere.
Hvad skal man ellers læse:
- .
- ?
- .
Kilde: www.habr.com