Denne natten neste utgivelse av Kubernetes - . I henhold til tradisjonen som har utviklet seg for bloggen vår, snakker vi om de viktigste endringene i den nye versjonen av dette fantastiske Open Source-produktet.
Informasjon som brukes til å utarbeide dette materialet er hentet fra , og relaterte problemer, pull-forespørsler, Kubernetes Enhancement Proposals (KEP).
La oss starte med en viktig introduksjon fra SIG cluster-lifecycle: dynamiske failover-klynger Kubernetes (eller for å være mer presis, selvvertsbaserte HA-distribusjoner) er nå ved å bruke kjente (i sammenheng med enkeltnode-klynger) kommandoer kubeadm (init и join). Kort sagt, for dette:
- sertifikater som brukes av klyngen overføres til hemmeligheter;
- for muligheten for å bruke etcd-klyngen inne i K8s-klyngen (dvs. bli kvitt den tidligere eksisterende eksterne avhengigheten) ;
- Dokumenterer de anbefalte innstillingene for en ekstern lastbalanser som gir en feiltolerant konfigurasjon (i fremtiden er det planlagt å eliminere denne avhengigheten, men ikke på dette stadiet).
Arkitektur av en Kubernetes HA-klynge opprettet med kubeadm
Detaljer om implementeringen finner du i . Denne funksjonen var virkelig etterlengtet: alfaversjonen var forventet tilbake i K8s 1.9, men dukket først opp nå.
API
Lag apply og generelt sett deklarativ objektstyring av kubectl i apiserver. Utviklerne selv forklarer kort beslutningen sin ved å si det kubectl apply - en grunnleggende del av arbeidet med konfigurasjoner i Kubernetes, "den er full av feil og vanskelig å fikse," og derfor må denne funksjonaliteten bringes tilbake til det normale og overføres til kontrollplanet. Enkle og klare eksempler på problemer som eksisterer i dag:
Detaljer om implementeringen er inne . Nåværende beredskap er alfa (opprykk til beta er planlagt for neste Kubernetes-utgivelse).
Tilgjengelig i alfaversjon bruker OpenAPI v3-skjemaet for opprette og publisere OpenAPI-dokumentasjon for CustomResources (CR) brukes til å validere (server-side) K8s brukerdefinerte ressurser (CustomResourceDefinition, CRD). Å publisere OpenAPI for CRD lar klienter (f.eks. kubectl) utføre validering på din side (innenfor kubectl create и kubectl apply) og utstede dokumentasjon i henhold til ordningen (kubectl explain). Detaljer - inn .
Eksisterende logger med flagg O_APPEND (men ikke O_TRUNC) for å unngå tap av logger i enkelte situasjoner og for å gjøre det enklere å avkorte logger med eksterne verktøy for rotasjon.
Også i sammenheng med Kubernetes API, kan det bemerkes at i PodSandbox и PodSandboxStatus felt runtime_handler å registrere informasjon om RuntimeClass i poden (les mer om det i teksten om , hvor denne klassen dukket opp som en alfaversjon), og i Admission Webhooks muligheten til å bestemme hvilke versjoner AdmissionReview de støtter. Endelig er Admission Webhooks-reglene nå omfanget av deres bruk av navnerom og klyngreammer.
repositories
, som hadde betastatus siden utgivelsen , stabil (GA): denne funksjonsporten er ikke lenger deaktivert og vil bli fjernet i Kubernetes 1.17.
bruke miljøvariabler kalt (for eksempel podnavnet) for navnene på kataloger montert som , ble utviklet - i form av et nytt felt subPathExpr, som nå brukes til å bestemme ønsket katalognavn. Funksjonen dukket opprinnelig opp i Kubernetes 1.11, men for 1.14 forble den i alfaversjonsstatus.
Som med den forrige Kubernetes-utgivelsen, introduseres mange betydelige endringer for det aktivt utviklende CSI (Container Storage Interface):
CSI
Ble tilgjengelig (som en del av alfaversjonen) endre størrelse for CSI-volumer. For å bruke den må du aktivere funksjonsporten som kalles ExpandCSIVolumes, samt tilgjengeligheten av støtte for denne operasjonen i en spesifikk CSI-driver.
En annen funksjon for CSI i alfaversjonen - referer direkte (dvs. uten å bruke PV/PVC) til CSI-volumer innenfor pod-spesifikasjonen. Dette fjerner begrensningen på bruk av CSI som eksklusivt ekstern datalagring, åpne dører til verden for dem . For bruk () må være aktivert CSIInlineVolume funksjonsport.
Det har også vært fremgang i "internals" av Kubernetes relatert til CSI, som ikke er så synlige for sluttbrukere (systemadministratorer) ... For øyeblikket er utviklere tvunget til å støtte to versjoner av hver lagringsplugin: en - "i old way", inne i K8s kodebase (i -tree), og den andre - som en del av den nye CSI (les mer om det, for eksempel i ). Dette forårsaker forståelige ulemper som må løses når CSI selv stabiliserer seg. Det er ikke mulig å bare avskrive APIen til interne (in-tree) plugins pga .
Alt dette førte til at alfaversjonen nådde intern plugin-kode, implementert som in-tree, i CSI-plugins, takket være at bekymringene til utviklere vil bli redusert til å støtte én versjon av pluginene deres, og kompatibilitet med gamle APIer vil forbli og de kan erklæres foreldet i det vanlige scenariet. Det forventes at ved neste utgivelse av Kubernetes (1.15) vil alle skyleverandørplugins bli migrert, implementeringen vil motta betastatus og vil bli aktivert i K8s-installasjoner som standard. For detaljer, se . Denne migrasjonen resulterte også i fra volumgrenser definert av spesifikke skyleverandører (AWS, Azure, GCE, Cinder).
I tillegg støtte for blokkeringsenheter med CSI (CSIBlockVolume) til betaversjon.
Noder/Kubelet
Alfaversjon presentert i Kubelet, designet for returnere beregninger på nøkkelressurser. Generelt sett, hvis tidligere Kubelet mottok statistikk om containerbruk fra cAdvisor, kommer nå disse dataene fra container runtime-miljøet via CRI (Container Runtime Interface), men kompatibilitet for arbeid med eldre versjoner av Docker er også bevart. Tidligere ble statistikk samlet inn i Kubelet sendt via REST API, men nå et endepunkt plassert på /metrics/resource/v1alpha1. Langsiktig strategi for utviklere er å minimere settet med beregninger levert av Kubelet. Forresten, disse beregningene selv ikke "kjernemålinger", men "ressursmålinger", og beskrives som "førsteklasses ressurser, som cpu og minne".
En veldig interessant nyanse: til tross for den klare ytelsesfordelen til gRPC-endepunktet sammenlignet med forskjellige tilfeller av bruk av Prometheus-formatet (se resultatet av en av benchmarkene nedenfor), foretrakk forfatterne tekstformatet til Prometheus på grunn av det klare lederskapet til dette overvåkingssystemet i samfunnet.
"gRPC er ikke kompatibel med store overvåkingsrørledninger. Endpoint vil bare være nyttig for å levere beregninger til Metrics Server eller overvåking av komponenter som integreres direkte med den. Prometheus tekstformatytelse ved bruk av caching i Metrics Server bra nok for oss å foretrekke Prometheus fremfor gRPC gitt den utbredte bruken av Prometheus i samfunnet. Når OpenMetrics-formatet blir mer stabilt, vil vi kunne nærme oss gRPC-ytelse med et protobasert format.»
En av de komparative ytelsestestene for bruk av gRPC- og Prometheus-formater i det nye Kubelet-endepunktet for beregninger. Flere grafer og andre detaljer finner du i .
Blant andre endringer:
- Kubelet nå (en gang) beholdere i en ukjent tilstand før omstart og sletting av operasjoner.
- Ved bruk nå til init-beholderen samme informasjon som for en vanlig container.
- kubelet
usageNanoCoresfra CRI-statistikkleverandøren, og for noder og containere på Windows nettverksstatistikk. - Operativsystem- og arkitekturinformasjon er nå registrert i etiketter
kubernetes.io/osиkubernetes.io/archNodeobjekter (overført fra beta til GA). - Evne til å spesifisere en spesifikk systembrukergruppe for containere i en pod (
RunAsGroup, dukket opp i ) før beta (aktivert som standard). - du og finne brukt i cAdvisor, on Go implementering.
CLI
I cli-runtime og kubectl -k flagg for integrasjon med (forresten, utviklingen utføres nå i et eget depot), dvs. for å behandle ytterligere YAML-filer fra spesielle kustomiseringskataloger (for detaljer om bruk av dem, se ):
Eksempel på enkel filbruk (en mer kompleks anvendelse av kustomize er mulig innenfor )
I tillegg:
- nytt lag
kubectl create cronjob, hvis navn taler for seg selv. - В
kubectl logsnå kan du flagg-f(--followfor strømmelogger) og-l(--selectorfor etikettspørring). - kubectl kopiere filer valgt med jokertegn.
- Til laget
kubectl waitflagg--allfor å velge alle ressurser i navneområdet til den angitte ressurstypen.
Andre
Følgende funksjoner har fått stabil (GA) status:
- , brukt i pod-spesifikasjonen for å definere tilleggsbetingelser tatt i betraktning i podens beredskap;
- Støtte for store sider (funksjonsport kalt );
- ;
- PriorityClass API .
Andre endringer introdusert i Kubernetes 1.14:
- Standard RBAC-policy tillater ikke lenger API-tilgang
discoveryиaccess-reviewbrukere uten autentisering (uautentisert). - Offisiell CoreDNS-støtte Bare Linux, så når du bruker kubeadm for å distribuere det (CoreDNS) i en klynge, må noder bare kjøre på Linux (nodeSelectors brukes for denne begrensningen).
- Standard CoreDNS-konfigurasjon er nå i stedet for proxy. Også i CoreDNS readinessProbe, som forhindrer lastbalansering på passende (ikke klar for service) pods.
- I kubeadm, på faser
initellerupload-certs, last inn sertifikatene som kreves for å koble det nye kontrollplanet til kubeadm-certs secret (bruk flagget--experimental-upload-certs). - En alfaversjon har dukket opp for Windows-installasjoner gMSA (Group Managed Service Account) - spesielle kontoer i Active Directory som også kan brukes av containere.
- For G.C.E. mTLS-kryptering mellom etcd og kube-apiserver.
- Oppdateringer i brukt/avhengig programvare: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, Docker 18.09-støtte i kubeadm, og minimum støttet Docker API-versjon er nå 1.26.
PS
Les også på bloggen vår:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com