I dag, onsdag, er det endnu en udgave af Kubernetes — 1.16. I tråd med traditionen for vores blog, fortæller vi nu for tiende gang om de mest markante ændringer i den nye version.
Oplysningerne, der er brugt til at forberede dette materiale, er taget fra , og de tilsvarende issues, pull requests samt Kubernetes Enhancement Proposals (KEP). Så lad os komme i gang! ..
Noder
Et virkelig stort antal markante nyheder (i alfa-status) præsenteres på node-siden af K8s-klyngerne (Kubelet).
For det første er der introduceret de såkaldte «» (Ephemeral Containers), der skal forenkle fejlfindingsprocesserne i pods. Den nye mekanisme giver mulighed for at starte specielle containere, der kører i navnerummet af eksisterende pods og kun lever i en kort periode. Deres formål er at interagere med andre pods og containere for at løse problemer og foretage fejlfinding. Der er implementeret en ny kommando kubectl debug, som minder om kubectl exec: men i stedet for at starte en proces i containeren (som i tilfældet med exec) starter den en container i pod'en. For eksempel vil en sådan kommando tilslutte en ny container til pod'en:
kubectl debug -c debug-shell --image=debian target-pod -- bashDetaljer om de efemeriske containere (og eksempler på deres anvendelse) kan findes i . Den nuværende implementering (i K8s 1.16) er i alfa-version, og blandt kriterierne for overgangen til beta-versionen er 'test af Ephemeral Containers API i mindst 2 udgivelser [Kubernetes]'.
NB: I sin essens og endda navn minder funktionen om den eksisterende plugin , which we . Det antages, at med introduktionen af de efemeriske containere vil udviklingen af en separat ekstern plugin stoppe.
En anden nyhed er , der skal give en mekanisme til beregning af overhead for pods, som kan variere betydeligt alt efter den anvendte runtime-miljø. Som eksempel nævner forfatterne Kata Containers, som kræver kørsel af et gæste-kerne, kata-agent, init-system og så videre. Når overheadet bliver så stort, at det ikke kan ignoreres, kræves der en måde at tage det i betragtning ved senere kvotering, planlægning osv. For at implementere dette er der tilføjet et felt PodSpec Overhead *ResourceList (svarer til data i , hvis sådanne bruges). RuntimeClassEndnu en markant nyhed er
node topologi manager node topology manager (Node Topology Manager), designet til at forene tilgangen til finjustering af fordelingen af hardware ressourcer til forskellige komponenter i Kubernetes. Denne initiativ er drevet af det stigende behov fra forskellige moderne systemer (inden for telekommunikation, maskinlæring, finansielle tjenesteydelser mv.) for højtydende parallelle beregninger og minimering af forsinkelser under udførelsen af operationer, for hvilket de bruger avancerede CPU-funktioner og hardwareacceleration. Sådanne optimeringer i Kubernetes er hidtil blevet opnået gennem disparate komponenter (CPU-manager, enhedsmanager, CNI), men nu vil de få et ensartet internt interface, der forener tilgangen og forenkler tilslutningen af nye tilsvarende — såkaldte topology-aware — komponenter på Kubelet-siden. Detaljer findes i .
Topology Manager komponenters skema
Den næste funktion er kontroller af containere under opstart (). Som bekendt er det vanskeligt for containere, der starter langsomt, at få den aktuelle status: de bliver enten 'dræbt' før de reelt begynder at fungere, eller de havner i deadlock i lang tid. Den nye kontrol (aktiveres gennem funktionens gate navngivet StartupProbeEnabled) annullerer — nærmere bestemt, udsætter — effekten af eventuelle andre kontroller, indtil pod'en er færdig med sin opstart. Af denne grund blev funktionen oprindeligt kaldt . For pod'er, der starter langsomt, kan tilstande forespørges i relativt korte tidsintervaller.
Derudover præsenteres straks i beta-versionen en forbedring for RuntimeClass, der tilføjer støtte til 'heterogene klynger'. C er det nu slet ikke nødvendigt, at hver node har understøttelse af hver enkelt RuntimeClass: for pod'er kan der vælges RuntimeClass uden at tænke over klyngets topologi. Tidligere blev der for at opnå dette — for at sikre, at pod'er havnede på noder med support for alt, hvad de har brug for — tildelt tilsvarende regler til NodeSelector og tolerationer. I gives der eksempler på brug og selvfølgelig detaljerne om implementeringen.
Netværk
To væsentlige netværksfunktioner, der første gang dukkede op (i alpha-versionen) i Kubernetes 1.16 — er:
- dobbelt netværksstak — IPv4/IPv6 — og den tilsvarende «forståelse» på niveauet af pod’er, noder, tjenester. Den omfatter interaktion mellem IPv4-to-IPv4 og IPv6-to-IPv6 mellem pod’er, fra pod’er til eksterne tjenester, referenceimplementeringer (som en del af Bridge CNI, PTP CNI og Host-Local IPAM plugins), samt bagudkompatibilitet med Kubernetes-klynger, der kun kører på IPv4 eller IPv6. Implementeringsdetaljer findes i .
Eksempel på output af IP-adresser af to typer (IPv4 og IPv6) i listen over pod’er:
kube-master# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE nginx-controller 1/1 Running 0 20m fd00:db8:1::2,192.168.1.3 kube-minion-1 kube-master# - Ny API til Endpoint — . Det løser de eksisterende problemer i Endpoint API med hensyn til ydeevne/skalerbarhed, som påvirker forskellige komponenter i kontrolplanet (apiserver, etcd, endpoints-controller, kube-proxy). Den nye API vil blive tilføjet til API-gruppen Discovery og vil være i stand til at betjene titusinde backend-endpoints på hver tjeneste i en klynge bestående af tusindvis af noder. Til dette vil hver Service blive vist som N objekter
EndpointSlice, hver af dem har som standard ikke mere end 100 endpoints (værdien kan konfigureres). I EndpointSlice API vil der også være muligheder for fremtidig udvikling: støtte til mange IP-adresser for hver pod, nye tilstande for endpoints (ikke kunKlarogNotReady), dynamisk underdeling for endpoints.
Fremdriften til beta-versionen har nået den, der blev præsenteret i den seneste udgivelse , kaldet service.kubernetes.io/load-balancer-cleanup og knyttet til hver service af typen LoadBalancer. Ved sletning af en sådan service forhindrer det faktisk sletningen af ressourcen, indtil «oprydningen» af alle tilknyttede load balancer-ressourcer er fuldført.
API Machinery
Den virkelige «milepæl for stabilisering» er registreret inden for API-serveren i Kubernetes og interaktionen med den. Dette er i høj grad sket takket være overgangen til status stable af dem, der ikke kræver særlig repræsentation (CRD), som har haft beta-status siden det fjerne Kubernetes 1.7 (som var i juni 2017!). Den samme stabilisering er også kommet til de relaterede funktioner:
- med
/statusog/scalefor CustomResources; - versioner for CRD, baseret på en ekstern webhook;
- (i K8s 1.15) standardværdier (defaulting) og automatisk sletning af felter (pruning) for CustomResources;
- anvendelse af OpenAPI v3-schemaet til at skabe og offentliggøre OpenAPI-dokumentation, der anvendes til validering af CRD-ressourcer på serversiden.
Endnu en mekanisme, der længe har været almindelig for Kubernetes-administratorer: — har også længe været i beta-status (siden K8s 1.9) og er nu erklæret stabil.
To andre funktioner er nået beta-version: og .
Og den eneste betydelige nyhed i alpha-versionen blev fra SelfLink — en særlig URI, der repræsenterer det angivne objekt og er en del af ObjectMeta og ListMeta (dvs. en del af ethvert objekt i Kubernetes). Hvorfor bliver det afskaffet? Motivation "enkelt" som manglen på reelle (uoverstigelige) grunde til, at dette felt fortsat eksisterer. Mere formelle grunde — at optimere ydeevnen (ved at fjerne unødvendigt felt) og forenkle arbejdet for generic-apiserver, som er nødt til at behandle et sådant felt på en særskilt måde (det er det eneste felt, der sættes lige før objektets serialisering). Den reelle "afskrivning" (indtil beta-versionen) SelfLink vil finde sted i Kubernetes version 1.20, mens den endelige — 1.21.
Dataopbevaring
Det primære arbejde inden for storage, ligesom i tidligere versioner, ses i området . De vigtigste ændringer her blev:
- for første gang (i alpha-versionen) understøttelse af CSI-plugins til worker nodes med Windows: den aktuelle metode til at arbejde med lagringsløsninger her vil erstatte in-tree plugins i Kubernetes-kernen og Microsofts FlexVolume-plugins baseret på Powershell;
Implementeringsskemaet for CSI-plugins i Kubernetes til Windows - mulighed , præsenteret første gang i K8s 1.12, er vokset til beta-version;
- en tilsvarende "opgradering" (fra alpha- til beta-version) er opnået af muligheden for at bruge CSI til oprettelsen af lokale ephemeral volumener ().
Funktionen til kloning af volumener, der opstod i den tidligere version af Kubernetes DataSource til at oprette nye PVC) har også nu opnået beta-status. To bemærkelsesværdige ændringer i planlægningen (begge i alpha-version):
Scheduler
EvenPodsSpreading
- for at bruge pods i stedet for logiske enheder af applikationen til "retfærdig fordeling" af belastninger (som Deployment og ReplicaSet) og justering af denne fordeling (som et strengt krav eller som en blød betingelse, dvs. prioritet). Funktionen vil udvide de eksisterende muligheder for fordeling af planlagte pods, som i øjeblikket er begrænset af indstillingerne PodAffinity
PodAntiAffinityogPodAntiAffinity, som giver administratorer en mere finmasket kontrol over dette emne, hvilket betyder bedre høj tilgængelighed og optimeret ressourceforbrug. Mere information findes i . - Brugen af BestFit-politik i RequestedToCapacityRatio-prioritetsfunktion , når der planlægges pod'er, hvilket muliggør at anvende ('container-pakning') både for grundlæggende ressourcer (CPU, hukommelse) og udvidede (som GPU). Se nærmere i .
Planlægning af pod'er: før brugen af best fit-politikken (direkte via standardplanlæggeren) og med dens brug (gennem scheduler extender)
Derudover, muligheden for at oprette egne plugins til planlæggeren uden for hovedudviklingsrækken af Kubernetes (out-of-tree).
Andre ændringer
I Kubernetes 1.16-udgivelsen kan man også bemærke initiativet til de eksisterende metrics på linje, eller mere præcist — i overensstemmelse med for K8s-instrumentering. De bygger stort set på den relevante Inkonsekvenser opstod af forskellige årsager (for eksempel blev nogle metrics simpelthen oprettet, før de nuværende instrukser blev offentliggjort), og udviklerne mente, at tiden var inde til at bringe alt til én standard, 'i overensstemmelse med resten af Prometheus-økosystemet'. Den nuværende implementering af dette initiativ har status som alpha-version, som gradvist vil blive opgraderet i de følgende versioner af Kubernetes til beta (1.17) og stabil (1.18).
Derudover kan man bemærke følgende ændringer:
- Udviklingen af Windows-support med for Kubeadm-værktøjet til dette OS (alpha-version),
RunAsUserNamefor Windows-containere (alpha-version), støtte til Group Managed Service Account (gMSA) til beta-version, mount/attach for vSphere-volumener. - mekanisme til datakomprimering i API-svarene.Tidligere blev der brugt en HTTP-filter til dette formål, hvilket medførte en række begrænsninger, der forhindrede, at det kunne være aktiveret som standard. Nu fungerer 'transparent forespørgselskomprimering': kunder, der sender
Accept-Encoding: gzipi headeren, modtager et komprimeret GZIP-svar, hvis dets størrelse oversteg 128 Kb. Kunder på Go understøtter automatisk komprimering (sender den nødvendige header), så de vil straks bemærke en reduktion i trafikken. (For andre sprog kan der være behov for små modifikationer.) - at skalere HPA fra/til nul pod'er baseret på eksterne metrics.. Hvis skaleringen foregår på grundlag af objekter/eksterne metrikker, kan der, når arbejdsbyrder er inaktive, automatisk skaleres ned til 0 replikaer for at spare ressourcer. Denne funktion bør være særligt nyttig i tilfælde, hvor arbejdere anmoder om GPU-ressourcer, og antallet af forskellige typer inaktive arbejdere overstiger antallet af tilgængelige GPU'er.
- Ny kunde — — til «generel» adgang til objekter. Den er designet til nemt at hente metadata (dvs. underafdeling
metadata) fra klyngens ressourcer og udføre operationer som affaldssamling og kvotering. - Indsamle Kubernetes uden forældede («indbyggede» i in-tree) cloududbydere (alphaversion).
- I kubeadm-værktøjet den eksperimentelle (alphaversion) mulighed for at anvende kustomize patches under
init,sammenføjeogopgraderinger. Læs mere om brugen af flaget--experimental-kustomize, se i . - Ny endpoint for apiserver — , — der muliggør eksport af information om dens klarhed (readiness). Apiserver har også fået et flag
--maximum-startup-sequence-duration, som gør det muligt at regulere dens genstart. - To funktioner for Azure er blevet erklæret stabile: understøttelse af (Availability Zones) og (RG). Derudover er der tilføjet i Azure:
- AAD og ADFS;
-
service.beta.kubernetes.io/azure-pip-nametil angivelse af offentlig IP for belastningsaflastningsbalanceren; - indstillinger
LoadBalancerNameogLoadBalancerResourceGroup.
- AWS har fået til EBS i Windows og API-opkald til EC2
DescribeInstances. - Kubeadm migrerer nu automatisk Binære filer
- etcd i den relevante Docker-container er blevet ophørt med Cluster Autoscaler 1.16.0
- I Opdateringer i det anvendte/afhængige software: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.
- Kubernetes 1.15: oversigt over de vigtigste nyheder
P.S.
Læs også på vores blog:
- «»;
- «»;
- «»;
- «».
Kilde: habr.com
