Zajrzyj pod maskę OpenShifta i odkryj sekret repozytorium Origin

Jeśli pracowałeś z OpenShiftem lub instalowałeś jego darmową dystrybucję OKD, z pewnością natknąłeś się na repozytorium openshift/origin. W erze OpenShifta 3 i wczesnych wydań 4.x to tutaj znajdowało się serce całej platformy. Deweloperzy klonowali ogromną część kodu Kubernetes i budowali na nim swoje komponenty.

Ale jeśli zajrzysz do tego repozytorium dziś, nie zobaczysz już dawnej struktury. Nie znajdziesz tu znajomych plików kontrolerów, ani kodu źródłowego binarki hyperkube. Gdzie wszystko się podziało i dlaczego Red Hat utrzymuje projekt z prawie dziewięcioma tysiącami gwiazdek?

Gdzie trafił kod źródłowy OpenShifta

Latem 2020 roku, przed wydaniem OpenShifta 4.6, zespół deweloperski przeszedł reorganizację. Monolityczne podejście stało się przeszkodą: synchronizowanie zmian z upstreamowym Kubernetesem w jednym miejscu, obok własnych testów, było zbyt skomplikowane.

W rezultacie kod został podzielony:

• Cała praca z forkiem Kubernetes i budowanie binarek takich jak hyperkube przeniosła się do repozytorium openshift/kubernetes.
• Repozytorium openshift/origin stało się wyspecjalizowanym hubem testowym.

Teraz głównym celem Origina jest służenie jako dom dla binarki openshift-tests i zestawu scenariuszy e2e, które weryfikują zgodność klastra ze standardami OpenShifta i Kubernetes.

Jak działa testowanie end-to-end w openshift-tests

Budowanie testów w tym projekcie nie ma nic wspólnego z uruchamianiem zwykłych testów go test. Tutaj kompilowana jest pełnoprawna binarka openshift-tests, wyposażona w setki scenariuszy integracyjnych i e2e.

Zespół OpenShifta ma ścisłą zasadę pisania testów e2e. Dwa różne testy nie powinny duplikować swojej funkcjonalności w więcej niż 10%. Zapomnij o skrupulatnym sprawdzaniu każdego błędu walidacji w API. Celem tych testów jest podążanie za prawdziwą ścieżką użytkownika od początku do końca: wdrożenie aplikacji, weryfikacja działania polityk sieciowych, sprawdzenie poprawności routingu i zbieranie metryk.

Binarkę testową możesz skompilować jednym poleceniem z korzenia projektu:

make

Wynikowa binarka może uruchamiać zarówno standardowe testy zgodności Kubernetes, jak i wąskie testy specyficzne dla komponentów Red Hat.

Selektory środowiskowe zamiast adnotacji

Dawniej, aby pominąć niekompatybilny test w określonej konfiguracji klastra, inżynierowie dołączali adnotacje bezpośrednio w kodzie Go. Tworzyło to chaos podczas aktualizacji.

W nowoczesnych gałęziach Origina adnotacje zostały wyeliminowane. Teraz filtrowanie jest kontrolowane przez tak zwane selektory środowiskowe (environment selectors). Framework sprawdza parametry docelowego klastra przed uruchomieniem (takie jak typ dostawcy sieci czy platforma chmurowa) i na bieżąco filtruje nieodpowiednie testy.

Logika wykluczeń jest podzielona na dwa poziomy:

• Wyjątki dla standardowych testów Kubernetes znajdują się w openshift/kubernetes w plikach environment_selectors.go i disabled_tests.go.
• Reguły dla testów specyficznych dla OpenShifta żyją bezpośrednio w Origin, w katalogu pkg/test/extensions.

Jeśli piszesz własny operator dla OpenShifta, ten schemat ułatwia zrozumienie, dlaczego dany test upstreamowy nie uruchamia się w Twoim środowisku.

Synchronizacja zależności i pułapki z sumami kontrolnymi Go

Ponieważ origin zależy od forka openshift/kubernetes, deweloperzy muszą stale aktualizować moduły Go. Aby uniknąć robienia tego ręcznie, do projektu dodano skrypt hack/update-kube-vendor.sh.

Możesz uruchomić aktualizację vendora dla konkretnej gałęzi lub commita SHA w ten sposób:

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

Skrypt może pobierać zmiany nawet z niezmergowanych pull requestów. Aby to zrobić, przekaż adres swojego forka jako drugi argument:

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

Pracując z tym skryptem, łatwo natknąć się na niemiły błąd. Proxy sum kontrolnych Go (sum.golang.org) czasami zwraca 410 Gone, jeśli commit został właśnie utworzony i baza danych sum kontrolnych nie zdążyła go jeszcze zindeksować.

Wygląda to tak:

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

Rozwiązanie jest proste — wymuś wyłączenie weryfikacji bazy danych sum kontrolnych podczas aktualizacji vendora:

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

Szybkie uruchamianie zewnętrznych przykładów

Oprócz testów, w repozytorium pozostał użyteczny skrypt hack/update-external-example.sh. Pobiera on aktualne manifesty aplikacji i przewodniki szybkiego startu z repozytoriów zewnętrznego ekosystemu i umieszcza je w folderze examples.

Jeśli potrzebujesz sprawdzonych przykładów Deployment, Route czy StatefulSet dla OpenShifta, warto zajrzeć do folderu examples/quickstarts — zawiera zweryfikowane konfiguracje.

Kto korzysta dziś z repozytorium Origin

Jeśli tylko zarządzasz klastrem OpenShift, nie będziesz musiał codziennie grzebać w kodzie Origina. Ale projekt będzie nieoceniony w trzech przypadkach:

• Piszesz własne operatory lub rozszerzenia platformy i chcesz uruchamiać oficjalne testy e2e w swoim pipeline CI/CD.
• Przyczyniasz się do rozwoju OKD lub debugujesz niestandardną kompilację Kubernetes dla konkretnego sprzętu.
• Chcesz zobaczyć, jak architektura testowania systemów rozproszonych w Go jest implementowana w dużych projektach komercyjnych.

Repozytorium jest otwarte na licencji Apache 2.0, a aktywna społeczność utrzymuje gałęzie dla wszystkich aktualnych wersji platformy.