Onder de motorkap van OpenShift kijken en het geheim van de Origin-repository onthullen

Als je met OpenShift hebt gewerkt of de gratis distributie OKD hebt geïnstalleerd, ben je ongetwijfeld de openshift/origin repository tegengekomen. In het tijdperk van OpenShift 3 en vroege 4.x-releases was dit waar de kern van het hele platform woonde. Ontwikkelaars kloonden hier een enorm deel van de Kubernetes-codebase en bouwden hun componenten er bovenop.

Maar als je vandaag naar deze repository gaat, zie je daar niet de oude structuur. Geen vertrouwde controller-bestanden, geen broncode voor de hyperkube binary. Waar is alles gebleven, en waarom houdt Red Hat een project met bijna negenduizend sterren in stand?

Waar is de OpenShift-broncode gebleven

In de zomer van 2020, vóór de release van OpenShift 4.6, heeft het ontwikkelteam de organisatie aangepast. De monolithische aanpak was een obstakel geworden: het synchroniseren van wijzigingen met upstream Kubernetes op één plek, samen met hun eigen tests, was te ingewikkeld geworden.

Als gevolg hiervan werd de codebase opgesplitst:

• Al het werk met de Kubernetes-fork en het bouwen van binaries zoals hyperkube verhuisde naar de openshift/kubernetes repository.
• De openshift/origin repository werd omgetoverd tot een gespecialiseerde test hub.

Nu is het hoofddoel van Origin om te dienen als thuisbasis voor de openshift-tests binary en een set e2e-scenario's die de cluster-naleving van OpenShift- en Kubernetes-standaarden verifiëren.

Hoe end-to-end testing werkt in openshift-tests

Het bouwen van tests in het project heeft niets te maken met het uitvoeren van reguliere go test. Hier wordt een volwaardige openshift-tests binary gecompileerd, waarin honderden integratie- en e2e-scenario's zijn verpakt.

Het OpenShift-team hanteert een strikte regel voor het schrijven van e2e-tests. Twee verschillende tests mogen elkaars functionaliteit niet meer dan 10% dupliceren. Vergeet het zorgvuldig controleren van elke validatiefout in de API. Het doel van deze tests is om een echte gebruikersreis van begin tot eind te volgen: implementeer een applicatie, verifieer dat netwerkbeleid werkt, zorg dat routing correct is en verzamel metrieken.

Je kunt de testtool compileren met een enkele opdracht vanaf de projectroot:

make

De resulterende binary kan zowel standaard Kubernetes conformance-tests als specifieke controles voor Red Hat-componenten uitvoeren.

Environment selectors in plaats van annotaties

Vroeger plakten engineers annotaties rechtstreeks in de Go-code om een incompatibele test op een specifieke clusterconfiguratie over te slaan. Dit veroorzaakte chaos tijdens upgrades.

In moderne Origin-branches zijn annotaties afgeschaft. Nu wordt het filteren beheerd door zogenaamde environment selectors (environment selectors). Het framework bekijkt de parameters van de doelcluster voordat tests worden uitgevoerd (zoals netwerkprovider-type of cloudplatform) en filtert ongeschikte tests direct uit.

De uitzonderingslogica is opgedeeld in twee niveaus:

• Uitzonderingen voor standaard Kubernetes-tests bevinden zich in openshift/kubernetes in de environment_selectors.go- en disabled_tests.go-bestanden.
• Regels voor OpenShift-specifieke tests staan direct in Origin in de pkg/test/extensions-directory.

Als je je eigen operator voor OpenShift schrijft, maakt dit schema het gemakkelijk om te begrijpen waarom een bepaalde upstream-test niet in jouw omgeving draait.

Dependency-synchronisatie en Go-checksum valkuilen

Omdat origin afhankelijk is van een fork van openshift/kubernetes, moeten ontwikkelaars voortdurend Go-modules bijwerken. Om dit niet handmatig te hoeven doen, is er een hack/update-kube-vendor.sh script aan het project toegevoegd.

Je kunt vendor-updates uitvoeren voor een specifieke branch of SHA-commit als volgt:

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

Het script kan wijzigingen zelfs ophalen uit niet-gemergede pull requests. Geef hiervoor je fork-adres door als tweede argument:

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

Bij het werken met dit script is het gemakkelijk om een vervelende fout tegen te komen. Go's checksum proxy (sum.golang.org) retourneert soms 410 Gone als een commit net is aangemaakt en de checksum-database er nog niet de tijd voor heeft gehad om deze te indexeren.

Het ziet er zo uit:

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

De oplossing hier is simpel — schakel verificatie van de checksum-database geforceerd uit tijdens vendor-updates:

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

Externe voorbeelden snel uitvoeren

Naast tests bevat de repository nog steeds een nuttig hack/update-external-example.sh script. Het downloadt actuele applicatiemanifesten en quick starts uit repositories van derden in het ecosysteem en plaatst ze in de examples-map.

Als je bewezen werkende voorbeelden van Deployment, Route of StatefulSet voor OpenShift nodig hebt, is het de moeite waard om de examples/quickstarts-map te controleren — deze bevat geverifieerde configuraties.

Wie profiteert er vandaag de dag van de Origin-repository

Als je alleen een OpenShift-cluster beheert, hoef je niet dagelijks in de Origin-code te duiken. Maar het project is in drie gevallen een grote hulp:

• Je schrijft je eigen operators of platform-extensies en wilt officiële e2e-controles uitvoeren in je CI/CD-pipeline.
• Je draagt bij aan OKD-ontwikkeling of debugt een aangepaste Kubernetes-build voor specifieke hardware.
• Je wilt zien hoe gedistribueerde systeemtestarchitectuur in Go is geïmplementeerd in grootschalige commerciële projecten.

De repository is open onder de Apache 2.0-licentie en een actieve community onderhoudt branches voor alle huidige platformversies.