Skip to main content
  • »
  • KUBERNETES »
  • Jak korzystać z interfejsu wiersza poleceń dla klastrów Kubernetes w NSIS OpenStack Magnum?

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

W tym artykule użyjesz interfejsu wiersza poleceń (CLI), aby przyspieszyć testowanie i tworzenie klastrów Kubernetes na serwerach OpenStack Magnum.

Co będziemy omawiać

  • Zalety korzystania z CLI w porównaniu z interfejsem graficznym Horizon

  • Debugowanie poleceń OpenStack i Magnum

  • Jak utworzyć nowy szablon klastra Kubernetes przy użyciu interfejsu CLI?

  • Jak utworzyć nowy klaster Kubernetes przy użyciu interfejsu CLI?

  • Powody, dla których klaster może nie zostać utworzony

  • Polecenia CLI służące do usuwania klastra

Wymagania wstępne

Nr 1 Hosting

Potrzebne jest konto hostingowe NSIS z interfejsem Horizon https://horizon.cloudferro.com.

Nr 2 Klucze prywatne i publiczne

Para kluczy SSH utworzona w pulpicie nawigacyjnym OpenStack. Aby ją utworzyć, postępuj zgodnie z tym artykułem Jak utworzyć parę kluczy w OpenStack Dashboard na NSIS Cloud. Zostanie utworzona para kluczy o nazwie sshkey i będzie można jej używać również w tym samouczku.

Nr 3 Struktura poleceń klienta OpenStack

Oto instrukcja dla poleceń OpenStackClient: Command Structure Xena version.

Nr 4 Lista poleceń klienta OpenStack

Oto wszystkie polecenia obsługiwane przez wersję Xena OpenStackClient: Lista poleceń Xena.

Nr 5 Dokumentacja dla klienta Magnum

Są to wszystkie polecenia obsługiwane przez wersję Xena MagnumClient: Magnum User Guide.

Nr 6 Jak zainstalować klientów OpenStack i Magnum

Krok, który bezpośrednio poprzedza ten artykuł to: Jak zainstalować klientów OpenStack i Magnum dla interfejsu wiersza poleceń w NSIS Horizon?.

W tym przewodniku zainstalowałeś CLI, a w tym samouczku użyjesz go do pracy z Kubernetes na OpenStack Magnum.

Nr 7 Autohealing klastrów Kubernetes

Aby dowiedzieć się więcej o automatycznym uzdrawianiu klastrów Kubernetes, postępuj zgodnie z tym oficjalnym artykułem Co to jest Magnum Autohealer?.

Zalety korzystania z interfejsu CLI

Z interfejsu CLI i Horizon można korzystać zamiennie, ale istnieją co najmniej trzy zalety korzystania z CLI.

Reproduce Commands Through Cut & Paste

Oto polecenie wyświetlające listę smaków w systemie

openstack flavor list
../_images/flavors_list1.png

Jeśli masz tę linię zapisaną w aplikacji edytora tekstu, możesz ją odtworzyć do woli. W przeciwieństwie do tego, aby uzyskać listę smaków za pomocą Horizon, musiałbyś kliknąć serię przycisków ekranowych

Compute => Instances => Launch instance => Flavor

i dopiero wtedy otrzymać listę smaków do wyboru:

../_images/horizon_flavors1.png

Dodatkową zaletą jest to, że przechowywanie poleceń w edytorze tekstu automatycznie tworzy dokumentację dla serwera i klastra.

Polecenia CLI mogą być zautomatyzowane

Można skorzystać z dostępnej automatyzacji. Wynikiem poniższego potoku Ubuntu jest adres url do komunikacji z kubectl do klastra Kubernetes:

../_images/kubernetes_url1.png

Są to dwa polecenia połączone w jedno:

KUBERNETES_URL=$(openstack coe cluster show k8s-cluster
   | awk '/ api_address /{print $4}')

Wynik pierwszego polecenia

openstack coe cluster show k8s-cluster

to seria wierszy rozpoczynająca się od nazwy parametru, po której następuje rzeczywista wartość.

../_images/api_address1.png

Druga instrukcja, na prawo od symbolu potokowania |

awk '/ api_address /{print $4}')

szuka linii zaczynającej się od api_address i wyodrębnia jej wartość https://64.225.132.135:6443. Końcowy wynik jest eksportowany do zmiennej systemowej KUBERNETES_URL, dzięki czemu jest automatycznie konfigurowany do użycia przez polecenie klastra Kubernetes kubectl podczas uzyskiwania dostępu do chmury.

