Skip to main content

Jak zainstalować Rancher RKE2 Kubernetes na NSIS

RKE2 - Rancher Kubernetes Engine version 2 to dystrybucja Kubernetes dostarczana przez SUSE. Uruchomienie samodzielnie zarządzanego klastra RKE2 w chmurze NSIS jest korzystną opcją, szczególnie dla tych, którzy potrzebują integracji z platformą Rancher i opcji dostosowywania.

Klaster RKE2 można konfigurować z poziomu Rancher GUI. W tym artykule wykorzystujemy jednak Terraform, który umożliwia usprawnione, zautomatyzowane tworzenie klastrów. Używamy również OpenStack Cloud Controller Manager (CCM) do integracji klastra RKE2 z szerszym środowiskiem OpenStack. Korzystanie z niestorazardowej wersji CCM pozwala nam korzystać z natywnych dla chmury funkcji NSIS. Efekt końcowy to:

  • udostępniony klaster RKE2

  • działający pod OpenStack

  • zintegrowany OpenStack Cloud Controller Manager.

Zilustrowaliśmy również zastosowane techniki kodowania, na wypadek jeśli chcesz jeszcze bardziej ulepszać implementację RKE2.

Co zostanie omówione?

  • Przeprowadzenie wstępnej konfiguracji

  • Tworzenie nowego projektu

  • Tworzenie poświadczeń aplikacji

  • Działająca para kluczy

  • Uwierzytelnienie w nowo utworzonym projekcie

  • Użycie konfiguracji Terraform dla RKE2 z repozytorium GitHub CloudFerro

  • Udostępnianie klastra RKE2

  • Demonstracja wbudowanego natywnego równoważenia obciążenia w chmurze

  • Szczegóły wdrożenia

  • Dalsze dostosowywanie

Kod został przetestowany na Ubuntu 22.04.

Wymagania wstępne

Nr 1 Konto

Jest wymagane konto hostingowe NSIS z dostępem do interfejsu Horizon: https://horizon.cloudferro.com.

Nr 2 Terraform dostępny w lokalnym wierszu poleceń

Zobacz artykuł Generowanie i autoryzacja Terraform przy użyciu użytkownika Keycloak na NSIS Cloud

Nr 3 Środowisko wirtualne Python

Jak zainstalować Python virtualenv lub virtualenvwrapper na NSIS Cloud

Nr 4 OpenStack CLI zainstalowany lokalnie

Po zainstalowaniu będziesz mieć dostęp do polecenia openstack i będziesz w stanie komunikować się z chmurą OpenStack:

Nr 5 Narzędzie kubectl zainstalowane lokalnie

Standardowe typy instalacji kubectl są opisane na stronie `Install Tools<https://kubernetes.io/docs/tasks/tools/>`_ na oficjalnej witrynie Kubernetes.

Nr 6 Para kluczy dostępna w OpenStack

Jak utworzyć parę kluczy w OpenStack Dashboard na NSIS Cloud.

Nr 7 Poświadczenia aplikacji

Poniższy artykuł opisuje sposób tworzenia i używania poświadczeń aplikacji przy użyciu interfejsu CLI:

Jak wygenerować lub użyć poświadczeń aplikacji za pośrednictwem CLI na NSIS Cloud

W tym artykule utworzymy poświadczenia aplikacji za pośrednictwem Horizon, ale z określonym wyborem ról użytkowników.

Nr 8 Projekty, role, użytkownicy i grupy

Opcja Identity wyświetla listę dostępnych projektów, ról, użytkowników i grup. Zobacz artykuł Co to jest projekt OpenStack na NSIS Cloud.

Nr 9 Doświadczenie z Kubernetes i Helm

Aby pracować z tym artykułem, musisz mieć ogólną wiedzę na temat Kubernetes. Jeszcze lepsze byłoby praktyczne doświadczenia w korzystaniu z Kubernetes w chmurze NSIS. Aby zapoznać się z serią artykułów na temat Kubernetes, zobacz KUBERNETES.

Aby przeprowadzić instalację wymaganą w tym artykule, jednym z kroków będzie utworzenie Helm CRD i użycie go. Podstawy korzystania z Helm są przedstawione w artykule /kubernetes/Deploying-Helm-Charts-on-Magnum-Kubernetes-Clusters-on-NSIS-Cloud.

