Denna kväll nästa utgåva av Kubernetes - . Enligt traditionen som har utvecklats för vår blogg, pratar vi om de viktigaste förändringarna i den nya versionen av denna underbara Open Source-produkt.
Information som används för att förbereda detta material är hämtad från , och relaterade frågor, pull-förfrågningar, Kubernetes Enhancement Proposals (KEP).
Låt oss börja med en viktig introduktion från SIG kluster-livscykel: dynamiska failover-kluster Kubernetes (eller för att vara mer exakt, HA-distributioner med egen värd) är nu med hjälp av välbekanta (i samband med ennodkluster) kommandon kubeadm (init и join). Kort sagt, för detta:
- certifikat som används av klustret överförs till hemligheter;
- för möjligheten att använda etcd-klustret inuti K8s-klustret (dvs att bli av med det tidigare existerande externa beroendet) ;
- Dokumenterar de rekommenderade inställningarna för en extern lastbalanserare som ger en feltolerant konfiguration (i framtiden är det planerat att eliminera detta beroende, men inte i detta skede).
Arkitektur av ett Kubernetes HA-kluster skapat med kubeadm
Detaljer om implementeringen finns i . Denna funktion var verkligen efterlängtad: alfaversionen väntades tillbaka i K8s 1.9, men dök upp först nu.
API
Team apply och generellt sett deklarativ objekthantering av kubectl i apiserver. Utvecklarna själva förklarar kort sitt beslut genom att säga det kubectl apply - en grundläggande del av att arbeta med konfigurationer i Kubernetes, dock "den är full av buggar och svår att fixa," och därför måste denna funktionalitet återställas till det normala och överföras till kontrollplanet. Enkla och tydliga exempel på problem som finns idag:
Detaljer om implementeringen finns . Nuvarande beredskap är alfa (befordran till beta är planerad till nästa Kubernetes-släpp).
Tillgänglig i alfaversion använder OpenAPI v3-schemat för skapa och publicera OpenAPI-dokumentation för CustomResources (CR) används för att validera (serversidan) K8s användardefinierade resurser (CustomResourceDefinition, CRD). Genom att publicera OpenAPI för CRD kan klienter (t.ex. kubectl) utför validering på din sida (inom kubectl create и kubectl apply) och utfärda dokumentation enligt schemat (kubectl explain). Detaljer - in .
Redan existerande loggar med flagga O_APPEND (Ej O_TRUNC) för att undvika förlust av stockar i vissa situationer och för att underlätta trunkering av stockar med externa verktyg för rotation.
Även i samband med Kubernetes API kan det noteras att i PodSandbox и PodSandboxStatus fält runtime_handler att registrera information om RuntimeClass i podden (läs mer om det i texten om , där den här klassen dök upp som en alfaversion), och i Admission Webhooks möjlighet att avgöra vilka versioner AdmissionReview de stödjer. Äntligen är Admission Webhooks-reglerna nu omfattningen av deras användning av namnutrymmen och klusterramar.
Lagring
, som hade betastatus sedan lanseringen , stabil (GA): denna funktionsport är inte längre inaktiverad och kommer att tas bort i Kubernetes 1.17.
använda miljövariabler som kallas (till exempel podnamnet) för namnen på kataloger monterade som , utvecklades - i form av ett nytt fält subPathExpr, som nu används för att bestämma önskat katalognamn. Funktionen dök först upp i Kubernetes 1.11, men för 1.14 förblev den i alfaversionsstatus.
Som med den tidigare Kubernetes-utgåvan, introduceras många betydande förändringar för det aktivt utvecklande CSI (Container Storage Interface):
CSI
Blev tillgänglig (som en del av alfaversionen) ändra storlek för CSI-volymer. För att använda den måste du aktivera funktionsporten som kallas ExpandCSIVolumes, samt närvaron av stöd för denna operation i en specifik CSI-drivrutin.
En annan funktion för CSI i alfaversionen - hänvisa direkt (dvs utan att använda PV/PVC) till CSI-volymer inom podspecifikationen. Detta tar bort begränsningen för användningen av CSI som enbart fjärrdatalagringöppnar dörrar till världen för dem . För användning () måste vara aktiverat CSIInlineVolume funktion grind.
Det har också skett framsteg i "internerna" av Kubernetes relaterade till CSI, som inte är så synliga för slutanvändare (systemadministratörer) ... För närvarande tvingas utvecklare att stödja två versioner av varje lagringsplugin: en - "i old way”, inuti K8s kodbas (i -tree), och den andra - som en del av den nya CSI (läs mer om det, till exempel i ). Detta orsakar förståeliga olägenheter som måste åtgärdas när CSI själv stabiliserar sig. Det är inte möjligt att helt enkelt fasa ut API:et för interna (in-tree) plugins pga .
Allt detta ledde till att alfaversionen nådde intern plugin-kod, implementerad som in-tree, i CSI-plugins, tack vare vilka oron för utvecklare kommer att reduceras till att stödja en version av deras plugins, och kompatibilitet med gamla API:er kommer att förbli och de kan förklaras föråldrade i det vanliga scenariot. Det förväntas att vid nästa utgåva av Kubernetes (1.15) kommer alla molnleverantörs plugins att migreras, implementeringen kommer att få betastatus och kommer att aktiveras i K8s installationer som standard. För detaljer, se . Denna migration resulterade också i från volymgränser definierade av specifika molnleverantörer (AWS, Azure, GCE, Cinder).
Dessutom stöd för blockenheter med CSI (CSIBlockVolume) till betaversion.
Noder/Kubelet
Alfaversion presenterad i Kubelet, designad för returnera mätvärden på nyckelresurser. Generellt sett, om tidigare Kubelet tagit emot statistik om containeranvändning från cAdvisor, kommer nu dessa data från containerruntime-miljön via CRI (Container Runtime Interface), men kompatibiliteten för att arbeta med äldre versioner av Docker är också bevarad. Tidigare har statistik som samlats in i Kubelet skickats via REST API, men nu finns en slutpunkt på /metrics/resource/v1alpha1. Långsiktig strategi för utvecklare är att minimera uppsättningen mätvärden som tillhandahålls av Kubelet. Förresten, dessa mätvärden själva inte "kärnmått", utan "resursmått", och beskrivs som "förstklassiga resurser, såsom cpu och minne".
En mycket intressant nyans: trots den tydliga prestandafördelen med gRPC-slutpunkten i jämförelse med olika fall av användning av Prometheus-formatet (se resultatet av ett av riktmärkena nedan), föredrog författarna textformatet för Prometheus på grund av det tydliga ledarskapet för detta övervakningssystem i samhället.
"gRPC är inte kompatibelt med större övervakningsledningar. Endpoint kommer bara att vara användbart för att leverera mätvärden till Metrics Server eller övervaka komponenter som integreras direkt med den. Prometheus textformatprestanda vid användning av cachning i Metrics Server tillräckligt bra för oss att föredra Prometheus framför gRPC med tanke på den utbredda adoptionen av Prometheus i samhället. När OpenMetrics-formatet blir mer stabilt kommer vi att kunna närma oss gRPC-prestanda med ett protobaserat format."
Ett av de jämförande prestandatesterna för att använda gRPC- och Prometheus-format i den nya Kubelet-ändpunkten för mätvärden. Fler grafer och andra detaljer finns i .
Bland andra ändringar:
- Kubelet nu (en gång) behållare i ett okänt tillstånd före omstart och radering.
- När du använder nu till init-behållaren samma information som för en vanlig container.
- kubelet
usageNanoCoresfrån CRI-statistikleverantören och för noder och behållare på Windows nätverksstatistik. - Information om operativsystem och arkitektur registreras nu i etiketter
kubernetes.io/osиkubernetes.io/archNodobjekt (överfört från beta till GA). - Möjlighet att ange en specifik systemanvändargrupp för behållare i en pod (
RunAsGroup, framträdde i ) före beta (aktiverad som standard). - du och hitta används i cAdvisor, on Go implementering.
CLI
I cli-runtime och kubectl -k flagga för integration med (förresten, dess utveckling sker nu i ett separat förvar), d.v.s. för att bearbeta ytterligare YAML-filer från speciella kustomiseringskataloger (för detaljer om hur du använder dem, se ):
Exempel på enkel filanvändning (en mer komplex tillämpning av kustomize är möjlig inom )
Dessutom:
- nytt lag
kubectl create cronjob, vars namn talar för sig själv. - В
kubectl logsnu kan du flaggor-f(--followför strömmande loggar) och-l(--selectorför etikettfråga). - kubectl kopiera filer valda med jokertecken.
- Till laget
kubectl waitflagga--allför att välja alla resurser i namnområdet för den angivna resurstypen.
Andra
Följande funktioner har fått stabil (GA) status:
- , som används i podspecifikationen för att definiera ytterligare villkor som tas med i beräkningen i poddens beredskap;
- Stöd för stora sidor (funktionsgrind kallas );
- ;
- PriorityClass API .
Andra ändringar som införts i Kubernetes 1.14:
- Standard RBAC-policy tillåter inte längre API-åtkomst
discoveryиaccess-reviewanvändare utan autentisering (oautentiserad). - Officiellt stöd för CoreDNS Endast Linux, så när du använder kubeadm för att distribuera det (CoreDNS) i ett kluster, måste noder endast köras på Linux (nodeSelectors används för denna begränsning).
- Standard CoreDNS-konfiguration är nu istället för proxy. Även i CoreDNS ReadinessProbe, som förhindrar lastbalansering på lämpliga (ej redo för service) kapslar.
- I kubeadm, på faser
initellerupload-certs, ladda de certifikat som krävs för att ansluta det nya kontrollplanet till kubeadm-certs secret (använd flaggan--experimental-upload-certs). - En alfaversion har dykt upp för Windows-installationer gMSA (Group Managed Service Account) - specialkonton i Active Directory som även kan användas av containrar.
- För G.C.E. mTLS-kryptering mellan etcd och kube-apiserver.
- Uppdateringar i använd/beroende programvara: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, Docker 18.09-stöd i kubeadm, och den lägsta stödda Docker API-versionen är nu 1.26.
PS
Läs även på vår blogg:
- «";
- «";
- «";
- «".
Källa: will.com