Kubernetes 1.14: översikt över de viktigaste nyheterna

I natt ska kom ytterligare en version av Kubernetes — 1.14. Enligt traditionen för vår blogg informerar vi 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 relaterade frågor, 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 deployments) 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:

• certifikaten som används av klustret överförs till hemligheter;
• för att göra det möjligt att använda etcd-klustret inom K8s-klustret (d.v.s. eliminera den tidigare externa beroendet) har etcd-operator;
• rekommenderade inställningar för en extern lastbalanserare som säkerställer en felresistent konfiguration dokumenterats (det planeras en framtida möjlighet att avskaffa denna beroende också, men inte i detta skede).

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

För detaljer kring implementeringen kan du läsa i design proposal. Den här funktionen har verkligen varit efterlängtad: alfa-versionen förväntades redan under K8s 1.9, men dök först upp nu.

API

Team apply och överhuvudtaget deklarativ hantering av objekt flyttas från kubectl i apiserver. Utvecklarna förklarar kortfattat sitt beslut med att kubectl apply — en grundläggande del av arbetet med konfigurationer i Kubernetes, men "full av buggar och svårt att fixa", vilket innebär att denna funktion behöver göras mer stabil och flyttas till control plane. Enkla och tydliga exempel på nuvarande problem är:

Detaljer om implementeringen finns i KEP. Nuvarande beredskap — alfa-version (uppgradering till beta planeras till nästa Kubernetes-version).

I alfa-versionen blev det tillgängligt att att använda OpenAPI v3 schemat för skapande och publicering av OpenAPI-dokumentation för CustomResources (CR), som används för validering (på serversidan) av användardefinierade resurser i K8s (CustomResourceDefinition, CRD). Publicering av OpenAPI för CRD gör det möjligt för klienter (t.ex. kubectl) att utföra validering på sin sida (inom kubectl create och kubectl apply) och tillhandahålla dokumentation för schemat (kubectl explain). För mer information — se KEP.

De tidigare loggarna kan nu öppnas med flaggan O_APPEND (inte O_TRUNC) för att undvika förlust av loggar i vissa situationer och för bekvämlighet vid trimming av loggar med externa verktyg för rotation.

I samband med Kubernetes API kan vi också notera att i PodSandbox och PodSandboxStatus har lagts till fältet runtime_handler för att ta hänsyn till information om RuntimeClass i podden (läs mer om det i texten om Kubernetes release 1.12, där denna klass först introducerades som en alfa-version), och i Admission Webhooks har möjligheten möjligheten att definiera vilka versioner AdmissionReview de stöder. Slutligen kan vi nu i reglerna för Admission Webhooks begränsa omfånget av deras tillämpning via namespaces och klustergränser.

Lagringar

BeständigaLokalaVolymer, som hade status som beta-versioner sedan releasen K8s 1.10, har proklamerats stabila (GA): denna feature gate inaktiveras inte längre och kommer att tas bort i Kubernetes 1.17.

Möjlighet användning av miljövariabler kallad Downward API (till exempel, namnet på podden) för namn på kataloger som monteras som subPath, har utvecklats — i form av ett nytt fält subPathExpr, vilket nu används för att bestämma rätt katalognamn. Funktionen introducerades först i Kubernetes 1.11, men för 1.14 förblev det i alfa-version.

Som i den tidigare Kubernetes-versionen presenteras många betydande förändringar för det aktivt utvecklade CSI (Container Storage Interface):

CSI

Stora tillgängligheter (i alfa-version) stöd för storleksändringar för CSI-volymer. För att använda det krävs det att du aktiverar feature gate som kallas ExpandCSIVolumes, samt att den specifika CSI-drivrutinen har stöd för denna operation.

En annan funktion för CSI i alfa-version — att att direkt referera till (dvs. utan att använda PV/PVC) CSI-volymer i pod-specifikationen. Detta tar bort begränsningen av att använda CSI enbart för fjärrlagringslösningar, vilket öppnar dörrar till lokala temporära volymer.För att använda (exempel från dokumentationen) måste du aktivera CSIInlineVolume feature gate.

Det har också skett framsteg i "interiören" av Kubernetes, kopplat till CSI, som inte är så märkbara för slutanvändare (systemadministratörer)… För närvarande måste utvecklarna underhålla två versioner av varje lagringsplugin: en – "den gamla stilen", inuti K8s kodbas (in-tree), och den andra – inom det nya CSI läs mer om det, till exempel, i här). Detta orsakar förståeliga besvär som måste åtgärdas allteftersom CSI stabiliseras i sig. Att bara deklarera inre (in-tree) pluginers API:er som föråldrade (deprecated) är inte möjligt på grund av den aktuella Kubernetes-policyn.

