Kubernetes 1.18 er her, og det er dens forbedringer og nyheder

Kubernetes udviklingsteam har for nylig frigivet gennem en meddelelse frigivelsen af den nye version "Kubernetes 1.18" hvor udviklingsteamet nævner, at det er en 'fit and ready' version.

I denne nye version der er gjort et betydeligt arbejde for at forbedre beta og stabil funktionalitet at garantere en bedre brugeroplevelse. Der er gjort en lige indsats for at tilføje nye udviklinger og spændende nye funktioner, der lover at forbedre brugeroplevelsen yderligere.

For dem der ikke er opmærksomme på Kubernetes, de burde vide det er et open source-system til automatisering implementering, skalering og styring af containeriserede applikationer.

Fue oprindeligt designet af Google, skønt dens udvikling efterfølgende er blevet overdraget til Open Source Cloud Computing Foundation (CNCF), som i dag har tilladt containerorkestreringsteknologi at modnes hurtigt takket være bidrag fra teknologigiganter.

Hvad er nyt i Kubernetes 1.18?

Denne nye version skiller sig ud for at have evne til at bruge servicekontotokens som en generel godkendelsesmetode. For eksempel, hvis du vil have en pod til at administrere andre Kubernetes-ressourcer, såsom en implementering eller en tjeneste, kan den tilknyttes en servicekonto og oprette de nødvendige roller og rollebindinger.

Kubernetes servicekonti (KSA'er) sender JSON web-tokens (JWT) til API-serveren for at godkende. Dette gør API-serveren til den eneste kilde til godkendelse til servicekonti.

Kubernetes 1.18 sgiver en funktionalitet at tillader API-serveren at levere et OpenID Connect-opdagelsesdokument A, der indeholder tokens offentlige nøgler ud over andre metadata.

En anden ændring, der skiller sig ud fra Kubernetes 1.81, er evne til at konfigurere HPA Velocity til bestemte bælg. Horizontal Pod Autoscaler (HPA) blev anvendta for at lade en Kubernetes-klynge automatisk reagere på høj / lav trafik. Med HPA kan brugeren bede controlleren om at oprette flere moduler som reaktion på CPU-spidser, andre målinger eller målinger leveret af applikationen.

Kubernetes 1.18 har en oversigt over profiler til at køre flere konfigurationer af planlægger. Generelt er der to typer arbejdsbelastninger i Kubernetes: langsigtede tjenester (for eksempel webservere, API'er osv.) Og opgaver, der kører til færdiggørelse (bedre kendt som navnet Jobs).

På grund af de åbenlyse forskelle mellem arbejdsbelastningstyper bruger nogle brugere til at skabe fulde klynger til forskellige behov. For eksempel en klynge til at styre data mining og en anden til at betjene applikations-API'erne.

Årsagen er, at de har brug for beslutningsprocessen for at være forskellig. For eksempel fremmer standardplanlægningsindstillingerne høj tilgængelighed.

På den anden side kan vi også finde evne til at definere en podcast-regel på klyngeniveau, som har gjort det muligt at sikre, at bælg vil blive planlagt i Tilgængelighedszoner (så længe du bruger en klynge med flere zoner) for at sikre maksimal tilgængelighed og ressourceudnyttelse.

Funktionaliteten muliggør topologySpreadConstraints-specifikationen, som identificerer områder ved at søge efter noder med det samme topologyKey-tag. Noder med det samme TopologyKey-tag tilhører det samme område. Konfigurationen var at fordele bælgene jævnt i de forskellige områder. Ulempen er imidlertid, at denne indstilling skal anvendes på podniveau. Pods, der ikke har konfigurationen, fordeles ikke jævnt på fejldomæner.

Sidst men ikke mindst, Vi kan også finde muligheden for at ignorere ændringen i egenskaben volumen. Når en lydstyrke er monteret i en container i en Kubernetes-klynge, ændres som standard alle filer og kataloger inden for denne lydstyrke til den værdi, der leveres gennem fsGroup.

Alt dette for at give fsGroup mulighed for at læse og skrive diskenheden. Imidlertid har denne adfærd vist sig at være uønsket i nogle tilfælde.

Denne nye version af Kubernetes kommer med en række ændringer, og vi har kun nævnt nogle få af de vigtigste. Hvis du vil vide den komplette liste, kan du gøre det ved at besøge følgende link.


Vær den første til at kommentere

Efterlad din kommentar

Din e-mailadresse vil ikke blive offentliggjort. Obligatoriske felter er markeret med *

*

*

  1. Ansvarlig for dataene: Miguel Ángel Gatón
  2. Formålet med dataene: Control SPAM, management af kommentarer.
  3. Legitimering: Dit samtykke
  4. Kommunikation af dataene: Dataene vil ikke blive kommunikeret til tredjemand, undtagen ved juridisk forpligtelse.
  5. Datalagring: Database hostet af Occentus Networks (EU)
  6. Rettigheder: Du kan til enhver tid begrænse, gendanne og slette dine oplysninger.