Kubernetes 1.14: översikt över de viktigaste nyheterna

I natt ska släpps ännu en version av Kubernetes — 1.14. Enligt traditionen för vår blogg kommer vi att berätta om de viktigaste förändringarna i den nya versionen av denna fantastiska Open Source-produkt.

Informationen som användes för att förbereda detta material har tagits från tabellen för spårning av förbättringar i Kubernetes, CHANGELOG-1.14 och motsvarande issues, pull requests, Kubernetes Enhancement Proposals (KEP).

Låt oss börja med en viktig introduktion från SIG cluster-lifecycle: dynamiska felresistenta kluster Kubernetes (eller mer exakt, self-hosted HA implementations) kan nu skapas med hjälp av de vanliga (i kontexten av kluster med en nod) kommandona kubeadm (init och join). Sammanfattningsvis, för detta:

• de certifikat som klustret använder flyttas till hemligheter;
• för att möjliggöra användning av etcd-klustret inuti K8s-klustret (dvs. bli av med den externa beroendet som tidigare fanns) används etcd-operator;
• rekommenderade inställningar för den externa lastbalanseraren som säkerställer en felresistent konfiguration dokumenteras (möjlighet att bli av med detta beroende planeras senare, men inte vid denna tidpunkt).

Arkitekturen för HA-klustret Kubernetes, skapat med kubeadm

Detaljer om implementeringen finns i designförslaget. Denna funktion har verkligen varit efterlängtad: alfa-versionen förväntades redan i K8s 1.9, men kom först nu.

API

Team apply och överlag deklarativ hantering av objekt flyttas från kubectl i apiserver. Utvecklarna förklarar kortfattat sitt beslut med att kubectl apply — en fundamental del av arbetet med konfigurationer i Kubernetes, men "full av buggar och svår att åtgärda", varför denna funktionalitet måste bringas i ordning och flyttas till control plane. Enkla och tydliga exempel på existerande problem idag:

Detaljer om implementeringen finns i KEP. Nuvarande beredskap — alfa-version (övergång till beta planeras vid nästa release av Kubernetes).

I alfa-versionen har möjlighet att använda schemat OpenAPI v3 för att skapande och publicering av OpenAPI-dokumentation för CustomResources (CR) som används för validering (på serversidan) av K8s-resurser definierade av användaren (CustomResourceDefinition, CRD). Publicering av OpenAPI för CRD låter kunder (t.ex. ) utföra validering på sin sida (inom kubectlkubectl create ) och ge dokumentation om schemat ( och kubectl apply). För detaljer — sekubectl explainDe tidigare loggarna KEP.

öppnas nu O_APPEND med flaggan (och inte O_TRUNC O_TRUNC) för att undvika förlust av loggar i vissa situationer och för bekvämligheten av att trunkera loggar med externa verktyg för rotation.

I samband med Kubernetes API kan det också nämnas att i PodSandbox och PodSandboxStatus har lagts till fältet runtime_handler för att redovisa information om RuntimeClass i pod'en (läs mer om det i texten om Kubernetes version 1.12, där denna klass först dök upp som en alfa-version), samt i Admission Webhooks har möjligheten möjligheten att bestämma vilka versioner AdmissionReview de stödjer. Slutligen, i reglerna för Admission Webhooks kan nu begränsa omfattningen av deras tillämpning till namespaces och klustergränser.

Lagringssystem

BeständigaLokalaVolymer, som haft status som beta-versioner sedan releasen K8s 1.10, har förklarats stabila (GA): denna feature gate kan inte längre stängas av och kommer att tas bort i Kubernetes 1.17.

