Das Kubernetes-Entwicklungsteam hat vor kurzem veröffentlicht durch eine Ankündigung der Veröffentlichung von die neue Version "Kubernetes 1.18" in dem das Entwicklungsteam erwähnt, dass es sich um eine Version handelt, die "fit und fertig" ist.
In dieser neuen Version Es wurden erhebliche Anstrengungen unternommen, um das Beta und die stabile Funktionalität zu verbessern zu garantieren a bessere Benutzererfahrung. Ebenso wurden Anstrengungen unternommen, um neue Entwicklungen und aufregende neue Funktionen hinzuzufügen, die eine weitere Verbesserung der Benutzererfahrung versprechen.
Für diejenigen, die es nicht wissen Kubernetes, Sie sollten das wissen ist ein Open-Source-System zur Automatisierung die Implementierung, Skalierung und Verwaltung von containerisierte Anwendungen.
Es war ursprünglich von Google entworfen, Obwohl seine Entwicklung später der Open Source Cloud Computing Foundation (CNCF) anvertraut wurde, die es heute dank der Beiträge von Technologiegiganten ermöglicht hat, die Technologie der Container-Orchestrierung schnell zu reifen.
Was ist neu in Kubernetes 1.18?
Diese neue Version zeichnet sich durch die Möglichkeit zur Verwendung von Dienstkonto-Token als allgemeine Authentifizierungsmethode. Wenn Sie beispielsweise möchten, dass ein Pod andere Kubernetes-Ressourcen verwaltet, z. B. eine Bereitstellung oder einen Dienst, kann er einem Dienstkonto zugeordnet werden und die erforderlichen Rollen und Rollenbindungen erstellen.
Kubernetes-Dienstkonten (KSAs) senden JSON-Web-Token (JWT) zur Authentifizierung an den API-Server. Dies macht den API-Server zur einzigen Authentifizierungsquelle für Dienstkonten.
Kubernetes 1.18pbietet eine Funktionalität dass Ermöglicht dem API-Server die Bereitstellung eines OpenID Connect-Erkennungsdokuments A enthält neben anderen Metadaten auch die öffentlichen Schlüssel des Tokens.
Eine weitere Änderung, die sich von Kubernetes 1.81 abhebt, ist die Möglichkeit, die HPA-Geschwindigkeit für bestimmte Pods zu konfigurieren. Es wurde ein horizontaler Pod-Autoscaler (HPA) verwendeta, damit ein Kubernetes-Cluster automatisch auf hohen / niedrigen Datenverkehr reagieren kann. Mit HPA kann der Benutzer den Controller auffordern, als Reaktion auf CPU-Spitzen, andere Messungen oder von der Anwendung bereitgestellte Messungen weitere Module zu erstellen.
Kubernetes 1.18 bietet eine Übersicht über Profile zum Ausführen mehrerer Konfigurationen des Planers. Im Allgemeinen gibt es in Kubernetes zwei Arten von Workloads: Langzeitdienste (z. B. Webserver, APIs usw.) und Aufgaben, die vollständig ausgeführt werden (besser bekannt als "Jobs").
Aufgrund offensichtlicher Unterschiede zwischen den Workload-Typen greifen einige Benutzer auf die Erstellung vollständiger Cluster für unterschiedliche Anforderungen zurück. Zum Beispiel ein Cluster zum Verwalten des Data Mining und ein anderer zum Bereitstellen der Anwendungs-APIs.
Der Grund ist, dass der Entscheidungsprozess unterschiedlich sein muss. Beispielsweise fördern die Standardeinstellungen des Schedulers eine hohe Verfügbarkeit.
Auf der anderen Seite können wir auch die finden Fähigkeit, eine Pod-Broadcast-Regel auf Cluster-Ebene zu definieren, als hat es möglich gemacht, sicherzustellen, dass Pods in Verfügbarkeitszonen geplant werden (solange Sie einen Mehrzonencluster verwenden), um maximale Verfügbarkeit und Ressourcennutzung sicherzustellen.
Die Funktionalität aktiviert die Spezifikation topologySpreadConstraints, mit der Bereiche identifiziert werden, indem nach Knoten mit demselben topologyKey-Tag gesucht wird. Knoten mit demselben TopologyKey-Tag gehören zum selben Bereich. Die Konfiguration bestand darin, die Pods gleichmäßig auf die verschiedenen Bereiche zu verteilen. Der Nachteil ist jedoch, dass diese Einstellung auf Pod-Ebene angewendet werden muss. Pods ohne Konfiguration werden nicht gleichmäßig auf die Fehlerdomänen verteilt.
Zu guter Letzt, Wir können auch die Möglichkeit finden, die Änderung in der Volume-Eigenschaft zu ignorieren. Wenn ein Volume in einem Container in einem Kubernetes-Cluster bereitgestellt wird, wird die Eigenschaft aller Dateien und Verzeichnisse in diesem Volume standardmäßig auf den von der fsGroup bereitgestellten Wert geändert.
All dies, damit fsGroup das Volume lesen und schreiben kann. Es hat sich jedoch gezeigt, dass dieses Verhalten in einigen Fällen unerwünscht ist.
Diese neue Version von Kubernetes bringt eine Reihe von Änderungen mit sich, und wir haben nur einige der wichtigsten erwähnt. Wenn Sie die vollständige Liste wissen möchten, können Sie dies tun, indem Sie die besuchen folgenden Link