Klaster OKD (OpenShift) na maszynach wirtualnych Proxmox – Uruchomienie maszyn Control-Plane

Klaster OKD (OpenShift) na maszynach wirtualnych Proxmox

Funkcje maszyn Control-Plane (master) w klastrze

Węzeł (node) control-plane (inaczej master) w klastrze OKD (OpenShift Kubernetes Distribution) to główny komponent odpowiedzialny za zarządzanie i koordynowanie całościowych operacji klastra. Te węzły hostują krytyczne usługi i komponenty wymagane do utrzymania funkcjonalności klastra i zapewnienia, że ​​obciążenia są planowane i zarządzane efektywnie.

Kluczowe cechy węzła płaszczyzny sterowania:

Centralne zarządzanie:

Płaszczyzna sterowania działa jak mózg klastra OKD, zarządzając stanem klastra, konfiguracją i koordynacją obciążeń.
Krytyczne usługi: Węzły płaszczyzny sterowania hostują podstawowe komponenty Kubernetes i OpenShift:

Serwer API (kube-apiserver): Zapewnia interfejs REST API do komunikacji między komponentami klastra i użytkownikami (kubectl, UI itp.).
etcd: Rozproszony magazyn wartości kluczowych, który przechowuje całą konfigurację, stan i metadane klastra.
Menedżer kontrolera (kube-controller-manager): Zarządza kontrolerami, które obsługują różne zadania klastra, takie jak stan węzła, replikacja i zbieranie śmieci.
Harmonogram (kube-scheduler): Przypisuje obciążenia (pody) do odpowiednich węzłów roboczych na podstawie dostępności zasobów i zasad harmonogramowania.
Składniki specyficzne dla OpenShift:
Operator wersji klastra
Stos monitorujący (np. Prometheus i Alertmanager)
Wysoka dostępność:

Wysoko dostępny klaster OKD zazwyczaj ma wiele węzłów płaszczyzny sterowania (np. 3 lub 5 węzłów), aby zapewnić redundancję i odporność.
Jeśli jeden węzeł płaszczyzny sterowania ulegnie awarii, inne mogą kontynuować zarządzanie klastrem bez przestoju.
Interakcja z węzłami roboczymi:

Węzły płaszczyzny sterowania wydają instrukcje węzłom roboczym, aby uruchamiały obciążenia.
Ciągle monitorują węzły robocze pod kątem metryk kondycji i wydajności.
Zarządzanie stanem klastra:

Węzły płaszczyzny sterowania ciągle uzgadniają pożądany stan klastra (zgodnie z definicją w manifestach YAML, wdrożeniach itp.) z jego rzeczywistym stanem. Zapewniają one prawidłowe działanie kontenerów, usług i innych zasobów.
Wymagania dotyczące hostingu:

Węzły płaszczyzny sterowania są zazwyczaj bardziej zasobochłonne niż węzły robocze, ponieważ uruchamiają wiele podstawowych komponentów.
W środowisku produkcyjnym często uruchamiają dedykowane obciążenia i nie są wykorzystywane do hostowania kontenerów aplikacji.

Przygotowanie maszyny wirtualnej Control-Plane (master)

Wykorzystany 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 3 nowe maszyny wirtualne o id 4051 ,4052,4053 i nazwie control-plane-1,control-plane-2,control-plane-3– 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 addressy maszyn do /etc/dnsmasq.d/vnet na maszynie LXC dnsmasq.

Instalacja maszyn Control-Plane (master)

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/master.ign

Wpisujemy ręcznie powyższe parametry kernela

Czekamy na instalację systemu

Na koniec czeka nas jeszcze 1 dodatkowy restart i przejście do ekranu logi. Pod spodem jednak następuje szereg akcji, w której maszyna próbuje dołączyć do klastra. Dlatego ważne jest śledzenie logów i postępu instalacji.

Więcej informacji o śledzeniu postępu instalacji maszyn control-plane-x (master) można znaleźć tutaj https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-zakonczenie-instalacji/

LPNazwa DNSAdres ipvCPUvRAMvHDDSystem OperacyjnyFunkcja
1dns1.okdlab.local192.168.40.1022 GB16 GBFedora Server 41DNS dla klastra
2storage.okdlab.local192.168.40.2024 GB128 GBFedora Server 41Storage NFS dla klastra
2bootstrap.testcluster.okdlab.local192.168.40.30416 GB128 GBFedora CoreOS 39Bootstrap node
3bastion.okdlab.local192.168.40.4044 GB128 GBFedora Server 41Haproxy Load balancer / instalacja
4control-plane-1.testcluster.okdlab.local192.168.40.51416 GB128 GBFedora CoreOS 39Master node
5control-plane-2.testcluster.okdlab.local192.168.40.52416 GB128 GBFedora CoreOS 39Master node
6control-plane-3.testcluster.okdlab.local192.168.40.53416 GB128 GBFedora CoreOS 39Master node
7compute-1.testcluster.okdlab.local192.168.40.61416 GB128 GBFedora CoreOS 39Worker node
8compute-2.testcluster.okdlab.local192.168.40.62416 GB128 GBFedora CoreOS 39Worker node