Nr 10 Cloud Controller Manager

W ogólnym środowisku Kubernetes „Cloud Controller Manager (CCM) https://kubernetes.io/docs/concepts/architecture/cloud-controller/ pozwala Kubernetes na integrację z API dostawcy chmury. Abstrahuje on logikę specyficzną dla chmury oraz zarządza i synchronizuje zasoby między Kubernetes a bazową infrastrukturą chmury. Zapewnia również kontrolery dla węzłów, tras, usług i woluminów.

W OpenStack CCM integruje się z interfejsami API OpenStack. Użyty tutaj kod pochodzi z konkretnego repozytorium dla Cloud Controller Manager – https://github.com/kubernetes/cloud-provider-openstack. Implementuje on wyżej wymienione, jak również inne integracje OpenStack-Kubernetes.

Nr 11 Repozytorium rke2-terraform

Musisz pobrać repozytorium

w celu zainstalowania manifestów Terraform dla wdrożenia RKE2 na NSIS przy użyciu Terraform.

Nr 12 Dostosowanie konfiguracji chmury dla Terraform

Jednym z plików pobranych z powyższego linku będzie variables.tf. Zacustomize_the_cloud2wiera on definicje regionu, nazwy klastra i wielu innych zmiennych.

../_images/customize_the_cloud1.png
../_images/customize_the_cloud21.png

Krok 1 Przeprowadzenie wstępnej konfiguracji

Naszym celem jest stworzenie klastra Kubernetes działającego w środowisku chmurowym. Pakiety oprogramowania RKE2 zostaną zainstalowane na maszynach wirtualnych w chmurze pełniących role węzłów głównych i roboczych Kubernetes. Utworzonych zostanie również kilka innych zasobów OpenStack.

W ramach wstępnej konfiguracji udostępniania tych zasobów:

  • utworzymy dedykowany projekt OpenStack, aby wyizolować wszystkie zasoby dedykowane dla klastra.

  • Tworzenie poświadczeń aplikacji

  • upewnimy się, że para kluczy jest dołączona dla projektu.

  • pozyskamy lokalnie plik RC dla tego projektu

Poniżej znajduje się instrukcja instalacji projektu, poświadczeń, pary kluczy i lokalnego pobrania pliku RC.

Krok przygotowawczy 1 Utworzenie nowego projektu

Pierwszym krokiem jest utworzenie nowego projektu przy użyciu interfejsu Horizon UI. Kliknij Identity → Projects. Wpisz nazwę projektu na pierwszej karcie:

../_images/image-2024-7-29_9-56-441.png

Na drugiej karcie upewnij się, że użytkownik, jako który pracujesz, został dodany jako członek projektu z rolami: „member”, „load-balancer member” i „creator”.

../_images/image-2024-7-29_9-54-451.png

Następnie kliknij przycisk „Create project”. Po utworzeniu projektu przejdź do kontekstu tego projektu z menu w lewym górnym rogu:

../_images/image-2024-7-23_16-5-281.png

Krok przygotowawczy 2 Utworzenie poświadczeń aplikacji

Następnym krokiem jest utworzenie poświadczeń aplikacji, które będą używane do uwierzytelniania OpenStack Cloud Controller Manager (używanego do automatycznego udostępniania modułu load balancer). Aby je utworzyć, przejdź do menu IdentityApplication Credentials. Wypełnij formularz zgodnie z poniższym przykładem, przekazując wszystkie role dostępne dla tego poświadczenia („member”, „load-balancer_member”, „creator”, „reader”). Ustaw datę wygaśnięcia na datę zapadającą w przyszłości.

../_images/image-2024-7-29_10-2-571.png

Po kliknięciu opcji Create Application Credential należy skopiować w bezpieczne miejsce zarówno identyfikator aplikacji, jak i tajny kod poświadczeń. Okno zostanie wyświetlone tylko raz, więc najlepszym rozwiązaniem jest pobranie plików openrc i clouds.yaml, które będą zawierały wymagane wartości.

../_images/credentials_first_time1.png

Wymaganie wstępne nr7 zawiera kompletny przewodnik dotycząc poświadczeń aplikacji.

Krok przygotowawczy 3 Działająca para kluczy

