De 10 bästa knepen och tipsen för Kubernetes

På internet finns det mycket referenslitteratur, men ibland är de enklaste råden de mest värdefulla. Teamet Kubernetes aaS från Mail.ru har översatt en sammanställning av tio knep och tips, som artikelns författare sammanställde efter ett års arbete med Kubernetes. Tipsen är inte sorterade efter vikt, men vi tror att alla kan hitta något användbart för sig själva.

Det enklaste kommandot för arbete med Kubernetes

För att börja, är nog den enklaste och mest användbara åtgärden i arbetet med Kubernetes. Följande kommando aktiverar autocompletion av kommandon kubectl i bash-skalet:

echo "source > ~/.bashrc

Autocompletion kubectl registreras i filen .bashrc och aktiveras automatiskt varje gång man startar skalet. Detta snabbar upp skrivandet av långa kommandon och parametrar, såsom all-namespaces. Mer information finns i Kubernetes-hjälp för bash.

Standardbegränsningar för minne och CPU i namnrymden

Om en applikation är felaktigt skriven, till exempel om den öppnar en ny databasanslutning varje sekund men aldrig stänger den, kommer det att leda till minnesläckor i klustret. Och om inget minnesgräns sätts vid deployment för applikationen, kan det leda till nodfel.

För att förhindra detta tillåter Kubernetes att man sätter standardbegränsningar för varje namnrymd. Dessa anges i en yaml-fil för den specifika namnrymden. Här är ett exempel på en sådan fil:

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
spec:
  limits:
  - default:
      memory: 512Mi
    defaultRequest:
      memory: 256Mi
    type: Container

Skapa en sådan yaml-fil och tillämpa den på vilken namnrymd som helst. Till exempel på namnrymden limit-example. Nu kommer en gräns på 512Mi att gälla för alla containrar som distribueras i denna namnrymd, om inte ett annat individuellt gräns sätts för den specifika containern.

Skräpstädning i äldre versioner av Kubernetes

Kubelet börjar som standard städa ut skräp när /var/lib/docker upptar 90 % av det tillgängliga diskutrymmet. Detta är bra, men fram till version 1.7 av Kubernetes fanns det ingen standardgräns för antalet använda inode-indexdeskriptorer (inodes), som motsvarar antalet filer i filsystemet.

Potentiellt kan din container /var/lib/docker bara använda 50 % av diskutrymmet, men ändå kan inodes ta slut, vilket kan orsaka problem med arbetarna.

I äldre versioner av kubelet från 1.4 till 1.6 måste du lägga till flaggan:

--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%

Från och med version 1.7 och senare är denna flagga aktiverad som standard. Tidigare versioner övervakar dock inte inodgränsen.

Minikube... liten men kraftfull lokal Kubernetes

Minikube är det enklaste sättet att starta en lokal Kubernetes-kluster. Den startas med ett enkelt kommando:

minikube start

Som ett resultat av att köra detta kommando kör du en riktig Kubernetes-kluster på din dator.

Källa till illustration

Tricket är att bygga en applikation och få den att köras lokalt i denna kluster. Om inga speciella instruktioner ges kommer Docker-bilden att byggas på din dator, inte i klustret.

För att få Docker att skicka bilden till den lokala Kubernetes-klustret ges följande kommando till docker-maskinen:

eval $(minikube docker-env)

Nu kan vi bygga applikationer på den lokala Kubernetes-klustret.

Ge inte kubectl-åtkomst till alla

Detta kan verka uppenbart, men om flera team använder en kluster för sina applikationer (vilket är syftet med Kubernetes), bör man inte bara ge åtkomst till alla. kubectlBättre att dela upp teamen och ge varje team sitt eget namnrymd och avgränsa åtkomst med RBAC-policies.

Det går att gå in i detalj och ange åtkomsträttigheter för varje podd för att läsa, skapa, ta bort och andra operationer. Men det viktigaste är att begränsa åtkomsten till hemligheter, och endast tillåta administratörer åtkomst. På så sätt skiljer vi på dem som kan administrera klustret och dem som bara kan distribuera i det.

Hantera poddarnas budgetar

