Jak utworzyć serwer API LoadBalancer dla klastra Kubernetes na platformie NSIS OpenStack Magnum

Load balancer może być rozumiany zarówno jako

external adres IP, przez który ruch sieciowy / internetowy dociera do klastra Kubernetes, a także

oprogramowanie, które decyduje, do którego z węzłów głównych wysyłać ruch przychodzący.

Istnieje opcja utworzenia load balancera podczas tworzenia klastra Kubernetes, ale klaster można również utworzyć bez niego. W tym artykule pokażemy, jak uzyskać dostęp do klastra, nawet jeśli podczas jego tworzenia nie określono load balancera.

Co zamierzamy zrobić?

Utworzyć klaster o nazwie NoLoadBalancer z jednym węzłem głównym i bez load balancera.

Przypisać adres floating IP do węzła głównego

Utworzyć plik config w celu uzyskania dostępu do klastra

W pliku config należy zamienić lokalny adres serwera rzeczywistym zmiennym floating IP węzła głównego

Użyj parametru –insecure-skip-tls-verify=true, aby zastąpić zabezpieczenia serwera.

Sprawdź, czy kubectl działa normalnie, co oznacza, że masz pełny dostęp do klastra Kubernetes.

Wymagania wstępne

Nr 1 Hosting

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

Nr 2 Instalacja polecenia openstack

Aby nożna było aktywować polecenie kubectl, musi działać polecenie openstack z interfejsu CLI OpenStack. Pierwsza część artykułu Jak korzystać z interfejsu wiersza poleceń dla klastrów Kubernetes w NSIS OpenStack Magnum pokazuje, jak je zainstalować.

Nr 3 Jak utworzyć klaster Kubernetes przy użyciu poleceń Horizon

Artykuł Jak utworzyć klaster Kubernetes przy użyciu NSIS OpenStack Magnum pokazuje tworzenie klastrów za pomocą wizualnego interfejssu Horizon. W tym artykule użyjesz go do utworzenia przykładowego klastra o nazwie NoLoadBalancer.

Nr 4 Połączenie z klastrem Kubernetes, aby umożliwić użycie kubectl

Artykuł Jak uzyskać dostęp do klastra Kubernetes po wdrożeniu przy użyciu Kubectl na NSIS OpenStack Magnum? wyjaśnia, jak podłączyć maszynę lokalną do istniejącego klastra Kubernetes.

Jak włączyć lub wyłączyć load balancer dla master nodes?

Domyślnie klaster Kubernetes w hostingu NSIS OpenStack Magnum jest tworzony bez wcześniej skonfigurowanego load balancera. Możesz zdecydować się na utworzenie load balancera wraz z podstawowym klastrem Kubernetes, zaznaczając opcję Enable Load Balancer for Master Nodes w oknie Network podczas tworzenia klastra za pośrednictwem interfejsu Horizon. Pełna procedura jest opisana w sekcji Wymaganie wstępne nr 3.

Pole wyboru włączające load balancer dla węzłów głównych ma dwa zupełnie różne znaczenia, gdy jest zaznaczone i niezaznaczone.

Zaznaczone

../_images/enable_load_balancer_checked1.png

Jeśli pole jest zaznaczone, zostanie utworzony load balancer dla węzłów głównych. Jeśli na poprzednich ekranach określono dwa lub więcej węzłów głównych, pole musi być zaznaczone.

Niezależnie od podanej liczby węzłów nadrzędnych zaznaczenie tego pola daje większe szanse na pomyślne utworzenie klastra Kubernetes.

Niezaznaczone

../_images/enable_load_balancer_unchecked1.png

Jeśli zaakceptujesz domyślne ustawienie**bez zaznaczenia**, nie zostanie utworzony żaden load balancer. Jednak bez load balancera „przed” klastrem API klastra jest dostępne tylko w sieci Kubernetes. Oszczędzasz na zasobach load balancera, ale bezpośrednie połączenie z maszyny lokalnej z klastrem zostaje utracone.

Jeden master node bez load balancera i problemy, jakie to stwarza

Aby pokazać dokładnie, na czym polega problem, musząbyć spełnione:

Warunek wstępny nr 2 jest – zainstalowanie klienta openstack na komputerze lokalnym, aby można było użyć polecenia openstack.

Warunek wstępny nr 4 – aby połączyć się z chmurą OpenStack i uruchomić polecenie openstack z lokalnego terminala.

Następnie możesz wypróbować często proste polecenie, takie jak

kubectl get nodes

To polecenie jednak nie zadziała. Gdyby „przed klastrem” istniał load balancer, polecenie by działało, ale w tym przypadku go nie ma. W dalszej części tego artykułu pokażemy, jak sprawić, by polecenie nadal działało, wykorzystując to, że węzeł główny klastra ma własny load balancer dla kube-api.

Krok 1 Utworzenie klastra z jednym węzłem nadrzędnym bez load balancera

Utwórz klaster NoLoadBalancer, jak wyjaśniono w sekcji Wymaganie wstępne nr 3. Niech konfiguracje będzie nastepująca:

jeden master node i

brak load balancerów (nie zaznaczaj pola Enable Load Balancer for Master Nodes w podoknie Network).

Użyj dowolnej pary kluczy – nie ma to znaczenia dla tego artykułu.

Aktywuj NGINX jako kontroler Ingress