CLI zapewnia dostęp do wszystkich istniejących parametrów OpenStack i Magnum

Polecenia CLI oferują dostęp do większego zestawu parametrów niż te dostępne w Horizon. Przykładowo, w Horizon domyślny czas dozwolony na utworzenie klastra wynosi 60 minut, podczas gdy w CLI można ustawić go na inne wybrane wartości.

Debugowanie poleceń OpenStack i Magnum

Aby zobaczyć, co faktycznie dzieje się za kulisami, podczas wykonywania poleceń klienta, dodaj parametr –debug:

openstack coe cluster list --debug

Dane wyjściowe będą miały długość kilku ekranów, składających się z wywołań internetowych GET i POST, z dziesiątkami parametrów wyświetlanych na ekranie. (Dane wyjściowe są zbyt obszerne, aby je tutaj odtworzyć).

Jak wprowadzać polecenia OpenStack

Informacja

In the forthcoming example, a version fedora-coreos-34.20210904.3.0 of fedora images is used. As the system is updated in time, the actual values may become different, for instance, any of values fedora-coreos-35 or fedora-coreos-33.20210426.3.0. Use Horizon command Compute -> Images to see what images of fedora are currently available, then edit and replace as needed.

Istnieje kilka sposobów zapisywania i wprowadzania poleceń Openstack do interfejsu wiersza poleceń terminala.

Jednym ze sposobów jest wpisanie komendy openstack i naciśnięcie Enter na klawiaturze. Wchodzisz w tryb liniowy polecenia openstack i możesz wprowadzać wiersze różnych parametrów openstack wiersz po wierszu. Ten sposób jest przeznaczony wyłącznie do ręcznego wprowadzania danych i jest trudny do zautomatyzowania.

../_images/ku_openstack_line_entry1.png

Wpisz quit i naciśnij Enter na klawiaturze, aby opuścić ten tryb.

Zwykłym sposobem wprowadzania parametrów openstack jest jedna długa linia. Pozostaw spacje między parametrami, ale wprowadź wartości etykiet bez spacji między nimi. Przykładem może być:

../_images/ku_long_line1.png

Przerwy w wierszach i spacje muszą być w tym przypadku usuwane ręcznie.

Bardziej eleganckim sposobem jest użycie znaku backslash, \, w tekście linii. Znak po odwrotnym ukośniku nie będzie brany pod uwagę, więc jeśli wprowadzisz go na samym końcu linii, znak EOL zostanie pominięty, a pierwsza i druga linia będą traktowane jako jedna ciągła linia. To jest dokładnie to, czego chcesz, więc oto jak mogłaby wyglądać linia wejściowa z tym podejściem:

openstack coe cluster template create kubecluster \
--image "fedora-coreos-34.20210904.3.0" \
--external-network external \
--master-flavor eo1.large \
--flavor eo1.large \
--docker-volume-size 50 \
--network-driver calico \
--docker-storage-driver overlay2 \
--master-lb-enabled \
--volume-driver cinder \
--labels boot_volume_type=,boot_volume_size=50,kube_tag=v1.18.2,availability_zone=nova \
--coe kubernetes -f value -c uuid

Koniec każdej linii jest poprzedzony odwrotnym ukośnikiem, więc wszystkie te linie pojawiają się jako jedna (długa) linia w skanerze linii poleceń terminala. Jednak podczas kopiowania i wklejania tego do linii terminala należy uważać na następującą sytuację:

../_images/ku_blanks1.png

Jeśli spacje występują na początku każdej linii, będzie to stanowić problem. Wyeliminuj je, przechodząc do dowolnego edytora tekstu, a następnie usuwając je ręcznie lub za pomocą funkcji replace. To, co musisz mieć w edytorze tekstu, to:

../_images/ku_no_blanks1.png

Teraz możesz go skopiować i wkleić do wiersza poleceń terminala:

../_images/ku_blanks_ok1.png

Zauważ, że linia z etykietami może stać się długa, a jej prawa część może nie być widoczna na ekranie. Użyj \ i nowej linii, aby podzielić długą linię –labels na kilka krótszych:

../_images/ku_labels_broken1.png

