Jak utworzyć serwer API LoadBalancer dla klastra Kubernetes na platformie NSIS OpenStack Magnum
Load balancer może być rozumiany zarówno jako
zewnętrzny 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 nadrzędnych wysłać ruch przychodzący.
Istnieje opcja utworzenia load balancera podczas tworzenia klastra Kubernetes, ale można go również utworzyć bez niego. W tym artykule pokażemy, jak uzyskać dostęp do klastra, nawet jeśli nie określono load balancera podczas jego tworzenia.
Co zamierzamy zrobić
Utwórz klaster o nazwie NoLoadBalancer z jednym węzłem głównym i bez load balancera.
Przypisanie pływającego adresu IP do węzła nadrzędnego
Utworzenie pliku config w celu uzyskania dostępu do klastra
W pliku config należy zamienić lokalny adres serwera z rzeczywistym zmiennym adresem 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
Potrzebne jest konto hostingowe NSIS z interfejsem Horizon https://horizon.cloudferro.com.
Nr 2 Instalacja polecenia openstack
Aby aktywować polecenie kubectl, polecenie openstack z interfejsu CLI OpenStack musi działać. Pierwsza część artykułu Jak korzystać z interfejsu wiersza poleceń dla klastrów Kubernetes w NSIS OpenStack Magnum? pokazuje jak ją 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 z wizualnym interfejsem Horizon. (W tym artykule użyjesz go do utworzenia przykładowego klastra o nazwie NoLoadBalancer).
Nr 4 Połączenie z klastrem Kubernetes w celu użycia kubectl
Artykuł Jak uzyskać dostęp do klastra Kubernetes po wdrożeniu przy użyciu Kubectl na NSIS OpenStack Magnum? pokaże ci jak podłączyć lokalną maszynę do istniejącego klastra Kubernetes.
Jak włączyć lub wyłączyć Load Balancer dla węzłów głównych?
Domyślnym stanem klastra Kubernetes w hostingu NSIS OpenStack Magnum jest brak 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 znajduje się w Wymaganiu wstępnym 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.
Stan sprawdzony
Jeśli 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, to pole musi być zaznaczone.
Niezależnie od liczby określonych węzłów nadrzędnych, zaznaczenie tego pola daje większe szanse na pomyślne utworzenie klastra Kubernetes.
Stan niezaznaczony
Jeśli zaakceptujesz domyślny stan unchecked, nie zostanie utworzony żaden load balancer. Jednak bez żadnego load balancera „przed” klastrem, API klastra jest dostępne tylko w sieci Kubernetes. Oszczędzasz na istnieniu load balancera, ale bezpośrednie połączenie z lokalnej maszyny do klastra zostaje utracone.
Jeden węzeł nadrzędny, brak Load Balancera i problem, jaki to wszystko stwarza
Aby pokazać dokładnie, na czym polega problem, użyj
Warunkiem wstępnym nr 2 jest zainstalowanie klienta openstack na komputerze lokalnym, aby można było użyć polecenia openstack.
Następnie użyj warunku nr 4, aby połączyć się z chmurą OpenStack i uruchomić polecenie openstack z lokalnego terminala.
Następnie możesz wypróbować bardzo zwykłe polecenie, takie jak
kubectl get nodes
ale to nie zadziała. Gdyby istniał load balancer „przed klastrem”, to by działało, ale tutaj go nie ma, więc nie będzie. W dalszej części tego artykułu pokażemy, jak sprawić, by nadal działało, wykorzystując fakt, ż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 i bez Load Balancera
Utwórz klaster NoLoadBalancer, jak wyjaśniono w warunku wstępnym nr 3. Niech będzie
jeden węzeł główny 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ższym obrazku:
Aby zilustrować problem, bardzo podstawowe polecenie, takie jak
kubectl get pods NoLoadBalancer -o yaml
aby wyświetlić listę strąkó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 włączony dostęp z Internetu.
Krok 2 Utwórz zmienny adres IP dla węzła nadrzędnego
Oto instancje, które służą jako węzły dla tego klastra:
Węzeł nadrzędny nazywa się noloadbalancer-3h2i5x5iz2u6-master-0 i kliknij po prawej stronie jego wiersza i kliknij opcję Associate Floating IP.
Aby dodać adres IP, kliknij wybór dostępnych adresów (może być tylko jeden, ale w niektórych przypadkach może być kilka do wyboru):
Oto rezultat:
Numer IP to 64.225.135.112 - zostanie on później użyty do zmiany pliku config w celu uzyskania dostępu do klastra Kubernetes.
Krok 3 Utworzenie pliku konfiguracyjnego dla klastra Kubernetes
Teraz zamierzasz połączyć się z klastrem NoLoadBalancer, mimo że od samego 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 ona 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ładając, że jesteś już w wymaganym folderze.
Plik konfiguracyjny będzie wyglądał jak bełkot, ponieważ zawiera 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 zmiennego adresu IP na adres sieciowy
Teraz wróć do interfejsu Horizon i wykonaj polecenia Compute -> Instances, aby zobaczyć adresy węzła głównego klastra NoLoadBalancer:
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, kończąc na adresie portu :6443.
Spróbuj teraz w terminalu wykonać polecenie kubectl i zobacz wynik, być może taki jak ten:
Dostęp jest, ale węzły i pody są nadal poza zasięgiem. 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 pływającego IP dla węzła głównego i będzie pasował idealnie.
Linia powinna wyglądać następująco:
Zapisanie edytowanego pliku. W przypadku nano będą to komendy Control-x, Y i naciśnięcie Enter na klawiaturze.
Krok 4 Dodaj parametr –insecure-skip-tls-verify=true, aby kubectl działał
Spróbuj ponownie aktywować kubectl i znowu się nie powiedzie. Aby to zadziałało, należy dodać parametr –insecure-skip-tls-verify=true:
kubectl get pods --insecure-skip-tls-verify=true
Lub wypróbuj bardziej znaczące polecenie
kubectl get nodes --insecure-skip-tls-verify=true
Oto wynik wszystkich tych poleceń w oknie terminala:
Aby kontynuować pomyślną pracę, należy używać zwykłych poleceń kubectl i zawsze dodawać –insecure-skip-tls-verify=true na końcu.
Uwaga
Użycie parametru –insecure-skip-tls-verify nie będzie sprawdzać ważności certyfikatów klastra. Spowoduje to, że połączenia https nie będą bezpieczne. Nie zalecane dla środowiska produkcyjnego. Używaj na własne ryzyko, być może do lokalnych testów lub gdy dopiero uczysz się o Kubernetes i klastrach.
W przypadku produkcji zdecydowanie zaleca się zaznaczenie pola Enable Load Balancer for Master Nodes podczas tworzenia nowego klastra, niezależnie od liczby określonych węzłów głównych.