
Cieszymy się, że możemy zaprezentować wersję beta (NSM), lekką siatkę usług, która wykorzystuje plan danych oparty na NGINX Plus do zarządzania ruchem kontenerów w środowiskach Kubernetes.
NSM jest dostępny za darmo . Mamy nadzieję, że wypróbujesz go w środowiskach developerskich i testowych – czekamy na Twoje opinie .
Wdrożenie metodologii mikroserwisów wiąże się z trudnościami przy skalowaniu wdrożeń oraz ich komplikacji. Komunikacja między usługami staje się bardziej złożona, problemy z debugowaniem są coraz bardziej skomplikowane, a rosnąca liczba usług wymaga więcej zasobów do zarządzania.
NSM rozwiązuje te problemy, oferując przede wszystkim:
- Bezpieczeństwo, co jest teraz ważniejsze niż kiedykolwiek. Wycieki danych mogą kosztować firmę miliony dolarów rocznie w utracie dochodów i reputacji. NSM zapewnia szyfrowanie wszystkich połączeń za pomocą mTLS – dzięki czemu nie ma wrażliwych danych, które mogliby wykraść hakerzy w sieci. Kontrola dostępu pozwala określić polityki, jak usługi będą komunikować się z innymi usługami.
- Zarządzanie ruchem. Przy wydawaniu nowej wersji aplikacji możesz chcieć na początku ograniczyć jej ruch przychodzący, na wypadek wystąpienia błędu. Dzięki inteligentnemu zarządzaniu ruchem kontenerów w NSM możesz określić politykę ograniczania ruchu dla nowych usług, która będzie zwiększać ruch z upływem czasu. Inne funkcje, takie jak ograniczenie prędkości i circuit breakers, dają Ci pełną kontrolę nad zarządzaniem ruchem wśród wszystkich Twoich usług.
- Wizualizacja. Zarządzanie tysiącami usług może być koszmarem debugowania i wizualizacji. NSM pomaga poradzić sobie z taką sytuacją za pomocą wbudowanego panelu kontrolnego Grafana, na którym wyświetlane są wszystkie metryki dostępne w NGINX Plus. Wbudowane Open Tracing pozwala szczegółowo śledzić transakcje.
- Hybrydowe dostawy, jeśli Twoja firma, jak większość innych, nie korzysta z infrastruktury w pełni uruchomionej na Kubernetes. NSM zapewnia, że starsze aplikacje nie pozostaną zaniedbane. Dzięki wbudowanemu kontrolerowi NGINX Kubernetes Ingress starsze usługi mogą połączyć się z siatką usług, i odwrotnie.
NSM zapewnia również bezpieczeństwo aplikacji w środowiskach o zerowym zaufaniu, transparently stosując szyfrowanie i autoryzację ruchu kontenerów. Daje również możliwość monitorowania i analizy transakcji, co pomaga szybko i dokładnie uruchamiać wdrożenia i rozwiązywać problemy. Dodatkowo zapewnia szczegółową kontrolę ruchu, umożliwiając zespołom DevOps wdrażanie i optymalizację części aplikacji, a jednocześnie pozwalając programistom na tworzenie i łatwe łączenie ich rozproszonych aplikacji.
Jak działa NGINX Service Mesh?
NSM składa się z zintegrowanego data plane dla pionowego (serwis-do-serwisu) ruchu i wbudowanego kontrolera wejścia NGINX Plus do zarządzania ruchem pionowym, który podlega jednemu control plane.
Control plane zostało specjalnie zaprojektowane i zoptymalizowane dla NGINX Plus data plane, definiuje zasady zarządzania ruchem, rozdzielone w sidecarach NGINX Plus.
W NSM sidecary proxy są instalowane dla każdej usługi w mesh. Współdziałają z następującymi rozwiązaniami open source:
- Grafana, wizualizacja wskaźników Prometheus, wbudowana tablica NSM pomaga w pracy;
- Kubernetes Ingress Controllers, do zarządzania ruchem przychodzącym i wychodzącym w mesh;
- SPIRE, CA do zarządzania, dystrybucji i aktualizacji certyfikatów w mesh;
- NATS, skalowalny system przesyłania wiadomości, np. aktualizacje tras, z control plane do sidecarów;
- Open Tracing, rozproszona debugowanie (obsługiwany Zipkin i Jaeger);
- Prometheus, zbieranie i przechowywanie charakterystyk z sidecarów NGINX Plus, np. liczba żądań, połączeń i SSL handshakes.
Funkcje i komponenty
NGINX Plus jako data plane obejmuje sidecar proxy (ruch poziomy) i kontroler wejścia (ruch pionowy), przechwytując i zarządzając ruchem kontenerów między usługami.
Funkcje obejmują:
- Wzajemną autoryzację TLS (mTLS);
- Równoważenie obciążenia;
- Odporność na awarie;
- Ograniczenie prędkości;
- Circuit breaking;
- Wdrożenia blue-green i kanaryjskie;
- Kontrola dostępu.
Uruchomienie NGINX Service Mesh
Aby uruchomić NSM, potrzebujesz:
- dostępu do środowiska Kubernetes. NGINX Service Mesh jest obsługiwany na wielu platformach Kubernetes, w tym Amazon Elastic Container Service for Kubernetes (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), VMware vSphere i standardowych klastrach Kubernetes wdrożonych na serwerach 'metalowych';
- Narzędzie
kubectl, zainstalowanego na maszynie, z której będzie się instalować NSM; - Dostęp do pakietów wydania NGINX Service Mesh. Pakiet zawiera obrazy NSM, które są potrzebne do załadunku do prywatnej rejestru dla kontenerów dostępnej w klastrze Kubernetes. Pakiet zawiera również
nginx-meshctl, potrzebny do wdrożenia NSM.
Aby wdrożyć NSM z ustawieniami domyślnymi, uruchom następującą komendę. W trakcie wdrażania wyświetlane są komunikaty o pomyślnym zainstalowaniu komponentów i na koniec komunikat, że NSM działa w osobnej przestrzeni nazw (najpierw trzeba ją i umieścić w rejestru, przyp. tłumacza):
$ DOCKER_REGISTRY=twoja-rejestracja-Docker ; MESH_VER=0.6.0 ;
./nginx-meshctl deploy
--nginx-mesh-api-image "${DOCKER_REGISTRY}/nginx-mesh-api:${MESH_VER}"
--nginx-mesh-sidecar-image "${DOCKER_REGISTRY}/nginx-mesh-sidecar:${MESH_VER}"
--nginx-mesh-init-image "${DOCKER_REGISTRY}/nginx-mesh-init:${MESH_VER}"
--nginx-mesh-metrics-image "${DOCKER_REGISTRY}/nginx-mesh-metrics:${MESH_VER}"
Utworzono przestrzeń nazw "nginx-mesh".
Utworzono CRD SpiffeID.
Czekam, aż pod'y Spire będą działały...zrobione.
Wdrożono Spire.
Wdrożono serwer NATS.
Utworzono polityki ruchu CRD.
Wdrożono API Mesh.
Wdrożono serwer API metryk.
Wdrożono serwer Prometheus nginx-mesh/prometheus-server.
Wdrożono Grafanę nginx-mesh/grafana.
Wdrożono serwer do śledzenia nginx-mesh/zipkin.
Wszystkie zasoby utworzone. Testowanie połączenia z serwerem API Service Mesh...
Połączono z NGINX Service Mesh API pomyślnie.
NGINX Service Mesh działa.Aby uzyskać dodatkowe opcje, w tym zaawansowane ustawienia, uruchom tę komendę:
$ nginx-meshctl deploy –hAby sprawdzić, czy kontrolny plane działa prawidłowo w przestrzeni nazw nginx-mesh, można to zrobić tak:
$ kubectl get pods –n nginx-mesh
NAZWA GOTOWY STATUS RESTARTY WIEK
grafana-6cc6958cd9-dccj6 1/1 Działa 0 2d19h
mesh-api-6b95576c46-8npkb 1/1 Działa 0 2d19h
nats-server-6d5c57f894-225qn 1/1 Działa 0 2d19h
prometheus-server-65c95b788b-zkt95 1/1 Działa 0 2d19h
smi-metrics-5986dfb8d5-q6gfj 1/1 Działa 0 2d19h
spire-agent-5cf87 1/1 Działa 0 2d19h
spire-agent-rr2tt 1/1 Działa 0 2d19h
spire-agent-vwjbv 1/1 Działa 0 2d19h
spire-server-0 2/2 Działa 0 2d19h
zipkin-6f7cbf5467-ns6wc 1/1 Działa 0 2d19hW zależności od parametrów wdrożenia, które ustalają polityki ręcznego lub automatycznego wstrzykiwania, proxy NGINX sidecars będą domyślnie dodawane do aplikacji. Aby wyłączyć automatyczne dodawanie, przeczytaj
Na przykład, jeśli wdrożymy aplikację sleep w przestrzeni nazw default, a następnie sprawdzimy Pod — zobaczymy dwa uruchomione kontenery, aplikacja sleep i powiązany z nią sidecar:
$ kubectl apply –f sleep.yaml
$ kubectl get pods –n default
NAZWA GOTOWY STATUS RESTARTY WIEK
sleep-674f75ff4d-gxjf2 2/2 Działa 0 5h23mMożemy również monitorować aplikację sleep w panelu NGINX Plus, uruchamiając tę komendę, aby uzyskać dostęp do sidecara z lokalnej maszyny:
$ kubectl port-forward sleep-674f75ff4d-gxjf2 8080:8886Następnie po prostu wchodzimy w przeglądarce. Możesz również połączyć się z Prometheusem, aby monitorować aplikację sleep.
Możesz używać oddzielnych zasobów Kubernetes do konfigurowania polityk ruchu, takich jak kontrola dostępu, ograniczenie prędkości i circuit breaking, więcej informacji znajdziesz w
Podsumowanie
NGINX Service Mesh jest dostępny do pobrania za darmo na . Wypróbuj go w swoich środowiskach deweloperskich i testowych oraz .
Aby spróbować NGINX Plus Ingress Controller, aktywuj na 30 dni, lub aby omówić swoje przypadki użycia.
Tłumaczenie autorstwa Pawła Demkowicza, inżyniera firmy . Administracja systemami za 15 000 ₽ miesięcznie. A jako oddzielna jednostka — centrum szkoleniowe , praktyka i nic poza praktyką.
Źródło: habr.com