Möjlighet användningen av miljövariabler i så kallade Downward API (till exempel namnet på pod'en) för namn på kataloger som monteras som subPath, har fått utveckling — i form av ett nytt fält subPathExpr, med hjälp av vilket det nu bestäms vilket namn på katalogen som behövs. Ursprungligen kom funktionen i Kubernetes 1.11, men den var fortfarande i alfa-status för 1.14.

Som i den tidigare releasen av Kubernetes, finns många betydande förändringar presenterade för det aktivt utvecklade CSI (Container Storage Interface):

CSI

Har blivit tillgänglig (inom ramen för alfa-versionen) stöd för storleksändringar för CSI-volymer. För att använda den krävs det att feature gate vid namn ExpandCSIVolumes, samt stöd för denna operation i specifik CSI-drivrutin.

En annan funktion för CSI i alfa-versionen — att att direkt referera (dvs. utan att använda PV/PVC) till CSI-volymer inom specifikationen för pod'ar. Detta tar bort begränsningen att använda CSI som uteslutande fjärrlagringslösningar, och öppnar dörrarna för dem till världen av lokala ephemeral volymer.För att använda (exempel från dokumentationen) krävs det att CSIInlineVolume feature gate är aktiverat.

Det har skett framsteg också inom "inuti" Kubernetes, relaterat till CSI, som inte är så märkbara för slutanvändarna (systemadministratörerna)… För närvarande tvingas utvecklarna att stödja två versioner av varje lagringsplugin: en - "på det gamla sättet", inuti kodbasen K8s (in-tree), och den andra - inom ramen för den nya CSI (läs mer om det till exempel i här). Detta medför förståeliga olägenheter som måste åtgärdas allteftersom CSI stabiliseras. Att bara deklarera de inbyggda (in-tree) plugin-API:erna som föråldrade (deprecated) är inte möjligt på grund av den relevanta Kubernetes-policyn.

Allt detta har lett till att alfa-versionerna har nått migrationsprocessen inre kod för plugins, implementerat som in-tree, i CSI-plugins, vilket innebär att utvecklarnas bekymmer kommer att reduceras till att stödja en version av sina plugins, medan kompatibiliteten med gamla API:er bevaras och de kan deklareras som föråldrade enligt det vanliga scenariot. Det förväntas att migrationen av alla plugins från molnleverantörer kommer att genomföras till nästa Kubernetes-version (1.15), implementeringen kommer att få beta-status och aktiveras i K8s-installationer som standard. Se mer information i designförslaget. Följden av denna migration har också blivit avskaffande från begränsningar för volymer definierade av specifika molnleverantörer (AWS, Azure, GCE, Cinder).

Dessutom kommer stöd för blockenheter med CSI (CSIBlockVolume) har förts till beta-version.

Noder / Kubelet

En alfa-version har presenterats av en ny endpoint i Kubelet, avsedd för att returnera mätvärden för grundläggande resurser. Generellt, tidigare fick Kubelet statistik om användningen av containrar från cAdvisor, men nu kommer dessa data från körmiljön för containern via CRI (Container Runtime Interface), men kompatibiliteten för att arbeta med gamla versioner av Docker har bevarats. Tidigare levererades den statistik som samlades in i Kubelet via REST API, men nu används en endpoint som ligger på adressen /metrics/resource/v1alpha1. Utvecklarnas långsiktiga strategi består är att minimera uppsättningen av mätvärden som tillhandahålls av Kubelet. Förresten, dessa mätvärden kallas nu inte "core metrics", utan "resource metrics", och beskriver som "first-class resources, such as cpu, and memory".

Ett intressant faktum: trots den uppenbara prestandafördelen med gRPC-endpointen jämfört med olika användningsfall för Prometheus-formatet (resultatet av en av benchmarkarna se nedan), föredrog författarna textformatet från Prometheus på grund av det uppenbara ledarskapet för detta övervakningssystem i samhället.

"gRPC är inkompatibelt med de viktigaste övervakningspipelinerna. Endpointen kommer dock att vara användbar endast för att leverera mätvärden till Metrics Server eller övervakningskomponenter som integreras direkt med den. Vid användning av caching i Metrics Server är prestandan för textformatet från Prometheus tillräckligt bra för oss att föredra Prometheus framför gRPC, med tanke på den breda spridningen av Prometheus i gemenskapen. När OpenMetrics-formatet blir mer stabilt kan vi närma oss gRPC:s prestanda med ett protobaserat format.

Ett av de jämförande prestandatesterna av användning av gRPC- och Prometheus-formaten i den nya endpointen Kubelet för metrik. Fler diagram och andra detaljer kan hittas i KEP.

Bland andra förändringar:

• Kubelet försöker nu (en gång) stoppa behållare i okänt tillstånd innan omstart- och borttagningsoperationer.
• När du använder PodPresets har nu init-behållare detta ytterligare sökväg samma information som en vanlig behållare.
• Kubelet började använda usageNanoCores från CRI-statistikleverantören, och för noder och behållare i Windows har lagts till nätverksstatistik.
• Information om operativsystem och arkitektur skrivs nu till etiketter kubernetes.io/os och kubernetes.io/arch för Node-objekt (översatt från beta till GA).
• Möjligheten att ange en specifik systemanvändargrupp för behållare i podden (RunAsGroup) introducerades i K8s 1.11) har avancerat till beta-version (aktiverad som standard).
• du och find som används i cAdvisor, har ersatts med Go-implementationer.

