Klaster OKD (OpenShift) na maszynach wirtualnych Proxmox

IT Admin > Konteneryzacja > OpenShift > Klaster OKD (OpenShift) na maszynach wirtualnych Proxmox – Przygotowanie maszyny Bastion

Spis treść

Przygotowanie maszyny wirtualnej Bastion

Maszyna bastion posłuży nam do następujących celów:

przygotowania plików instalacyjnych do postawienia klastra
zarządzania klastrem po jego instalacji
tworzenia projektów OpenShift i zarządzanie nimi
uruchomienia usługi HAProxy z load balancer

Obraz systemu Fedora Server 41 jest do pobrania z tego linku https://fedoraproject.org/server/download.
Po przegraniu obrazu na isostore Proxmoxa możemy rozpocząć instalację systemu.

Tworzymy nową maszynę wirtualną o id 4040 i nazwie bastion 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
4 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

Podajemy nazwę hosta: bastion.okdlab.local

Ustawiamy hasło dla root-a.
Tworzymy także nowego użytkownika: bastuser

Wybieramy w Software selection: Guest Agent

Aktualizacja systemu

logujemy się na maszynie bastion jako bastuser i przeprowadzamy wszelkie administracyjne operacje przez sudo.

sudo dnf update -y

Instalacja przydatnego oprogramowania (do wyboru)

# oprogramowanie użytkowe
sudo dnf install mc git screen wget nano unzip ncdu bzip2 bc vim lynx nmap sshpass -y

# oprogramowanie testujące 
sudo dnf install sysbench stress vnstat sysstat htop atop iftop btop nmon glances -y

# klient FUSE
sudo dnf install sshfs -y

# klient NFS
sudo dnf install nfs-utils -y

# klient SMB/CIFS
sudo dnf install cifs-utils -y

Ustawienie konfiguracji sieciowej

Aby poprawnie działało lokalne rozwiązywanie nazw należy wyłączyć split dns usuwając usługę systemd-resolved

sudo systemctl status systemd-resolved
sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved
# usunąć link
sudo rm /etc/resolv.conf
# utworzyć od nowa
sudo vim /etc/resolv.conf
search okdlab.local
nameserver 192.168.40.10
# restart servera
sudo reboot

Od tej pory to usługa NetworkManager przejmie generowanie /etc/resolv.conf. Jeśli tego nie zrobiliśmy wcześniej to należy również ustawić tutaj statystyczny adres ip używając polecenia.

sudo nmcli connection modify enp6s18 ipv4.addresses 192.168.40.40/24 ipv4.gateway 192.168.40.1 ipv4.dns 192.168.40.10 ipv4.method manual
systemctl restart NetworkManager

Sprawdzenie komunikacji z serwerem DNS dns1.okdlab.local

Przed przystąpieniem do dalszych kroków należy dokładnie sprawdzić rozwiązywanie nazw przez nasz serwer dns1.okdlab.local próbując na różne sposoby odczytać zwracane przez narzędzia dig, nslookup czy ping informacje.

# sprawdzenie konfiguracji DNS
resolvectl
# sprawdzenie działania reverse dns (rekordy PTR)
dig -x 192.168.40.51
# sprawdzenie działania forward dns
nslookup compute-1.testcluster.okdlab.local

Instalacja środowiska graficznego Xfce

W dalszych etapach konfiguracji klastra konieczne będzie skorzystanie z przeglądarki www uruchomionej na maszynie bastion z bezpośrednim dostępem do klastra. Więcej informacji o samym Xfce https://fedoraproject.org/wiki/Xfce

sudo dnf install @xfce-desktop-environment
# automatyczne uruchomienie środowiska graficznego
sudo systemctl set-default graphical.target
# włączenie dostępu zdalnego przez protokół rdp np. ze stacji Windows
sudo dnf install -y xrdp tigervnc-server
sudo systemctl enable xrdp --now
# zezwolenie na połączenia na porcie 3389
sudo firewall-cmd --permanent --add-port=3389/tcp
sudo firewall-cmd --reload
# przygotowanie automatycznego uruchamiania sesji Xfce dla aktualnego użytkownika
vim ~/startwm.sh
#!/bin/sh
dbus-launch --exit-with-session /usr/bin/startxfce4
# nadanie uprawnień
sudo chmod 755 ~/startwm.sh
sudo reboot

