Vad är nytt i Kubernetes v1.23?

0
138
Piotr Swat/Shutterstock.com< /figure>

Kubernetes v1.23 är den sista större utgåvan av 2021. Den senaste uppdateringen av den ledande containerorkestreringsplattformen främjar 11 funktioner till den stabila kanalen, vilket markerar dem som lämpliga för allmänt bruk. Här är vad du behöver veta innan du uppgraderar.

Dual-stack IPv4/IPv6 Networking

Dual-stack IPv4 /IPv6-nätverk är allmänt tillgängligt i v1.23. Funktionen gör det möjligt att tilldela en Pod eller tjänst både IPv4- och IPv6-adresser. Du behöver nätverksgränssnitt med dubbla stack på dina noder och en stödjande CNI-nätverksplugin för att detta ska fungera.

Fältet .spec.ipFamilyPolicy definierar om en Pod eller tjänst får ett enkel- eller dubbelstackgränssnitt. Ställ in den på PreferDualStack eller RequireDualStack för att aktivera dual-stack-stöd. Standard är SingleStack.

spec: ipFamilyPolicy: RequireDualStack

Dual-stack-lägen kommer att tilldela tjänstekluster-IP:er från både IPv4- och IPv6-adressutrymmena. Du kan ställa in stackpreferensordningen med fältet .spec.ipFamilies. Detta tillåter också att ange antingen IPv4 eller IPv6 som familjen för SingleStack-läget.

Ephemeral Volumes

Efemeriska volymer är en annan gradering till GA-status. En kortvarig volym är knuten till en Pod och raderas när Poden avslutas. Det fungerar med alla befintliga lagringsdrivrutiner som stöder dynamisk provisionering.

Annons

Efemära volymer skapas genom att kapsla en volymClaimMall under ett nytt tillfälligt fält i volymsektionen i en Pod-specifikation. VolumeClaimTemplate bör likna ett vanligt PersistentVolumeClaim.

spec: volymer: – namn: ephemeral-volume ephemeral: volumeClaimMall: metadata: etiketter: typ: exempel-volymtyp spec: accessModes: ["ReadWriteOnce"] storageClassName: exempel-lagringsklassresurser: requests: storage: 1Gi

Medan en “flyktig” volymen kan från början låta konstigt, det finns flera användningsfall för den här funktionen. Volymer används ofta för att tillhandahålla en Pods process med konfigurationsvärden för första körning som bara nås en gång. I det här scenariot är en tillfällig Pod idealisk eftersom den kommer att raderas när Pod stoppas, istället för att återkopplas till framtida Pods som aldrig kommer att använda data. Ett annat tänkbart fall är processer som cachelagrar stora mängder data men som inte behöver bevaras mellan individuella Pod-avslutningar.

Horizontal Pod Autoscaler v2< /h2>

Efter fem år har v2 av Horizontal Pod Autoscaler API nått stabil. Med automatisk skalning kan Kubernetes automatiskt justera replikantalet för dina distributioner, replicaSets och StatefulSets för att svara på ändringar i realtidsmätvärden.

Denna kampanj påverkar för närvarande inte den ursprungliga implementeringen av autoscaler. v1 API förblir användbar och fasas inte ut. Den nya autoscaling/v2 API tar över från autoscaling/v2beta2 från tidigare Kubernetes-utgåvor.

Att använda v2 API är fördelaktigt eftersom du kan definiera autoskalningsbeslut som är baserade på anpassade mätvärden. Autoscaler-styrenheten kommer att göra godtyckliga API-frågor för att informera replikaändringar, istället för att begränsa dig till nod-CPU och minnesförhållanden.

Hoppa över ändringar av volymägande vid Podstart

Att använda fsGroup-fältet på en volym för att definiera dess ägande gör för närvarande att Kubernetes rekursivt exekvera chown() och chmod() på volymens innehåll varje gång den monteras på en Pod. Detta kan vara ett betydande prestandaproblem när man arbetar med stora volymer som huvudsakligen består av små filer. Podden startar inte förrän behörigheterna har ändrats.

Annons

