News

Updates zu unserem Open-Source-Projekt Yaook

Bereits im letzten Newsletter haben wir euch ein technisches Update zu unserem Fokusprojekt Yaook gegeben. Nachfolgend möchten wir euch zu den Neuerungen der letzten drei Monate und aktuellen Entwicklungsständen unseres Open-Source-Lifecycle-Management-Tools informieren.

Features:

• Yaook/K8s: Um mit der sich ändernden URL des Tigera Operators in verschiedenen Versionen von Calico umzugehen, wurde ein neuer Ansatz gewählt. Anstatt das Operator Manifest manuell herunterzuladen und anzuwenden, verwenden wir jetzt ein Helm Chart für die Bereitstellung. Diese Änderung erleichtert uns die Wartung des vorherigen Ansatzes über vergangene und zukünftige Versionen hinweg. Trotz dieser Änderung behalten wir die Flexibilität, das Deployment durch Übergeben einer benutzerdefinierten Wertedatei anzupassen. Dadurch können wir das Deployment gemäß unseren spezifischen Anforderungen anpassen und konfigurieren und gleichzeitig von der Bequemlichkeit und Konsistenz des Helm Charts profitieren.
• Wir haben Unterstützung für die Offline-Installation von Python-Paketen im Yaook/K8s Teilprojekt eingeführt. Diese Ergänzung ermöglicht es den Benutzern, erforderliche Python-Pakete ohne aktive Internetverbindung zu installieren und gewährleistet einen reibungsloseren Installationsprozess. Es gibt ebenso eine Implementierung für das Yaook/Baremetal Projekt, um eine Ausführung ohne Internetverbindung zu ermöglichen.
• Yaook/Operator: Wir freuen uns, die Unterstützung für das Herunterfahren des Hypervisors bei Nova Compute Eviction anzukündigen, um einen lang andauernden Workflow zu vermeiden, bis der Knoten tatsächlich entfernt wird. Diese Funktion verbessert die Fähigkeiten des Operators und bietet eine verbesserte Kontrolle über den Eviction-Prozess. Sie reduziert auch die Auswirkungen eines fehlerhaften Hypervisors auf den Nutzer und beschleunigt den Prozess um ein vielfaches.
  • Dies ist eine neue Funktion namens „Eviction Manager“ in einem System namens NovaDeployment. Der Zweck dieser Funktion besteht darin, den Status von Hypervisoren oder Compute-Services mit Hilfe der Nova API zu überwachen (ein Programm, das beim Verwalten von virtuellen Maschinen hilft). Wenn die Nova API anzeigt, dass ein Hypervisor ausgefallen ist, führt der Eviction Manager folgende Aktionen durch:
    1. Überprüfen, ob der Hypervisor tatsächlich ausgefallen ist, indem vorhandene Prüfungen wie „virsh list“ oder Pingen des Knotens verwendet werden. Wenn festgestellt wird, dass der Hypervisor läuft, schlägt der Job fehl, um einen Alarm auszulösen.
    2. Den Hypervisor mit einem Tool namens Ironic herunterfahren.
    3. Warten, bis alle Sperren, insbesondere solche, die sich auf Volumes beziehen, freigegeben sind. Die Dauer dieses Wartens kann konfiguriert werden. Die Dauer sollte auf der letzten erhaltenen Kommunikation von Nova basieren (sogenanntes „Nova-Heartbeat“).
    4. Den Hypervisor mit der Nova API entfernen, was bedeutet, ihn aus dem System zu entfernen.
  • Um irrtümliches Entfernen gesunder Hypervisoren aufgrund von Netzwerkproblemen oder Ausfällen in der „control plane“ zu verhindern, sollte eine Schwellwert eingestellt werden. Dieser Schwellwert stellt sicher, dass der Evictionsprozess (Beenden von Pods) angehalten wird, wenn zu viele Hypervisoren gleichzeitig als ausgefallen gemeldet werden, um unnötige Evictions zu vermeiden.
  • Letztendlich kann die bestehende Logik für das Eviction- oder Migrationsverfahren unverändert bleiben, da Kubernetes bereits verhindert, dass zwei Eviction-Jobs mit demselben Namen gleichzeitig ausgeführt werden.
• Zudem freuen wir uns, die neueste Ergänzung unserer Cloud-Infrastruktur anzukündigen: die Ironic 2023.1 Version, Codename „Antelope“.
• Yaook/Baremetal: Zusätzliche Flexibilität durch Netbox-Integration: Wir haben Netbox, ein beliebtes Tool für IP-Adressverwaltung und Data Center Infrastructure Management (DCIM), integriert, um die Flexibilität und Erweiterbarkeit des Projekts zu verbessern.