Hur kan man säkerställa att applikationen inte får driftstopp i Kubernetes-klustret? PodDisruptionBudget och återigen PodDisruptionBudget.

Klustren uppdateras regelbundet och noder töms. Ingenting står still, sådan är verkligheten. Varje deployment med mer än en instans bör nödvändigtvis inkludera PDB (PodDisruptionBudget). Den skapas i en enkel yaml-fil som tillämpas på klustret. Täckningsområdet för ett specifikt PDB definieras av label-selektorer.

Anmärkning: PDB-budgeten beaktas endast vid reversibla budgetöverträdelser (voluntary disruption). I situationer som hårdvarufel kommer PDB inte att fungera.

Exempel på PDB:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: app-a-pdb
spec:
  minAvailable: 2
  selector:
      matchLabels:
        app: app-a

De två främsta parametrarna är matchLabels och minAvailableI den första parametern anges vilka applikationer budgeten gäller. Till exempel, om jag har distributioner med etiketter app: app-a och app: app-b, så kommer denna PDB endast att tillämpas på den första.

Parameter minAvailable beaktas vid tömning av noden. Till exempel, i vårt exempel tas alla instanser bort under tömningen, app: app-a, utom två.

Detta gör det möjligt att kontrollera hur många instanser av applikationen som ska köras vid varje given tidpunkt.

Övervakning av applikationens hälsa

Sådan övervakning är möjlig på två sätt: genom Readiness eller Liveness kontroller.

Den första kontrollen (readiness) avgör om containern är redo att ta emot trafik.

Den andra (liveness) visar huruvida containern är funktionell eller om den behöver startas om.

De relevanta konfigurationerna läggs enkelt till i yaml-filen för distributionen. Där kan tidsgränser, fördröjningar och antal upprepningar anges. Mer information om dem finns i Kubernetes-dokumentationen.

Etiketter överallt

Etiketter är ett av de grundläggande begreppen i Kubernetes. De gör det möjligt för objekt att fritt kopplas samman och att skapa förfrågningar baserade på etiketter. I Kubernetes kan man till och med gå till klienten och övervaka händelser baserat på specifika etiketter.

Med hjälp av etiketter kan man göra nästan vad som helst, men ett bra exempel är att skapa flera miljöer för att köra program i en och samma kluster.

Anta att ni använder samma kluster för dev och qa. Det betyder att ni kan ha en applikation app-a, som arbetar samtidigt i båda miljöerna. qa och dev. I så fall kan vi hänvisa till en specifik instans av applikationen i en viss miljö genom att ange den motsvarande parameter miljö. Till exempel, app: app-a och environment: dev för en miljö, och app: app-a och environment: qa för den andra.

Detta gör det möjligt att hänvisa till båda instanserna av applikationen, till exempel för att samtidigt genomföra tester.

Rensa upp

Kubernetes är ett mycket kraftfullt system, men vilket system som helst kan så småningom fastna i ett stort antal processer. Kubelet startar alla processer och kontroller som ni angivit, samt sina egna.

Naturligtvis kommer en föräldralös tjänst inte att bromsa systemet, och Kubernetes är från början designat för skalning. Men om en tjänst blir en miljon börjar kubelet att kvävas.

Om du av någon anledning raderar en distribution (container, bild, vad som helst), se bara till att rensa helt.

Lär känna Go

Det viktigaste rådet har vi sparat till sist. Lär dig programmeringsspråket Go.

Kubernetes är skrivet i Go, alla tillägg är skrivna i Go, och den officiella klientbiblioteket client-go stöds också.

Det kan användas för olika och intressanta saker. Till exempel för att anpassa Kubernetes-systemet. Du kan använda egna program för att samla in data, distribuera applikationer eller helt enkelt rensa containrar.

Att lära sig programmeringsspråket Go och bemästra client-go är förmodligen det viktigaste rådet man kan ge nybörjare i Kubernetes.

Översatt med stöd från Mail.ru Cloud Solutions

Vad mer att läsa:

1. Tre nivåer av automatisk skalning i Kubernetes och hur man använder dem effektivt.
2. Arbetsnoder i Kubernetes: många små eller få stora?
3. 25 användbara verktyg för distribution och hantering av Kubernetes.

Källa: habr.com