Ponowne wdrażanie certyfikatów OKD 3.11

Od początku linii wydań 3.x OpenShift/OKD występują różne problemy z wewnętrznymi certyfikatami. Komunikacja TLS wewnątrz klastra jest używana w wielu miejscach, takich jak router, registry, węzły obliczeniowe, węzły master, etcd i tak dalej. Niestety setki deweloperów na całym świecie dają w efekcie może nie tyle chaos, co niepewność i brak zaufania z perspektywy użytkownika.

CSR powinny być zatwierdzane automatycznie, a nie są:

oc get csr -o name | xargs oc adm certificate approve

W najgorszym scenariuszu trzeba jednak także sprawdzić ważność certyfikatów. Można to zrobić za pomocą playbooka Ansible. Można je pobrać z https://github.com/openshift/openshift-ansible. Trzeba pamiętać, by zawsze robić checkout wersji, którą masz wdrożoną. Użyj taga lub brancha właściwego dla danego wydania. Unikaj uruchamiania playbooków z mastera, ponieważ zawiera on najnowszą wersję, która może być niekompatybilna z Twoją.

Aby sprawdzić ważność, uruchom:

ansible-playbook openshift-checks/certificate_expiry/easy-mode.yaml

Aby ponownie wdrożyć certyfikaty, uruchom to:

ansible-playbook playbooks/redeploy-certificates.yml

Jeśli zakończy się to błędem z powodu wygasłych lub wkrótce wygasających certyfikatów (tak…), musisz ustawić w /etc/ansible/host lub dowolnym innym pliku, którego używasz jako inwentarza:

openshift_certificate_expiry_warning_days=7

I uruchomić sprawdzenie lub ponowne wdrożenie jeszcze raz. Jeśli Twój certyfikat wygasa dziś lub jutro, użyj 0 jako wartości tego parametru. Po ponownym wdrożeniu użyj wartości 10000, aby sprawdzić, czy jakiś certyfikat wygasa. Jest tu kilka błędów, które uniemożliwiają ponowne wdrożenie, a nawet poprawne sprawdzenie ważności certyfikatów, i nie da się znaleźć jednego prawdziwego rozwiązania. Być może jakieś istnieje, ale wymaga subskrypcji Red Hat, by uzyskać dostęp do ich zamkniętego forum.

Po ponownym wdrożeniu i sprawdzeniu, że wszystko jest w porządku albo przynajmniej trochę lepiej, czasem pojawia się problem z uruchomieniem openshift-web-console. Czasami występuje błąd HTTP 502. Sam web-console działa poprawnie, ale nie jest w stanie zarejestrować swojej trasy w routerze HAProxy. Możesz to sprawdzić za pomocą:

oc get service webconsole -n openshift-web-console
curl -vk https://172.x.y.z/console/ # replace x, y and z with your webconsole IP

Jeśli dostaniesz poprawną odpowiedź, musisz ręcznie usunąć i odtworzyć elementy webconsole. Najpierw jednak wypróbuj podstawowe rozwiązania, bo mogą zadziałać:

oc scale --replicas=0 deployment.apps/webconsole
# wait around a minute
oc scale --replicas=1 deployment.apps/webconsole

Jeśli nadal nie ma webconsole:

oc delete secret webconsole-serving-cert
oc delete svc/webconsole
oc delete pod/webconsole-xxx # xxx is your pod ID

OKD powinien automatycznie odtworzyć właśnie usuniętą konfigurację webconsole. Jeśli jednak nadal się to nie udaje, spróbuj uruchomić od zera kompletny playbook odtwarzający webconsole:

ansible-playbook openshift-web-console/config.yml

Na tę chwilę powinieneś odzyskać swój webconsole. Zastanawiam się, czy ta sama niska jakość dotyczy OKD 4.x, ale w przypadku 3.x liczba problemów i dziwactw jest dość wysoka, znacznie wyższa, niż bym się spodziewał.