Jak utworzyć klaster Kubernetes przy użyciu Terraform na NSIS

W tym artykule demonstrujemy użycie Terraform do wdrożenia klastra OpenStack Magnum Kubernetes w chmurze NSIS.

Wymagania wstępne

Nr 1 Konto hostingowe

Potrzebne jest aktywne konto NSIS https://nsis-cloud-innovation.cloudferro.com/login.

Nr 2 Aktywna sesja CLI z OpenStackClient dla Linux

Potrzebny jest zainstalowany OpenStack CLI i odpowiednie środowisko wirtualne Python. Wytyczne można znaleźć na stronie:

Jak zainstalować OpenStackClient dla systemu Linux na NSIS

Pokaże on, jak zainstalować Pythona, utworzyć i aktywować środowisko wirtualne, a następnie połączyć się z chmurą, pobierając i aktywując odpowiedni plik RC z chmury NSIS.

Nr 3 Połącz się z chmurą za pomocą pliku RC

Kolejny artykuł, Jak aktywować dostęp OpenStack CLI do chmury NSIS przy użyciu uwierzytelniania dwuskładnikowego, dotyczy łączenia się z chmurą i obejmuje jedną z procedur uwierzytelniania jedno- lub dwuskładnikowego, które są włączone na koncie. Obejmuje również wszystkie główne platformy: Linux, MacOS i Windows.

Będziesz używał zarówno wirtualnego środowiska Python, jak i pobranego pliku RC po zainstalowaniu Terraform.

Nr 4 Znajomość tworzenia klastrów Kubernetes

Znajomość tworzenia klastrów Kubernetes w standardowy sposób, np. przy użyciu Horizon lub OpenStack CLI:

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

Jak korzystać z interfejsu wiersza poleceń dla klastrów Kubernetes w NSIS OpenStack Magnum?

Nr 5 Terraform operacyjny

Zainstaluj Terraform lokalnie lub na maszynie wirtualnej w chmurze - wskazówki dotyczące instalacji wraz z dalszymi informacjami można znaleźć w tym artykule:

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

Po zakończeniu pracy z tym artykułem będziesz mieć dostęp do chmury za pośrednictwem aktywnego polecenia openstack. Ponadto, specjalne zmienne środowiskowe (env) (OS_USERNAME, OS_PASSWORD, OS_AUTH_URL i inne) zostaną skonfigurowane tak, aby różne programy mogły z nich korzystać - Terraform jest tutaj głównym celem.

Definiowanie dostawcy dla Terraform

Terraform używa pojęcia provider, które reprezentuje konkretne środowisko chmury i obejmuje uwierzytelnianie. Chmury NSIS są zbudowane zgodnie z technologią OpenStack, a OpenStack jest jednym ze standardowych typów dostawców dla Terraform.

Musimy:

poinstruować Terraform, aby używał OpenStack jako typu dostawcy

podać dane uwierzytelniające, które będą wskazywać na nasz własny projekt i użytkownika w chmurze.

Zakładając, że przeszedłeś przez warunek wstępny nr 2 (pobranie i źródło pliku RC), kilka zmiennych środowiskowych związanych z OpenStack zostanie wypełnionych w twoim lokalnym systemie. Te wskazujące na środowisko OpenStack zaczynają się od OS, np. OS_USERNAME, OS_PASSWORD, OS_AUTH_URL. Kiedy zdefiniujemy OpenStack jako typ dostawcy TerraForm, Terraform będzie wiedział, aby automatycznie używać tych zmiennych env do uwierzytelniania.

Zdefiniujmy teraz dostawcę Terraform, tworząc plik provider.tf o następującej zawartości:

provider.tf

# Define providers
terraform {
required_version = ">= 0.14.0"
  required_providers {
    openstack = {
      source  = "terraform-provider-openstack/openstack"
      version = "~> 1.35.0"
    }
  }
}

# Configure the OpenStack Provider
provider "openstack" {
  auth_url =  "https://keystone.cloudferro.com:5000/v3"
  # the rest of configuration parameters are taken from environment variables once RC file is correctly sourced
}

Opcja auth_url jest jedyną opcją konfiguracyjną, którą należy podać w pliku konfiguracyjnym, mimo że jest ona również dostępna w zmiennych środowiskowych.

Posiadanie tej specyfikacji dostawcy umożliwia nam utworzenie klastra w kolejnych krokach, ale może być również ponownie wykorzystane do tworzenia innych zasobów w środowisku OpenStack, np. maszyn wirtualnych, wolumenów i wielu innych.

Definiowanie zasobu klastra w Terraform

