Klaster OKD (OpenShift) na maszynach wirtualnych Proxmox
- część 1 https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-przygotowanie-dns/
- część 2 https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-przygotowanie-maszyny-bastion/
- część 3 https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-przygotowanie-maszyny-storage-nfs/
- część 4 https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-uruchomienie-maszyny-bootstrap/
- część 5 https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-uruchomienie-maszyn-control-plane/
- część 6 https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-uruchomienie-maszyn-compute/
- część 7 https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-zakonczenie-instalacji/
Przygotowanie maszyny wirtualnej Bootstrap
Węzeł bootstrap w klastrze OKD (OpenShift Kubernetes Distribution) to tymczasowy węzeł odpowiedzialny za inicjowanie procesu instalacji i provisioningu klastra. Odgrywa on kluczową rolę w bootstrappingu płaszczyzny sterowania i zapewnia, że komponenty klastra są wdrażane i konfigurowane poprawnie. Obraz systemu Fedora CoreOS 39 jest do pobrania z tego linku https://ftp.pcss.pl/linux/coreos/fedora-coreos-39.20231101.3.0-live.x86_64.iso . Po przegraniu obrazu na isostore Proxmoxa możemy rozpocząć instalację systemu. Obraz ten jest nam potrzebny jedynie do momentu wpisania parametrów kernela. Dalsza instalacja odbywa się bowiem z udostępnionego pliku http://192.168.40.40:8080/okd4/fcos.raw.xz
Tworzymy nową maszynę wirtualną o id 4030 i nazwie bootstrap z podanymi parametrami:
- Machine : q35, Qemu Agent (włączone)
- 128 GB HDD, SCSI VirtIO Single, Cache: Write Back
- 4 vCPU – 2 x Sockets, Enable NUMA (włączone) , Type: Host
- 16 GB RAM , Balloning Device (włączone)
- Bridge: vmbr4, Model: VirtIO
Przed pierwszym uruchomieniem kopiujemy MAC address maszyny do /etc/dnsmasq.d/vnet na maszynie LXC dnsmasq.
Instalacja maszyny Bootstrap
Zaraz po uruchomieniu maszyny wirtualnej i widoku Console w Proxmox należy wcisnąć TAB i wpisać poniższe parametry uruchomienia kernela
coreos.inst.install_dev=/dev/sda coreos.inst.image_url=http://192.168.40.40:8080/okd4/fcos.raw.xz coreos.inst.ignition_url=http://192.168.40.40:8080/okd4/bootstrap.ign
Wpisujemy ręcznie powyższe parametry kernela.
Nie ma możliwości wklejenia ich do okna.
Czekamy na zakończenie instalacji systemu na dysku /dev/sda
Pod koniec czeka nas jeszcze 1 dodatkowy restart i maszyna oczekuje na dołączenie kolejnych maszyn control-plane-x i compute-x do klastra.
Maszyna bootstrap służy jedynie do zbudowania klastra i po jego utworzeniu będzie mogła być usunięta / wyłączona aby zwolnić zasoby.
| LP | Nazwa DNS | Adres ip | vCPU | vRAM | vHDD | System Operacyjny | Funkcja |
|---|---|---|---|---|---|---|---|
| 1 | dns1.okdlab.local | 192.168.40.10 | 2 | 2 GB | 16 GB | Fedora Server 41 | DNS dla klastra |
| 2 | storage.okdlab.local | 192.168.40.20 | 2 | 4 GB | 128 GB | Fedora Server 41 | Storage NFS dla klastra |
| 2 | bootstrap.testcluster.okdlab.local | 192.168.40.30 | 4 | 16 GB | 128 GB | Fedora CoreOS 39 | Bootstrap node |
| 3 | bastion.okdlab.local | 192.168.40.40 | 4 | 4 GB | 128 GB | Fedora Server 41 | Haproxy Load balancer / instalacja |
| 4 | control-plane-1.testcluster.okdlab.local | 192.168.40.51 | 4 | 16 GB | 128 GB | Fedora CoreOS 39 | Master node |
| 5 | control-plane-2.testcluster.okdlab.local | 192.168.40.52 | 4 | 16 GB | 128 GB | Fedora CoreOS 39 | Master node |
| 6 | control-plane-3.testcluster.okdlab.local | 192.168.40.53 | 4 | 16 GB | 128 GB | Fedora CoreOS 39 | Master node |
| 7 | compute-1.testcluster.okdlab.local | 192.168.40.61 | 4 | 16 GB | 128 GB | Fedora CoreOS 39 | Worker node |
| 8 | compute-2.testcluster.okdlab.local | 192.168.40.62 | 4 | 16 GB | 128 GB | Fedora CoreOS 39 | Worker node |
Weryfikacja poprawności działania maszyny bootstrap
# z maszyny bastion po zakończonej instalacji maszyny bootstrap gdy pojawi się na niej login curl https://api-int.testcluster.okdlab.local:22623/config/master # jeśli jest błąd podobny do poniższego curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to api-int.testcluster.okdlab.local:22623 # to z maszyny bastion połączyć się przez SSH do bootstrap ssh -i /home/bastuser/ssh/id_ed25519 [email protected] # i podejrzeć logi journalctl -f -u bootkube.service # lub journalctl -b -f -u release-image.service -u bootkube.service
W powyższym przykładzie był błąd w polu pullSecret w manifeście Kubernetes który był utworzony na maszynie bastion w /home/bastuser/install_dir/install-config.yaml.
Po poprawieniu błędu należy po usunięciu wszystkich plików w /install_dir z wyjątkiem install-config.yaml uruchomić ponownie openshift-install create manifests –dir=install_dir oraz
openshift-install create ignition-configs –dir=install_dir/ i wgrać poprawioną wersją /install_dir na /var/www/okd4. Po wszystkim zrestartować usługę systemctl restart bootkube.service i kontynuować instalację klastra.
Wszelkie komunikaty typu unable to pull świadczą o tym, że popełniliśmy błąd we wpisywaniu parametrów kernela przy starcie np. ins zamiast inst lub niedostępności adresu http://192.168.40.40:8080/okd4/fcos.raw.xz lub http://192.168.40.40:8080/okd4/bootstrap.ign
Wszelkie komunikaty typu Get „https://quay.io/v2/”: dial tcp: lookup quay.io: no such host, świadczą o tym, że nie poprawnie działa nasza usługa DNS dla klastra i zapytanie przekazane do dns z maszyny bootstrap nie są poprawnie osbługiwane a nazwy rozwiązywane.
# w razie błędów typu Get "https://quay.io/v2/": dial tcp: lookup quay.io: no such host # na maszynie bootstrap curl -v https://quay.io/v2/ # na maszynie z DNS curl -v https://quay.io/v2/ nslookup quay.io
Jeśli wszystko przebiegło poprawnie to w logach maszyna bootstrap będzie widoczne coś takiego
to następnie rozpocznie się proces tworzenie klastra i oczekiwanie na dołączenie kolejnych maszyn wirtualnych czyli nodów master i worker.
