Skip to main content
  • »
  • KUBERNETES »
  • Korzystanie z Kubernetes Ingress w NSIS OpenStack Magnum

Korzystanie z Kubernetes Ingress w NSIS OpenStack Magnum

Funkcja Ingress w Kubernetes może być powiązana z kierowaniem ruchu spoza klastra do usług w klastrze. Dzięki 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 eksponowania usług Kubernetes za pomocą Ingress w chmurze. Na koniec będziesz mógł 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 LoadBalancera dla każdej usługi i będzie również

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

Co będziemy omawiać

  • Utwórz klaster Magnum Kubernetes z włączonym NGINX Ingress

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

  • Utwórz zasób Ingress

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

Wymagania wstępne

Nr 1 Konto

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

Nr 2 Podstawowa znajomość podstaw Kubernetes

Przyda się podstawowa znajomość podstaw Kubernetes: tworzenie klastrów, podsów, wdrożeń, usług i tak dalej.

Nr 3 Dostęp do polecenia kubectl

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

Wynikiem netto postępowania zgodnie z instrukcjami zawartymi w tym i powiązanych artykułach będzie

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

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

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

Kiedy tworzymy klaster Kubernetes w chmurze, możemy wdrożyć go ze wstępnie skonfigurowaną konfiguracją ingress. Wymaga to minimalnych ustawień i jest opisane w tej sekcji pomocy: 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, np. (wirtualnego) load balancera. Rolą backendu jest zapewnienie dostępu do tej infrastruktury zgodnie z regułami zdefiniowanymi przez ingress resource (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 działające jako strąki 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 serwerów Nginx i Apache

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

  • Serwer Nginx

  • Serwer WWW Apache

Oba będą dostępne z jednego publicznego adresu IP przy użyciu jednego domyślnego Load Balancera. Strony internetowe 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

Powyższe działania skutkują utworzeniem usługi dla każdej aplikacji, którą 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

Powinieneś zobaczyć wynik podobny do poniższego:

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 ingressem. 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 zweryfikować, przypisując pływający adres IP do jednego z węzłów (patrz Jak dodać lub usunąć Floating IP maszyny wirtualnej w NSIS). Następnie SSH do węzła i uruchom następujące polecenie:

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

Na przykład dla powyższego scenariusza widzimy:

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

Krok 3 Utwórz zasób przychodzący

Aby wystawić aplikację na publiczny adres IP, należy zdefiniować zasób wejściowy. Ponieważ obie aplikacje będą dostępne z tego samego adresu IP, zasób wejściowy 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, przedstawiamy tutaj tylko ułamek 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

I wdrożyć z:

kubectl apply -f my-ingress-resource.yaml

Po pewnym czasie (zwykle od 2 do 5 minut) sprawdź, czy pływający adres IP został przypisany do wejścia:

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

Informacja

Adres 64.225.130.77 jest generowany losowo i w twoim przypadku będzie inny. Pamiętaj, aby skopiować i użyć adresu pokazanego przez kubectl get ingress.

Krok 4 Sprawdź, czy działa

Skopiuj pływający adres IP w przeglądarce, a następnie kilka przykładowych tras. Powinieneś zobaczyć wynik podobny do poniższego. Oto zrzut ekranu dla trasy /apache:

../_images/apache_route1.png

Ten zrzut ekranu pokazuje, co dzieje się na każdej innej trasie - domyślnie jest to Nginx:

../_images/any_other_route1.png

Co robić dalej

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

Utwórz inną usługę 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.

Dodaj inne punkty końcowe do użytku z Nginx

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

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

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

Microservices

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

  • Pod nr 1 zawierałby bazę danych, powiedzmy MariaDB, jako backend,

  • Moduł nr 2 może zawierać PHPMyAdmin dla interfejsu bazy danych,

  • Podpunkt nr 3 może zawierać instalację WordPressa, który jest front-endem dla odwiedzającego witrynę

  • Strąk nr 4 może zawierać zastrzeżony kod wtyczek WordPress.

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

Użyj 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 Menedżera certyfikatów i bezpłatnej usługi, takiej jak Let’s Encrypt, serwer wejściowy będzie w prosty sposób obsługiwał protokół HTTPS.