Sous le capot d'OpenShift : à la découverte du secret du dépôt Origin

Si vous avez travaillé avec OpenShift ou installé sa distribution gratuite OKD, vous avez certainement croisé le dépôt openshift/origin. À l'époque d'OpenShift 3 et des premières versions 4.x, c'était là que résidait le cœur de toute la plateforme. Les développeurs y clonaient une grande partie du code Kubernetes et construisaient leurs composants par-dessus.

Mais si vous vous rendez sur ce dépôt aujourd'hui, vous n'y trouverez plus l'ancienne structure. Plus de fichiers de contrôleurs familiers, plus de code source pour le binaire hyperkube. Où tout cela est-il passé, et pourquoi Red Hat maintient-il un projet avec près de neuf mille étoiles ?

Où est passé le code source d'OpenShift

Durant l'été 2020, avant la sortie d'OpenShift 4.6, l'équipe de développement s'est réorganisée. L'approche monolithique était devenue un obstacle : synchroniser les modifications avec Kubernetes en amont au même endroit que leurs propres tests était devenu trop complexe.

En conséquence, la base de code a été divisée :

• Tout le travail avec le fork Kubernetes et la construction des binaires comme hyperkube a été déplacé vers le dépôt openshift/kubernetes.
• Le dépôt openshift/origin est devenu un centre de tests spécialisé.

Désormais, le but principal d'Origin est de servir de foyer au binaire openshift-tests et à un ensemble de scénarios e2e qui vérifient la conformité des clusters aux normes OpenShift et Kubernetes.

Comment fonctionne le test de bout en bout dans openshift-tests

La construction des tests dans le projet n'a rien à voir avec l'exécution de go test classique. Ici, un binaire openshift-tests complet est compilé,，里面包含了数百个集成和e2e场景。

L'équipe OpenShift applique une règle stricte pour l'écriture des tests e2e. Deux tests différents ne doivent pas se dupliquer mutuellement dans plus de 10 % de leurs fonctionnalités. Oubliez la vérification méticuleuse de chaque erreur de validation dans l'API. Le but de ces tests est de suivre le parcours réel d'un utilisateur du début à la fin : déployer une application, vérifier que les politiques réseau fonctionnent, s'assurer que le routage est correct et collecter les métriques.

Vous pouvez compiler l'outil de test avec une seule commande depuis la racine du projet :

make

Le binaire résultant peut exécuter à la fois les tests de conformité Kubernetes standard et les vérifications spécifiques aux composants Red Hat.

Les sélecteurs d'environnement à la place des annotations

Auparavant, pour ignorer un test incompatible sur une configuration de cluster spécifique, les ingénieurs attachaient des annotations directement dans le code Go. Cela créait du chaos lors des mises à niveau.

Dans les branches Origin modernes, les annotations ont été éliminées. Maintenant, le filtrage est contrôlé par des soi-disant sélecteurs d'environnement (environment selectors). Le framework examine les paramètres du cluster cible avant l'exécution (comme le type de fournisseur réseau ou la plateforme cloud) et filtre les tests inadaptés à la volée.

La logique d'exclusion est divisée en deux niveaux :

• Les exceptions pour les tests Kubernetes standard se trouvent dans openshift/kubernetes dans les fichiers environment_selectors.go et disabled_tests.go.
• Les règles pour les tests spécifiques à OpenShift résident directement dans Origin dans le répertoire pkg/test/extensions.

Si vous écrivez votre propre operator pour OpenShift, ce schéma facilite la compréhension de la raison pour laquelle un test upstream particulier ne s'exécute pas dans votre environnement.

Synchronisation des dépendances et pièges des checksums Go

Comme origin dépend d'un fork de openshift/kubernetes, les développeurs doivent constamment mettre à jour les modules Go. Pour éviter de le faire manuellement, un script hack/update-kube-vendor.sh a été ajouté au projet.

Vous pouvez exécuter les mises à jour vendor pour une branche ou un commit SHA spécifique comme ceci :

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

Le script peut récupérer les modifications même des pull requests non fusionnées. Pour cela, transmettez l'adresse de votre fork comme deuxième argument :

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

En travaillant avec ce script, il est facile de tomber sur une erreur embêtante. Le proxy de checksum de Go (sum.golang.org) retourne parfois 410 Gone si un commit vient d'être créé et que la base de données des checksums n'a pas eu le temps de l'indexer.

Cela ressemble à ceci :

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

La solution ici est simple — désactiver forcé ment la vérification de la base de données des checksums lors des mises à jour vendor :

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

Exécuter rapidement des exemples externes

En plus des tests, un script utile hack/update-external-example.sh reste dans le dépôt. Il télécharge les manifests d'application et les quick starts à jour depuis les dépôts de l'écosystème tiers et les place dans le dossier examples.

Si vous avez besoin d'exemples éprouvés de Deployment, Route ou StatefulSet pour OpenShift, cela vaut le coup de vérifier le dossier examples/quickstarts — il contient des configurations vérifiées.

Qui profite du dépôt Origin aujourd'hui

Si vous utilisez simplement un cluster OpenShift, vous n'aurez pas besoin de fouiller dans le code d'Origin tous les jours. Mais le projet sera d'une grande aide dans trois cas :

• Vous écrivez vos propres operators ou extensions de plateforme et souhaitez exécuter les vérifications e2e officielles dans votre pipeline CI/CD.
• Vous contribuez au développement d'OKD ou déboguez une build Kubernetes personnalisée pour du matériel spécifique.
• Vous souhaitez voir comment l'architecture de test des systèmes distribués en Go est implémentée dans les grands projets commerciaux.

Le dépôt est ouvert sous licence Apache 2.0, et une communauté active maintient des branches pour toutes les versions actuelles de la plateforme.