W razie problemów z połączeniem zajrzeć do logów

sudo tail -f /var/log/xrdp.log
sudo tail -f /var/log/xrdp-sesman.log

Jeśli połączenie przez protokół rdp działa poprawnie to instalujemy przeglądarkę chromium.
Więcej informacji o instalacji chrome w systemie Fedora https://docs.fedoraproject.org/en-US/quick-docs/installing-chromium-or-google-chrome-browsers/

sudo dnf install chromium

Instalacja i konfiguracja HAProxy

Jak działa przepływ ruchu:

Frontend: Każdy frontend nasłuchuje na określonym porcie (np. 6443, 80, 443) i obsługuje przychodzące żądania.
Backend: Gdy frontend odbierze ruch, przekazuje go do odpowiedniego backendu. Backend równoważy obciążenie ruchem na zestawie serwerów na podstawie określonego algorytmu równoważenia (np. źródła równowagi).
Kontrole kondycji: Opcja sprawdzania zapewnia, że HAProxy wykonuje regularne kontrole kondycji na serwerach, aby upewnić się, że są dostępne.

Równoważenie obciążenia:

Opcja źródła równowagi zapewnia, że ruch z określonego źródłowego adresu IP jest kierowany do tego samego serwera backendu, co jest przydatne do utrzymania trwałości sesji.

Rejestrowanie:

Ruch jest rejestrowany za pomocą tcplog, zapewniając szczegółowe logi połączeń.
Sekcja statystyk umożliwia monitorowanie HAProxy za pośrednictwem strony statystyk na porcie 9000.
Ta konfiguracja służy do równoważenia obciążenia różnych usług w środowisku Kubernetes lub OKD (OpenShift), w tym interfejsu API Kubernetes, serwerów konfiguracji maszyn i ruchu przychodzącego HTTP/HTTPS.

sudo dnf install haproxy -y

Przygotowanie konfiguracji dla HAProxy

global
    maxconn     20000
    log         /dev/log local0 info
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    user        haproxy
    group       haproxy
    daemon

    # turn on stats unix socket
    stats socket /var/lib/haproxy/stats

defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          300s
    timeout server          300s
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 20000

listen stats
    bind :9000
    mode http
    stats enable
    stats uri /

frontend okd4_k8s_api_fe
    bind :6443
    default_backend okd4_k8s_api_be
    mode tcp
    option tcplog

backend okd4_k8s_api_be
    balance source
    mode tcp
    server      bootstrap 192.168.40.30:6443 check
    server      control-plane-1 192.168.40.51:6443 check
    server      control-plane-2 192.168.40.52:6443 check
    server      control-plane-3 192.168.40.53:6443 check

frontend okd4_machine_config_server_fe
    bind :22623
    default_backend okd4_machine_config_server_be
    mode tcp
    option tcplog

backend okd4_machine_config_server_be
    balance source
    mode tcp
    server      bootstrap 192.168.40.30:22623 check
    server      control-plane-1 192.168.40.51:22623 check
    server      control-plane-2 192.168.40.52:22623 check
    server      control-plane-3 192.168.40.53:22623 check

frontend okd4_http_ingress_traffic_fe
    bind :80
    default_backend okd4_http_ingress_traffic_be
    mode tcp
    option tcplog

backend okd4_http_ingress_traffic_be
    balance source
    mode tcp
    server      compute-1 192.168.40.61:80 check
    server      compute-2 192.168.40.62:80 check

frontend okd4_https_ingress_traffic_fe
    bind *:443
    default_backend okd4_https_ingress_traffic_be
    mode tcp
    option tcplog

backend okd4_https_ingress_traffic_be
    balance source
    mode tcp
    server      compute-1 192.168.40.61:443 check
    server      compute-2 192.168.40.62:443 check

Przed uruchomieniem HAProxy należy ustawić parametry SELinux

sudo setsebool -P haproxy_connect_any 1

lub go całkowicie wyłączyć

sudo sudo sed -i 's/^SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config
sudo reboot

Włączenie usługi HAProxy

