Lansarea Kubernetes 1.18, un sistem de gestionare a clusterelor de containere izolate

Publicat lansarea platformei pentru orchestrationul containerelor Kubernetes 1.18, care permite gestionarea unui cluster de containere izolate ca un întreg și oferă mecanisme pentru desfășurarea, întreținerea și scalarea aplicațiilor desfășurate în containere. Proiectul a fost inițial creat de Google, dar a fost ulterior transferat pe o platformă independentă, gestionată de Linux Foundation. Platforma este poziționată ca o soluție universală dezvoltată de comunitate, nelegată de sisteme specifice și capabilă să funcționeze cu orice aplicații în orice medii cloud. Codul Kubernetes este scris în limbajul Go și se răspândește sub licența Apache 2.0.

oferă funcții pentru desfășurarea și gestionarea infrastructurii, cum ar fi gestionarea bazei DNS, echilibrarea sarcinii,
distribuția containerelor pe nodurile clusterului (migrarea containerelor în funcție de schimbările de sarcină și necesitățile serviciilor), verificarea funcționalității la nivelul aplicațiilor, gestionarea conturilor, actualizarea și scalarea dinamică a clusterului în funcțiune, fără a-l opri. Este posibilă desfășurarea grupurilor de containere cu operațiuni de actualizare și anulare a modificărilor simultan pentru întreaga grupă, precum și subdivizarea logică a clusterului în părți cu separarea resurselor. Există suport pentru migrarea dinamică a aplicațiilor, pentru care pot fi utilizate atât stocări locale, cât și sisteme de stocare în rețea.

Lansarea Kubernetes 1.18 include 38 de modificări și îmbunătățiri, dintre care 15 sunt trecute în stadiul stabil, iar 11 în stadiul beta. 12 modificări noi sunt propuse în stadiul alfa. În pregătirea noii versiuni, s-au depus eforturi egale atât pentru îmbunătățirea diferitelor funcționalități și stabilizarea caracteristicilor experimentale, cât și pentru adăugarea de dezvoltări noi. Cele mai importante modificări:

  • Kubectl
    • Adăugat versiunea alfa a comenzii „kubectl debug”, care permite simplificarea depanării în poduri, prin lansarea de containere efemere cu instrumente pentru depanare.
    • Anunțat ca stabil comanda „kubectl diff”, care permite vizualizarea a ceea ce se va schimba în cluster dacă se aplică manifestul.
    • Au fost eliminate toate generatoarele comenzii „kubectl run”, cu excepția generatorului pentru lansarea unui singur pod.
    • Au fost modificate flagul «—dry-run», în funcție de valoarea sa (client, server și none), execuția de încercare a comenzii se realizează pe partea clientului sau serverului.
    • Codul kubectl a fost separat într-un depozit distinct. Acest lucru a permis separarea kubectl de dependențele interne Kubernetes și a facilitat importul codului în proiecte terțe.
  • Ingress
    • A început schimbarea grupului API pentru Ingress la networking.v1beta1.
    • Adăugate câmpuri noi:
      • pathType, care permite specificarea modului în care va fi comparat calea în cerere
      • IngressClassName — înlocuirea unei anotații kubernetes.io/ingress.class, care a fost declarată depreciată. În acest câmp se specifică numele unui obiect special IngressClass.
    • Adăugat obiectul IngressClass, în care se specifică numele controlerului de ingresa, parametrii săi suplimentari și semnul utilizării sale ca implicit
  • Serviciu
    • A fost adăugat câmpul AppProtocol, în care se poate specifica ce protocol folosește aplicația
    • a fost tradus în statut beta și inclus implicit EndpointSlicesAPI, care este o înlocuire mai funcțională pentru Endpoints obișnuite.
  • Rețea
  • Discuri permanente. Următoarea funcționalitate a fost declarată stabilă:
  • Configurarea aplicației
    • În obiectele ConfigMap și Secret adăugat câmpul nou «immutable». Setarea valorii câmpului pe true interzice modificarea obiectului.
  • Planificatorul de sarcini din Airflow este construit pe
    • Adăugat posibilitatea de a crea profiluri suplimentare pentru kube-scheduler. Dacă anterior era necesar să se ruleze planificatori separate pentru a implementa algoritmi non-standard de distribuție a pod-urilor, acum a apărut posibilitatea de a crea seturi suplimentare de configurație pentru planificatorul standard și de a specifica numele său în același câmp al pod-ului «.spec.schedulerName». Statut — alfa.
    • Evacuarea pe baza Taint declarată stabilă
  • Scalare
    • Adăugat posibilitatea de a specifica în manifestul HPA gradul de agresivitate în modificarea numărului de pod-uri rulate, adică la creșterea sarcinii să se pornească imediat de N ori mai multe instanțe.
  • Kubelet
    • Managerul de Topologie a obținut statut beta. Funcția include distribuirea NUMA, ceea ce permite evitarea degradării performanței pe sistemele cu mai multe socket-uri.
    • Statut beta a primit funcția PodOverhead, care permite specificarea în RuntimeClass a unui număr suplimentar de resurse necesare pentru a rula un pod.
    • Extinsă suport pentru HugePages, izolarea la nivel de container și suportul pentru dimensiuni multiple de hugepages a fost adăugat în statut alpha.
    • Șters endpoint pentru metrici /metrics/resource/v1alpha1, în locul său se folosește /metrics/resource
  • API
    • Finalizat a fost eliminată posibilitatea de a utiliza API-urile învechite group apps/v1beta1 și extensions/v1beta1.
    • ServerSide Apply a fost upgradata la statut beta2. Această îmbunătățire mută manipularea obiectelor din kubectl în API-server. Autorii îmbunătățirii afirmă că acest lucru va permite corectarea multor erori existente care nu pot fi remediate în situația actuală. De asemenea, au adăugat secțiunea „.metadata.managedFields”, propunând stocarea istoriei modificărilor obiectului, specificând cine, când și ce a fost modificat.
    • Declarat API-ul CertificateSigningRequest este stabil.
  • Suport pentru platforma Windows.

Sursa: opennet.ro

Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS 🔥 Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS | ProHoster