Hi ha molta literatura de referència a Internet, però de vegades el consell més senzill és el més valuós. Equip traduït , que l'autor de l'article va recollir després d'un any de treball amb Kubernetes. Els consells no estan ordenats per importància, però creiem que cadascú trobarà alguna cosa útil per a si mateix.
L'ordre més senzill per treballar amb Kubernetes
Per començar, potser l'acció més senzilla i útil per treballar amb Kubernetes. L'ordre següent permet completar l'ordre kubectl a bash shell:
echo "source <(kubectl completion bash)" >> ~/.bashrc
Ompliment automàtic kubectl s'escriurà al fitxer .bashrc i s'activarà automàticament cada vegada que s'iniciï l'intèrpret d'ordres. Això accelera l'escriptura d'ordres llargues i paràmetres com ara all-namespaces. Més detalls a .
Límits de memòria i CPU per defecte en un espai de noms
Si l'aplicació està escrita incorrectament, per exemple, obre una nova connexió a la base de dades cada segon però mai la tanca, aleshores el clúster té una fuga de memòria. I si l'aplicació no té un límit de memòria establert durant el desplegament, això pot provocar una fallada del node.
Per evitar-ho, Kubernetes us permet establir restriccions predeterminades per espai de noms. S'escriuen al fitxer yaml per a un espai de noms específic. Aquí teniu un exemple d'aquest fitxer:
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
Creeu aquest yaml i apliqueu-lo a qualsevol espai de noms. Per exemple, a l'espai de noms limit-example. Ara qualsevol contenidor desplegat en aquest espai de noms tindrà un límit de 512 Mi, tret que s'estableixi un altre límit individual per a aquest contenidor.
Recollida d'escombraries en versions anteriors de Kubernetes
Kubelet comença per defecte la recollida d'escombraries quan var/lib/docker ocupa el 90% de l'espai disponible en disc. Això és fantàstic, però, fins a Kubernetes 1.7 no hi havia cap límit predeterminat en el nombre d'inodes utilitzats, que corresponen al nombre de fitxers del sistema de fitxers.
Potencialment el teu contenidor var/lib/docker només pot utilitzar el 50% de l'espai del disc, però pot quedar sense inodes, cosa que causarà problemes als treballadors.
A les versions anteriors de kubelet de l'1.4 a la 1.6 haureu d'afegir aquesta marca:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
A les versions 1.7 i posteriors, aquesta marca està establerta per defecte. Tanmateix, les versions anteriors no controlen el límit d'inode.
Minikube... Kubernetes locals petits però potents
Minikube és la manera més senzilla d'executar un clúster local de Kubernetes. S'inicia amb una ordre senzilla:
minikube start
L'execució d'aquesta ordre resulta en un clúster de Kubernetes real que s'executa al vostre ordinador.
El truc és com crear l'aplicació i executar-la localment en aquest clúster. Tret que s'indiqui específicament, la imatge de Docker es crearà al vostre ordinador i no al clúster.
Per forçar Docker a enviar la imatge al clúster local de Kubernetes, la màquina docker rep l'ordre següent:
eval $(minikube docker-env)
Ara podem crear aplicacions en un clúster local de Kubernetes.
No doneu accés a kubectl a tothom
Això sembla obvi, però si diversos equips utilitzen el mateix clúster per a les seves aplicacions (per a què es va crear Kubernetes), no hauríeu de donar a tothom kubectl. És millor separar les ordres, assignant a cadascuna d'elles el seu propi espai de noms i limitant l'accés mitjançant polítiques RBAC.
Us podeu confondre assignant drets per accedir, llegir, crear, suprimir i altres operacions per a cada pod. Però el més important és limitar l'accés als secrets, permetent-lo només als administradors. D'aquesta manera diferenciarem entre els que poden administrar el clúster i els que simplement poden desplegar-s'hi.
Gestioneu els pressupostos dels pods
Com garantir que no hi hagi temps d'inactivitat per a una aplicació en un clúster de Kubernetes? PodDisruptionBudget i de nou PodDisruptionBudget.
Els clústers s'actualitzen periòdicament i els nodes es buiden. Res no s'atura, aquesta és la realitat. Cada desplegament amb més d'una instància hauria d'incloure un PDB (PodDisruptionBudget). Es crea en un fitxer yaml senzill que s'aplica al clúster. L'àrea de cobertura d'un PDB particular està determinada pels selectors d'etiquetes.
Nota: El pressupost de l'APB només es té en compte quan la infracció pressupostària és reversible (). En situacions com ara errors de maquinari, PDB no funcionarà.
Exemple de PDB:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
Els dos paràmetres principals són matchLabels и minAvailable. El primer paràmetre especifica a quines aplicacions s'aplica el pressupost. Per exemple, si tinc desplegaments amb etiquetes app: app-a и app: app-b, llavors aquest PDB només s'aplicarà al primer.
Paràmetre minAvailable es té en compte a l'hora de buidar (netejar) el node. Per exemple, en el nostre exemple, durant el buidatge, totes les instàncies són desallotjades app: app-a, excepte dos.
Això us permet controlar quantes instàncies de l'aplicació s'haurien d'executar en un moment donat.
Supervisió de l'estat de l'aplicació
Aquest seguiment és possible de dues maneres: mitjançant proves de Preparació o de Viva.
La primera sonda (preparació) determina la disposició del contenidor per rebre trànsit.
La segona (vivència) mostra si el contenidor està sa o s'ha de reiniciar.
Les configuracions rellevants simplement s'afegeixen al yaml per al desplegament. Allà podeu especificar temps d'espera, temps de retard i el nombre de reintents. Vegeu més detalls sobre ells .
Les etiquetes estan a tot arreu
Les etiquetes són un dels conceptes fonamentals de Kubernetes. Permeten que els objectes es comuniquin lliurement entre ells, així com crear consultes basades en etiquetes. A Kubernetes, fins i tot podeu anar al client i veure esdeveniments per a etiquetes específiques.
Podeu fer gairebé qualsevol cosa amb les etiquetes, però un bon exemple seria crear diversos entorns per executar programes al mateix clúster.
Suposem que utilitzeu el mateix clúster per dev и qa. Això vol dir que podeu tenir una aplicació app-a, treballant simultàniament en ambdós entorns qa и dev. En aquest cas, podem accedir per separat a la instància de l'aplicació en un entorn específic especificant el paràmetre adequat environment. Per exemple app: app-a и environment: dev per a un entorn, i app: app-a и environment: qa per al segon.
Això us permet accedir a les dues instàncies de l'aplicació, per exemple, per realitzar proves simultàniament.
Posar les coses en ordre
Kubernetes és un sistema molt potent, però qualsevol sistema pot acabar empantanat amb massa processos. El Kubelet executa tots els processos i comprovacions que especifiqueu, així com els seus.
Per descomptat, un servei orfe no alentirà el sistema i Kubernetes està dissenyat per escalar des de zero. Però si en lloc d'un servei apareix un milió, el kubelet comença a sufocar-se.
Si per algun motiu suprimiu un desplegament (contenidor, imatge, el que sigui), només assegureu-vos de fer una neteja completa.
Coneix Go
Vam guardar el consell principal per al final. Aprèn el llenguatge de programació Go.
Kubernetes es desenvolupa a Go, totes les extensions estan escrites a Go i la biblioteca client de client-go també és compatible oficialment.
Es pot utilitzar per a coses diferents i interessants. Per exemple, per ampliar el sistema Kubernetes al vostre gust. Per tant, podeu utilitzar els vostres propis programes per recollir dades, desplegar aplicacions o simplement netejar contenidors.
Aprendre el llenguatge de programació Go i dominar client-go és potser el consell més important que podeu donar als nous usuaris de Kubernetes.
Què més llegir:
- .
- ?
- .
Font: www.habr.com