Zanim przejdziesz dalej, upewnij się, że masz dostępną parę kluczy. Jeśli Masz już parę kluczy w swoim głównym projekcie, będzie ona dostępna również dla nowo utworzonego projektu. Jeśli jeszcze jej nie masz, utwórz ją z lewego menu ProjectComputeKey Pairs. Aby uzyskać więcej informacji, sprawdź Wymagania wstępne nr 6.

Krok przygotowawczy 4 Uwierzytelnienie w nowo utworzonym projekcie

Na koniec należy pobrać z interfejsu graficznego Horizon plik RC odpowiadający nowemu projektowi, a następnie uruchomić ten plik w lokalnym terminalu Linux. Zobacz Wymaganie wstępne nr4.

Krok 2 Użycie konfiguracji Terraform dla RKE2 z repozytorium GitHub CloudFerro

Dodaliśmy folder rke2-terraform do repozytorium CloudFerro K8s-samples GitHub, z Wymagania wstępnego nr11. Ten projekt zawiera pliki konfiguracyjne do utworzenia klastra RKE2 w chmurach CloudFerro i może być używany jako pakiet startowy do dalszych dostosowań do konkretnych wymagań.

../_images/image-2024-7-26_12-36-541.png

W tej sekcji krótko przedstawimy to repozytorium, wyjaśniając zawartość i przeznaczenie poszczególnych plików konfiguracyjnych. Pliki te są rzeczywistymi poleceniami dla Terraform i są zdefiniowane w jego standardowych plikach z rozszerzeniem .tf.

variables.tf

Zawiera kluczowe zmienne określające konfigurację klastra, takie jak liczba węzłów roboczych, region chmury, w którym zostanie umieszczony klaster czy nazwa klastra. Większość z tych zmiennych ma ustawione wartości domyślne, które i można modyfikować bezpośrednio w pliku. Zmienne bez wartości domyślnych (tajny kod, wrażliwe dane) powinny mieć wartości dostarczone osobno, za pomocą pliku tfvars, co wyjaśniono w następnej sekcji.

providers.tf

Służy do deklarowania i konfigurowania dostawców Terraform. W naszym przypadku używamy tylko dostawcy OpenStack, który udostępnia zasoby chmurowe tworzące klaster.

main.tf

Zawiera deklarację zasobów, które mają zostać utworzone przez Terraform. Do utworzenia klastra wymaganych jest kilka zasobów OpenStack, na przykład sieć, podsieć, router, maszyny wirtualne i inne. Przejrzyj plik, aby uzyskać szczegółowe informacje i dostosuj go do swoich preferencji.

security-groups.tf

Zawiera deklarację grup zabezpieczeń i reguł grup zabezpieczeń używanych w OpenStack do otwierania określonych portów na maszynach wirtualnych tworzących klaster. W ten sposób komunikacja z wybranych źródeł zostaje włączona na każdej maszynie wirtualnej. Zmodyfikuj plik, aby dostosować go do własnych potrzeb.

cloud-init-masters.yml.tpl

oraz

cloud-init-workers.yml.tpl

Są to pliki szablonów używane do tworzenia plików cloud-init, które z kolei są używane do uruchamiania utworzonych maszyn wirtualnych i :

  • zapewniają, że na tych maszynach wirtualnych są instalowane określone pakiety ,

  • tworzą i uruchamiają na nich skrypty itp.

Zawartość tych szablonów jest wypełniana na podstawie sekcji user-data w deklaracjach maszyn wirtualnych w pliku main.conf.

Jedną z podstawowych funkcji każdego z plików cloud-init jest instalacja rke2 zarówno na węzłach głównych, jak i roboczych.

Krok 3 Udostępnienie klastra RKE2

Utworzymy teraz klaster RKE2 Kubernetes. Proces będzie się składać z następujących kroków:

  • Klonowanie repozytorium github

  • Dostosowanie wartości domyślnych w pliku variables.tf.

  • Utworzenie pliku terraform.tfvars zawierającego tajne kody

  • Inicjalizacja, planowanie i stosowanie konfiguracji Terraform

  • Użycie pobranego pliku kubeconfig w celu uzyskania dostępu do klastra za pomocą kubectl.

Pierwszym krokiem jest sklonowanie repozytorium github. Klonujemy całe repozytorium, ale pozostawiamy tylko katalog rke2-terraform za pomocą poniższych poleceń:

git clone https://github.com/CloudFerro/K8s-samples
mkdir ~/rke2-terraform
mv ~/K8s-samples/rke2-terraform/* ~/rke2-terraform
rm K8s-samples/ -rf
cd rke2-terraform

Jak wspomniano w sekcji Wymaganie wstępne nr12, sprawdź i ewentualnie zmień wartość ustawień domyślnych w pliku variables.tf, na przykład zmień nazwę klastra, region chmury lub ustawienia maszyny wirtualnej.

W naszym przypadku zachowamy ustawienia domyślne.

Informacja

Płaszczyzna kontrolna o wysokiej dostępności nie jest obecnie obsługiwana przez to repozytorium. Ponadto nie jest obsługiwane ustawienie liczby węzłów głównych na wartość inną niż1.

Wprowadź dane do pliku terraform.tfvars

Następnym krokiem jest utworzenie pliku terraform.tfvars o następującej zawartości:

ssh_keypair_name = "your_ssh_keypair_name"
project_id = "your_project_id"
public_key = "your_public_key"
application_credential_id = "your_app_credential_id"
application_credential_secret = "your_app_credential_secret"
Get ssh_keypair_name

Wybierz jedną parę kluczy z listy wyświetlanej w sekcji Compute -> Key Pairs.

Uzyskaj identyfikator projektu

Aby uzyskać project_id, najprostszym sposobem jest wyświetlenie listy wszystkich projektów w sekcji Identity -> Projects, kliknięcie nazwy projektu i odczytanie jego ID.

Pobierz klucz publiczny

Aby uzyskać public_key, przejdź do sekcji Compute -> Key Pairs i kliknij nazwę pary kluczy wprowadzoną dla zmiennej ssh_keypair_name.

Pobierz application_credential_id

Pobierz ID poświadczenia aplikacji z jednego z plików openrc lub clouds.yaml.

Pobierz application_credential_secret

To samo, ale dla tajnego kodu.

Uruchom Terraform, aby udostępnić klaster RKE2

To jest koniec części dotyczącej konfiguracji. Możemy teraz uruchomić standardowe polecenia Terraform - init, plan i apply, aby utworzyć nasz klaster RKE2. Polecenia powinny być wykonywane w podanej poniżej kolejności. Wpisz yes, gdy jest to wymagane, aby ponownie potwierdzić kroki zaplanowane przez Terraform.

terraform init
terraform plan
terraform apply

Tworzenie zasobów zajmie kilka minut (około 5-10 minut w przypadku małego klastra). W konsoli zostaną wyświetlone dzienniki potwierdzające utworzenie każdego zasobu. Oto przykładowy wynik końcowy polecenia terraform apply:

../_images/image-2024-7-24_13-56-31.png

Podczas procesu tworzenia plik**kubeconfig.yaml** zostanie on skopiowany do lokalnego katalogu roboczego. Wyeksportuj do tej lokalizacji KUBECONFIG zmienną środowiskową wskazującą lokalną instalację kubectl (zastąp ścieżkę w przykładowym poleceniu poniżej):

export KUBECONFIG=/path_to_your_kubeconfig_file/kubeconfig.yaml

Następnie sprawdź, czy klaster jest dostępny za pomocą polecenia:

kubectl get nodes

Widzimy, że w naszym przypadku klaster został utworzony poprawnie, a zarówno węzeł główny, jak i węzeł roboczy mają status ready:

../_images/image-2024-7-24_14-9-18_nsis_pl1.png

Krok 4 Zademonstrowanie integracji natywnej dla chmury objętej repozytorium

Możemy zweryfikować automatyczne przypisywanie load balancerów i publicznego adresu Floating IP poprzez wystawienie usługi typu load balancer. Poniższe polecenia kubectl wdrożą i udostępnią serwer nginx w domyślnej przestrzeni nazw naszego klastra RKE2:

kubectl create deployment nginx-deployment --image=nginx:latest
kubectl expose deployment nginx-deployment --type=LoadBalancer --port=80 --target-port=80

Udostępnienie FIP i load balancera zajmuje około 2-3 minut po uruchomieniu tego polecenia:

kubectl get services

Po upływie tego czasu powinien pojawić się wynik podobny do poniższego, w którym EXTERNAL-IP został prawidłowo przydzielony:

../_images/image-2024-7-24_15-20-4_nsis_pl1.png

Podobnie obecność utworzonego load balancera można sprawdzić w interfejsie Horizon za pomocą menu po lewej stronie: ProjectNetworkLoadBalancers.

../_images/image-2024-7-24_15-27-55_nsis_pl1.png

oraz ProjectNetworkFloating IPs:

../_images/image-2024-7-24_15-29-17_nsis_pl1.png

Na koniec możemy sprawdzić, czy usługa działa jako usługa publiczna w naszej przeglądarce z przypisanym adresem floating IP:

../_images/image-2024-7-24_15-30-26_nsis_pl1.png

Szczegóły wdrożenia

Wyjaśnienie wszystkich technik, które zostały wykorzystane do utworzenia repozytorium RKE2 z sekcji Wymaganie wstępne nr11, wykracza poza zakres tego artykułu. Poniżej znajduje się jednak ilustracja tego, jak zaimplementowano co najmniej jedną funkcję.

Przyjrzyjmy się plikowi cloud-init-masters.yml.tpl, a konkretnie jego części pomiędzy wierszami 53 i 79:

- path: /var/lib/rancher/rke2/server/manifests/rke2-openstack-cloud-controller-manager.yaml
  permissions: "0600"
  owner: root:root
  content: |
    apiVersion: helm.cattle.io/v1
    kind: HelmChart
    metadata:
      name: openstack-cloud-controller-manager
      namespace: kube-system
    spec:
      chart: openstack-cloud-controller-manager
      repo: https://kubernetes.github.io/cloud-provider-openstack
      targetNamespace: kube-system
      bootstrap: True
      valuesContent: |-
        nodeSelector:
          node-role.kubernetes.io/control-plane: "true"
        cloudConfig:
          global:
            auth-url: https://keystone.cloudferro.com:5000
            application-credential-id: "${application_credential_id}"
            application-credential-secret: "${application_credential_secret}"
            region: ${region}
            tenant-id: ${project_id}
          loadBalancer:
            floating-network-id: "${floating_network_id}"
            subnet-id: ${subnet_id}

Określają one tworzenie definicji yaml dla wykresu Helm CRD

rke2-openstack-cloud-controller-manager.yaml

w lokalizacji

/var/lib/rancher/rke2/server/manifests/

na węźle głównym. Po utworzeniu klastra dostawca RKE2 automatycznie przechwytuje ten plik i wdraża pod odpowiedzialny za udostępnianie takich load balancerów. Można to zweryfikować, sprawdzając pody w przestrzeni nazw kube-system:

kubectl get pods -n kube-system

Jednym z wpisów jest wspomniany wcześniej pod:

NAME                                                    READY   STATUS      RESTARTS     AGE
...
openstack-cloud-controller-manager-bz7zt                1/1     Running     1 (4h ago)   26h
...

Dalsze dostosowywanie

W zależności od przypadku wymagane będzie dalsze dostosowanie dostarczonego przykładowego repozytorium w celu dostrojenia konfiguracji Terraform do obsługi klastra RKE2. Sugerujemy rozważenie następujących ulepszeń:

  • Włączenie wysokiej dostępności płaszczyzny kontrolnej

  • Integracja z CSI Cinder w celu umożliwienia zautomatyzowanego dostarczania blokowej pamięci masowej za pomocą persistent volume claims (PVCs).

  • Zintegrowanie wtyczki NVIDIA, aby umożliwić natywną integrację maszyn wirtualnych z vGPU.

  • Wdrożenie autoskalera węzłów w celu uzupełnienia natywnego horyzontalnego autoskkalera podów (HPA) w Kubernetes.

  • Wdrożenie reguł affinity i anti-affinity dla umieszczania węzłów podrzędnych i głównych.

Aby wdrożyć te funkcje, należy jednocześnie dostosować definicje zarówno dla zasobów Terraform, jak i Kubernetes. Omówienie tych kroków wykracza zatem poza zakres tego artykułu.

Co można zrobić dalej?

W tym artykule zostało stworzone odpowiednie rozwiązanie Kubernetes z użyciem klastra RKE2 jako podstawy.

Można również rozważyć tworzenie klastrów Kubernetes przy użyciu Magnum w OpenStack:

Jak utworzyć klaster Kubernetes przy użyciu NSIS OpenStack Magnum