Sotto il cofano di OpenShift: scopriamo i segreti del repository Origin

Se hai lavorato con OpenShift o installato la sua distribuzione gratuita OKD, ti sarai sicuramente imbattuto nel repository openshift/origin. Nell'era di OpenShift 3 e delle prime release 4.x, qui viveva il core dell'intera piattaforma. Gli sviluppatori clonavano una parte massiccia del codebase Kubernetes qui e costruivano i loro componenti sopra di esso.

Ma se vai in questo repository oggi, non vedrai la vecchia struttura lì. Nessun file controller familiare, nessun codice sorgente per il binario hyperkube. Dove è andato a finire tutto, e perché Red Hat mantiene un progetto con quasi novemila stelle?

Dove è finito il codice sorgente di OpenShift

Nell'estate del 2020, prima del rilascio di OpenShift 4.6, il team di sviluppo si è riorganizzato. L'approccio monolitico era diventato un ostacolo: sincronizzare le modifiche con il Kubernetes upstream in un unico posto insieme ai loro test era diventato troppo complicato.

Di conseguenza, il codebase è stato diviso:

• Tutto il lavoro con il fork di Kubernetes e la compilazione dei binari come hyperkube è stato spostato nel repository openshift/kubernetes.
• Il repository openshift/origin è stato trasformato in un hub di test specializzato.

Ora lo scopo principale di Origin è quello di fungere da casa per il binario openshift-tests e un insieme di scenari e2e che verificano la conformità del cluster agli standard di OpenShift e Kubernetes.

Come funziona il testing end-to-end in openshift-tests

La compilazione dei test nel progetto non ha nulla a che fare con l'esecuzione dei normali go test. Qui viene compilato un binario openshift-tests completo, con all'interno centinaia di scenari di integrazione ed e2e.

Il team OpenShift ha una regola rigorosa per la scrittura dei test e2e. Due test diversi non devono duplicare la funzionalità l'uno dell'altro per più del 10%. Dimentica di controllare meticolosamente ogni errore di validazione nell'API. Lo scopo di questi test è seguire il percorso di un vero utente dall'inizio alla fine: distribuire un'applicazione, verificare che le policy di rete funzionino, assicurarsi che il routing sia corretto e raccogliere le metriche.

Puoi compilare lo strumento di test con un singolo comando dalla root del progetto:

make

Il binario risultante può eseguire sia i test di conformità standard di Kubernetes che i controlli specifici ristretti per i componenti Red Hat.

Selettori di ambiente invece di annotazioni

In passato, per saltare un test incompatibile su una configurazione di cluster specifica, gli ingegneri allegavano le annotazioni direttamente nel codice Go. Questo creava caos durante gli upgrade.

Nelle branch moderne di Origin, le annotazioni sono state eliminate. Ora il filtraggio è controllato dai cosiddetti selettori di ambiente (environment selectors). Il framework esamina i parametri del cluster di destinazione prima dell'esecuzione (come il tipo di provider di rete o la piattaforma cloud) e filtra i test non idonei al volo.

La logica di esclusione è suddivisa in due livelli:

• Le eccezioni per i test standard di Kubernetes si trovano in openshift/kubernetes nei file environment_selectors.go e disabled_tests.go.
• Le regole per i test specifici di OpenShift risiedono direttamente in Origin nella directory pkg/test/extensions.

Se stai scrivendo il tuo operatore per OpenShift, questo schema rende facile capire perché un particolare test upstream non viene eseguito nel tuo ambiente.

Sincronizzazione delle dipendenze e inconvenienti con il checksum Go

Poiché origin dipende da un fork di openshift/kubernetes, gli sviluppatori devono costantemente aggiornare i moduli Go. Per evitare di farlo manualmente, è stato aggiunto al progetto uno script hack/update-kube-vendor.sh.

Puoi eseguire gli aggiornamenti vendor per una branch o un commit SHA specifico in questo modo:

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

Lo script può prelevare modifiche anche da pull request non ancora unite. Per farlo, passa l'indirizzo del tuo fork come secondo argomento:

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

Quando si lavora con questo script, è facile incappare in un fastidioso errore. Il proxy checksum di Go (sum.golang.org) a volte restituisce 410 Gone se un commit è stato appena creato e il database dei checksum non ha ancora avuto il tempo di indicizzarlo.

Si presenta così:

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

La soluzione qui è semplice: disabilita forzatamente la verifica del database dei checksum durante gli aggiornamenti vendor:

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

Esecuzione rapida di esempi esterni

Oltre ai test, nel repository rimane uno script hack/update-external-example.sh utile. Scarica manifest aggiornati di applicazioni e quick starts da repository di ecosistemi di terze parti e li colloca nella cartella examples.

Se hai bisogno di esempi funzionanti di Deployment, Route o StatefulSet per OpenShift, vale la pena controllare la cartella examples/quickstarts: contiene configurazioni verificate.

Chi beneficia del repository Origin oggi

Se ti limiti a gestire un cluster OpenShift, non avrai bisogno di scavare nel codice di Origin ogni giorno. Ma il progetto sarà di grande aiuto in tre casi:

• Stai scrivendo i tuoi operatori o estensioni della piattaforma e vuoi eseguire i controlli e2e ufficiali nella tua pipeline CI/CD.
• Stai contribuendo allo sviluppo di OKD o eseguendo il debug di una build Kubernetes personalizzata per hardware specifico.
• Vuoi vedere come viene implementata l'architettura di testing dei sistemi distribuiti in Go nei progetti commerciali su larga scala.

Il repository è aperto sotto licenza Apache 2.0 e una comunità attiva gestisce le branch per tutte le attuali versioni della piattaforma.