Fixes:

• Hotfix: CVE-2023-1668 – Dieser Hotfix behebt eine kritische Sicherheitslücke in Open vSwitch: Remote Traffic Denial of Service durch manipulierte Pakete mit IP-Protokoll 0. Die Details der Sicherheitslücke sind wie folgt: https://mail.openvswitch.org/pipermail/ovs-discuss/2023-April/052344.html

Mehrere Versionen von Open vSwitch sind anfällig für manipulierte IP-Pakete mit ip proto auf 0 gesetzt, was zu einem potenziellen Denial-of-Service führen kann. Um die Sicherheitslücke auszulösen, müsste ein Angreifer ein manipuliertes IP-Paket mit einem Protokollfeld von 0 und Flow-Regeln mit „set“-Aktionen auf anderen Feldern im IP-Protokollheader senden. Die resultierenden Flows würden erforderliche Aktionen auslassen und das IP-Protokollfeld nicht maskieren, was zu einem großen Bucket führt, in dem alle IP-Pakete erfasst werden.

Alle Versionen von Open vSwitch, mindestens ab 1.5.0, sind betroffen.

• Yaook/Operator: „crash looping“ des OVSDB Relays: Wir haben ein Problem mit einer Absturzschleife der OVSDB Relay-Komponenten behoben, um einen stabileren und zuverlässigeren Betrieb zu gewährleisten. Dies wird durch das Löschen der Datenbank erreicht: „Der Befehl ovsdb-tool create funktioniert nicht, wenn bereits eine Datenbankdatei vorhanden ist.“
  • OVSDB Relay ist ein Tool, das verschiedenen Teilen eines Computernetzwerks hilft, miteinander zu kommunizieren. Es fungiert als Übersetzer oder Vermittler zwischen der Open vSwitch-Datenbank (OVSDB) und anderen Netzwerkgeräten.
  • Open vSwitch Database (OVSDB) ist ein System, das Informationen über die Netzwerkkonfiguration und den Status speichert, z. B. welche Geräte verbunden sind und wie sie kommunizieren sollen.
  • OVSDB Relay überwacht Änderungen in der OVSDB und leitet diese Informationen an andere Netzwerkgeräte weiter, die über diese Änderungen informiert werden müssen. Wenn beispielsweise ein neues Netzwerkgerät der OVSDB hinzugefügt oder daraus entfernt wird, benachrichtigt das OVSDB Relay andere Geräte, damit diese ihre Konfigurationen entsprechend aktualisieren können.
  • Einfach ausgedrückt hilft das OVSDB Relay verschiedenen Teilen eines Netzwerks, durch Übersetzung und Weiterleitung von Informationen zwischen der OVSDB und anderen Geräten synchron zu bleiben und ein einheitliches Verständnis der Netzwerkkonfiguration und des Status zu haben.
• Yaook/Operator: Stabilitätsprobleme mit OVN behoben: Wir haben mehrere Stabilitätsprobleme mit OVN angegangen, um die Zuverlässigkeit und Leistung des Systems weiter zu verbessern.
  • OVN steht für Open Virtual Network. Es handelt sich um eine virtuelle Netzwerktechnologie, die dabei hilft, virtuelle Maschinen (VMs) und Container in einem Computernetzwerk zu verwalten und zu verbinden. OVN basiert auf Open vSwitch, einem Software-Switch, der den Netzwerkverkehr zwischen virtuellen Maschinen verbindet und routet.
  • Einfach ausgedrückt bietet OVN eine Möglichkeit zur Erstellung und Verwaltung virtueller Netzwerke für virtuelle Maschinen und Container. Es hilft dabei, zu kontrollieren, wie diese virtuellen Entitäten miteinander und mit dem physischen Netzwerk kommunizieren. OVN vereinfacht die Konfiguration und Verwaltung virtueller Netzwerke und erleichtert so die Einrichtung und Aufrechterhaltung der Netzwerkverbindung in einer virtualisierten Umgebung.
