Det finns mycket referenslitteratur på Internet, men ibland är de enklaste råden de mest värdefulla. Team översatt , som författaren till artikeln samlade in efter ett års arbete med Kubernetes. Tipsen är inte sorterade efter betydelse, men vi tror att alla kommer att hitta något användbart för sig själva.
Det enklaste kommandot för att arbeta med Kubernetes
Till att börja med, kanske den enklaste och mest användbara åtgärden i arbetet med Kubernetes. Följande kommando möjliggör kommandoslutförande kubectl i bash-skal:
echo "source <(kubectl completion bash)" >> ~/.bashrc
Komplettera automatiskt kubectl kommer att skrivas till .bashrc-filen och kommer att aktiveras automatiskt varje gång skalet startas. Detta snabbar på att skriva långa kommandon och parametrar som t.ex all-namespaces. Läs mer i .
Standardminne och CPU-gränser i ett namnområde
Om applikationen är felskriven, till exempel, öppnar den en ny anslutning till databasen varje sekund men stänger den aldrig, då har klustret en minnesläcka. Och om applikationen inte har en minnesgräns inställd under driftsättning kan detta leda till ett nodfel.
För att förhindra detta låter Kubernetes dig ställa in standardbegränsningar per namnutrymme. De skrivs i yaml-filen för ett specifikt namnområde. 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 och tillämpa på valfritt namnområde. Till exempel till namnområdet limit-example. Nu kommer alla behållare som distribueras i det här namnutrymmet att ha en gräns på 512Mi, såvida inte en annan individuell gräns dessutom är inställd för den här behållaren.
Sophämtning i äldre versioner av Kubernetes
Kubelet startar som standard sophämtning när var/lib/docker upptar 90 % av tillgängligt diskutrymme. Detta är dock bra, fram till Kubernetes 1.7 fanns det ingen standardgräns för antalet använda inoder, vilket motsvarar antalet filer i filsystemet.
Potentiellt din behållare var/lib/docker kan bara använda 50 % av diskutrymmet, men kan få slut på inoder, vilket kommer att orsaka problem för arbetarna.
I äldre versioner av kubelet från 1.4 till 1.6 måste du lägga till denna flagga:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
I 1.7 och senare versioner är denna flagga inställd som standard. Tidigare versioner övervakar dock inte inodgränsen.
Minikube... små men kraftfulla lokala Kubernetes
Minikube är det enklaste sättet att köra ett lokalt Kubernetes-kluster. Det startas med ett enkelt kommando:
minikube start
Att köra detta kommando resulterar i att ett riktigt Kubernetes-kluster körs på din dator.
Tricket är hur man bygger applikationen och kör den lokalt på det klustret. Såvida du inte har särskilda instruktioner kommer Docker-avbildningen att byggas på din dator och inte på klustret.
För att tvinga Docker att skicka bilden till det lokala Kubernetes-klustret får docker-maskinen följande kommando:
eval $(minikube docker-env)
Nu kan vi bygga applikationer på ett lokalt Kubernetes-kluster.
Ge inte kubectl tillgång till alla
Detta verkar uppenbart, men om flera team använder samma kluster för sina applikationer (vilket är vad Kubernetes skapades för), bör du inte bara ge alla kubectl. Det är bättre att separera kommandona, tilldela vart och ett av dem ett eget namnområde och begränsa åtkomsten med hjälp av RBAC-policyer.
Du kan bli förvirrad genom att tilldela rättigheter att komma åt, läsa, skapa, ta bort och andra åtgärder för varje pod. Men det viktigaste är att begränsa åtkomsten till hemligheter, vilket endast tillåter administratörer. På så sätt kommer vi att skilja mellan de som kan administrera klustret och de som helt enkelt kan distribuera till det.
Hantera podbudgetar
Hur säkerställer man ingen stilleståndstid för en applikation i ett Kubernetes-kluster? PodDisruptionBudget och igen PodDisruptionBudget.
Kluster uppdateras med jämna mellanrum och noder töms. Inget står stilla, det är verkligheten. Varje distribution med mer än en instans bör innehålla ett PDB (PodDisruptionBudget). Den skapas i en enkel yaml-fil som appliceras på klustret. Täckningsområdet för en viss PDB bestäms av etikettväljare.
Notera: Budgeten i det preliminära budgetförslaget beaktas endast när budgetöverträdelsen är reversibel (). I situationer som hårdvarufel kommer PDB inte att fungera.
Exempel PDB:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
De två huvudparametrarna är matchLabels и minAvailable. Den första parametern anger vilka applikationer budgeten gäller. Till exempel om jag har distributioner med etiketter app: app-a и app: app-b, då kommer detta preliminära budgetförslag endast att gälla för det första.
Parameter minAvailable beaktas vid tömning (rengöring) av noden. Till exempel, i vårt exempel, vid tömning, vräkas alla instanser app: app-a, förutom två.
Detta låter dig styra hur många instanser av applikationen som ska köras vid varje given tidpunkt.
Applikationshälsoövervakning
Sådan övervakning är möjlig på två sätt: genom att använda beredskaps- eller Liveness-tester.
Den första sonden (beredskap) bestämmer containerns beredskap att ta emot trafik.
Den andra (liveness) visar om behållaren är frisk eller behöver startas om.
De relevanta konfigurationerna läggs helt enkelt till i yaml för distribution. Där kan du ange timeouts, fördröjningstider och antalet återförsök. Se mer information om dem .
Taggar finns överallt
Etiketter är ett av de grundläggande begreppen i Kubernetes. De tillåter objekt att fritt kommunicera med varandra, samt skapa frågor baserade på etiketter. I Kubernetes kan du till och med gå till klienten och titta på händelser för specifika taggar.
Du kan göra nästan vad som helst med taggar, men ett bra exempel skulle vara att skapa flera miljöer för att köra program på samma kluster.
Låt oss säga att du använder samma kluster för dev и qa. Det betyder att du kan ha en ansökan app-a, arbetar samtidigt i båda miljöerna qa и dev. I det här fallet kan vi separat komma åt applikationsinstansen i en specifik miljö genom att ange lämplig parameter environment. Till exempel app: app-a и environment: dev för en miljö, och app: app-a и environment: qa för den andra.
Detta gör att du kan komma åt båda instanserna av applikationen, till exempel för att utföra tester samtidigt.
Bli organiserad
Kubernetes är ett mycket kraftfullt system, men vilket system som helst kan så småningom fastna med för många processer. Kubelet kör alla processer och kontroller du anger, såväl som sina egna.
Naturligtvis kommer en föräldralös tjänst inte att sakta ner systemet, och Kubernetes är designad för att skala från grunden. Men om en miljon dyker upp istället för en tjänst börjar kubelet att kvävas.
Om du av någon anledning tar bort en distribution (behållare, bild, vad som helst), se bara till att göra en fullständig rensning.
Möt Go
Vi sparade huvudrådet till sist. Lär dig programmeringsspråket Go.
Kubernetes är utvecklat i Go, alla tillägg är skrivna i Go, och klient-go-klientbiblioteket stöds också officiellt.
Den kan användas till olika och intressanta saker. Till exempel för att utöka Kubernetes-systemet efter din smak. Så du kan använda dina egna program för att samla in data, distribuera applikationer eller helt enkelt rensa upp behållare.
Att lära sig Go-programmeringsspråket och behärska client-go är kanske det viktigaste rådet du kan ge nya Kubernetes-användare.
Vad mer att läsa:
- .
- ?
- .
Källa: will.com