Kubernetes 1.18 vine cu îmbunătățiri pentru depanarea Kubectl, securitate și multe altele

Săptămâna trecută lansarea noii versiuni a platforma de orchestrare a containerelor Kubernetes 1.18, versiune care include 38 de modificări și îmbunătățiri, dintre care 15 sunt în stare stabilă și 11 sunt în stare beta, pe lângă Sunt propuse 12 noi modificări ale stării alfa. La pregătirea noii versiuni, eforturile echitabile s-au îndreptat atât către rafinarea diferitelor funcții, cât și la stabilizarea capacităților experimentale, precum și la încorporarea de noi dezvoltări.

Pentru cei care nu sunt familiarizați cu Kubernetes, ar trebui să știți asta aceasta este o platformă de orchestrare a containerelorvă permite să gestionați un cluster de containere izolate în ansamblu și oferă mecanisme pentru implementarea, întreținerea și scalarea aplicațiilor care rulează în containere.

Proiectul a fost creat inițial de Google, dar ulterior a fost transferat pe o platformă separată, organizat de Linux Foundation. Platforma este poziționată ca o soluție universală dezvoltată de comunitate, nu legată de sisteme individuale și capabilă să funcționeze cu orice aplicație în orice mediu cloud. Codul Kubernetes este scris în Go și este distribuit sub licența Apache 2.0.

Ce este nou în Kubernetes 1.18?

Această nouă versiune a Kubernetes vine cu diverse îmbunătățiri pentru Kubectl, dintre care se menționează în anunț că a adăugat o versiune alfa a comenzii „kubectl debug”, ceea ce face mai ușoară depanarea în pod-uri atunci când rulează containere cu instrumente de depanare.

În timp ce comanda „Kubectl diff” a fost declarat stabil, care vă permite să vedeți ce se va schimba în cluster dacă aplicați manifestul.

de asemenea toți generatorii de comenzi „kubectl run” au fost eliminați, cu excepția pornirii generatorului de pod unic, plus indicatorul –Rezul uscat a fost schimbat, în funcție de valoarea acesteia (client, server și niciuna), executarea testului comenzii se face pe partea client sau server.

Codul kubectl este atribuit unui depozit separat. Acest lucru ne-a permis să separăm kubectl de dependențele interne de kubernetes și a facilitat importarea codului în proiecte terțe.

Cu privire la schimbări de rețea, se observă că suportul IPv6 este acum în versiune beta, a adăugat clonarea din PVC, posibilitatea blocării în rețea a dispozitivelor brute, cum ar fi discurile permanente, suport pentru blocarea dispozitivelor brute în CSI, transferul de informații despre unitatea care solicită conectarea unui disc la controlerul CSI, plus că s-a adăugat un nou câmp „imuabil” la obiectele ConfigMap și Secret.

Dintre celelalte schimbări care se remarcă:

  • Capacitatea de a utiliza grupul API depreciat / aplicațiile v1beta1 și extensiile / v1beta1 a fost în cele din urmă eliminată.
  • ServerSide Apply actualizat la starea beta2. Această îmbunătățire aduce manipularea obiectelor kubectl pe serverul API.
  • API CertificateSigningRequest declarat stabil.
  • Suport pentru platforma Windows.
  • Suportul nodurilor Windows continuă să se extindă
  • Suport CRI-ContainerD
  • Implementare RuntimeClass
  • proxy CSI
  • Sprijinul transferat a fost stabil
  • Cont de serviciu gestionat de grup
  • RunAsUserName
  • Managerul de topologie a primit statutul beta. Funcția include distribuția NUMA, care previne degradarea performanței pe sistemele cu mai multe prize.
  • Starea beta a fost obținută folosind funcția PodOverhead, care vă permite să specificați în RuntimeClass cantitatea suplimentară de resurse necesare pentru a porni casa.
  • Suport extins pentru pagini imense, starea de izolare alfa adăugată la container și suport pentru dimensiuni de pagini imense pe mai multe niveluri.
  • S-a adăugat câmpul AppProtocol unde puteți specifica ce protocol utilizează aplicația
  • Tradus în stare beta și activat implicit EndpointSlicesAPI, care este un înlocuitor mai funcțional pentru Endpoint-uri obișnuite.
  • S-a adăugat un obiect IngressClass, care indică numele controlerului de intrare, parametrii săi suplimentari și semnul pentru al utiliza în mod implicit.
  • S-a adăugat capacitatea de a specifica în HPA manifest gradul de agresivitate la schimbarea numărului de locuințe în funcțiune, adică atunci când încărcătura crește, începe imediat de N ori mai multe copii.

Lasă comentariul tău

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *

*

*

  1. Responsabil pentru date: Miguel Ángel Gatón
  2. Scopul datelor: Control SPAM, gestionarea comentariilor.
  3. Legitimare: consimțământul dvs.
  4. Comunicarea datelor: datele nu vor fi comunicate terților decât prin obligație legală.
  5. Stocarea datelor: bază de date găzduită de Occentus Networks (UE)
  6. Drepturi: în orice moment vă puteți limita, recupera și șterge informațiile.