Naciśnięcie klawisza Enter na klawiaturze aktywuje całe polecenie i jest ono akceptowane przez system, co widać w linii poniżej polecenia.

Ostrzeżenie

If you are new to Kubernetes please, at first, create clusters only directly using the default cluster template. Once you get more experience, you can start creating your own cluster templates and here is how to do it using CLI.

Polecenie OpenStack służące do utworzenia klastra

W tym kroku można utworzyć nowy klaster przy użyciu domyślnego szablonu klastra lub dowolnego z już utworzonych szablonów.

Enter

openstack coe cluster create -h

aby zobaczyć parametry. Podaj wszystkie lub prawie wszystkie wymagane parametry.

usage: openstack coe cluster create
[-h]
--cluster-template <cluster-template>
[--discovery-url <discovery-url>]
[--docker-volume-size <docker-volume-size>]
[--labels <KEY1=VALUE1,KEY2=VALUE2;KEY3=VALUE3...>]
[--keypair <keypair>]
[--master-count <master-count>]
[--node-count <node-count>]
[--timeout <timeout>]
[--master-flavor <master-flavor>]
[--flavor <flavor>]
<name>

Oto jak może wyglądać jedno z takich poleceń:

openstack coe cluster create
   --cluster-template k8s-stable-1.23.5
   --docker-volume-size 50
   --labels eodata_access_enabled=false,floating-ip-enabled=true,
   --merge-labels
   --keypair sshkey
   --master-count 3
   --node-count 2
   --timeout 190
   --master-flavor eo1.large
   --flavor eo1.large
   newcluster

Ostrzeżenie

Podczas korzystania z przykładowego domyślnego szablonu klastra, k8s-stable-1.23.5, nie ma potrzeby określania etykiety master-lb-enabled=true, ponieważ główny load balancer zawsze będzie tworzony z domyślnym szablonem klastra. Jedynym sposobem na nie utworzenie głównego load balancera z domyślnym szablonem jest określenie flagi -master-lb-disabled. Ponownie, użycie master-lb-enabled=false z -merge-labels zastosowanym później, również nie zadziała, tj. nie zapobiegnie utworzeniu master LB.

Oto kilka specjalnych etykiet, których funkcjonalność jest dostępna tylko przez CLI, a nie przez Horizon.

Jak prawidłowo utworzyć klaster z włączonym automatycznym leczeniem

Informacja

Wymaganie wstępne nr 6 pokaże, jak włączyć interfejs wiersza poleceń na serwerze w chmurze. Wymaganie wstępne nr 7 zapewni formalne wprowadzenie do pojęcia automatycznego uzdrawiania Kubernetes, zaimplementowanego w OpenStack Magnum.

Jedynym sposobem na włączenie automatycznego leczenia i jednoczesne zagwarantowanie, że klaster zostanie utworzony normalnie, jest ustawienie następującej etykiety:

auto_healing_enabled=True

Ostrzeżenie

Nie dołączaj powyższej etykiety, jeśli chcesz utworzyć klaster, który nie korzysta z automatycznego uzdrawiania.

Oto odmiana polecenia CLI do generowania klastra. Będzie on używał średnich wartości zamiast dużych dla smaków, będzie miał tylko jeden węzeł główny i jeden węzeł roboczy, będzie miał włączone automatyczne uzdrawianie itp.

openstack coe cluster create –cluster-template k8s-stable-1.23.5 –labels floating-ip-enabled=true,master-lb-enabled=true,auto_healing_enabled=true –merge-labels –keypair sshkey –master-count 1 –node-count 1 –master-flavor eo1.medium –flavor eo1.medium newcluster

Wykonaj polecenie utworzenia klastra

Skopiuj i wklej powyższe polecenie do terminala, w którym aktywni są klienci OpenStack i Magnum:

../_images/cli_newcluster1.png

Jak sprawdzić status klastra

Polecenie wyświetlające stan klastrów to

openstack coe cluster list

newcluster ma status CREATE_IN_PROGRESS, czyli jest tworzony pod maską. Powtórz polecenie po minucie lub dwóch i zobacz najnowszy status, który teraz brzmi CREATE_FAILED. Aby sprawdzić przyczynę zatrzymania tworzenia klastra, przejdź do interfejsu Horizon, wyświetl listę klastrów i kliknij nazwę newcluster.

W sekcji Stack znajduje się następujący komunikat:

Resource CREATE failed: OverQuotaClient: resources.secgroup_kube_master: Quota exceeded for resources:
['security_group_rule']. Neutron server returns request_ids: ['req-1aff5045-db64-4075-81df-80611db8cb6c']

Przekroczono limit dla reguł grupy zabezpieczeń. Aby to sprawdzić, wykonaj następujące polecenie:

openstack quota show --default

Wynik może być zbyt zagracony w normalnym oknie terminala, więc w tym przypadku więcej informacji będzie dostępnych w interfejsie Horizon:

../_images/overview1.png

Kolory czerwony i pomarańczowy oznaczają niebezpieczeństwo i albo trzeba poprosić pomoc techniczną o podwojenie limitów, albo usunąć instancje i klastry, które je przekroczyły.

Informacja

Opisywanie sposobu usuwania elementów za pośrednictwem interfejsu Horizon wykracza poza zakres tego artykułu. Upewnij się, że przydziały są dostępne przed utworzeniem nowego klastra.

Niepowodzenie utworzenia klastra

Istnieje wiele powodów, dla których klaster może nie zostać utworzony. Być może stan przydziałów systemowych nie jest optymalny, być może istnieje rozbieżność między parametrami klastra a parametrami w pozostałej części chmury. Na przykład, jeśli oprzesz tworzenie klastra na domyślnym szablonie klastra, użyje on dystrybucji Fedora i będzie wymagał 10 GiB pamięci. Może to kolidować z –docker-volume-size, jeśli został on ustawiony na większy niż 10 GiB.

Smaki (flavors) dla mastera i minionów to eo1.large, a jeśli chcesz zwiększyć rozmiar obrazu Dockera, zwiększ rozmiar parametru –master-flavor.

Cała chmura może być przeciążona i tworzenie klastra może trwać dłużej niż domyślne 60 minut. W takich przypadkach należy ustawić parametr –timeout na 120 lub 180 minut.

Jeśli proces tworzenia nie powiódł się przedwcześnie, wówczas

  • przegląd kwot systemowych

  • usunięcie nieudanych klastrów

  • ponownie przejrzeć kwoty systemowe

  • zmienić parametry i

  • uruchom ponownie polecenie utworzenia klastra.

Polecenia CLI służące do usuwania klastra

Jeśli utworzenie klastra nie powiodło się, nadal zajmuje on zasoby systemowe. Usuń go poleceniem takim jak

openstack coe cluster delete

Wyświetl listę klastrów, a najpierw zobaczysz, że status to DELETE_IN_PROGRESS, a po chwili newcluster zniknie.

Teraz spróbuj usunąć klaster largecluster. Istnieją dwa klastry, więc wpisanie polecenia takiego jak

openstack coe cluster delete largecluster

nie zostanie zaakceptowana. Zamiast nazwy należy wprowadzić wartość uuid:

openstack coe cluster delete e80c5815-d20b-4a2b-8588-49cf7a7e1aad

Ponownie żądanie zostanie zaakceptowane, a po minucie lub dwóch wymagany klaster zniknie.

Teraz jest tylko jeden largecluster, więc to zadziała:

openstack coe cluster delete largecluster

Usunięcie klastrów, które nie zostały poprawnie zainstalowane, uwolniło znaczną ilość zasobów systemowych. Nie ma już pomarańczowych i czerwonych kwot:

../_images/after_delete_cluster1.png

W tym kroku udało się usunąć klastry, których tworzenie zostało przedwcześnie zatrzymane, otwierając tym samym drogę do utworzenia kolejnego klastra w nieco innych okolicznościach.

Co robić dalej

W tym samouczku użyto poleceń CLI do generowania szablonów klastrów, a także samych klastrów. Ponadto, jeśli proces klastrowania nie powiódł się, jak zwolnić zasoby systemowe i spróbować ponownie.

OpenStack i Magnum wykonały ciężką pracę za Ciebie, umożliwiając tworzenie pełnoprawnych klastrów Kubernetes za pomocą zaledwie kilku poleceń CLI. Następnym krokiem jest rozpoczęcie bezpośredniej pracy z klastrami Kubernetes. Oznacza to zainstalowanie polecenia kubectl z artykułu Jak uzyskać dostęp do klastra Kubernetes po wdrożeniu przy użyciu Kubectl na NSIS OpenStack Magnum? i użycie go do zainstalowania aplikacji, które chcemy uruchomić na klastrach Kubernetes.