Kubernetes stöder ett fsGroupChangePolicy-fält som låter dig åsidosätta detta beteende. Den är nu allmänt tillgänglig via en Pod's securityContextfield. Att ställa in ändringspolicyn till OnRootMismatch kommer bara att anropa chown() om roten av volymen har felaktiga behörigheter. Detta påskyndar start av pod när behörigheter redan är kompatibla med fsGroup-deklarationen.

securityContext: fsGroupChangePolicy: OnRootMismatch

Övriga höjdpunkter

Det finns några anmärkningsvärda tillägg till alfa- och beta-API:erna. Betakanalen innehåller nu:

  • Strukturerad loggning – Fler komponenter stöder det strukturerade textloggningsformatet som producerar JSON-utdata. Strukturerade loggar är enklare att analysera av externa verktyg, vilket underlättar förenklad logginläsning och frågeprocesser.
  • PodSecurity API– PodSecurity ersätter den äldre PodSecurityPolicy-tillträdeskontrollanten som låter dig upprätthålla säkerhetsregler på namnområdesnivå. PodSecurity tillhandahåller en mekanism för att bestämma att Pods inte kan existera i ett namnområde om de saknar vissa säkerhetskontextskydd.
  • CSI-migreringsstöd– Den här funktionen ger ett sömlöst sätt att flytta från en lagringsdrivrutin i trädet som är en del av Kubernetes API, som kubernetes.io/aws-ebs, till en CSI-drivrutin som säljs. Användare bör inte märka några ändringar i sin lagring efter att migreringen är klar. Denna funktion är nu beta för AWS EBS, Azure Disk och GCE PD. Den är märkt alfa för Ceph RBD och Portworx.

Över i alfakanalen finns det några ytterligare funktioner som gör sin debut:

  • < strong>Verifiering av fält på serversidan– Validering av fält på serversidan skickar varningar från servern när en klient försöker skapa resurser som inkluderar okända eller duplicerade fält. Kubernetes har historiskt tagit bort dessa fält, vilket kan orsaka förvirrande beteende. Aktivering av ServerSideFeatureValidation-funktionsporten ger ett sätt att hantera detta.
  • Verifiering av uttrycksspråk för CRD:er – Ett nytt inline expression-språk underlättar validering av anpassade resursdefinitioner (CRD). Detta hjälper till att ta itu med den abstrakta karaktären hos CRD:er där användardefinierade resurser för närvarande inte kan garanteras att de respekterar kraven för befintliga kontroller och klientapplikationer.
  • Stöd för OpenAPI v3– OpenAPI v3 har lagts till bakom en funktionsgrind (OpenAPIV3). När den är aktiverad kan du begära OpenAPI v3.0-specifikationen för vilken som helst av Kubernetes-objekttyperna, vilket ger ett sätt att programmatiskt upptäcka och gå igenom resurser via öppna API-standarder.

Slutsats

Kubernetes v1.23 stabiliserar flera viktiga funktioner, inklusive nätverk med dubbla stack, den nya anpassningsbara Horizontal Pod Autoscaler och tillfälliga volymer för att arbeta med icke-kritisk data. Det finns dussintals andra ändringar också, vid sidan av två utfasningar: FlexVolume-lagringsdrivrutinens gränssnitt som är före CSI, och flera loggningsflaggor som kommer att tas bort i framtiden.

Totalt 11 befintliga funktioner har flyttats till GA-status. Ytterligare 17 funktioner är nu markerade som beta, medan ytterligare 19 är helt nya funktioner som landar i alfa. Kubernetes releasestrategi fokuserar på leveransfunktionalitet tidigt, gör det möjligt för communityn att vägleda dess utveckling och hjälpa till att effektivisera API-implementeringar. Även om alfa- eller betafunktioner vanligtvis går igenom till stabila, är detta inte garanterat. API:er kan ändras avsevärt eller tas bort helt under utvecklingsprocessen.

Du kan läsa hela versionskommentarerna för v1.23 på GitHub. Nedladdningar finns tillgängliga på releasesidan. Du kan uppgradera ett befintligt kluster som skapades med Kubeadm genom att följa anvisningarna i dokumenten. Processen kommer att skilja sig åt för användare av hanterade molnerbjudanden och Kubernetes-distributioner från tredje part.