Kubernetes utvecklingsteam har nyligen släppt genom ett tillkännagivande släppandet av den nya versionen "Kubernetes 1.18" där utvecklingsteamet nämner att det är en version 'fit and finish'.
I den här nya versionen betydande arbete har gjorts för att förbättra beta och stabil funktionalitet för att garantera en bättre användarupplevelse. En lika insats har gjorts för att lägga till ny utveckling och spännande nya funktioner som lovar att ytterligare förbättra användarupplevelsen.
För de som inte är medvetna om Kubernetes, de borde veta det är ett system med öppen källkod att automatisera implementering, skalning och hantering av containeriserade applikationer.
Det var ursprungligen designad av Google, även om dess utveckling sedan har anförtrotts Open Source Cloud Computing Foundation (CNCF), som idag har gjort det möjligt för containerorkestreringsteknik att mogna snabbt tack vare bidrag från teknikjättar.
Vad är nytt i Kubernetes 1.18?
Denna nya version sticker ut för att ha förmåga att använda servicekontotoken som en allmän autentiseringsmetod. Om du till exempel vill att en pod ska hantera andra Kubernetes-resurser, till exempel en distribution eller en tjänst, kan den associeras med ett servicekonto och skapa nödvändiga roller och rollbindningar.
Kubernetes servicekonton (KSAs) skickar JSON-webben-tokens (JWT) till API-servern för att autentisera. Detta gör API-servern till den enda autentiseringskällan för servicekonton.
Kubernetes 1.18 sger en funktionalitet que tillåter API-servern att tillhandahålla ett OpenID Connect-upptäcktdokument A som innehåller tokens offentliga nycklar förutom andra metadata.
En annan förändring som sticker ut från Kubernetes 1.81 är förmåga att konfigurera HPA Velocity för specifika kapslar. Horizontal Pod Autoscaler (HPA) användesa för att låta ett Kubernetes-kluster automatiskt svara på hög / låg trafik. Med HPA kan användaren be styrenheten att skapa fler moduler som svar på CPU-spikar, andra mätningar eller mätningar som tillhandahålls av applikationen.
Kubernetes 1.18 har en översikt över profiler för att köra flera konfigurationer av planeraren. Generellt finns det två typer av arbetsbelastningar i Kubernetes: långsiktiga tjänster (till exempel webbservrar, API, etc.) och uppgifter som körs till slutförande (bättre känt som namnet Jobb).
På grund av de uppenbara skillnaderna mellan arbetsbelastningstyper, använder vissa användare att skapa fullständiga kluster för olika behov. Till exempel ett kluster för att hantera datautvinning och ett annat för att betjäna applikations-API: er.
Anledningen är att de behöver olika beslutsprocesser. Till exempel främjar standardinställningarna för schemaläggare hög tillgänglighet.
Å andra sidan kan vi också hitta förmåga att definiera en podsändningsregel på klusternivå, som har gjort det möjligt att säkerställa att pods kommer att schemaläggas i tillgänglighetszoner (förutsatt att du använder ett kluster med flera zoner) för att säkerställa maximal tillgänglighet och resursutnyttjande.
Funktionaliteten möjliggör topologySpreadConstraints-specifikationen, som identifierar områden genom att söka efter noder med samma topologyKey-tagg. Noder med samma TopologyKey-tagg tillhör samma område. Konfigurationen var att fördela bälgen jämnt i de olika områdena. Nackdelen är dock att denna inställning måste tillämpas på podnivå. Pods som inte har konfigurationen kommer inte att fördelas jämnt över feldomäner.
Sist men inte minst, vi kan också hitta möjligheten att ignorera förändringen i volymegenskapen. Som standard, när en volym är monterad i en container i ett Kubernetes-kluster, har alla filer och kataloger inom den här volymen sin egendom ändrad till det värde som tillhandahålls via fsGroup.
Allt detta för att låta fsGroup läsa och skriva volymen. Detta beteende har dock visat sig vara oönskat i vissa fall.
Denna nya version av Kubernetes kommer med ett antal förändringar, och vi har bara nämnt några av de viktigaste. Om du vill veta hela listan kan du göra det genom att besöka följande länk.