Korzystanie z Kubernetes Ingress w OpenStack Magnum w NSIS Cloud

Funkcja Ingress w Kubernetes może być powiązana z kierowaniem ruchu spoza klastra do usług w klastrze. Dzięki funkcji Ingress wiele usług Kubernetes może być dostępnych przy użyciu jednego load balancera.

W tym artykule przedstawimy, w jaki sposób Ingress jest wdrażany w chmurze. Zademonstrujemy również praktyczny przykład udostępniania usług Kubernetes w chmurze za pomocą Ingress. Na koniec będziesz w stanie utworzyć jedną lub więcej witryn i usług działających w klastrze Kubernetes. Utworzone w ten sposób usługi będą:

  • działać na tym samym adresie IP bez potrzeby tworzenia dodatkowego load balancera dla każdej usługi i będą również

  • automatycznie korzystać ze wszystkich zalet klastra Kubernetes – niezawodności, skalowalności itp.

Co zostanie omówione?

  • Utworzenie klastra Magnum Kubernetes z włączonym NGINX Ingress

  • Tworzenie i udostępnianie serwerów Apache i Nginx do testowania

  • Tworzenie zasobu Ingress

  • Sprawdzenie, czy Ingress może uzyskać dostęp do obu serwerów testowych

Wymagania wstępne

Nr 1 Konto

Jest wymagane konto hostingowe NSIS z dostępem do interfejsu Horizon: https://horizon.cloudferro.com.

Nr 2 Ogólna znajomość podstaw Kubernetes

Przydatna będzie ogólna znajomość podstaw Kubernetes: tworzenie klastrów, podów, wdrożeń, usług i tak dalej.

Nr 3 Dostęp do polecenia kubectl

Aby zainstalować niezbędne oprogramowanie (jeśli jeszcze nie jest zainstalowane), zobacz artykuł Jak uzyskać dostęp do klastra Kubernetes po wdrożeniu przy użyciu Kubectl na NSIS OpenStack Magnum?.

Wynikiem czynności wykonanych zgodnie z instrukcjami zawartymi w tym i powiązanych artykułach będzie:

  • utworzony poprawnie klaster gotowy do użycia, a także

  • umożliwienie dostępu do klastra z lokalnej maszyny (uruchomienie polecenia kubectl).

Krok 1 Utworzenie klastra Magnum Kubernetes z włączoną usługą NGINX Ingress

Tworząc klaster Kubernetes w chmurze, możemy wdrożyć go ze wstępnie skonfigurowanymi ustawieniami ingress. Wymaga to minimalnych zmian i jest opisane w artykule Jak utworzyć klaster Kubernetes przy użyciu NSIS OpenStack Magnum.

Taki klaster jest wdrażany z kontrolerem ingress NGINX i domyślnym backendem ingress. Rolą kontrolera jest umożliwienie udostępniania infrastruktury, na przykład (wirtualnego) load balancera. Rolą backendu jest zapewnienie dostępu do tej infrastruktury zgodnie z regułami zdefiniowanymi przez ingress resource (zostanie to wyjaśnione później).

Możemy zweryfikować dostępność tych artefaktów, wpisując następujące polecenie:

kubectl get pods -n kube-system

Wynik powinien być podobny do poniższego. Widzimy, że utworzono kontroler ingress, a także backend ingress, oba te komponenty działają jako pody w naszym klastrze.

kubectl get pods -n kube-system
NAME                                                   READY   STATUS    RESTARTS   AGE
...
magnum-nginx-ingress-controller-zxgj8                  1/1     Running   0          65d
magnum-nginx-ingress-default-backend-9dfb4c685-8fjdv   1/1     Running   0          83d
...

W domyślnej przestrzeni nazw dostępna jest również klasa ingress:

kubectl get ingressclass
NAME    CONTROLLER             PARAMETERS   AGE
nginx   k8s.io/ingress-nginx   <none>       7m36s

Krok 2 Tworzenie usług dla serwera Apache i Nginx

Zamierzasz teraz zbudować i udostępnić dwie minimalne aplikacje:

  • Serwer Nginx

  • Serwer WWW Apache

Oba serwery będą dostępne z jednego publicznego adresu IP przy użyciu jednego domyślnego load balancera. Strony WWW serwowane z każdego serwera będą dostępne w przeglądarce z ujednoliconym schematem routingu. W podobny sposób można mieszać i dopasowywać aplikacje napisane w różnych innych technologiach.

Najpierw utwórzmy aplikację serwera Nginx. Dla zwięzłości użyjemy wiersza poleceń z domyślnymi ustawieniami:

kubectl create deployment nginx-web --image=nginx
kubectl expose deployment nginx-web --type=NodePort --port=80

Podobnie tworzymy aplikację Apache:

kubectl create deployment apache-web --image=httpd
kubectl expose deployment apache-web --type=NodePort --port=80

W wyniku tych czynności zostają utworzpne usługi dla każdej aplikacji, co można sprawdzić za pomocą poniższego polecenia. Za każdą usługą kryje się wdrożenie i działający pod.

kubectl get services

Wynik powinien być podobny do tego:

