I aften endnu en udgivelse af Kubernetes — . Som en tradition for vores blog, vil vi fortælle om de vigtigste ændringer i den nye version af dette fantastiske Open Source-produkt.
Oplysningerne, der er brugt til at forberede dette materiale, er taget fra , og de relevante issues, pull requests, Kubernetes Enhancement Proposals (KEP).
Lad os begynde med en vigtig introduktion fra SIG cluster-lifecycle: dynamiske fejltolerante klynger Kubernetes (eller mere præcist, self-hosted HA deployments) kan nu ved hjælp af de velkendte (i forbindelse med enkelt-node klynger) kommandoer kubeadm (init og sammenføje). Kort fortalt, for at gøre dette:
- de anvendte klyngecertifikater flyttes til hemmeligheder;
- for muligheden for at anvende etcd i K8s-klyngen (dvs. fjerne den eksisterende eksterne afhængighed) er ;
- dokumenteret de anbefalede konfigurationer for en ekstern load balancer, der sikrer en fejltolerant konfiguration (muligheden for at fjerne denne afhængighed planlægges senere, men ikke på nuværende tidspunkt).
Architektur for HA-klyngen Kubernetes, oprettet med kubeadm
Med detaljer om implementeringen kan findes i . Denne funktion har virkelig været ventet: alpha-versionen blev forventet allerede i K8s 1.9, men den er først kommet nu.
API
Kommandoen apply og generelt deklarativ styring af objekter af kubectl til apiserver. Selve udviklerne forklarer kort deres beslutning ved, at kubectl apply — en grundlæggende del af arbejdet med konfigurationer i Kubernetes, men "fuld af fejl og svært at rette", hvorfor denne funktionalitet skal bringes i orden og flyttes til control plane. Enkle og klare eksempler på eksisterende problemer i dag:
Detaljer om implementeringen — i . Den nuværende beredskab — alpha-version (fremme til beta er planlagt til den næste udgivelse af Kubernetes).
I alpha-versionen blev tilgængelig for brugen af OpenAPI v3 skemaet til oprettelse og publicering af OpenAPI-dokumentation for CustomResources (CR), der bruges til validering (på serversiden) af K8s-ressourcer, der er defineret af brugeren (CustomResourceDefinition, CRD). Publicering af OpenAPI for CRD gør det muligt for kunder (for eksempel, kubectl) at udføre validering på deres egen side (inden for kubectl create og kubectl apply) og generere dokumentation for skemaet (kubectl explain). Detaljer — i .
De tidligere eksisterende logs med flag O_APPEND (og ikke O_TRUNC) for at undgå tab af logs i visse situationer og for at gøre det nemmere at truncate logs med eksterne værktøjer til rotation.
I konteksten af Kubernetes API kan det også nævnes, at i PodSandbox og PodSandboxStatus feltet runtime_handler til at håndtere oplysninger om RuntimeClass i pod’en (læs mere om det i teksten om , hvor denne klasse blev introduceret som en alpha-version), og i Admission Webhooks muligheden for at definere, hvilke versioner AdmissionReview de understøtter. Endelig kan reglerne for Admission Webhooks nu omfanget af deres anvendelse til namespaces og klyngens rammer.
Lagringssystemer
, som havde beta-status siden udgivelsen af , stabile (GA): denne feature gate deaktiveres ikke længere og vil blive fjernet i Kubernetes 1.17.
anvendelsen af miljøvariabler fra det såkaldte (for eksempel navnet på pod’en) til navne på kataloger, der er monteret som , har fået udvikling — i form af et nyt felt subPathExpr, hvormed det nu bestemmes, hvilket katalognavn der er nødvendigt. Denne funktion blev først introduceret i Kubernetes 1.11, men forblev i alpha-status i 1.14.
Som i den forrige Kubernetes-udgivelse, er der mange betydelige ændringer præsenteret for den aktivt udviklende CSI (Container Storage Interface):
CSI
blev tilgængelig (i alpha-status) ændringer af størrelsen for CSI-volumener.For at bruge den skal feature gate kaldet ExpandCSIVolumesaktiveres, samt at denne operation skal understøttes af den specifikke CSI-driver.
Endnu en funktion for CSI i alpha-status — henvise direkte (dvs. uden brug af PV/PVC) til CSI-volumener i pod-specifikationerne. Dette fjerner begrænsningen omkring brugen af CSI som udelukkende eksterne datalagringssystemer, og åbner dørene for dem til For at bruge () skal CSIInlineVolume feature gate aktiveres.
Der er også sket fremskridt i "indre" dele af Kubernetes, relateret til CSI, som ikke er så synlige for slutbrugerne (systemadministratorer)… I øjeblikket er udviklerne nødt til at understøtte to versioner af hver lagringsplugin: en — “den gamle måde”, inden for K8s kodebase (in-tree), og den anden — inden for den nye CSI (læs mere om det i ). Dette medfører forståelige ulemper, som skal løses, i takt med at CSI stabiliseres som sådan. Det er ikke muligt blot at erklære interne (in-tree) API'er for forældede (deprecated) på grund af .
Alt dette har ført til, at alpha-versionerne har nået den interne kode for plugins, implementeret som in-tree, til CSI-plugins, hvilket betyder, at udviklernes bekymringer vil være begrænset til at støtte en version af deres plugins, samtidig med at kompatibilitet med gamle API'er bevares, så de kan erklæres forældede efter det sædvanlige scenarie. Det forventes, at alle plugins fra cloududbydere vil være migreret til næste Kubernetes-udgivelse (1.15), implementeringen vil få beta-status og aktiveres i K8s-installationer som standard. Se nærmere i . Følgen af denne migration er også af begrænsninger for volumes, der defineres af specifikke cloududbydere (AWS, Azure, GCE, Cinder).
Desuden er understøttelsen af block devices med CSI (CSIBlockVolume) til beta-version.
Noder / Kubelet
Der er præsenteret en alpha-version i Kubelet, der er beregnet til at returnere data om centrale ressourcer. Generelt set, hvis Kubelet tidligere modtog statistikker om containerbrug fra cAdvisor, så kommer disse data nu fra containerens runtime gennem CRI (Container Runtime Interface), men der er også bevaret kompatibilitet til at arbejde med gamle versioner af Docker. Den statistik, der tidligere blev indsamlet i Kubelet, blev sendt via REST API, men nu anvendes et endpoint, som er tilgængeligt på adressen /metrics/resource/v1alpha1. Den langsigtede strategi for udviklerne at minimere mængden af målepunkter, der leveres af Kubelet. For resten kaldes disse målepunkter ikke «core metrics», men «resource metrics», og beskrives som «first-class resources, such as cpu, and memory».
Et bemærkelsesværdigt detalje: på trods af den åbenlyse ydelsesfordel ved gRPC-endpoint sammenlignet med forskellige anvendelser af Prometheus-formatet (resultatet af en af benchmarkene, se nedenfor), foretrækker forfatterne det tekstbaserede format fra Prometheus på grund af den åbenlyse føring, som dette overvågningssystem har i samfundet.
«gRPC er ikke kompatibel med de primære overvågningspipeline. Endpointen vil dog være nyttig kun til at levere metrics til Metrics Server eller overvågningskomponenter, der integrerer direkte med den. Ved brug af caching i Metrics Server er ydelsen for tekstformatet Prometheus tilstrækkeligt god for os til at foretrække Prometheus frem for gRPC, givet den brede udbredelse af Prometheus i samfundet. Når formatet OpenMetrics bliver mere stabilt, kan vi nærme os ydeevnen fra gRPC ved hjælp af et proto-baseret format».
En af de sammenlignende ydelsestests, der bruger formaterne gRPC og Prometheus i den nye endpoint Kubelet for metrics. Flere grafer og andre detaljer kan findes i .
Blandt andre ændringer:
- Kubelet forsøger nu (én gang) containere i ukendt tilstand (unknown) før genstarts- og sletningsoperationer.
- Ved brug af nu tilføjes den samme information til init-containeren, som til den almindelige container. er begyndt at bruge
- usageNanoCores
netværksstatistik.Information om operativsystemet og arkitekturen registreres nu i labels kubernetes.io/os - kubernetes.io/arch
af Node-objekterne (oversat fra beta til GA).ogMuligheden for at angive en specifik systemgruppe af brugere for containere i pod'en (RunAsGroup - , er blevet tilføjet i
K8s 1.11er gået ) er blevet erstattet - med Go-implementeringer. I cli-runtime og kubectl
flagen -k til integration med
(for øvrigt, dens udvikling foregår nu i et separat repository), det vil sige til behandling af ekstra YAML-filer fra specifikke direktørkustomiseringer (detaljer om brugen kan ses i Eksempel på enkel brug af filen kustomization ):
(mere kompleks anvendelse af kustomize mulig indenfor Derudover: )
kubectl create cronjob
- , hvis navn siger alt.
kubectl logskan nu - I
kombineresflags til streaming af logs) og-f(--selectortil label query).-l(lært atkopiere filer, der vælges med wildcard. - kubectl kubectl wait
- flag
--alltil at vælge alle ressourcer i det angivne navnerum for den angivne ressource type.AndreStabil (GA) status har fået følgende funktioner:
ReadinessGate
Stable (GA) status har fået følgende funktioner:
- , der anvendes i pod-specifikationen til at definere ekstra betingelser, der tages i betragtning i forhold til pod'ens klarhed;
- Understøttelse af store sider (feature gate kaldet );
- ;
- PriorityClass API, .
Andre ændringer præsenteret i Kubernetes 1.14:
- RBAC-politikken giver ikke længere adgang til API'en
discoveryogaccess-reviewfor brugere uden autentifikation (unauthenticated). - Officiel understøttelse af CoreDNS kun for Linux, så når du bruger kubeadm til at implementere (CoreDNS) i klyngen, skal noder kun køre på Linux (til denne begrænsning anvendes nodeSelectors).
- CoreDNS konfigurationen er nu i stedet for proxy. Derudover i CoreDNS readinessProbe, der forhindrer belastningsbalancering på de relevante (ikke klar til service) pod'er.
- I kubeadm, i faserne
initellerupload-certs, at uploade certifikater, der kræves for at forbinde den nye control-plane til kubeadm-certs hemmeligheden (bruger flaget--experimental-upload-certs). - For Windows-installationer er der en alpha-version gMSA (Group Managed Service Account) — specielle konti i Active Directory, der kan bruges af containere.
- For GCE Opdateringer i det anvendte/afhængige software: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, understøttelse af Docker 18.09 i kubeadm, og den mindste understøttede version af Docker API blev 1.26.
- Kubernetes 1.13: oversigt over de vigtigste nyheder
P.S.
Læs også på vores blog:
- «»;
- «»;
- «»;
- «».
Kilde: habr.com
