Denne nat næste udgivelse af Kubernetes - . Ifølge traditionen, der har udviklet sig for vores blog, taler vi om de vigtigste ændringer i den nye version af dette vidunderlige Open Source-produkt.
Oplysninger brugt til at udarbejde dette materiale er taget fra , og relaterede problemer, pull-anmodninger, Kubernetes Enhancement Proposals (KEP).
Lad os starte med en vigtig introduktion fra SIG cluster-lifecycle: dynamiske failover-klynger Kubernetes (eller for at være mere præcis, selv-hostede HA-implementeringer) er nu ved hjælp af velkendte (i sammenhæng med enkeltknude-klynger) kommandoer kubeadm (init и join). Kort sagt til dette:
- certifikater, der bruges af klyngen, overføres til hemmeligheder;
- for muligheden for at bruge etcd-klyngen inde i K8s-klyngen (dvs. at slippe af med den tidligere eksisterende eksterne afhængighed) ;
- Dokumenterer de anbefalede indstillinger for en ekstern belastningsbalancer, der giver en fejltolerant konfiguration (i fremtiden er det planlagt at fjerne denne afhængighed, men ikke på dette stadium).
Arkitektur af en Kubernetes HA-klynge oprettet med kubeadm
Detaljer om implementeringen kan findes i . Denne funktion var virkelig længe ventet: alfaversionen var forventet tilbage i K8s 1.9, men dukkede først op nu.
API
Team apply og generelt set deklarativ objektstyring af kubectl i apiserver. Udviklerne selv forklarer kort deres beslutning ved at sige det kubectl apply - en grundlæggende del af arbejdet med konfigurationer i Kubernetes, "den er fuld af fejl og svær at rette," og derfor skal denne funktionalitet bringes tilbage til normal og overføres til kontrolplanet. Enkle og klare eksempler på problemer, der eksisterer i dag:
Detaljer om implementeringen er i . Nuværende parathed er alfa (promovering til beta er planlagt til den næste Kubernetes-udgivelse).
Fås i alfa-version bruger OpenAPI v3-skemaet til oprettelse og udgivelse af OpenAPI-dokumentation til CustomResources (CR) bruges til at validere (server-side) K8s brugerdefinerede ressourcer (CustomResourceDefinition, CRD). Udgivelse af OpenAPI til CRD tillader klienter (f.eks. kubectl) udføre validering på din side (indenfor kubectl create и kubectl apply) og udstede dokumentation i henhold til ordningen (kubectl explain). Detaljer - in .
Eksisterende logfiler med flag O_APPEND (Ikke O_TRUNC) for at undgå tab af logfiler i nogle situationer og for at gøre det lettere at afkorte logfiler med eksterne hjælpeprogrammer til rotation.
Også i forbindelse med Kubernetes API kan det bemærkes, at i PodSandbox и PodSandboxStatus felt runtime_handler at registrere oplysninger om RuntimeClass i poden (læs mere om det i teksten om , hvor denne klasse optrådte som en alfaversion), og i Admission Webhooks mulighed for at bestemme hvilke versioner AdmissionReview de støtter. Endelig er Admission Webhooks reglerne nu omfanget af deres brug af navnerum og cluster-rammer.
Opbevaring
, som havde betastatus siden udgivelsen , stabil (GA): denne funktionsport er ikke længere deaktiveret og vil blive fjernet i Kubernetes 1.17.
bruge miljøvariabler kaldet (for eksempel pod-navnet) for navnene på mapper monteret som , blev udviklet - i form af et nyt felt subPathExpr, som nu bruges til at bestemme det ønskede biblioteksnavn. Funktionen dukkede oprindeligt op i Kubernetes 1.11, men for 1.14 forblev den i alfaversionsstatus.
Som med den tidligere Kubernetes-udgivelse introduceres mange væsentlige ændringer for den aktivt udviklende CSI (Container Storage Interface):
CSI
Blev tilgængelig (som en del af alfaversionen) ændre størrelse for CSI-volumener. For at bruge det skal du aktivere den kaldede feature-gate ExpandCSIVolumes, samt tilgængeligheden af support til denne operation i en specifik CSI-driver.
En anden funktion til CSI i alfaversionen - henvise direkte (dvs. uden at bruge PV/PVC) til CSI-volumener inden for pod-specifikationen. Det her fjerner begrænsningen for brugen af CSI som udelukkende fjerndatalagring, åbne døre til verden for dem . Til brug () skal være aktiveret CSIInlineVolume funktionslåge.
Der er også sket fremskridt i "internals" af Kubernetes relateret til CSI, som ikke er så synlige for slutbrugere (systemadministratorer) ... I øjeblikket er udviklere tvunget til at understøtte to versioner af hvert lagerplugin: en - "i old way”, inde i K8s kodebase (i -tree), og den anden - som en del af den nye CSI (læs mere om det, for eksempel i ). Dette medfører forståelige gener, der skal løses, efterhånden som CSI selv stabiliserer sig. Det er ikke muligt blot at forælde API'et af interne (in-tree) plugins pga .
Alt dette førte til, at alfa-versionen nåede intern plugin-kode, implementeret som in-tree, i CSI plugins, takket være hvilke bekymringerne for udviklere vil blive reduceret til at understøtte en version af deres plugins, og kompatibilitet med gamle API'er vil forblive, og de kan erklæres for forældede i det sædvanlige scenarie. Det forventes, at ved den næste udgivelse af Kubernetes (1.15) vil alle cloud-udbyderplugins blive migreret, implementeringen vil modtage betastatus og vil blive aktiveret i K8s-installationer som standard. For detaljer, se . Denne migration resulterede også i fra volumengrænser defineret af specifikke cloud-udbydere (AWS, Azure, GCE, Cinder).
Derudover understøtter blokenheder med CSI (CSIBlockVolume) til betaversion.
Noder/Kubelet
Alpha version præsenteret i Kubelet, designet til returnere metrics på nøgleressourcer. Generelt set, hvis tidligere Kubelet modtog statistik om containerbrug fra cAdvisor, kommer disse data nu fra container runtime-miljøet via CRI (Container Runtime Interface), men kompatibiliteten til at arbejde med ældre versioner af Docker er også bevaret. Tidligere blev statistik indsamlet i Kubelet sendt via REST API, men nu et slutpunkt placeret på /metrics/resource/v1alpha1. Langsigtet strategi for udviklere er at minimere det sæt af metrics, der leveres af Kubelet. Forresten, disse målinger selv ikke "kernemålinger", men "ressourcemålinger", og beskrives som "førsteklasses ressourcer, såsom cpu og hukommelse".
En meget interessant nuance: på trods af den klare ydeevnefordel ved gRPC-endepunktet i sammenligning med forskellige tilfælde af brug af Prometheus-formatet (se resultatet af et af benchmarks nedenfor), foretrak forfatterne Prometheus' tekstformat på grund af dette overvågningssystems klare ledelse i samfundet.
"gRPC er ikke kompatibel med større overvågningsrørledninger. Endpoint vil kun være nyttigt til levering af metrics til Metrics Server eller overvågning af komponenter, der integreres direkte med den. Prometheus tekstformatydeevne ved brug af caching i Metrics Server godt nok for os at foretrække Prometheus frem for gRPC i betragtning af den udbredte adoption af Prometheus i samfundet. Når OpenMetrics-formatet bliver mere stabilt, vil vi være i stand til at nærme os gRPC-ydeevne med et proto-baseret format."
En af de sammenlignende præstationstest ved brug af gRPC- og Prometheus-formater i det nye Kubelet-endepunkt for metrics. Flere grafer og andre detaljer kan findes i .
Blandt andre ændringer:
- Kubelet nu (en gang) containere i en ukendt tilstand før genstart og sletning.
- Ved brug af nu til init-beholderen samme information som for en almindelig container.
- kubelet
usageNanoCoresfra CRI-statistikudbyderen og for noder og containere på Windows netværksstatistik. - Oplysninger om operativsystem og arkitektur er nu registreret i etiketter
kubernetes.io/osиkubernetes.io/archNodeobjekter (overført fra beta til GA). - Mulighed for at angive en specifik systembrugergruppe for containere i en pod (
RunAsGroup, dukkede op i ) før beta (aktiveret som standard). - du og find brugt i cAdvisor, on Go implementering.
CLI
I cli-runtime og kubectl -k flag til integration med (i øvrigt udføres dens udvikling nu i et separat depot), dvs. at behandle yderligere YAML-filer fra specielle kustomiseringsmapper (for detaljer om brug af dem, se ):
Eksempel på simpel filbrug (en mere kompleks anvendelse af kustomize er mulig inden for )
Derudover:
- nyt hold
kubectl create cronjob, hvis navn taler for sig selv. - В
kubectl logsnu kan du flag-f(--followtil streaming logs) og-l(--selectorfor etiketforespørgsel). - kubectl kopiere filer valgt med jokertegn.
- Til holdet
kubectl waitflag--allfor at vælge alle ressourcer i navnerummet for den angivne ressourcetype.
Andre
Følgende funktioner har fået stabil (GA) status:
- , brugt i pod-specifikationen til at definere yderligere betingelser, der tages i betragtning i podens parathed;
- Understøttelse af store sider (feature gate kaldet );
- ;
- PriorityClass API .
Andre ændringer introduceret i Kubernetes 1.14:
- Standard RBAC-politik tillader ikke længere API-adgang
discoveryиaccess-reviewbrugere uden godkendelse (ikke-godkendt). - Officiel CoreDNS-support Kun Linux, så når du bruger kubeadm til at implementere det (CoreDNS) i en klynge, må noder kun køre på Linux (nodeSelectors bruges til denne begrænsning).
- Standard CoreDNS-konfiguration er nu i stedet for proxy. Også i CoreDNS ReadinessProbe, som forhindrer belastningsbalancering på passende (ikke klar til service) pods.
- I kubeadm, på faser
initellerupload-certs, indlæs de nødvendige certifikater for at forbinde det nye kontrolplan til kubeadm-certs-hemmeligheden (brug flaget--experimental-upload-certs). - En alfaversion er dukket op til Windows-installationer gMSA (Group Managed Service Account) - særlige konti i Active Directory, der også kan bruges af containere.
- For G.C.E. mTLS-kryptering mellem etcd og kube-apiserver.
- Opdateringer i brugt/afhængig software: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, Docker 18.09-understøttelse i kubeadm, og den mindste understøttede Docker API-version er nu 1.26.
PS
Læs også på vores blog:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com