Autoskalowanie zasobów klastra Kubernetes na platformie NSIS OpenStack Magnum
Gdy autoskalowanie klastrów Kubernetes jest włączone, system może
Dodaj zasoby, gdy zapotrzebowanie jest wysokie, lub
Usuń niepotrzebne zasoby, gdy zapotrzebowanie jest niskie, a tym samym obniż koszty.
Cały proces może być zautomatyzowany, pomagając administratorowi skoncentrować się na ważniejszych zadaniach.
Ten artykuł wyjaśnia różne polecenia służące do zmiany rozmiaru lub skalowania klastra i prowadzi do polecenia automatycznego tworzenia autoskalowalnego klastra Kubernetes dla OpenStack Magnum.
Co będziemy omawiać
Definicje skalowania poziomego, pionowego i węzłów
Definiowanie automatycznego skalowania podczas tworzenia klastra w interfejsie Horizon
Definiowanie automatycznego skalowania podczas tworzenia klastra za pomocą interfejsu CLI
Pobieranie etykiet szablonów klastrów z interfejsu Horizon
Pobieranie etykiet szablonów klastrów z interfejsu CLI
Wymagania wstępne
Nr 1 Hosting
Potrzebne jest konto hostingowe NSIS z interfejsem Horizon https://horizon.cloudferro.com.
Nr 2 Tworzenie klastrów za pomocą CLI
Artykuł Jak korzystać z interfejsu wiersza poleceń dla klastrów Kubernetes w NSIS OpenStack Magnum? wprowadzi cię w tworzenie klastrów za pomocą interfejsu wiersza poleceń.
Nr 3 Podłącz klienta openstack do chmury
Przygotuj klientów openstack i magnum, wykonując Krok 2 Podłącz klientów OpenStack i Magnum do chmury Horizon z artykułu Jak zainstalować klientów OpenStack i Magnum dla interfejsu wiersza poleceń w NSIS Horizon?.
Nr 4. Resizing Nodegroups
Krok 7 artykułu Tworzenie dodatkowych podgrup w klastrze Kubernetes na platformie NSIS OpenStack Magnum pokazuje przykład zmiany rozmiaru nodegroups dla autoskalowania.
Nr 5 Tworzenie klastrów
Krok 2 artykułu Jak utworzyć klaster Kubernetes przy użyciu NSIS OpenStack Magnum pokazuje jak zdefiniować węzły master i worker dla autoskalowania.
Istnieją trzy różne funkcje automatycznego skalowania, które może oferować chmura Kubernetes:
Poziomy autoskaler podów
Skalowanie klastra Kubernetes w poziomie oznacza zwiększanie lub zmniejszanie liczby uruchomionych podów, w zależności od rzeczywistych wymagań w czasie wykonywania. Parametry, które należy wziąć pod uwagę, to wykorzystanie procesora i pamięci, a także pożądana minimalna i maksymalna liczba replik podów.
Skalowanie poziome jest również znane jako „skalowanie na zewnątrz” i jest skracane jako HPA.
Autoskaler pionowy
Skalowanie pionowe (lub „skalowanie w górę”, VPA) polega na dodawaniu lub odejmowaniu zasobów do i od istniejącej maszyny. Jeśli potrzeba więcej procesorów, należy je dodać. Gdy nie są one potrzebne, wyłącz niektóre z nich.
Autoskaler klastrów
HPA i VPA reorganizują wykorzystanie zasobów i liczbę podów, jednak może nadejść czas, gdy rozmiar samego systemu uniemożliwi zaspokojenie zapotrzebowania. Rozwiązaniem jest autoskalowanie samego klastra, aby zwiększyć lub zmniejszyć liczbę węzłów, na których będą działać pody.
Po dostosowaniu liczby węzłów, pody i inne zasoby muszą ponownie zrównoważyć się w klastrze, również automatycznie. Liczba węzłów stanowi fizyczną barierę dla automatycznego skalowania podów.
Wszystkie trzy modele automatycznego skalowania można łączyć ze sobą.
Zdefiniuj autoskalowanie podczas tworzenia klastra
Parametry autoskalowania można zdefiniować podczas definiowania nowego klastra, korzystając z okna o nazwie Rozmiar w kreatorze tworzenia klastra:
Określa minimalną i maksymalną liczbę węzłów roboczych. Jeśli wartości te wynoszą odpowiednio 2 i 4, klaster będzie miał nie mniej niż 2 węzły i nie więcej niż 4 węzły w dowolnym momencie. Jeśli nie ma ruchu do klastra, zostanie on automatycznie skalowany do 2 węzłów. W tym przykładzie klaster może mieć 2, 3 lub 4 węzły w zależności od ruchu.
Dla całego procesu tworzenia klastra Kubernetes w Horizon, zobacz Wymagania wstępne No. 5.
Ostrzeżenie
Jeśli zdecydujesz się użyć opcji NGINX Ingress podczas definiowania klastra, NGINX ingress będzie działał jako 3 repliki na 3 oddzielnych węzłach. Spowoduje to zastąpienie minimalnej liczby węzłów w autoskalerze Magnum.
Automatyczne skalowanie grup węzłów w czasie wykonywania
Autoskaler w Magnum wykorzystuje grupy węzłów. Grupy węzłów mogą być używane do tworzenia pracowników o różnych smakach. Domyślna grupa węzłów jest tworzona automatycznie podczas tworzenia klastra. Grupy węzłów mają dolne i górne limity liczby węzłów. To jest polecenie, aby wydrukować je dla danego klastra:
openstack coe nodegroup show NoLoadBalancer default-worker -f json -c max_node_count -c node_count -c min_node_count
The result would be:
{
"node_count": 1,
"max_node_count": 2,
"min_node_count": 1
}
Działa to dobrze, dopóki nie spróbujesz zmienić rozmiaru klastra poza limit ustawiony w grupie węzłów. Jeśli spróbujesz zmienić rozmiar powyższego klastra do 12 węzłów, tak jak poniżej:
openstack coe cluster resize NoLoadBalancer --nodegroup default-worker 12
pojawi się następujący błąd:
Resizing default-worker outside the allowed range: min_node_count = 1, max_node_count = 2 (HTTP 400) (Request-ID: req-bbb09fc3-7df4-45c3-8b9b-fbf78d202ffd)
Aby rozwiązać ten błąd, należy ręcznie zmienić node_group max_node_count:
openstack coe nodegroup update NoLoadBalancer default-worker replace max_node_count=15
a następnie zmienić rozmiar klastra do żądanej wartości, która w tym przykładzie była mniejsza niż 15:
openstack coe cluster resize NoLoadBalancer –nodegroup default-worker 12
Jeśli powtórzysz pierwsze stwierdzenie:
openstack coe nodegroup show NoLoadBalancer default-worker -f json -c max_node_count -c node_count -c min_node_count
wynik będzie teraz zawierał poprawioną wartość:
{
"node_count": 12,
"max_node_count": 15,
"min_node_count": 1
}
Jak automatyczne skalowanie wykrywa górny limit
Pierwsza wersja autoskalowania pobierała aktualny górny limit autoskalowania w zmiennej node_count i dodawała do niego 1. Jeśli polecenie utworzenia klastra brzmiałoby
openstack coe cluster create mycluster --cluster-template mytemplate --node-count 8 --master-count 3
ta wersja Autoskalera przyjmowała wartość 9 (licząc jako 8 + 1). Procedura ta była jednak ograniczona tylko do domyślnej grupy węzłów roboczych.
Obecny Autoskaler może obsługiwać wiele grup węzłów poprzez wykrywanie roli grupy węzłów:
openstack coe nodegroup show NoLoadBalancer default-worker -f json -c role
a wynik to
{
"role": "worker"
}
Dopóki rolą jest worker, a max_node_count jest większe niż 0, Autoskaler będzie próbował skalować grupę węzłów default-worker dodając 1 do max_node_count.
Uwaga
Każda dodatkowa grupa węzłów musi zawierać konkretny atrybut max_node_count.
Szczegółowe przykłady korzystania z rodziny poleceń openstack coe nodegroup można znaleźć w Wymaganiach wstępnych nr 4.
Automatyczne skalowanie etykiet dla klastrów
Istnieją trzy etykiety dla klastrów, które wpływają na autoskalowanie:
auto_scaling_enabled – jeśli true, to jest włączone
min_node_count – minimalna liczba węzłów
max_node_count – the maximal number of nodes, at any time.
Podczas definiowania klastra za pośrednictwem interfejsu Horizon, użytkownik faktycznie konfiguruje te etykiety klastra.
Wyświetl listę klastrów za pomocą Container Infra => Cluster i kliknij nazwę klastra. Pod Labels znajdziesz aktualną wartość dla auto_scaling_enabled.
Jeśli wartość true jest włączona, klaster będzie skalowany automatycznie.
Tworzenie nowego klastra przy użyciu interfejsu CLI z włączonym autoskalowaniem
Polecenie utworzenia klastra za pomocą CLI musi zawierać wszystkie zwykłe parametry, a także wszystkie etykiety potrzebne do działania klastra. Osobliwością składni jest to, że parametry etykiet muszą być pojedynczym ciągiem znaków, bez spacji pomiędzy nimi.
Tak mogłoby wyglądać jedno z takich poleceń:
openstack coe cluster create mycluster
--cluster-template k8s-stable-1.23.5
--keypair sshkey
--master-count 1 c
--node-count 3
--labels auto_scaling_enabled=true,autoscaler_tag=v1.22.0,calico_ipv4pool_ipip=Always,cinder_csi_plugin_tag=v1.21.0,cloud_provider_enabled=true,cloud_provider_tag=v1.21.0,container_infra_prefix=registry-public.cloudferro.com/magnum/,eodata_access_enabled=false,etcd_volume_size=8,etcd_volume_type=ssd,hyperkube_prefix=registry-public.cloudferro.com/magnum/,k8s_keystone_auth_tag=v1.21.0,kube_tag=v1.21.5-rancher1,master_lb_floating_ip_enabled=true
Jeśli po prostu spróbujesz skopiować i wkleić go do terminala, otrzymasz błędy składni. Koniec linii jest niedozwolony, całe polecenie musi być jednym długim ciągiem. Aby ułatwić ci życie, oto wersja polecenia, którą możesz skopiować z powodzeniem.
Ostrzeżenie
Linia zawierająca etykiety będzie tylko częściowo widoczna na ekranie, ale po wklejeniu jej do wiersza poleceń oprogramowanie terminala wykona ją bez problemów.
Polecenie to:
openstack coe cluster create mycluster –cluster-template k8s-stable-1.23.5 –keypair sshkey –master-count 1 –node-count 3 –labels auto_scaling_enabled=true,autoscaler_tag=v1.22.0,calico_ipv4pool_ipip=Always,cinder_csi_plugin_tag=v1.21.0/,cloud_provider_enabled=true,cloud_provider_tag=v1.21.0,container_infra_prefix=registry-public.cloudferro.com/magnum/,eodata_access_enabled=false,etcd_volume_size=8,etcd_volume_type=ssd,hyperkube_prefix=registry-public.cloudferro.com/magnum/,k8s_keystone_auth_tag=v1.21.0,kube_tag=v1.21.5-rancher1,master_lb_floating_ip_enabled=true,min_node_count=2,max_node_count=4
Na początku będzie to mycluster, jeden węzeł główny i trzy węzły robocze.
Informacja
Ustawienie maksymalnej liczby węzłów w autoskalowaniu jest obowiązkowe. Jeśli nie zostanie określona, max_node_count będzie domyślnie wynosić 0 i nie będzie żadnego autoskalowania dla danej grupy węzłów.
To jest wynik po utworzeniu:
Aktywne są trzy adresy węzłów roboczych: 10.0.0.102, 10.0.0.27 i 10.0.0.194.
Nie ma ruchu do klastra, więc autoskalowanie natychmiast się uruchomiło. Minutę lub dwie po zakończeniu tworzenia liczba węzłów roboczych spadła o jeden, do adresów 10.0.0.27 i 10.0.0.194 - to jest autoskalowanie w pracy.
Nodegrupy z rolą pracownika będą automatycznie wybierane automatycznie
Autoscaler automatycznie wykrywa wszystkie nowe grupy węzłów z przypisaną rolą „worker”. Rola „worker” jest przypisywana domyślnie, jeśli nie została określona. Należy również podać maksymalną liczbę węzłów.
Najpierw sprawdź, które grupy węzłów są obecne dla klastra k8s-cluster. Polecenie to
openstack coe nodegroup list k8s-cluster -c name -c node_count -c status -c role
Przełącznik -c oznacza, która kolumna ma zostać wyświetlona, pomijając wszystkie inne kolumny, które nie są wymienione w poleceniu. Zobaczysz tabelę z kolumnami name, node_count, status i role, co oznacza, że kolumny takie jak uuid, flavor_id i image_id nie będą zajmować cennego miejsca na ekranie. Rezultatem jest tabela zawierająca tylko cztery kolumny, które są istotne dla dodawania grup węzłów z rolami:
Teraz dodaj i wydrukuj nodegroup bez roli:
openstack coe nodegroup create k8s-cluster nodegroup-without-role --node-count 1 --min-nodes 1 --max-nodes 5
openstack coe nodegroup list k8s-cluster -c name -c node_count -c status -c role
Ponieważ rola nie została określona, domyślna wartość „worker” została przypisana do grupy węzłów nodegroup-without-role. Ponieważ system jest skonfigurowany do automatycznego automatycznego skalowania grup węzłów z rolą worker, jeśli dodasz grupę węzłów bez roli, zostanie ona automatycznie skalowana.
Teraz dodaj grupę węzłów o nazwie nodegroup-with-role, a nazwą roli będzie custom:
openstack coe nodegroup create k8s-cluster nodegroup-with-role --node-count 1 --min-nodes 1 --max-nodes 5 --role custom
openstack coe nodegroup list k8s-cluster -c name -c node_count -c status -c role
Spowoduje to dodanie grupy węzłów, ale nie spowoduje jej automatycznego skalowania, ponieważ dla grupy węzłów nie określono roli worker.
Na koniec dodaj nodegroup o nazwie nodegroup-with-role-2, która będzie miała dwie role zdefiniowane w jednej instrukcji, czyli zarówno custom, jak i worker. Ponieważ co najmniej jedną z ról jest worker, zostanie ona automatycznie skalowana.
openstack coe nodegroup create k8s-cluster nodegroup-with-role-2 --node-count 1 --min-nodes 1 --max-nodes 5 --role custom,worker
openstack coe nodegroup list k8s-cluster -c name -c node_count -c status -c role
Klaster k8s-cluster ma teraz 8 węzłów:
Te trzy klastry można usunąć za pomocą następującego zestawu poleceń:
openstack coe nodegroup delete k8s-cluster nodegroup-with-role
openstack coe nodegroup delete k8s-cluster nodegroup-with-role-2
openstack coe nodegroup delete k8s-cluster nodegroup-without-role
Jeszcze raz zobacz wynik:
openstack coe nodegroup list k8s-cluster -c name -c node_count -c status -c role
Jak uzyskać wszystkie etykiety z interfejsu Horizon
Użyj Container Infra => Clusters i kliknij na nazwę klastra. W przeglądarce pojawi się zwykły tekst, wystarczy skopiować wiersze pod Labels i wkleić je do wybranego edytora tekstu.
W edytorze tekstu ręcznie usuń końce linii i utwórz jeden ciąg bez przerw i powrotów karetki, a następnie wklej go z powrotem do polecenia.
Jak uzyskać wszystkie etykiety z CLI
Istnieje specjalne polecenie, które tworzy etykiety z klastra:
openstack coe cluster template show k8s-stable-1.23.5 -c labels -f yaml
To jest wynik:
Jest to format yaml, określony przez parametr -f. Wiersze reprezentują wartości etykiet, a następnym działaniem jest utworzenie jednego długiego ciągu bez podziałów wierszy, jak w poprzednim przykładzie, a następnie utworzenie polecenia CLI.
Używanie ciągu etykiet podczas tworzenia klastra w Horizon
Długi ciąg etykiet można również wykorzystać podczas ręcznego tworzenia klastra, tj. z poziomu interfejsu Horizon. Miejsce wstawienia tych etykiet opisano w Kroku 4 Definiowanie etykiet w Wymaganiach wstępnych nr 2.
Co robić dalej
Autoskalowanie jest podobne do automatycznego uzdrawiania klastrów Kubernetes i oba zapewniają automatyzację. Gwarantują również, że system będzie dokonywał autokorekty tak długo, jak długo będzie mieścił się w swoich podstawowych parametrach. Korzystaj z autoskalowania zasobów klastra tak często, jak to tylko możliwe!