Allt detta har lett till att alfa-versionerna nått migreringsprocessen den interna koden för plugins, implementerade som in-tree och i CSI-plugins, vilket innebär att utvecklarnas bekymmer minskas till att stödja en version av sina plugins, samtidigt som kompatibiliteten med äldre API:er bibehålls och de kan aviseras som föråldrade enligt det vanliga scenariot. Det förväntas att alla cloudprovider-plugins migreras till nästa Kubernetes-version (1.15), implementeringen kommer att få beta-status och aktiveras i K8s-installationer som standard. Se detaljer i design proposal. Följden av denna migration har också varit avskaffande från begränsningarna för volymer som definieras av specifika cloud providers (AWS, Azure, GCE, Cinder).

Dessutom stöds blockenheter med CSI (CSIBlockVolume) överfört till beta-version.

Noder / Kubelet

En alfa-version har presenterats av den nya slutpunkten i Kubelet, avsedd för att tillhandahålla mätvärden för grundläggande resurser. Generellt sett, om tidigare Kubelet fick statistik om containeranvändning från cAdvisor, kommer dessa data nu från containermiljön via CRI (Container Runtime Interface), men kompatibiliteten för att fungera med äldre versioner av Docker har bibehållits. Tidigare överfördes den statistik som samlades i Kubelet via REST API, och nu används en slutpunkt som är belägen på adressen /metrics/resource/v1alpha1. Utvecklarnas långsiktiga strategi består är att minimera uppsättningen av de mätvärden som Kubelet tillhandahåller. För övrigt kallas dessa mätvärden numera inte "core metrics", utan "resource metrics", och beskrivs som "first-class resources, such as cpu, and memory".

En intressant detalj: trots den tydliga prestandafördelen med gRPC-slutpunkten i jämförelse med olika användningsfall av Prometheus-formatet (resultatet av en av benchmarkarna se nedan), föredrog författarna det textbaserade formatet av Prometheus på grund av det tydliga ledarskapet hos detta övervakningssystem i communityt.

"gRPC är inte kompatibelt med de huvudsakliga övervakningspipelines. Slutpunkten 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 det textbaserade formatet av Prometheus tillräckligt bra för oss att föredra Prometheus framför gRPC, med tanke på den breda spridningen av Prometheus inom gemenskapen. När OpenMetrics-formatet blir mer stabilt kan vi närma oss gRPC:s prestanda med ett proto-baserat format.

Ett av jämförelsetesterna för prestanda mellan gRPC- och Prometheus-format i den nya Kubelet-endpointen för mätvärden. Fler diagram och andra detaljer finns i KEP.

Bland andra förändringar:

• Kubelet försöker nu (en gång) stoppa behållare i okänt tillstånd innan omsstart och borttagning.
• När du använder PodPresets nu till init-behållare detta ytterligare sökväg samma information som en vanlig behållare.
• Kubelet har börjat 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 registreras nu i etiketterna kubernetes.io/os och kubernetes.io/arch för Node-objekt (översatt från beta till GA).
• Möjligheten att ange en specifik systemgrupp av användare för behållare i podden (RunAsGroup, introducerades i K8s 1.11) förflyttades 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 sker nu i ett eget arkiv), det vill säga för att bearbeta ytterligare YAML-filer från speciella kustomization-kataloger (detaljer om deras användning finns i KEP):

Exempel på enkel användning av filen kustomization (möjligtvis mer komplexa tillämpningar av kustomize inom överlagringar)

Dessutom:

• Tillagd det nya kommandot kubectl create cronjob, vars namn talar för sig självt.
• I kubectl logs användas kombinera flaggor -f (--follow för att strömma loggar) och -l (--selector för etikettsökning).
• kubectl lärde sig kopiera filer som väljs med hjälp av wildcard.
• I teamet kubectl wait lagt till flagga --all för att välja alla resurser i det angivna resurstypnamnet.

Andra

Stabil (GA) status har fått 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 för kallad HugePages);
• CustomPodDNS;
• PriorityClass API, Pod Priority & Preemption.

Andra förändringar presenterade i Kubernetes 1.14:

• RBAC-policyerna ger inte längre åtkomst till API:n discovery och access-review för 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 (nodeSelectors används för att implementera denna begränsning).
• CoreDNS-konfigurationen som standard är nu använder forward-plugin istället för proxy. Dessutom har CoreDNS har lagts till readinessProbe, som hindrar lastbalansering till lämpliga (inte klara för service) poddar.
• I kubeadm, under faserna init eller upload-certs, har det blivit möjligt att ladda upp certifikat som krävs för att ansluta den nya control-plane till kubeadm-certs hemligheten (flaggan --experimental-upload-certs).
• Det finns en alpha-version för Windows-installationer stöd för gMSA (Group Managed Service Account) - speciella konton i Active Directory som kan användas av containrar.
• För GCE har aktiverats 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 huvudnyheterna»;
• «Kubernetes 1.10: översikt över huvudnyheterna».

Källa: habr.com