sudo systemctl enable haproxy
sudo systemctl start haproxy
sudo systemctl status haproxy

Zezwolenie na ruch sieciowy w firewallu

sudo firewall-cmd --permanent --add-port=6443/tcp
sudo firewall-cmd --permanent --add-port=22623/tcp
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

Instalacja i konfiguracja serwera httpd (Apache)

Usługa http pozwoli na wystawienie plików manifestu Kubernetes i konfiguracji ignition dla instalacji maszyn potrzebnych do zbudowania klastra OKD (OpenShift) tj. bootstrap, control-plane, compute.

sudo dnf install -y httpd
sudo sed -i 's/Listen 80/Listen 8080/' /etc/httpd/conf/httpd.conf

# jeśli mamy włączone SELinux
sudo setsebool -P httpd_read_user_content 1
# uruchomienie usługi
sudo systemctl enable httpd
sudo systemctl start httpd
# dodanie zezwolenie ruchu na porcie 8080 na firewallu
sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload
# test działania serwera httpd
curl localhost:8080

Pobranie instalatora i klienta OpenShift

Aktualne wersje instalatora oraz klienta OpenShift znajdują się tutaj https://github.com/okd-project/okd/releases/

cd /home/bastuser/Downloads
# pobranie aktualnych wersji
wget https://github.com/okd-project/okd/releases/download/4.15.0-0.okd-2024-03-10-010116/openshift-install-linux-4.15.0-0.okd-2024-03-10-010116.tar.gz
wget https://github.com/okd-project/okd/releases/download/4.15.0-0.okd-2024-03-10-010116/openshift-client-linux-4.15.0-0.okd-2024-03-10-010116.tar.gz
# rozpakowanie archiwum
tar -zxvf openshift-client-linux-4.15.0-0.okd-2024-03-10-010116.tar.gz
tar -zxvf openshift-install-linux-4.15.0-0.okd-2024-03-10-010116.tar.gz
# skopiowanie binarek do właściwego katalogu
sudo mv kubectl oc openshift-install /usr/local/bin/
# sprawdzenie wersji
oc version
openshift-install version

Sprawdzenie zalecanej wersji Fedora CoreOS

Należy koniecznie sprawdzić jaką wersję Fedora CoreOS należy wykorzystać do instalacji klastra OKD z pobraną wersję openshift-install.

openshift-install coreos print-stream-json

W tym przykładzie widać, że powinniśmy użyć wersji Fedora CoreOS 39.20231101.3.0

Więcej informacji na ten temat można znaleźć pod adresem https://github.com/okd-project/okd/blob/master/FAQ.md#which-fedora-coreos-should-i-use

Przygotowanie klucza SSH

ssh-keygen

W definicji manifestu Klastra install-config.yaml będziemy używali klucza publicznego z pliku .ssh/id_ed25519.pub

Pobranie pullsecret.txt z RedHat

Logujemy się na portalu https://console.redhat.com/openshift/create/local i pobieramy pull secret.

Przygotowanie manifestu Kubernetes dla klastra OKD

# tworzymy katalog dla plików roboczych
mkdir -p /home/bastuser/install_dir/
# tworzymy konfigurację dla manifestu Kubernetes
nano  /home/bastuser/install_dir/install-config.yaml

W pole sshKey należy wkleić zawartość /home/bastuser/.ssh/id_ed25519.pub
W pole pullSecret należy wkleić dokładnie całą zawartość pullsecret

apiVersion: v1
baseDomain: okdlab.local
metadata:
  name: testcluster
platform:
  none: {}
pullSecret: '{"auths":{"cloud.openshift.com":{"auth":"b3BxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxdVTlVEOQ==","email":"[email protected]"},"quay.io":{"auth":"b3BxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxdVTlVEOQ==","email":"[email protected]"},"registry.connect.redhat.com":{"auth":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxx==","email":"[email protected]"},"registry.redhat.io":{"auth":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx==","email":"[email protected]"}}}'
sshKey: 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDGy5Fc6Dl8m3cezP5nNOq2jHPTyNJFJdeY+AQ7awOqP [email protected]'
compute:
- hyperthreading: Enabled
  name: worker
  replicas: 0
