W dzisiejszym artykule skupimy się na już dosyć dobrze zadomowionej zarówno w chmurze publicznej, jak i prywatnych firmowych serwerowniach wersji 3.11 platformy Red Hat OpenShift. Jakkolwiek obecnie największe prace rozwojowe trwają nad wersją 4, to jednak ciągle można ocenić tę platformę jako relatywnie nową i jeszcze nie zawsze chętnie wdrażaną.
’Trójka’ zyskała już status ‘wygrzanej’, jednak mimo to, klienci pragnący produktu już dobrze sprawdzonego w bojach mogą podczas instalacji czy rekonfiguracji produktu natknąć się na kilka od razu nieoczywistych problemów. W poniższym artykule postaramy się zasygnalizować metodycznie najbardziej popularne z nich. Podpowiemy, na co zwrócić uwagę przy instalacji platformy, wspominając problemy zarówno charakterystyczne dla tej wersji, jak i te bardziej ‘uniwersalne’, do których sposób diagnostyki i naprawy mógłby być identyczny, jak w przypadku wersji 4.
Generalnie, sam proces instalacji tego produktu, jeśli chodzi o wiedzę na jego temat, w wersji 3 ma dosyć duży ‘próg wejścia’, tzn. już na etapie instalacji trzeba dysponować dosyć sporą wiedzą na temat jego działania, aby zrobić to poprawnie, a już na pewno sensownie.
Pod tym względem, na pewno różni się od innych produktów Red Hat typu np. RHV, IPA, Satellite, czy nawet swojego młodszego brata – OpenShifta w wersji 4. Tam, jakkolwiek wymagana jest wiedza z zakresu szeregu serwerów, usług (PXE, dhcp, dns, haproxy) to jednak nie jest potrzebny aż taki poziom świadomości dotyczącej już samej platformy kontenerowej i jej specyfiki wraz z logiką działania i znajomością wewnętrznych mechanizmów.
Zacznijmy od początku, czyli od tzw. prerequisites. Skorzystamy tutaj z https://docs.openshift.com/container-platform/3.11/install/host_preparation.html. Tą obszerną i dobrze napisaną dokumentacją będziemy się posiłkować także na kolejnych etapach instalacji. Na tym etapie najważniejsza sprawa to poprawne skonfigurowanie serwera DNS dla naszych maszyn wchodzących w skład przyszłego klastra OpenShift.
Jeżeli którykolwiek node nie będzie rozwiązywany lub to rozwiązanie DNS będzie niepoprawne, instalator zwróci błąd. Niestety, nie będzie to wcale na tak początkowym etapie, jak tego byśmy sobie tego życzyli. Podobnie z błędami w plikach /etc/hostname i /etc/hosts. Oczywiście nazwy maszyn w tych plikach muszą być spójne. Playbook ansibowy o nazwie prerequisites.yml generalnie sprawdzi nam komunikację między hostami, zainstaluje niezbędne paczki, skonfiguruje firewalla oraz doker-storage.
Ten ostatni element jednak mimo wszystko dobrze jest konfigurować ‘ręcznie’, tworząc dedykowaną volume grupę oraz ustawiając opcje sterownika filesystemu dla lokalnego rejestru Dockera. Czy chcemy korzystać z overlay2, czy może ‘standardowego’ devicemappera? Jakie fizyczne wolumeny będą wchodziły w skład docker-vg i czy w ogóle zachowujemy tę standardową nazwę? Dobrze odpowiedzieć sobie na te lub podobne pytania jeszcze przed uruchomieniem wspomnianego playbooka.
Gdy już to zrobimy, a jego wykonanie przebiegnie pomyślnie, jesteśmy gotowi na właściwą instalację, a więc tak naprawde zadania realizowane przez playbook deploy_cluster.yml. Wracając do problemów z DNS, hostsami czy hostname’em to niestety podczas jego wykonania mogą one dopiero się objawić.
Jakkolwiek ‘drobniejsze kwestie’ typu niemożności ściągnięcia potrzebnych obrazów doker, paczek, niespełnienia wymagań minimalnych, firewalla czy jakieś proste braki komunikacyjne pomiędzy węzłami da się dosyć łatwo wychwycić w niemalże dosłownych komunikatach błędów playbooka ansible, o tyle w przypadku błędów DNS komunikaty te nie są po prostu zbyt informacyjne.
Najpopularniejszy i zarazem jeden z trudniejszych do diagnostyki błąd to etap rozstawiania openshiftowego SDN. Jeśli DNS działa niepoprawnie lub mamy np. literówkę we wspomnianym pliku hosts instalacja może zakończyć się niepowodzeniem. Błąd ‘Control plane pods didn’t come up’ nie od razu zwraca naszą uwagę na wspomniane dolegliwości. Konkretnie chodzi tu o pody w projekcie kube-system, które nie mogą się poprawnie rozłożyć.
Tak naprawdę, w niektórych przypadkach może brakować nawet pliku konfiguracyjnego SDN-a (openshift-sdn.conf) w /etc/cni/net.d/. Generalnie jednak control-plane pods to pody api, controllers i etcd. O ich poprawne rozstawienie należy zadbać w pierwszej kolejności.
Temat sieciowych problemów jest chyba jednym z najtrudniejszych do diagnozowania, gdyż na jego etapie nie mamy jeszcze rozłożonych wielu elementów funkcjonalnych samego klastra, które ułatwiają nam diagnostykę. Z ważniejszych, należy też zwrócić uwagę na potrzebę poprawnego zweryfikowania konfiguracji dnsmasq, pliku /etc/resolv.conf oraz plików interfejsów sieciowych, które modyfikowane są podczas instalacji.
Zasadniczo, dopóki nie mamy możliwości sprawdzenia poprawności rozstawienia niektórych podów funkcyjnych poprzez ‘oc describe pod’ oraz inwestygacje logów Dockera poszczególnych obrazów pozostaje jedynie weryfikacja odpowiednich wpisów w /etc/oring/master lub /etc/origin/node, np. /etc/origin/node/resolv.conf. Na tym etapie, również ‘zwykły’ /var/log/messages będzie informacyjny i powiadomi nas o nieprawidłowościach np.:
May 15 04:11:15 okd-master1 origin-node: E0515 04:11:15.274491 2678 pod_workers.go:186] Error syncing pod 88b813b8-8d86-11ea-98f6-001a4a16015f ("sdn-fdlnf_openshift-sdn(88b813b8-8d86-11ea-98f6-001a4a16015f)"), skipping: timeout expired waiting for volumes to attach or mount for pod "openshift-sdn"/"sdn-fdlnf". list of unmounted volumes=[sdn-token-dn7wr]. list of unattached volumes=[host-config host-sysconfig host-modules host-var-run host-var-run-dbus host-var-run-ovs host-var-run-kubernetes host-var-run-openshift-sdn host-opt-cni-bin host-etc-cni-netd host-var-lib-cni-networks-openshift-sdn sdn-token-dn7wr]
May 15 04:11:44 okd-master1 origin-node: E0515 04:11:44.168789 2678 cni.go:260] Error adding network: OpenShift SDN network process is not (yet?) available
May 15 04:11:44 okd-master1 origin-node: E0515 04:11:44.170348 2678 cni.go:228] Error while adding to cni network: OpenShift SDN network process is not (yet?) available
May 15 04:11:45 okd-master1 origin-node: E0515 04:11:45.433168 2678 cni.go:260] Error adding network: OpenShift SDN network process is not (yet?) available
May 15 04:11:45 okd-master1 origin-node: E0515 04:11:45.434584 2678 cni.go:228] Error while adding to cni network: OpenShift SDN network process is not (yet?) avaGdy odpowiednie pody funkcyjne będą już gotowe można sprawdzać ich poprawność rozstawienia (czy w ogóle są w statusie ‘Running’) czy ich powołanie spotkało się z jakimiś problemami.
Innym ważnym momentem jest tzw. joining, czyli przyłączanie wszystkich węzłów i formowanie klastra. Jeśli błędne wykonanie playbooka doeploy_cluster.yml informuje nas o potrzebie uruchomienia specyficznego playbooka ze ścieżki /usr/share/ansible/openshift-ansible/playbooks/, np. bootstrap – warto w takiej sytuacji ręcznie sprawdzić, czy zaaprobowane są wszystkie certyfikaty klienckie (oc get csr), wszystkie node’y mają zainstalowane odpowiednie paczki (output /var/log/yum/ porównać z innymi, ‘poprawnymi’ węzłami oraz zweryfikować czy aktualne ustawienia sieci pozwalają na komunikację hosta z pozostałymi.
Czasami, szczególnie w środowiskach labowych i testowych, które są dosyć ubogie w przydzielone zasoby sprzętowe z przyczyn obciążenia tych zasobów (highIOPressure, HighMemoryPressure), istnieje konieczność ponownego uruchomienia playbooka. Na samą koncentrację operacji I/O należy być szczególnie przygotowanym przy diagnostyce poprawności rozłożenia podów etcd. Przy standardowych ustawieniach, operując na minimum 3 masterach i jeszcze ‘talerzowych’ dyskach natężenie operacji wejścia/wyjścia może dawać się we znaki.
Pozostając przy operacjach dyskowych, jednakże płynnie przechodząc do ustawień persystentnego storeage’u, warto zwrócić uwagę na 2 fakty.
Pierwszy – nieco bardziej oczywisty to poważne rozważenie instalacji Docker-registry serwowanego z NFS, nawet w przypadkach testowych. Otóż nawet w wersji 3.11 pojawiało się sporo problemów ze źle previsionowanymi PV i PVC dla tego kontenera w przypadku, gdy było to robione właśnie z wykorzystaniem leciwego już serwera plików.
Pomijając fakt, że aby instalacja w ogóle zakończyła się pomyślnie, należy użyć opcji openshift_enable_unsupported_configurations=true to jeszcze mogą pojawić się wspomniane problemy z nieprawidłowym wykonaniem playbooka. Przechodząc do supportowanych instalacji, to należy pamiętać, że instalacja storage jest jedyną, ale jednak nieidempotentną instalacją w całym klastrze.
To znaczy, tworząc np. bricki pod instalację glusterfs (zarówno w trybie convergent, jak i independent), tworzymy jednocześnie odpowiednie znaczniki i metadane na urządzeniach fizycznych, a nawet uruchomienie skryptu uninstall.yml nie pozwoli na ich usunięcie. Trzeba wtedy robić to ręcznie, a cały proces instalacji po prostu zostaje przerwany.
Czy to problematyczne? Tak, jeśli nie pamiętamy sekwencji kolejnych playbooków z katalogu /usr/share/ansible/openshift-ansible/playbooks, które należy wykonać w celu ‘dokończenia’ instalacji, jeśli działanie zbiorczego deploy_cluster.yml zostanie przerwane.
Gdy już uda nam się przejść przez etap ustawień sieci, instalacji i konfiguracji pakietów, rozstawiania podów control plane, przyłączania węzłów, ustawiania storag’u, konfiguracji i provisionowania webconsoli i service-catalogu instalator powinien nas uszczęśliwić podsumowaniem z zieloną czcionką:
PLAY RECAP ***************************************************************************
localhost : ok=13 changed=0 unreachable=0 failed=0
ocp-int.ipa.linuxpolska.pl : ok=29 changed=6 unreachable=0 failed=0
okd-master1.ipa.linuxpolska.pl : ok=779 changed=327 unreachable=0 failed=0
okd-master2.ipa.linuxpolska.pl : ok=304 changed=113 unreachable=0 failed=0
okd-master3.ipa.linuxpolska.pl : ok=304 changed=113 unreachable=0 failed=0
okd-node1.ipa.linuxpolska.pl : ok=130 changed=32 unreachable=0 failed=0
okd-node2.ipa.linuxpolska.pl : ok=134 changed=59 unreachable=0 failed=0
okd-node3.ipa.linuxpolska.pl : ok=130 changed=32 unreachable=0 failed=0INSTALLER STATUS **********************************************************************
Initialization : Complete (0:01:11)
Health Check : Complete (0:00:14)
Node Bootstrap Preparation : Complete (0:08:15)
etcd Install : Complete (0:01:45)
Load Balancer Install : Complete (0:00:33)
Master Install : Complete (0:10:21)
Master Additional Install : Complete (0:03:44)
Node Join : Complete (0:05:06)
GlusterFS Install : Complete (0:18:24)
Hosted Install : Complete (0:03:29)
Web Console Install : Complete (0:01:59)
Console Install : Complete (0:01:42)
Service Catalog Install : Complete (0:05:59)
[root@okd-master1 ~]#