Kubernetes utviklingsteam har nylig gitt ut gjennom en kunngjøring utgivelsen av den nye versjonen "Kubernetes 1.18" der utviklingsteamet nevner at det er en "passe og ferdig" versjon.
I denne nye versjonen betydelig arbeid er gjort for å forbedre beta og stabil funksjonalitet for å garantere en bedre brukeropplevelse. Det er gjort en like stor innsats for å legge til nye utviklingstrekk og spennende nye funksjoner som lover å ytterligere forbedre brukeropplevelsen.
For de som ikke er klar over Kubernetes, det burde de vite er et åpen kildekodesystem å automatisere distribusjon, skalering og styring av containeriserte applikasjoner.
Det var opprinnelig designet av Google, Selv om utviklingen senere er blitt betrodd Open Source Cloud Computing Foundation (CNCF), som i dag har tillatt containerorkestreringsteknologi å modnes raskt, takket være bidrag fra teknologigiganter.
Hva er nytt i Kubernetes 1.18?
Denne nye versjonen skiller seg ut for å ha muligheten til å bruke tjenestekontotokener som en generell autentiseringsmetode. For eksempel, hvis du vil at en pod skal administrere andre Kubernetes-ressurser, for eksempel en distribusjon eller en tjeneste, kan den knyttes til en tjenestekonto og opprette de nødvendige rollene og rollebindingene.
Kubernetes servicekontoer (KSAer) sender JSON web tokens (JWT) til API-serveren for å autentisere. Dette gjør API-serveren til den eneste kilden til autentisering for tjenestekontoer.
Kubernetes 1.18 sgir funksjonalitet que lar API-serveren levere et OpenID Connect-oppdagelsesdokument A som inneholder tokens offentlige nøkler i tillegg til andre metadata.
En annen endring som skiller seg ut fra Kubernetes 1.81 er muligheten til å konfigurere HPA Velocity for bestemte pods. Horizontal Pod Autoscaler (HPA) ble brukta for å la en Kubernetes-klynge automatisk svare på høy / lav trafikk. Med HPA kan brukeren be kontrolleren om å lage flere moduler som svar på CPU-pigger, andre målinger eller målinger som leveres av applikasjonen.
Kubernetes 1.18 har en oversikt over profiler for å kjøre flere konfigurasjoner av planleggeren. Generelt er det to typer arbeidsmengder i Kubernetes: langsiktige tjenester (for eksempel webservere, API-er osv.) Og oppgaver som kjører til fullføring (bedre kjent som navnet Jobs).
På grunn av de åpenbare forskjellene mellom arbeidsbelastningstyper, bruker noen brukere å lage fulle klynger for forskjellige behov. For eksempel en klynge for å administrere data mining og en annen for å betjene applikasjons-API-ene.
Årsaken er at de trenger beslutningsprosessen for å være annerledes. For eksempel fremmer standard planleggerinnstillinger høy tilgjengelighet.
På den annen side kan vi også finne evne til å definere en pod-kringkastingsregel på klyngenivå, som har gjort det mulig å sikre at pods blir planlagt i tilgjengelighetssoner (forutsatt at du bruker en klyngeserie med flere soner) for å sikre maksimal tilgjengelighet og ressursutnyttelse.
Funksjonaliteten muliggjør topologySpreadConstraints-spesifikasjonen, som identifiserer områder ved å søke etter noder med samme topologyKey-tag. Noder med samme TopologyKey-tag tilhører samme område. Konfigurasjonen var å fordele belgene jevnt i de forskjellige områdene. Ulempen er imidlertid at denne innstillingen må brukes på pod-nivå. Pods som ikke har konfigurasjonen, blir ikke jevnt fordelt på feildomener.
Sist men ikke minst, vi kan også finne muligheten til å ignorere endringen i volumegenskapen. Som standard, når et volum er montert i en container i en Kubernetes-klynge, har alle filer og kataloger i dette volumet sin egenskap endret til verdien som tilbys gjennom fsGroup.
Alt dette for å la fsGroup lese og skrive volumet. Imidlertid har denne oppførselen vist seg å være uønsket i noen tilfeller.
Denne nye versjonen av Kubernetes kommer med en rekke endringer, og vi har bare nevnt noen få av de viktigste. Hvis du vil vite hele listen, kan du gjøre det ved å gå til følgende lenke.