Există o mulțime de literatură de referință pe Internet, dar uneori cel mai simplu sfat este cel mai valoros. Echipă tradus , pe care autorul articolului l-a colectat după un an de lucru cu Kubernetes. Sfaturile nu sunt sortate după importanță, dar credem că fiecare își va găsi ceva util.
Cea mai simplă comandă pentru a lucra cu Kubernetes
Pentru început, poate cea mai simplă și mai utilă acțiune în lucrul cu Kubernetes. Următoarea comandă permite finalizarea comenzii kubectl în bash shell:
echo "source <(kubectl completion bash)" >> ~/.bashrc
AutoComplete kubectl va fi scris în fișierul .bashrc și va fi activat automat de fiecare dată când shell-ul este pornit. Acest lucru accelerează tastarea comenzilor lungi și a parametrilor precum all-namespaces. Mai multe detalii în .
Limitele implicite de memorie și CPU într-un spațiu de nume
Dacă aplicația este scrisă incorect, de exemplu, deschide o nouă conexiune la baza de date în fiecare secundă, dar nu o închide niciodată, atunci clusterul are o scurgere de memorie. Și dacă aplicația nu are o limită de memorie setată în timpul implementării, acest lucru poate duce la o defecțiune a nodului.
Pentru a preveni acest lucru, Kubernetes vă permite să setați restricții implicite pe bază de spațiu de nume. Sunt scrise în fișierul yaml pentru un anumit spațiu de nume. Iată un exemplu de astfel de fișier:
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
Creați un astfel de yaml și aplicați la orice spațiu de nume. De exemplu, la spațiul de nume limit-example. Acum, orice container implementat în acest spațiu de nume va avea o limită de 512Mi, cu excepția cazului în care este setată suplimentar o altă limită individuală pentru acest container.
Colectarea gunoiului în versiunile mai vechi de Kubernetes
Kubelet începe în mod implicit colectarea gunoiului când var/lib/docker ocupă 90% din spațiul disponibil pe disc. Acest lucru este grozav, totuși, până la Kubernetes 1.7 nu exista o limită implicită a numărului de inoduri utilizate, care corespund numărului de fișiere din sistemul de fișiere.
Potenţial containerul dvs var/lib/docker poate folosi doar 50% din spațiul pe disc, dar poate rămâne fără inoduri, ceea ce va cauza probleme lucrătorilor.
În versiunile mai vechi de kubelet de la 1.4 la 1.6 va trebui să adăugați acest steag:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
În versiunile 1.7 și ulterioare, acest steag este setat implicit. Cu toate acestea, versiunile anterioare nu monitorizează limita inodului.
Minikube... Kubernetes local mic, dar puternic
Minikube este cel mai simplu mod de a rula un cluster Kubernetes local. Se lansează cu o comandă simplă:
minikube start
Rularea acestei comenzi are ca rezultat un cluster Kubernetes real care rulează pe mașina dvs.
Trucul este cum să construiți aplicația și să o rulați local pe acel cluster. Cu excepția cazului în care este specificat în mod specific, imaginea Docker va fi construită pe computerul dvs. și nu pe cluster.
Pentru a forța Docker să împingă imaginea în cluster-ul Kubernetes local, mașinii docker primesc următoarea comandă:
eval $(minikube docker-env)
Acum putem construi aplicații pe un cluster Kubernetes local.
Nu acordați acces kubectl tuturor
Acest lucru pare evident, dar dacă mai multe echipe folosesc același cluster pentru aplicațiile lor (care este scopul pentru care a fost creat Kubernetes), nu ar trebui să oferiți tuturor kubectl. Este mai bine să separați comenzile, atribuindu-le fiecăruia propriul spațiu de nume și limitând accesul folosind politicile RBAC.
Puteți fi confuz atribuind drepturi de acces, citire, creare, ștergere și alte operațiuni pentru fiecare pod. Dar principalul lucru este să limitați accesul la secrete, permițându-l doar administratorilor. În acest fel vom face diferența între cei care pot administra clusterul și cei care se pot implementa pur și simplu în el.
Gestionați bugetele podului
Cum să vă asigurați că nu există timpi de nefuncționare pentru o aplicație dintr-un cluster Kubernetes? PodDisruptionBudget și din nou PodDisruptionBudget.
Clusterele sunt actualizate periodic și nodurile sunt golite. Nimic nu stă pe loc, asta e realitatea. Fiecare implementare cu mai mult de o instanță ar trebui să includă un PDB (PodDisruptionBudget). Este creat într-un fișier yaml simplu care este aplicat clusterului. Aria de acoperire a unui anumit PDB este determinată de selectoare de etichete.
Nota: Bugetul PPB este luat în considerare numai atunci când încălcarea bugetară este reversibilă (). În situații precum defecțiuni hardware, PDB nu va funcționa.
Exemplu PDB:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
Cei doi parametri principali sunt matchLabels и minAvailable. Primul parametru specifică aplicațiilor cărora li se aplică bugetul. De exemplu, dacă am implementări cu etichete app: app-a и app: app-b, atunci acest PDB se va aplica numai primului.
Parametru minAvailable luate în considerare la golirea (curățarea) nodului. De exemplu, în exemplul nostru, în timpul golirii, toate instanțele sunt evacuate app: app-a, cu excepția a două.
Acest lucru vă permite să controlați câte instanțe ale aplicației ar trebui să ruleze la un moment dat.
Monitorizarea sănătății aplicației
O astfel de monitorizare este posibilă în două moduri: folosind teste de pregătire sau de viabilitate.
Prima sondă (pregătirea) determină gradul de pregătire al containerului de a primi trafic.
Cel de-al doilea (intensitatea) arată dacă containerul este sănătos sau trebuie repornit.
Configurațiile relevante sunt pur și simplu adăugate la yaml pentru implementare. Acolo puteți specifica timeout-uri, timpii de întârziere și numărul de reîncercări. Vezi mai multe detalii despre ele .
Etichetele sunt peste tot
Etichetele sunt unul dintre conceptele fundamentale din Kubernetes. Acestea permit obiectelor să comunice liber între ele, precum și să creeze interogări bazate pe etichete. În Kubernetes, puteți chiar să mergeți la client și să urmăriți evenimente pentru anumite etichete.
Puteți face aproape orice cu etichete, dar un exemplu bun ar fi crearea mai multor medii pentru a rula programe pe același cluster.
Să presupunem că utilizați același cluster pentru dev и qa. Aceasta înseamnă că puteți avea o aplicație app-a, lucrând simultan în ambele medii qa и dev. În acest caz, putem accesa separat instanța aplicației într-un mediu specific prin specificarea parametrului corespunzător environment. De exemplu app: app-a и environment: dev pentru un mediu și app: app-a и environment: qa pentru al doilea.
Acest lucru vă permite să accesați ambele instanțe ale aplicației, de exemplu, pentru a efectua testarea simultan.
Pune lucrurile în ordine
Kubernetes este un sistem foarte puternic, dar orice sistem poate deveni în cele din urmă blocat cu prea multe procese. Kubelet rulează toate procesele și verificările pe care le specificați, precum și propriile sale.
Desigur, un serviciu orfan nu va încetini sistemul, iar Kubernetes este proiectat să se extindă de la zero. Dar dacă în loc de un serviciu apare un milion, kubeletul începe să se sufoce.
Dacă dintr-un motiv oarecare ștergeți o implementare (container, imagine, orice), asigurați-vă că faceți o curățare completă.
Faceți cunoștință cu Go
Am păstrat sfatul principal pentru final. Învață limbajul de programare Go.
Kubernetes este dezvoltat în Go, toate extensiile sunt scrise în Go, iar biblioteca client-go este, de asemenea, acceptată oficial.
Poate fi folosit pentru lucruri diferite și interesante. De exemplu, pentru a extinde sistemul Kubernetes după gustul dvs. Deci, puteți folosi propriile programe pentru a colecta date, a implementa aplicații sau pur și simplu pentru a curăța containerele.
Învățarea limbajului de programare Go și stăpânirea client-go este poate cel mai important sfat pe care îl puteți oferi noilor utilizatori Kubernetes.
Ce altceva de citit:
- .
- ?
- .
Sursa: www.habr.com