kubectl get services
NAME              TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)        AGE
apache-web        NodePort       10.254.80.182    <none>           80:32660/TCP   75s
kubernetes        ClusterIP      10.254.0.1       <none>           443/TCP        84d
nginx-web         NodePort       10.254.101.230   <none>           80:32532/TCP   36m

Usługi zostały utworzone z typem NodePort, który jest wymagany do pracy z ingress, dlatego nie są one jeszcze dostępne pod publicznym adresem IP. Serwery są już jednak uruchomione i obsługują swoje domyślne strony powitalne.

Możesz to sprawdzić, przypisując adres Floating IP do jednego z węzłów (patrz artykuł /networking/How-to-Add-or-Remove-Floating-IPs-to-your-VM-on-NSIS). Następnie połącz się przez SSH z węzłem i uruchom następujące polecenie:

curl <name-of-node>:<port-number>

Na przykład dla powyższego scenariusza widzimy dane wyjściowe:

curl ingress-tqwzjwu2lw7p-node-1:32660
<html><body><h1>It works!</h1></body></html>

Krok 3 Utworzenie zasobu Ingress

Aby udostępnić aplikację na publicznym adresie IP, należy zdefiniować zasób Ingress. Ponieważ obie aplikacje będą dostępne na tyn samym adresie IP, zasób Ingress zdefiniuje szczegółowe zasady dotyczące tego, co będzie obsługiwane w której trasie. W tym przykładzie trasa /apache będzie obsługiwana przez usługę Apache, a wszystkie inne trasy będą obsługiwane przez usługę Nginx.

Informacja

Trasy można konfigurować na wiele sposobów, tutaj przedstawiamy tylko ułamek tych możliwości.

Utwórz plik YAML o nazwie my-ingress-resource.yaml z następującą zawartością:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
    - http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: nginx-web
              port:
                number: 80
        - path: /apache
          pathType: Prefix
          backend:
            service:
              name: apache-web
              port:
                number: 80

Wdróż go za pomocą polecenia:

kubectl apply -f my-ingress-resource.yaml

Po pewnym czasie (zwykle od 2 do 5 minut) sprawdź, czy adres floating IP został przypisany do ingress:

kubectl get ingress
NAME              CLASS   HOSTS      ADDRESS         PORTS   AGE
example-ingress   nginx   *          64.225.130.77   80      3m16s

Informacja

Adres 46.60.19.253 został wygenerowany losowo i w twoim przypadku będzie inny. Pamiętaj, aby skopiować i użyć adresu wyświetlonego przez polecenie kubectl get ingress.

Krok 4 Sprawdzenie działania

Skopiuj adres floating IP do przeglądarki i dodaj kilka przykładowych tras. Powinien zostać wyświetlony wynik podobny do tego poniżej. Oto zrzut ekranu dla trasy /apache:

../_images/apache_route_nsis_pl1.png

Ten zrzut ekranu pokazuje, co dzieje się dla każdej innej trasy – domyślnie jest to Nginx:

../_images/any_other_route_nsis_pl1.png

Co można zrobić dalej?

Masz teraz dwa najpopularniejsze serwery internetowe zainstalowane jako usługi w klastrze Kubernetes. Oto kilka pomysłów na wykorzystanie tej konfiguracji:

Utworzenie innej usługi na tym samym serwerze.

Aby utworzyć kolejną usługę pod tym samym adresem IP, powtórz całą procedurę z inną nazwą punktu końcowego zamiast /apache. Nie zapomnij dodać odpowiedniego wpisu do pliku YAML.

Dodanie innych punktów końcowych do użytku z Nginx

Można utworzyć inne punkty końcowe i używać Nginx jako podstawowego serwera zamiast Apache.

Użycie obrazów innych niż nginx i httpd

W Internecie istnieje wiele źródeł kontenerów, ale najpopularniejszym katalogiem jest dockerhub.com. Zawiera on obrazy systemów operacyjnych z preinstalowanym oprogramowaniem, którego możesz chcieć użyć, co zaoszczędzi ci wysiłku związanego z pobieraniem i testowaniem instalacji.

Mikrousługi

Zamiast umieszczać cały kod i dane na jednej maszynie wirtualnej, na Kubernetes można wdrażać wiele niestandardowych kontenerów. Typowa konfiguracja wygląda następująco:

  • pod nr 1 zawiera bazę danych, na przykład MariaDB, jako backend,

  • pod nr 2 może zawierać PHPMyAdmin jako frontend bazy danych,

  • pod nr 3 może zawierać instalację WordPress, który jest frontendem dla odwiedzających witrynę

  • pod nr 4 może zawierać własny spersonalizowany kod wtyczek WordPress.

Każdy z tych podów będzie pobierał kod z wyspecjalizowanego obrazu. Jeśli chcesz edytować część kodu, wystarczy zaktualizować odpowiedni obraz Docker w Docker hub i ponownie go wdrożyć.

Użycie DNS, aby utworzyć nazwę domeny dla serwera.

Możesz użyć usługi DNS, aby połączyć odpowiednią nazwę domeny z adresem IP używanym w tym artykule. Po dodaniu Cert Manager i bezpłatnej usługi, takiej jak Let’s Encrypt, serwer wejściowy będzie w prosty sposób obsługiwał protokół HTTPS.