Unter der Haube von OpenShift: Das Geheimnis des Origin-Repositorys enthüllt

Wer mit OpenShift gearbeitet oder die freie Distribution OKD installiert hat, ist unweigerlich auf das openshift/origin-Repository gestoßen. In der Ära von OpenShift 3 und den frühen 4.x-Versionen befand sich hier das Herzstück der gesamten Plattform. Entwickler klonen einen Großteil des Kubernetes-Codebase und bauten ihre Komponenten darauf auf.

Wenn Sie heute jedoch dieses Repository aufrufen, finden Sie dort nicht mehr die alte Struktur vor. Keine vertrauten Controller-Dateien, kein Quellcode für die hyperkube-Binärdatei. Wohin ist alles verschwunden, und warum pflegt Red Hat ein Projekt mit fast neuntausend Stars?

Wohin ist der OpenShift-Quellcode verschwunden

Im Sommer 2020, vor der Veröffentlichung von OpenShift 4.6, reorganisierte das Entwicklungsteam seine Arbeit. Der monolithische Ansatz war zum Hindernis geworden: Änderungen mit dem Upstream-Kubernetes an einem Ort zu synchronisieren, zusammen mit eigenen Tests, war zu kompliziert geworden.

Daher wurde der Codebase aufgeteilt:

• Gesamte Arbeit mit dem Kubernetes-Fork und das Erstellen von Binärdateien wie hyperkube wurde in das openshift/kubernetes-Repository verschoben.
• Das openshift/origin-Repository wurde in ein spezialisiertes Test-Hub umgewandelt.

Heute dient Origin hauptsächlich als Heimat für die openshift-tests-Binärdatei und eine Sammlung von e2e-Szenarien, die die Konformität des Clusters mit OpenShift- und Kubernetes-Standards überprüfen.

Wie End-to-End-Tests in openshift-tests funktionieren

Tests in diesem Projekt zu erstellen hat nichts mit dem Ausführen regulärer go test zu tun. Hier wird eine vollwertige openshift-tests-Binärdatei kompiliert, die Hunderte von Integrations- und e2e-Szenarien enthält.

Das OpenShift-Team hat eine strenge Regel für das Schreiben von e2e-Tests. Zwei verschiedene Tests sollten ihre Funktionalität nicht um mehr als 10% duplizieren. Vergessen Sie das akribische Überprüfen jedes Validierungsfehlers in der API. Der Zweck dieser Tests ist es, eine echte Benutzerreise von Anfang bis Ende zu durchlaufen: eine Anwendung bereitstellen, Netzwerkrichtlinien überprüfen, Routing korrekt sicherstellen und Metriken sammeln.

Sie können das Test-Tool mit einem einzigen Befehl aus dem Projektstammverzeichnis kompilieren:

make

Die resultierende Binärdatei kann sowohl standardmäßige Kubernetes-Konformitätstests als auch eng spezifische Prüfungen für Red-Hat-Komponenten ausführen.

Umgebungsauswahl statt Annotationen

In der Vergangenheit hängten Entwickler Annotationen direkt im Go-Code an, um einen inkompatiblen Test für eine bestimmte Cluster-Konfiguration zu überspringen. Dies führte während Upgrades zu Chaos.

In modernen Origin-Branches wurden Annotationen abgeschafft. Jetzt wird die Filterung durch sogenannte Umgebungsauswahl (Environment Selectors, environment selectors) gesteuert. Das Framework prüft vor der Ausführung die Parameter des Zielclusters (wie Netzwerkanbietertyp oder Cloud-Plattform) und filtert unpassende Tests dynamisch heraus.

Die Ausschlusslogik ist auf zwei Ebenen aufgeteilt:

• Ausnahmen für standardmäßige Kubernetes-Tests befinden sich in openshift/kubernetes in den Dateien environment_selectors.go und disabled_tests.go.
• Regeln für OpenShift-spezifische Tests befinden sich direkt in Origin im Verzeichnis pkg/test/extensions.

Wenn Sie Ihren eigenen Operator für OpenShift schreiben, macht dieses Schema es einfach zu verstehen, warum ein bestimmter Upstream-Test in Ihrer Umgebung nicht ausgeführt wird.

Abhängigkeitssynchronisierung und Go-Checksummen-Fallstricke

Da origin von einem Fork von openshift/kubernetes abhängt, müssen Entwickler ständig Go-Module aktualisieren. Um dies nicht manuell tun zu müssen, wurde ein hack/update-kube-vendor.sh-Skript zum Projekt hinzugefügt.

Sie können Vendor-Updates für einen bestimmten Branch oder SHA-Commit so ausführen:

./hack/update-kube-vendor.sh master

Das Skript kann Änderungen sogar aus nicht zusammengeführten Pull-Requests abrufen. Dazu übergeben Sie Ihre Fork-Adresse als zweites Argument:

./hack/update-kube-vendor.sh my-feature-branch github.com/myname/kubernetes

Bei der Arbeit mit diesem Skript stößt man leicht auf einen unangenehmen Fehler. Go's Checksum-Proxy (sum.golang.org) gibt manchmal 410 Gone zurück, wenn ein Commit gerade erstellt wurde und die Checksum-Datenbank ihn noch nicht indexiert hat.

Es sieht so aus:

go: k8s.io/[email protected] ... 410 Gone
        server response: not found

Die Lösung ist einfach – deaktivieren Sie die Prüfung der Checksum-Datenbank während der Vendor-Updates zwangsweise:

GOSUMDB=off hack/update-kube-vendor.sh master

Externe Beispiele schnell ausführen

Neben Tests bleibt ein nützliches hack/update-external-example.sh-Skript im Repository. Es lädt aktuelle Anwendungsmanifeste und Quick Starts aus Repositorys des Drittanbieter-Ökosystems herunter und platziert sie im examples-Ordner.

Wenn Sie funktionierende Beispiele für Deployment, Route oder StatefulSet für OpenShift benötigen, lohnt es sich, den examples/quickstarts-Ordner zu überprüfen – er enthält verifizierte Konfigurationen.

Wer profitiert heute vom Origin-Repository

Wenn Sie nur einen OpenShift-Cluster betreiben, müssen Sie nicht täglich im Origin-Code graben. Aber das Projekt ist in drei Fällen äußerst hilfreich:

• Sie entwickeln Ihre eigenen Operatoren oder Plattformerweiterungen und möchten offizielle e2e-Prüfungen in Ihrer CI/CD-Pipeline ausführen.
• Sie tragen zur OKD-Entwicklung bei oder debuggen einen benutzerdefinierten Kubernetes-Build für spezifische Hardware.
• Sie möchten sehen, wie eine Testarchitektur für verteilte Systeme in Go in groß angelegten kommerziellen Projekten implementiert ist.

Das Repository ist unter der Apache-2.0-Lizenz open source, und eine aktive Community pflegt Branches für alle aktuellen Plattformversionen.