Jak utworzyć klaster Kubernetes przy użyciu NSIS OpenStack Magnum
W tym samouczku zaczniesz od pustego ekranu Horizon, a skończysz na uruchomieniu pełnego klastra Kubernetes.
Co będziemy omawiać
Tworzenie nowego klastra Kubernetes przy użyciu jednego z domyślnych szablonów klastrów
Wizualna interpretacja utworzonych sieci i węzłów klastra Kubernetes
Wymagania wstępne
Nr 1 Hosting
Potrzebne jest konto hostingowe NSIS z interfejsem Horizon https://horizon.cloudferro.com.
Zasoby, których potrzebujesz i używasz, będą odzwierciedlone w stanie portfela Twojego konta. Sprawdź statystyki swojego konta na https://nsis-cloud-innovation.cloudferro.com/login i jeśli nie zamierzasz już korzystać z klastra, usuń go całkowicie, aby zaoszczędzić na kosztach zasobów.
Klastry Magnum utworzone przez określonych użytkowników są powiązane z tokenem impersonacji i w przypadku usunięcia tego użytkownika z projektu, klaster utraci uwierzytelnienie do Openstack API, co spowoduje, że klaster nie będzie działał. Typowy scenariusz zakłada, że menedżer dzierżawy tworzy konta użytkowników i pozwala im tworzyć klastry Kubernetes. Później, w tym scenariuszu, gdy klaster będzie działał, użytkownik zostanie usunięty z projektu. Klaster byłby obecny, ale użytkownik nie mógłby, powiedzmy, tworzyć nowych klastrów lub trwałe roszczenia woluminu byłyby dysfunkcyjne i tak dalej.
Dlatego dobrą praktyką przy tworzeniu nowych klastrów Kubernetes jest utworzenie konta usługi dedykowanego do tworzenia klastra Magnum. Zasadniczo należy poświęcić jedno konto na jeden klaster Kubernetes, nic więcej i nic mniej.
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.
Para kluczy utworzona w tym artykule nosi nazwę „sshkey”. Zostanie ona użyta jako jeden z parametrów do utworzenia klastra Kubernetes.
Krok 1 Ekran tworzenia nowego klastra
Kliknij Container Infra, a następnie Clusters.
Nie ma jeszcze klastrów, więc kliknij przycisk + Utwórz klaster po prawej stronie ekranu.
On the left side and in blue color are the main options – screens into which you will enter data for the cluster. The three with the asterisks, Details, Size, and Network are mandatory; you must visit them and either enter new values or confirm the offered default values within each screen. When all the values are entered, the Submit button in the lower right corner will become active.
Nazwa klastra
To twój pierwszy klaster, nazwij go po prostu Kubernetes.
Nazwa klastra nie może zawierać spacji. Użycie nazwy takiej jak XYZ k8s Production spowoduje wyświetlenie komunikatu o błędzie, podczas gdy nazwa taka jak XYZ-k8s-Production nie spowoduje błędu.
Szablon klastra
Szablon klastra to plan podstawowej konfiguracji klastra, w którym numer wersji odzwierciedla używaną wersję Kubernetes.
Od razu widać, jak stosowany jest szablon klastra:
Strefa dostępności
nova to nazwa powiązanego modułu w OpenStack i jest to jedyna oferowana tutaj opcja.
Para kluczy
Zakładając, że skorzystałeś z Warunku wstępnego nr 2, wybierz klucz.
Oprogramowanie dodatkowe - dostęp do danych EO
To pole jest specyficzne dla systemów OpenStack, które są rozwijane przez firmę hostingową Cloudferro. EODATA oznacza tutaj Earth Observation Data i odnosi się do danych uzyskanych z satelitów naukowych monitorujących Ziemię.
Zaznaczenie tego pola spowoduje zainstalowanie sieci, która będzie miała dostęp do pobranych danych satelitarnych.
Jeśli dopiero próbujesz poznać Kubernetes na OpenStack, pozostaw tę opcję niezaznaczoną. I odwrotnie: jeśli chcesz przejść do produkcji i korzystać z danych satelitarnych, włącz tę opcję.
Informacja
Istnieje etykieta szablonu klastra o nazwie eodata_access_enabled=true, która - jeśli zostanie włączona - będzie miała ten sam efekt tworzenia sieci do łączenia się z EODATA.
Tak wygląda ekran po wprowadzeniu wszystkich danych:
Kliknij prawy dolny przycisk Next lub opcję Size z lewego menu głównego ekranu, aby przejść do następnego kroku definiowania klastra Kubernetes.
Krok 2 Definiowanie węzłów głównych i roboczych
Ogólnie rzecz biorąc, węzły główne są używane do hostowania wewnętrznej infrastruktury klastra, podczas gdy węzły robocze są używane do hostowania aplikacji K8s.
Tak wygląda to okno przed wprowadzeniem danych:
Jeśli istnieją pola z wartościami domyślnymi, takie jak Smak Węzłów Głównych i Smak węzłów roboczych, wartości te zostały wstępnie zdefiniowane w szablonie klastra.
Liczba węzłów nadrzędnych
Klaster Kubernetes składa się z węzłów master i worker. W rzeczywistych zastosowaniach typowa konfiguracja obejmuje 3 węzły główne, aby zapewnić wysoką dostępność infrastruktury klastra. W tym przypadku chcemy utworzyć pierwszy klaster w nowym środowisku, więc wystarczy 1 węzeł główny.
Smak Węzłów Głównych
Wybierz eo1.large dla smaku węzła głównego.
Liczba węzłów roboczych
Wpisz 3. Służy to jedynie celom wprowadzającym, w rzeczywistości klaster może składać się z wielu węzłów roboczych. Wytyczne dotyczące rozmiaru klastra wykraczają poza zakres tego artykułu.
Smak węzłów roboczych
Ponownie wybierz eo1.large.
Auto Skalowanie
Gdy istnieje duże zapotrzebowanie na usługi pracowników, system Kubernetes może skalować się do użycia większej liczby węzłów roboczych. Nasze przykładowe ustawienie to minimum 2 i maksimum 4 węzły główne. Przy tym ustawieniu liczba węzłów będzie dynamicznie dostosowywana między tymi wartościami, w oparciu o bieżące obciążenie (liczba i żądania zasobów kapsuł uruchamiających aplikacje K8S w klastrze).
Oto jak wygląda ekran Size po wprowadzeniu wszystkich danych:
Aby kontynuować, kliknij prawy dolny przycisk Next lub opcję Network z menu głównego po lewej stronie.
Krok 3 Definiowanie sieci i LoadBalancera
Jest to ostatni z obowiązkowych ekranów i niebieski przycisk Prześlij w prawym dolnym rogu jest teraz aktywny. (Jeśli nie jest, użyj przycisku ekranowego Wstecz, aby poprawić wartości z poprzednich ekranów).
Włącz Load Balancer dla węzłów głównych
Opcja ta zostanie automatycznie zaznaczona po wybraniu więcej niż jednego węzła głównego. Korzystanie z wielu węzłów nadrzędnych zapewnia wysoką dostępność infrastruktury klastra, a w takim przypadku Load Balancer będzie niezbędny do dystrybucji ruchu między węzłami nadrzędnymi.
Jeśli wybrano tylko jeden węzeł główny, co może być istotne w scenariuszach nieprodukcyjnych, np. testowych, nadal będzie dostępna opcja dodania lub pominięcia Load Balancera. Należy pamiętać, że korzystanie z LoadBalancera z jednym węzłem głównym jest nadal istotną opcją, ponieważ ta opcja umożliwi dostęp do klastra spoza sieci klastra. W przypadku braku takiej opcji trzeba będzie polegać na dostępie SSH do węzła nadrzędnego.
Utwórz nową sieć
To pole jest włączone, co oznacza, że system utworzy sieć tylko dla tego klastra. Ponieważ klastry Kubernetes potrzebują podsieci do wzajemnej komunikacji, najpierw zostanie utworzona powiązana podsieć, która będzie używana później.
Zdecydowanie zaleca się korzystanie z automatycznego tworzenia sieci podczas tworzenia nowego klastra.
Jednak wyłączenie tego pola wyboru ujawnia również opcję korzystania z istniejącej sieci.
Użyj istniejącej sieci
Korzystanie z istniejącej sieci jest bardziej zaawansowaną opcją. Należy najpierw utworzyć sieć dedykowaną dla tego klastra w OpenStack wraz z niezbędnymi dostosowaniami. Tworzenie takiej niestandardowej sieci wykracza poza zakres tego artykułu. Nie należy używać sieci innego klastra, sieci projektu lub sieci EODATA.
Jeśli masz istniejącą sieć i chcesz kontynuować, musisz wybrać sieć i podsieć z listy rozwijanej poniżej:
Oba pola mają za sobą gwiazdkę, co oznacza, że w każdym z nich należy podać konkretną wartość.
Cluster API
Ustawienie „Dostępne w publicznym Internecie” oznacza, że pływające adresy IP zostaną przypisane zarówno do węzłów głównych, jak i roboczych. Ta opcja jest zazwyczaj zbędna i ma wpływ na bezpieczeństwo. Jeśli nie masz konkretnych wymagań, pozostaw tę opcję w ustawieniu „prywatnym”. Następnie zawsze można przypisać pływające adresy IP do wymaganych węzłów z sekcji „Compute” w Horizon.
Ingress Controller
Korzystanie z ingress jest bardziej zaawansowaną funkcją, związaną z równoważeniem obciążenia ruchu do aplikacji Kubernetes.
Jeśli dopiero zaczynasz korzystać z Kubernetes, raczej nie będziesz potrzebować tej funkcji od razu, więc możesz pominąć tę opcję.
Krok 4 Opcje zaawansowane
**Zarządzanie opcjami
W oknie tym znajduje się tylko jedna opcja, Auto Healing i jej pole Automatically Repair Unhealthy Nodes.
Węzeł Node jest podstawową jednostką klastra Kubernetes, a oprogramowanie systemowe Kubernetes automatycznie sprawdza stan każdego klastra; jeśli nie jest gotowy lub niedostępny, system zastąpi niezdrowy węzeł zdrowym - oczywiście pod warunkiem, że to pole jest zaznaczone.
Jeśli po raz pierwszy wypróbowujesz tworzenie klastrów Kubernetes, automatyczne uzdrawianie może Cię nie interesować. Jednak w środowisku produkcyjnym funkcja automatycznego leczenia powinna być zawsze włączona.
Opcja zaawansowana
Opcja Advanced pozwala na wprowadzenie tzw. labels, czyli nazwanych parametrów dla systemu Kubernetes. Zwykle nie trzeba tu nic wpisywać.
Etykiety mogą zmienić sposób tworzenia klastra. Istnieje zestaw etykiet o nazwie Template and Workflow Labels, które system ustawia domyślnie. Jeśli to pole wyboru pozostanie niezaznaczone, domyślne etykiety będą używane bez zmian. Gwarantuje to, że klaster zostanie utworzony z zachowaniem wszystkich istotnych parametrów. Nawet jeśli dodasz własne etykiety, jak pokazano na powyższym obrazku, wszystko będzie nadal działać.
Jeśli włączysz pole Chcę zastąpić szablon i etykiety przepływu pracy i jeśli użyjesz dowolnego szablonu i etykiety przepływu pracy według nazwy, zostaną one skonfigurowane w określony sposób. Z tej opcji należy korzystać bardzo rzadko, jeśli w ogóle, i tylko wtedy, gdy jest się pewnym tego, co się robi.
Krok 5 Tworzenie klastra
Po kliknięciu przycisku Submit, OpenStack rozpocznie tworzenie klastra Kubernetes. W prawym górnym rogu okna pojawi się komunikat w chmurze z zielonym tłem, informujący, że tworzenie klastra zostało rozpoczęte.
Generowanie klastrów trwa zazwyczaj od 10 do 15 minut. Zostanie ono automatycznie przerwane, jeśli czas trwania przekroczy 60 minut.
Jeśli wystąpi jakikolwiek problem z utworzeniem klastra, system zasygnalizuje to na różne sposoby. W prawym górnym rogu może pojawić się komunikat na czerwonym tle, taki jak ten:
Wystarczy powtórzyć proces, a w większości przypadków przejdziesz do następującego ekranu:
Kliknij nazwę klastra Kubernetes i zobacz, jak będzie wyglądał, jeśli wszystko poszło dobrze.
Krok 6 Przegląd stanu klastra
Oto, co OpenStack Magnum stworzył dla ciebie w wyniku wypełnienia danych na tych trzech ekranach:
Nowa sieć o nazwie Kubernetes, wraz z podsiecią, gotowa do dalszego połączenia.
Nowe instancje - maszyny wirtualne, które służą jako węzły.
Nowy router zewnętrzny.
Nowe grupy zabezpieczeń i oczywiście
W pełni funkcjonujący klaster Kubernetes na szczycie wszystkich tych innych elementów.
Można zauważyć, że liczba węzłów w klastrze wynosiła początkowo 3, ale po pewnym czasie klaster automatycznie przeskalował się do 2. Jest to oczekiwane i jest wynikiem działania autoskalera, który wykrył, że nasz klaster jest w większości nadal bezczynny pod względem obciążenia aplikacji.
Istnieje jeszcze jeden sposób, w jaki możemy wyświetlić naszą konfigurację klastra i sprawdzić wszelkie odchylenia od wymaganego stanu. Kliknij na Network w menu głównym, a następnie na Network Topology. Zobaczysz graficzną reprezentację sieci w czasie rzeczywistym. Gdy tylko jeden z elementów klastra zostanie dodany, zostanie on wyświetlony na ekranie.
Również w panelu „Compute” Horizon można zobaczyć maszyny wirtualne, które zostały utworzone dla węzłów głównych i roboczych:
Nazwy węzłów zaczynają się od kubernetes, ponieważ jest to nazwa klastra pisana małymi literami.
Zasoby związane z jedną próbą utworzenia klastra nie są automatycznie odzyskiwane przy ponownej próbie utworzenia nowego klastra. Dlatego kilka prób z rzędu doprowadzi do sytuacji patowej, w której żaden klaster nie zostanie utworzony, dopóki wszystkie związane zasoby nie zostaną zwolnione.
Co robić dalej
Masz teraz w pełni działający klaster Kubernetes. Możesz
używać gotowych obrazów Docker do automatyzacji instalacji aplikacji,
aktywować pulpit nawigacyjny Kubernetes i obserwować stan klastra online,
dostęp do EODATA za pośrednictwem klastra
i tak dalej.
Oto kilka istotnych artykułów:
Przeczytaj więcej o ingress tutaj: Korzystanie z Kubernetes Ingress w NSIS OpenStack Magnum
Artykuł Jak korzystać z interfejsu wiersza poleceń dla klastrów Kubernetes w NSIS OpenStack Magnum? pokazuje jak używać interfejsu wiersza poleceń do tworzenia klastrów Kubernetes.
Aby uzyskać dostęp do nowo utworzonego klastra z linii poleceń, zobacz artykuł Jak uzyskać dostęp do klastra Kubernetes po wdrożeniu przy użyciu Kubectl na NSIS OpenStack Magnum?.
Aby pracować z EODATA z klastra Kubernetes, zobacz artykuł Dostęp do EODATA z Kubernetes Pods w NSIS Cloud przy użyciu boto3.