Entdecken Sie die neuen Funktionen von etcd v3.6.0 und wie diese Ihre Kubernetes-Projekte optimieren können.
Heute freuen wir uns, die Veröffentlichung von etcd v3.6.0 bekannt zu geben, dem ersten Minor-Release seit etcd v3.5.0. Dieses Update bringt zahlreiche neue Funktionen mit sich, verbessert die Unterstützung für Downgrades und Migrationen zum v3store und behebt viele kritische und wichtige Probleme. Zudem wurden bedeutende Optimierungen in der Speichernutzung vorgenommen, die sowohl die Effizienz als auch die Leistung verbessern.
Ein weiterer wichtiger Punkt: etcd ist nun Teil von Kubernetes als SIG (sig-etcd). Dies wird uns helfen, die Nachhaltigkeit des Projekts zu verbessern. Wir haben systematische Robustheitstests eingeführt, um die Korrektheit und Zuverlässigkeit sicherzustellen. Durch die etcd-Operator Working Group planen wir außerdem, die Benutzerfreundlichkeit zu verbessern.
Hier sind die wichtigsten Änderungen in etcd v3.6.0, sowie eine Diskussion über den Fahrplan für die zukünftige Entwicklung. Eine detaillierte Liste der Änderungen finden Sie im CHANGELOG-3.6.
Ein herzlicher Dank geht an alle Mitwirkenden, die diese Veröffentlichung möglich gemacht haben!
Sicherheit wird bei etcd großgeschrieben. Um die Sicherheit der Software in v3.6.0 zu verbessern, haben wir unseren Workflow durch die Integration von govulncheck zur Überprüfung des Quellcodes und trivy zur Überprüfung von Container-Images optimiert. Diese Verbesserungen wurden auch auf unterstützte stabile Releases zurückportiert.
etcd folgt weiterhin dem Security Release Process um sicherzustellen, dass Schwachstellen ordnungsgemäß verwaltet und behoben werden.
Der v2store wurde seit etcd v3.4 als veraltet betrachtet, konnte jedoch weiterhin über --enable-v2 aktiviert werden. Er blieb die Datenquelle für Mitgliedschaftsinformationen. In etcd v3.6.0 kann der v2store jedoch nicht mehr aktiviert werden, da das Flag --enable-v2 entfernt wurde und der v3store die einzige Quelle für Mitgliedschaftsdaten geworden ist.
Obwohl der v2store in v3.6.0 noch existiert, wird etcd nicht starten, wenn er Daten enthält, die nicht Mitgliedschaftsinformationen sind. Um bei der Migration zu helfen, bietet etcd v3.5.18+ den Befehl etcdutl check v2store, der überprüft, ob der v2store nur Mitgliedschaftsdaten enthält.
Im Vergleich zum v2store bietet der v3store bessere Leistung und Transaktionsunterstützung. Er ist auch die aktiv gewartete Speicher-Engine für die Zukunft.
Die Entfernung des v2store ist noch im Gange und wird in issues/12913 verfolgt.
etcd v3.6.0 ist die erste Version, die das Downgrade vollständig unterstützt. Der Aufwand für diese Downgrade-Aufgabe erstreckt sich über die Versionen 3.5 und 3.6, und alle zugehörigen Arbeiten werden in issues/11716 verfolgt.
Auf hoher Ebene umfasst der Prozess die Migration des Datenschemas zur Zielversion (z. B. v3.5), gefolgt von einem schrittweisen Downgrade. Stellen Sie sicher, dass der Cluster gesund ist, und erstellen Sie ein Snapshot-Backup. Überprüfen Sie, ob das Downgrade gültig ist:
$ etcdctl downgrade validate 3.5
Downgrade validate success, cluster version 3.6
Wenn das Downgrade gültig ist, aktivieren Sie den Downgrade-Modus:
$ etcdctl downgrade enable 3.5
Downgrade enable success, cluster version 3.6
etcd migriert dann das Datenschema im Hintergrund. Nach Abschluss fahren Sie mit dem schrittweisen Downgrade fort. Für Details siehe den Downgrade-3.6.
In etcd v3.6.0 haben wir Kubernetes-ähnliche Feature-Gates zur Verwaltung neuer Funktionen eingeführt. Zuvor wurden instabile Funktionen durch das Präfix --experimental in den Namen der Feature-Flags angezeigt. Dieses Präfix wurde entfernt, sobald die Funktion stabil war, was zu einer Breaking Change führte. Jetzt starten Funktionen in Alpha, entwickeln sich zu Beta und dann GA oder werden veraltet. Dies sorgt für ein viel reibungsloseres Upgrade- und Downgrade-Erlebnis für die Benutzer.
Weitere Details finden Sie unter feature-gates.
Wir bei ayedo unterstützen Sie gerne bei der Implementierung von etcd in Ihren Kubernetes-Projekten und helfen Ihnen, die neuen Möglichkeiten optimal zu nutzen!
Quelle: Kubernetes Blog
Profitieren Sie von skalierbarem App Hosting in Kubernetes, hochverfügbarem Ingress Loadbalancing und erstklassigem Support durch unser Plattform Team. Mit der ayedo Cloud können Sie sich wieder auf das konzentrieren, was Sie am besten können: Software entwickeln.
Kubernetes ist der De-facto-Standard für die Container-Orchestrierung, aber wenn es um den Umgang mit spezialisierter Hardware wie GPUs und anderen Beschleunigern geht, wird es kompliziert. In diesem …
In Branchen, in denen Systeme äußerst zuverlässig laufen müssen und strenge Leistungsanforderungen bestehen, wie beispielsweise in der Telekommunikation, Hochleistungs- oder KI-Computing, benötigen …
Interessiert an weiteren Inhalten? Hier gehts zu allen Blogs →