• Yaook/Baremetal: Behobene Probleme mit Dateiberechtigungen: Während des Docker-Builds verlieren kopierte Dateien ihre ursprünglichen Berechtigungen und erhalten unsichere Berechtigungen wie UMASK 666 oder 777. Diese unsicheren Berechtigungen bleiben beim Deployment bestehen und schaffen Sicherheitsrisiken.
• Yaook/Baremetal: Fehlende Abhängigkeit des pip-Pakets „six“ hinzugefügt: Der Metal Controller stürzt ab, da das aktualisierte Keystoneauth-Paket eine neue Abhängigkeit hinzugefügt hat: https://opendev.org/openstack/keystoneauth/commit/ca28df84808787342303666e1b286dbc5ec88c61
• Yaook/Baremetal: Es wurden Berechtigungen für die pip-Konfiguration korrigiert.
• Yaook/Baremetal: Authentifizierungstoken für Vault korrekt widerrufen: Der Code verursachte Ausnahmen, die den Zugriff auf Vault für den Metal Controller unterbrachen, seit wir hvac auf 0.11.2 aktualisiert haben.
• Diverse weitere Fixes und Fehlerbehebungen

Updates:

• Unterstützung für Kubernetes (K8s) 1.25 und alle kommenden Patch-Versionen hinzugefügt. Mit diesem Update unterstützt Yaook jetzt die neueste Version von Kubernetes und gewährleistet die Kompatibilität mit zukünftigen Patches.
• Unterstützung für Kubernetes-Versionen 1.19 bis 1.23 eingestellt. Um den Fokus auf die neuesten Versionen von Kubernetes zu legen und die Wartungskosten zu senken, haben wir die Unterstützung für ältere Versionen eingestellt. Wir empfehlen den Benutzern, auf die neueste unterstützte Version zu aktualisieren.
• OpenStack-Version aus ovn-bgp-agent entfernt: Um das Projekt zu rationalisieren und zu vereinfachen, haben wir die OpenStack-Versionsabhängigkeit aus der ovn-bgp-agent-Komponente entfernt.
  • „ovn-bgp-agent“ ist eine Komponente des Open Virtual Network (OVN)-Systems, das die Funktionalität des Border Gateway Protocol (BGP) verwaltet. BGP ist ein Protokoll, das in Computernetzwerken zum Austausch von Routing-Informationen zwischen verschiedenen autonomen Systemen (ASes) verwendet wird.
• Verbesserungen der Dokumentation: Wir haben die Projektdokumentation erheblich verbessert und sie umfassender, zugänglicher und benutzerfreundlicher gemacht.
• Erhöhte Sicherheit: Wir haben restriktivere Berechtigungen für kopierte Dateien im Metal-Controller-Image festgelegt, um die allgemeine Sicherheitslage des Projekts zu verbessern.

Ausblick:

Mit Blick auf die Zukunft zielt das Yaook-Projekt darauf ab, mehrere wichtige Herausforderungen anzugehen und aufregende neue Funktionen zu implementieren. Diese beinhalten:

• Upgrade-Pfad für neuere OpenStack-/OVN-Releases: Wir arbeiten aktiv an der Entwicklung eines nahtlosen Upgrade-Pfads für die neuesten OpenStack- und OVN-Releases, um sicherzustellen, dass Benutzer mühelos über die neuesten Entwicklungen auf dem Laufenden bleiben können.
• Stabilität von OVN: Wir sind bestrebt, die Stabilität der OVN-Komponente weiter zu verbessern, wobei wir uns auf die Beseitigung potenzieller Probleme und die Verbesserung der Gesamtleistung konzentrieren.
• Node lifecycle operator für Updates: Um reibungslosere Updates und Wartung zu ermöglichen, prüfen wir die Entwicklung eines Node lifecycle operators. Dieser Operator würde den Prozess der Neuinstallation von Knoten während Updates automatisieren und so die Abläufe für Administratoren optimieren.
• Release-Management: Wir arbeiten derzeit daran, eine robuste Routine, einen Workflow und Tools für das Release-Management des Projekts zu etablieren. Dazu gehört die Implementierung automatisierter Versionshinweise und Dokumentationsaktualisierungen. Da Yaook/K8s in dieser Hinsicht relativ neu ist, werden wir es als „Spielwiese“ nutzen, um zu experimentieren und einen geeigneten Workflow zu finden, der später auf andere Projektkomponenten angewendet werden kann.
• Weiterentwicklung des Yaook/K8s Teilprojekts, um die Integration mit weiteren Kubernetes-Features und Tools zu verbessern.
• Erweiterung der Yaook/Operator-Funktionalität, um die Automatisierung von Routineaufgaben und die Verbesserung der Systemleistung zu ermöglichen.
• Fortsetzung der Arbeit am Yaook/Baremetal-Projekt, um die Unterstützung für verschiedene Hardware- und Infrastrukturplattformen zu erweitern.
• Verbesserung der Dokumentation und der Benutzerfreundlichkeit des gesamten Yaook-Projekts, um die Einführung und den Einsatz für Entwickler und Administratoren zu erleichtern.