controlPlane:
  hyperthreading: Enabled
  name: master
  replicas: 3
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  networkType: OVNKubernetes
  serviceNetwork:
  - 172.30.0.0/16
fips: false

Wykonujemy kopię powyższego pliku, gdyby była potrzeba powtórzenia tworzenia manifestu.

cp /home/bastuser/install_dir/install-config.yaml /home/bastuser/install_dir/install-config.yaml.bak

Tworzymy manifest Kubernetes

cd /home/bastuser
openshift-install create manifests --dir=install_dir/

Przygotowanie konfiguracji ignitions

Należy wyłączyć scheduling dla podów na workerach czyli maszynach wirtualnych control-plane-x

cd /home/bastuser
sed -i 's/mastersSchedulable: true/mastersSchedulable: False/' install_dir/manifests/cluster-scheduler-02-config.yml

Teraz można przygotować konfigurację ignitions

cd /home/bastuser
openshift-install create ignition-configs --dir=install_dir/

Katalog install_dir powinien wyglądać mniejwięcej tak.

OpenShift, ignition-configs odnoszą się do plików konfiguracyjnych Ignition używanych podczas wdrażania i inicjalizacji klastrów OpenShift, szczególnie w OpenShift Container Platform 4.x. Ignition to narzędzie provisioningowe używane przez CoreOS (obecnie Fedora CoreOS i RHEL CoreOS), które są systemami operacyjnymi zaprojektowanymi specjalnie dla środowisk kontenerowych.

Te pliki konfiguracyjne Ignition odgrywają kluczową rolę w automatyzacji konfiguracji i konfiguracji węzłów klastra podczas procesu instalacji.

Kluczowe punkty dotyczące Ignition-Configs

Cel:

Ignition-configs definiują sposób konfiguracji węzłów w klastrze OpenShift (np. bootstrap, płaszczyzna sterowania i węzły obliczeniowe) podczas uruchamiania.
Określają działania, takie jak konfiguracja pamięci masowej, konfiguracja sieci, zapisywanie plików i stosowanie konfiguracji systemd.
Generowane przez instalator:

Podczas procesu instalacji OpenShift narzędzie openshift-install generuje pliki konfiguracyjne Ignition na podstawie określonych ustawień klastra.

Trzy kluczowe pliki Ignition:

bootstrap.ign:
Służy do konfigurowania węzła bootstrap, który odgrywa kluczową rolę podczas początkowej konfiguracji klastra (np. bootstrapping płaszczyzny sterowania).
master.ign:
Służy do konfigurowania węzłów płaszczyzny sterowania (masterów), które zarządzają podstawowymi komponentami klastra i API.
worker.ign:
Służy do konfigurowania węzłów roboczych, które uruchamiają obciążenia aplikacji (pody).

Udostępnienie konfiguracji do instalacji klastra przez serwer www

sudo mkdir /var/www/html/okd4
sudo cp -R install_dir/* /var/www/html/okd4/
sudo chown -R apache: /var/www/html/
sudo chmod -R 755 /var/www/html/

# test dostepnosci plikow przez serwer www
curl localhost:8080/okd4/metadata.json

Pobranie obrazów z podpisem systemu CoreOS

cd /var/www/html/okd4/
wget https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/39.20231101.3.0/x86_64/fedora-coreos-39.20231101.3.0-metal.x86_64.raw.xz
wget https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/39.20231101.3.0/x86_64/fedora-coreos-39.20231101.3.0-metal.x86_64.raw.xz.sig

# zmiana nazwy na krotsza
sudo mv fedora-coreos-39.20231101.3.0-metal.x86_64.raw.xz fcos.raw.xz
sudo mv fedora-coreos-39.20231101.3.0-metal.x86_64.raw.xz.sig fcos.raw.xz.sig

# nadanie uprawnień do plików
sudo chown -R apache: /var/www/html/
sudo chmod -R 755 /var/www/html/

Maszyna bastion jest teraz gotowa do serwowania plików instalacyjnych przez http potrzebnych do zbudowania klastra.

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

Klaster OKD (OpenShift) na maszynach wirtualnych Proxmox – Przygotowanie maszyny Bastion