CLI

I cli-runtime och kubectl tillagd flaggan -k för integration med kustomize (för övrigt, dess utveckling pågår nu i ett separat arkiv), det vill säga för hantering av ytterligare YAML-filer från särskilda direktingar för kustomization (mer om deras användning finns i KEP):

Exempel på enkel användning av filen kustomization (även mer avancerad tillämpning av kustomize inom ramen för överlagringar)

Dessutom:

• Tillagd det nya kommandot kubectl create cronjob, ett namn som talar för sig självt.
• I kubectl logs användas kombinera flaggor -f (--follow för loggstreaming) och -l (--selector för etikettfrågor).
• kubectl har lärt sig kopiera filer som väljs med hjälp av wild card.
• I teamet kubectl wait lagt till flagga --all för att välja alla resurser i det angivna typens resursnamn.

Andra

Stabil (GA) status har beviljats följande funktioner:

• ReadinessGate, som används i pod-specifikationen för att definiera ytterligare villkor som beaktas i podens beredskap;
• Stöd för stora sidor (funktionsport under namnet HugePages);
• CustomPodDNS;
• PriorityClass API, Pod Priority & Preemption.

Övriga förändringar presenterade i Kubernetes 1.14:

• RBAC-policyn ger som standard inte längre tillgång till API discovery och access-review användare utan autentisering (unauthenticated).
• Officiellt stöd för CoreDNS tillhandahålls. endast för Linux, så när du använder kubeadm för att distribuera den (CoreDNS) i klustret måste noderna fungera endast i Linux (för denna begränsning används nodeSelectors).
• CoreDNS-konfigurationen är nu som standard använder plugin forward istället för proxy. Dessutom har CoreDNS har lagts till readinessProbe, som förhindrar lastbalansering på de relevanta (inte redo för service) podarna.
• I kubeadm, under faserna init eller upload-certs, har det blivit möjligt att ladda upp certifikat som krävs för att ansluta en ny control-plane till kubeadm-certs hemlighet (använder flaggan --experimental-upload-certs).
• För Windows-installationer har en alfa-version blivit tillgänglig stöd för gMSA (Group Managed Service Account) – speciella konton i Active Directory som kan användas av containrar.
• För GCE aktiverades mTLS-kryptering mellan etcd och kube-apiserver.
• Uppdateringar i den använda/beroende programvaran: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, stöd för Docker 18.09 i kubeadm, och den minimi stödda versionen av Docker API blev 1.26.

P.S.

Läs även i vår blogg:

• «Kubernetes 1.12: översikt över huvudnyheterna»;
• «🥇Kubernetes 1.16: översikt över huvudnyheterna | ProHoster»;
• «Kubernetes 1.11: översikt över de viktigaste nyheterna»;
• «Kubernetes 1.10: översikt över de viktigaste nyheterna».

Källa: habr.com