Vanavond is weer een nieuwe release van Kubernetes — . Volgens de traditie van onze blog bespreken we de belangrijkste veranderingen in deze nieuwe versie van dit geweldige Open Source-product.
De informatie die is gebruikt voor de voorbereiding van dit materiaal, is afkomstig van , en de bijbehorende issues, pull requests, Kubernetes Enhancement Proposals (KEP).
Laten we beginnen met een belangrijke introductie van SIG cluster-lifecycle: dynamische fouttolerante clusters Kubernetes (of, om het preciezer te zeggen, self-hosted HA deployments) kan nu met behulp van de vertrouwde (in de context van single-node clusters) commando's kubeadm (, wat erg handig is. Bovendien kunnen meerdere configuraties worden geschreven: ontwikkelen op de standaardconfiguratie, en daarna implementeren met het commando en join). In het kort, om dit te doen:
- worden de door de cluster gebruikte certificaten overgebracht naar secrets;
- om het gebruik van etcd binnen de K8s-cluster mogelijk te maken (d.w.z. om de tot nu toe bestaande externe afhankelijkheid te elimineren) is er gebruikgemaakt van ;
- de aanbevolen configuraties voor een externe load balancer die een fouttolerante configuratie biedt, worden gedocumenteerd (uiteindelijk is het de bedoeling deze afhankelijkheid ook te kunnen opheffen, maar niet in deze fase).
HA-clusterarchitectuur van Kubernetes, gemaakt met kubeadm
Voor meer details over de implementatie, zie . Deze functie was echt langverwacht: de alfa-versie werd al verwacht in K8s 1.9, maar is pas nu verschenen.
API
Opdracht apply en in het algemeen declaratieve objectbeheer uit kubectl naar apiserver. De ontwikkelaars leggen hun beslissing kort uit met de opmerking dat kubectl apply een fundamenteel onderdeel is van het werken met configuraties in Kubernetes, maar "vol met bugs is en moeilijk te corrigeren", daarom moet deze functionaliteit worden gefixt en naar het control plane worden verplaatst. Eenvoudige en heldere voorbeelden van bestaande problemen zijn:
Details over de implementatie zijn te vinden in . De huidige gereedheid is alfa-versie (de promotie naar beta is gepland voor de volgende release van Kubernetes).
In de alfa-versie is het mogelijk geworden de OpenAPI v3-schema voor te gebruiken voor het creëren en publiceren van OpenAPI-documentatie voor CustomResources (CR) die worden gebruikt voor de validatie (aan serverzijde) van door gebruikers gedefinieerde K8s-resources (CustomResourceDefinition, CRD). De publicatie van OpenAPI voor CRD stelt klanten (bijvoorbeeld, kubectl) in staat om validatie aan hun zijde uit te voeren (binnen kubectl create en kubectl apply) en documentatie over het schema te verstrekken (kubectl explain). Voor meer details, zie .
De eerder bestaande logs met de vlag O_APPEND (en niet O_TRUNC) om te voorkomen dat de logs in bepaalde situaties verloren gaan en voor het gemak van het trunceren van logs met externe hulpprogramma's voor rotatie.
Daarnaast kan in de context van de Kubernetes API worden opgemerkt dat PodSandbox en PodSandboxStatus veld runtime_handler voor het bijhouden van informatie over RuntimeClass in de pod (meer hierover leest u in de tekst over , waar deze klasse als een alfa-versie is geïntroduceerd), en in Admission Webhooks de mogelijkheid om te bepalen welke versies AdmissionReview ze ondersteunen. Ten slotte kunnen in de regels voor Admission Webhooks nu Opslagplaatsen
, die de status bètaversie had vanaf de release
K8s 1.10 , het gebruik van omgevingsvariabelen van het zogenaamde
Downward API , heeft zich ontwikkeld — in de vorm van een nieuw veld subPathExpr , waarmee nu de benodigde naam van de map wordt bepaald. Deze functie is oorspronkelijk geïntroduceerd in Kubernetes 1.11, maar bleef ook in 1.14 in de status van alfa-versie.Net als in de vorige release van Kubernetes zijn er veel significante wijzigingen gepresenteerd voor CSI (Container Storage Interface), dat zich actief ontwikkelt:
De beschikbaarheid van
CSI
groottewijzigingen voor CSI-volumes is gemaakt (in alfa-status). Voor gebruik is het inschakelen van de feature gate genaamdExpandCSIVolumes vereist, evenals dat deze bewerking wordt ondersteund door de specifieke CSI-driver.Een andere functie voor CSI in alfa-status is
directe verwijzing (d.w.z. zonder het gebruik van PV/PVC) naar CSI-volumes binnen de specificatie van pods. Dit verwijdert de beperking van het gebruik van CSI als uitsluitend externe datastorage, en opent de deuren voor hen naar de wereld vanlokale ephemere volumes. ) moetde feature gate CSIInlineVolume worden ingeschakeld.
Er is vooruitgang geboekt en in de "binnenkant" van Kubernetes, gerelateerd aan CSI, die niet zo zichtbaar is voor eindgebruikers (systeembeheerders)... Op dit moment zijn ontwikkelaars gedwongen om twee versies van elke opslagplugin te ondersteunen: één — "ouderwets", binnen de codebase van K8s (in-tree), en de tweede — binnen het nieuwe CSI (meer hierover leest u bijvoorbeeld in ). Dit veroorzaakt begrijpelijke ongemakken die moeten worden verholpen naarmate CSI als zodanig stabiliseert. Gewoon de interne (in-tree) plugins als verouderd (deprecated) verklaren is niet mogelijk vanwege .
Dit heeft geleid tot het bereiken van alfa-versies interne plugin-code, geïmplementeerd als in-tree, in CSI-plugins, waardoor de zorgen van ontwikkelaars beperkt worden tot het onderhoud van één versie van hun plugins, terwijl compatibiliteit met oude API's behouden blijft en ze volgens de gebruikelijke procedure als verouderd kunnen worden aangeduid. Het wordt verwacht dat tegen de volgende release van Kubernetes (1.15) de migratie van alle plugins van cloudproviders zal zijn uitgevoerd, de implementatie de status bètaversie zal krijgen en standaard zal worden geactiveerd in K8s-installen. Voor meer details zie . Een gevolg van deze migratie was ook van beperkingen voor volumes gedefinieerd door specifieke cloudproviders (AWS, Azure, GCE, Cinder).
Bovendien wordt de ondersteuning voor blokapparaten met CSI (CSIBlockVolume) naar bètaversie.
Nodes / Kubelet
is de alfa-versie geïntroduceerd van in Kubelet, bedoeld voor het leveren van metingen van de belangrijkste middelen. Over het algemeen, als Kubelet voorheen statistieken over containergebruik van cAdvisor ontving, komen deze gegevens nu uit de uitvoeringsomgeving van de container via CRI (Container Runtime Interface), maar is de compatibiliteit met oude versies van Docker behouden. De eerder in Kubelet verzamelde statistieken werden via de REST API geleverd, maar nu wordt hiervoor een endpoint gebruikt dat zich op het adres bevindt /metrics/resource/v1alpha1. De langetermijnstrategie van de ontwikkelaars uit het minimaliseren van het aantal metingen dat door Kubelet wordt geleverd. Overigens worden deze metingen niet als 'core metrics', maar als 'resource metrics', en beschrijven ze als 'first-class resources, zoals cpu en geheugen'.
Een opvallend detail: ondanks het duidelijke prestatievoordeel van de gRPC endpoint vergeleken met verschillende toepassingen van het Prometheus-formaat (het resultaat van een van de benchmarks zie hieronder), gaven de auteurs de voorkeur aan het tekstformaat van Prometheus vanwege de duidelijke dominantie van dit monitoringsysteem binnen de gemeenschap.
"gRPC is niet compatibel met de belangrijkste monitoring-pijplijnen. De endpoint zal echter alleen nuttig zijn voor het leveren van metingen aan Metrics Server of monitoringcomponenten die rechtstreeks met hem integreren. Bij gebruik van caching in Metrics Server is de prestatie van het tekstformaat van Prometheus voldoende goed. voor ons om Prometheus te verkiezen boven gRPC, gezien de brede verspreiding van Prometheus binnen de gemeenschap. Zodra het OpenMetrics-formaat stabieler wordt, kunnen we de prestaties van gRPC naderen met een op proto gebaseerd formaat.
Een van de vergelijkende prestatietests van het gebruik van de gRPC- en Prometheus-formaten in de nieuwe Kubelet-endpoint voor metriek. Meer grafieken en andere details zijn te vinden in .
Onder andere veranderingen:
- Kubelet probeert nu (eenmalig) containers in een onbekende toestand te stoppen vóór restart- en verwijderoperaties.
- Bij het gebruik van wordt nu aan de init-container dezelfde informatie als voor de reguliere container.
- Kubelet
usageNanoCoresvan de CRI-statistiekprovider, en voor knooppunten en containers in Windows netwerkstatistieken. - Informatie over het besturingssysteem en de architectuur wordt nu vastgelegd in labels
kubernetes.io/osenkubernetes.io/archvan de Node-objecten (overgezet van beta naar GA). - De mogelijkheid om een specifieke systeemgebruikersgroep voor containers in een pod op te geven (
RunAsGroup) is geïntroduceerd in ) naar de bètaversie (standaard ingeschakeld). - du en find, gebruikt in cAdvisor, door Go-implementaties.
CLI
In cli-runtime en kubectl de -k-vlag voor integratie met (overigens wordt de ontwikkeling ervan nu in een aparte repository gedaan), dat wil zeggen, voor het verwerken van extra YAML-bestanden uit speciale kustomization-mappen (details over het gebruik ervan zijn te vinden in ):
Voorbeeld van eenvoudig gebruik van een (ook mogelijk is complexere toepassing van kustomize in het kader van )
Bovendien:
- de nieuwe opdracht
kubectl create cronjob, waarvan de naam voor zichzelf spreekt. - In
kubectl logskan nu vlaggen-f(--followvoor het streamen van logs) en-l(--selectorvoor labelquery). - kubectl bestanden te kopiëren die met behulp van wildcards zijn geselecteerd.
- In de functie
kubectl waitvlag--allvoor het selecteren van alle resources in de opgegeven namespace van het type resources.
Andere
De volgende mogelijkheden hebben de stabiele (GA) status gekregen:
- , gebruikt in de specificatie van de pod om extra voorwaarden voor de gereedheid van de pod in overweging te nemen;
- Ondersteuning voor grote pagina's (feature gate met de naam );
- ;
- PriorityClass API, .
Overige wijzigingen gepresenteerd in Kubernetes 1.14:
- De RBAC-beleid standaard verleent geen toegang meer tot de API
discoveryenaccess-reviewvoor gebruikers zonder authenticatie (unauthenticated). - Officiële ondersteuning voor CoreDNS alleen voor Linux, dus bij het gebruik van kubeadm voor de implementatie ervan (CoreDNS) in een cluster moeten de knooppunten alleen op Linux draaien (voor deze beperking worden nodeSelectors gebruikt).
- De standaardconfiguratie van CoreDNS is nu in plaats van proxy. Bovendien heeft CoreDNS readinessProbe, die voorkomt dat de load balancer verbinding maakt met de relevante (niet klaar voor service) pods.
- In kubeadm, in de fasen van
, wat erg handig is. Bovendien kunnen meerdere configuraties worden geschreven: ontwikkelen op de standaardconfiguratie, en daarna implementeren met het commandoofupload-certs, om certificaten te uploaden die nodig zijn voor het verbinden van een nieuwe control-plane met het geheim kubeadm-certs (de vlag wordt gebruikt)--experimental-upload-certs). - Voor Windows-installaties is er een alfa-versie gMSA (Group Managed Service Account) - speciale accounts in Active Directory die door containers gebruikt kunnen worden.
- Voor GCE tussen etcd en kube-apiserver.
- Updates in de gebruikte/afhankelijke software: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, ondersteuning voor Docker 18.09 in kubeadm, en de minimale ondersteunde versie van Docker API is 1.26.
P.S.
Lees ook op onze blog:
- «»;
- «»;
- «»;
- «».
Bron: habr.com