Wynikiem będzie utworzenie klastra NoLoadBalancer, jak widać na poniższej ilustracji:

kubernetes/noloadbalancer_created_nsis_pl.png

Aby zilustrować problem, bardzo podstawowe polecenie, takie jak

kubectl get pods NoLoadBalancer -o yaml

służące do wyświetlania listę podów w klastrze NoLoadBalancer wyświetli komunikat o błędzie podobny do tego:

Unable to connect to the server: dial tcp 10.0.0.54:6443: i/o timeout

Adresy zaczynające się od 10.0… są zwykle zarezerwowane dla sieci lokalnych, co oznacza, że w tym czasie nie jest możliwy dostęp z Internetu.

Krok 2 Utwórz adres floating IP dla master node

Oto instancje, które służą jako węzły dla tego klastra:

kubernetes/created_instances_nsis_pl.png

Węzeł nadrzędny nazywa się noloadbalancer-3h2i5x5iz2u6-master-0. Kkliknij po prawej stronie jego wiersza i wybierz opcję Associate Floating IP.

Aby dodać adres IP, kliknij wybór dostępnych adresów (może być tylko jeden adres, ale w niektórych przypadkach może być ich kilka do wyboru):

kubernetes/associate_floating_ip_nsis_pl.png

Wynik jest następujący:

kubernetes/floating_ip_created_nsis_pl.png

Adres IP to 64.225.135.112 – zostanie on później użyty, aby zmienić plik config w celu uzyskania dostępu do klastra Kubernetes.

Krok 3 Utworzenie pliku konfiguracyjnego dla klastra Kubernetes

Teraz połączysz się z klastrem NoLoadBalancer, mimo że na początku nie ma on load balancera. W tym celu utwórz plik konfiguracyjny, aby połączyć się z klastrem za pomocą następującego polecenia:

openstack coe cluster config NoLoadBalancer --force

Zwróci ono wiersz taki jak ten:

export KUBECONFIG=/Users/<YOUR PATH TO CONFIG FILE>/config

Wykonaj to polecenie z wiersza poleceń terminala. Pod tym adresem został również utworzony plik konfiguracyjny. Aby wyświetlić jego zawartość, wykonaj polecenie:

cat config

Zakłada się przy tym, że jesteś już w wymaganym katalogu.

Zawartość pliku konfiguracyjnego będzie wyglądać jak śmieci, ponieważ zawiera on certyfikaty, tokeny i inne wiersze z losową zawartością, niektóre z nich mają setki znaków. Oto jedna z jego części:

Ważnym wierszem jest tutaj adres sieciowy:

server: https://10.0.0.54:6443

Krok 4 Zamiana istniejącego adresu floating IP na adres sieciowy

Teraz wróć do interfejsu Horizon i wykonaj polecenia Compute -> Instances, aby zobaczyć adresy węzła głównego klastra NoLoadBalancer:

kubernetes/master_node_addresses_nsis_pl.png

Istnieją dwa adresy:

10.0.0.54, 64.225.135.112

Nawiasem mówiąc, ten sam adres 10.0.0.54 jest również obecny w pliku config, a po nim następuje numer portu :6443.

Spróbuj teraz w terminalu wykonać polecenie kubectl i zobacz wynik, być może będzie taki jak ten:

kubernetes/kubectl_without_access_nsis_pl.png

Istnieje dostęp, ale węzły i pody są nadal niedostępne. Dzieje się tak, ponieważ adres 10.0.0.54 jest wewnętrznym adresem sieciowym klastra i nigdy nie miał działać jako adres internetowy.

Otwórz plik config za pomocą nano (lub innego edytora tekstu). Zamień 10.0.0.54 na 64.225.135.112 w linii dostępu do serwera. Adres 64.225.135.112 jest adresem floating IP dla węzła głównego i będzie pasował idealnie.

Wierds powinien wyglądać następująco:

Zapisz edytowany pliku. W przypadku nano będą to polecenia Control-x, Y i naciśnięcie klawisza Enter na klawiaturze.

Krok 4 Dodaj parametr –insecure-skip-tls-verify=true, aby kubectl działał

Spróbuj ponownie aktywować kubectl i znowu się to nie powiedzie. Aby polecenie zadziałało, należy dodać parametr –insecure-skip-tls-verify=true:

kubectl get pods --insecure-skip-tls-verify=true

Ewentualnie wypróbuj szersze polecenie:

kubectl get nodes --insecure-skip-tls-verify=true

Oto wynik wszystkich tych poleceń w oknie terminala:

Aby kontynuować pracę, należy używać zwykłych poleceń kubectl i zawsze dodawać parametr –insecure-skip-tls-verify=true na końcu.

Uwaga

Użycie parametru –insecure-skip-tls-verify powoduje pominięcie sprawdzenia ważności certyfikatów klastra. Spowoduje to, że połączenia https nie będą bezpieczne. Nie jest to zalecane dla środowiska produkcyjnego. Używaj tej opcji na własne ryzyko, na przykład do lokalnych testów lub gdy dopiero uczysz się pracować z Kubernetes i klastrami.

W przypadku środowiska produkcyjnego zdecydowanie zaleca się zaznaczenie pola Enable Load Balancer for Master Nodes podczas tworzenia nowego klastra, niezależnie od liczby określonych master nodes.