Drugim krokiem jest zdefiniowanie dokładnej specyfikacji zasobu, który chcemy utworzyć za pomocą Terraform. W naszym przypadku chcemy utworzyć klaster OpenStack Magnum. W terminologii Terraform będzie to instancja typu zasobu openstack_containerinfra_cluster_v1. Aby kontynuować, utwórz plik cluster.tf, który zawiera specyfikację naszego klastra:

cluster.tf

# Create resource
resource "openstack_containerinfra_cluster_v1" "k8s-cluster" {
  name                      = "k8s-cluster"
  cluster_template_id       = "524535ed-9a0f-4b70-966f-6830cdc52604"
  node_count                = 3
  master_count              = 3
  flavor                    = "eo1.large"
  master_flavor             = "hmad.medium"
  keypair                   = "mykeypair"
  labels = {
    eodata_access_enabled   = true
    etcd_volume_size        = 0
  }
  merge_labels              = true
}

Powyższa konfiguracja odzwierciedla klaster z kilkoma często używanymi dostosowaniami:

cluster_template_id

odpowiada identyfikatorowi jednego z domyślnych szablonów klastrów w chmurze WAW3-2, którym jest k8s-localstorage-1.23.16-v1.0.0. Domyślne szablony i ich identyfikatory można sprawdzić w interfejsie Horizon UI w podmenu Cluster Infra -→ Container Templates.

node_count, node_flavor, master_node_count, master_node_flavor

odpowiadają intuicyjnie liczbie i rodzajowi węzłów nadrzędnych i podrzędnych w klastrze.

para kluczy

odzwierciedla nazwę pary kluczy używanej w naszym projekcie openstack w wybranej chmurze.

labels i merge_labels

Używamy dwóch etykiet:

eodata_access_enabled=true: zapewnia, że sieć EODATA z szybkim dostępem do zdjęć satelitarnych jest połączona z naszymi węzłami klastra,
etcd_volume_size=0: która zapewnia, że węzły główne są prawidłowo zaopatrzone w lokalną pamięć masową NVME.

W przypadku tej konfiguracji obowiązkowe jest również użycie konfiguracji merge_labels=true, aby poprawnie zastosować te etykiety i uniknąć nadpisania ich przez domyślne ustawienia szablonu.

W naszym przykładzie działamy na chmurze WAW3-2, gdzie dostępny jest smak hmad.medium. Jeśli używasz innej chmury, dostosuj odpowiednio parametry.

Powyższa konfiguracja odzwierciedla klaster, w którym loadbalancer jest umieszczony przed węzłami głównymi, a smak tego loadbalancera to HA-large. Dostosowanie tego domyślnego ustawienia, podobnie jak w przypadku innych bardziej zaawansowanych ustawień domyślnych, wymagałoby utworzenia niestandardowego szablonu Magnum, co wykracza poza zakres tego artykułu.

Zastosowanie konfiguracji i utworzenie klastra

Po zdefiniowaniu obu konfiguracji Terraform opisanych w poprzednich krokach, możemy je zastosować do utworzenia naszego klastra.

Pierwszym krokiem jest posiadanie obu plików provider.tf i cluster.tf w dedykowanym folderze. Następnie cd do tego folderu i wpisz:

terraform init

To polecenie zainicjuje wdrożenie naszego klastra. Wychwyci wszelkie formalne błędy związane z uwierzytelnianiem do OpenStack, które mogą wymagać poprawienia przed przejściem do następnego etapu.

W następnym kroku Terraform zaplanuje działania, które musi wykonać, aby utworzyć zasób. Kontynuuj wpisywanie:

terraform plan

Wynik jest pokazany poniżej i daje szansę na poprawienie wszelkich błędów logicznych w naszej oczekiwanej konfiguracji:

Ostatnim krokiem jest zastosowanie zaplanowanych zmian. Wykonaj ten krok za pomocą polecenia:

terraform apply

Wyjście tego ostatniego polecenia początkowo powtórzy plan, a następnie poprosi o wpisanie słowa tak, aby uruchomić Terraform.

Po potwierdzeniu yes, akcja zostanie wdrożona, a konsola będzie aktualizować się co 10 sekund, aby sprawdzić „Still creating …”, dopóki nasz klaster nie zostanie utworzony.

Końcowe wiersze danych wyjściowych po pomyślnym udostępnieniu klastra powinny wyglądać podobnie do poniższych:

Co robić dalej

Terraform może być również używany do wdrażania dodatkowych aplikacji do naszego klastra, np. przy użyciu dostawcy Helm dla Terraform. Więcej szczegółów można znaleźć w dokumentacji Terraform.