Wdrażanie klastra Kubernetes o wysokiej dostępności w usłudze Azure Stack Hub

W tym artykule pokazano, jak utworzyć środowisko klastra Kubernetes o wysokiej dostępności wdrożone w wielu wystąpieniach usługi Azure Stack Hub w różnych lokalizacjach fizycznych.

W tym przewodniku wdrażania rozwiązania dowiesz się, jak wykonywać następujące działania:

  • Pobieranie i przygotowywanie aparatu AKS
  • Nawiązywanie połączenia z maszyną wirtualną pomocnika aparatu usługi AKS
  • Wdrażanie klastra Kubernetes
  • Nawiązywanie połączenia z klastrem Kubernetes
  • Łączenie usługi Azure Pipelines z klastrem Kubernetes
  • Konfigurowanie monitorowania
  • Wdrażanie aplikacji
  • Aplikacja autoskaluj
  • Konfigurowanie usługi Traffic Manager
  • Upgrade Kubernetes (Uaktualnianie usługi Kubernetes)
  • Skalowanie platformy Kubernetes

Porada

Filary hybrydowe Microsoft Azure Stack Hub to rozszerzenie platformy Azure. Usługa Azure Stack Hub zapewnia elastyczność i innowacje związane z przetwarzaniem w chmurze w środowisku lokalnym, umożliwiając korzystanie z jedynej chmury hybrydowej, która umożliwia tworzenie i wdrażanie aplikacji hybrydowych w dowolnym miejscu.

Artykuł Zagadnienia dotyczące projektowania aplikacji hybrydowych zawiera przegląd filarów jakości oprogramowania (umieszczania, skalowalności, dostępności, odporności, możliwości zarządzania i zabezpieczeń) do projektowania, wdrażania i obsługi aplikacji hybrydowych. Zagadnienia projektowe pomagają w optymalizacji projektowania aplikacji hybrydowych, minimalizując wyzwania w środowiskach produkcyjnych.

Wymagania wstępne

Przed rozpoczęciem pracy z tym przewodnikiem wdrażania upewnij się, że:

Pobieranie i przygotowywanie aparatu AKS

Aparat usługi AKS to plik binarny, który może być używany z dowolnego hosta systemu Windows lub Linux, który może dotrzeć do punktów końcowych usługi Azure Resource Manager Azure Stack Hub. W tym przewodniku opisano wdrażanie nowej maszyny wirtualnej z systemem Linux (lub Windows) w usłudze Azure Stack Hub. Będzie on używany później, gdy aparat AKS wdraża klastry Kubernetes.

Uwaga

Możesz również użyć istniejącej maszyny wirtualnej z systemem Windows lub Linux do wdrożenia klastra Kubernetes w usłudze Azure Stack Hub przy użyciu aparatu AKS.

Proces krok po kroku i wymagania dotyczące aparatu AKS są udokumentowane tutaj:

Aparat AKS to narzędzie pomocnicze do wdrażania i obsługi klastrów Kubernetes (niezarządzanych) (na platformie Azure i w usłudze Azure Stack Hub).

Szczegółowe informacje i różnice dotyczące aparatu AKS w usłudze Azure Stack Hub opisano tutaj:

Przykładowe środowisko użyje narzędzia Terraform do zautomatyzowania wdrażania maszyny wirtualnej aparatu AKS. Szczegóły i kod można znaleźć w towarzyszącym repozytorium GitHub.

Wynikiem tego kroku jest nowa grupa zasobów w usłudze Azure Stack Hub, która zawiera maszynę wirtualną pomocnika aparatu usługi AKS i powiązane zasoby:

Zasoby maszyny wirtualnej aparatu AKS w usłudze Azure Stack Hub

Uwaga

Jeśli musisz wdrożyć aparat usługi AKS w rozłączonym środowisku z przerwą w powietrzu, zapoznaj się z tematem Rozłączone wystąpienia usługi Azure Stack Hub, aby dowiedzieć się więcej.

W następnym kroku użyjemy nowo wdrożonej maszyny wirtualnej aparatu AKS do wdrożenia klastra Kubernetes.

Nawiązywanie połączenia z maszyną wirtualną pomocnika aparatu usługi AKS

Najpierw musisz nawiązać połączenie z wcześniej utworzoną maszyną wirtualną pomocnika aparatu usługi AKS.

Maszyna wirtualna powinna mieć publiczny adres IP i powinna być dostępna za pośrednictwem protokołu SSH (port 22/TCP).

Strona przeglądu maszyny wirtualnej aparatu usługi AKS

Porada

Możesz użyć wybranego narzędzia, takiego jak MobaXterm, puTTY lub PowerShell w Windows 10, aby nawiązać połączenie z maszyną wirtualną z systemem Linux przy użyciu protokołu SSH.

ssh <username>@<ipaddress>

Po nawiązaniu połączenia uruchom polecenie aks-engine. Przejdź do sekcji Obsługiwane wersje aparatu AKS , aby dowiedzieć się więcej na temat wersji aparatu AKS i platformy Kubernetes.

przykład wiersza polecenia aks-engine

Wdrażanie klastra Kubernetes

Sama maszyna wirtualna pomocnika aparatu AKS nie utworzyła jeszcze klastra Kubernetes w usłudze Azure Stack Hub. Tworzenie klastra to pierwsza akcja do wykonania na maszynie wirtualnej pomocnika aparatu usługi AKS.

Proces krok po kroku został udokumentowany tutaj:

Końcowy wynik aks-engine deploy polecenia i przygotowania w poprzednich krokach to w pełni funkcjonalny klaster Kubernetes wdrożony w przestrzeni dzierżawy pierwszego wystąpienia usługi Azure Stack Hub. Sam klaster składa się z składników IaaS platformy Azure, takich jak maszyny wirtualne, moduły równoważenia obciążenia, sieci wirtualne, dyski itd.

Witryna Azure Stack Hub składników klastra IaaS

  1. Węzły główne modułu równoważenia obciążenia platformy Azure (punkt końcowy interfejsu API K8s) 2) Węzły robocze (pula agentów) 3)

Klaster jest teraz uruchomiony i w następnym kroku połączymy się z nim.

Nawiązywanie połączenia z klastrem Kubernetes

Teraz możesz nawiązać połączenie z wcześniej utworzonym klastrem Kubernetes za pośrednictwem protokołu SSH (przy użyciu klucza SSH określonego jako część wdrożenia) lub za pośrednictwem kubectl (zalecane). Narzędzie kubectl wiersza polecenia Kubernetes jest dostępne dla systemów Windows, Linux i macOS tutaj. Jest ona już wstępnie zainstalowana i skonfigurowana w węzłach głównych klastra:

ssh azureuser@<k8s-master-lb-ip>

Wykonywanie narzędzia kubectl w węźle głównym

Nie zaleca się używania węzła głównego jako serwera przesiadkowego do zadań administracyjnych. Konfiguracja kubectl jest przechowywana w .kube/config węzłach głównych, a także na maszynie wirtualnej aparatu AKS. Konfigurację można skopiować na maszynę administracyjną z łącznością z klastrem Kubernetes i użyć tam kubectl polecenia . Plik .kube/config jest również używany później do konfigurowania połączenia usługi w usłudze Azure Pipelines.

Ważne

Zachowaj bezpieczeństwo tych plików, ponieważ zawierają poświadczenia klastra Kubernetes. Osoba atakująca mająca dostęp do pliku ma wystarczającą ilość informacji, aby uzyskać do niego dostęp administratora. Wszystkie akcje wykonywane przy użyciu pliku początkowego .kube/config są wykonywane przy użyciu konta administratora klastra.

Teraz możesz wypróbować różne polecenia, używając kubectl polecenia, aby sprawdzić stan klastra. Oto przykładowe polecenia:

kubectl get nodes
NAME                       STATUS   ROLE     VERSION
k8s-linuxpool-35064155-0   Ready    agent    v1.14.8
k8s-linuxpool-35064155-1   Ready    agent    v1.14.8
k8s-linuxpool-35064155-2   Ready    agent    v1.14.8
k8s-master-35064155-0      Ready    master   v1.14.8
kubectl cluster-info
Kubernetes master is running at https://aks.***
CoreDNS is running at https://aks.***/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
kubernetes-dashboard is running at https://aks.***/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy
Metrics-server is running at https://aks.***/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy

Ważne

Platforma Kubernetes ma własny model Access Control oparty na rolach (RBAC), który umożliwia tworzenie precyzyjnych definicji ról i powiązań ról. Jest to preferowany sposób kontrolowania dostępu do klastra zamiast przekazywania uprawnień administratora klastra.

Łączenie usługi Azure Pipelines z klastrami Kubernetes

Aby połączyć usługę Azure Pipelines z nowo wdrożonym klastrem Kubernetes, potrzebujemy pliku kubeconfig (.kube/config), jak wyjaśniono w poprzednim kroku.

  • Połącz się z jednym z węzłów głównych klastra Kubernetes.
  • Skopiuj zawartość .kube/config pliku.
  • Przejdź do obszaru Połączenia usługi Azure DevOps > Project Settings > , aby utworzyć nowe połączenie usługi "Kubernetes" (użyj metody uwierzytelniania KubeConfig)

Ważne

Usługa Azure Pipelines (lub jej agenci kompilacji) musi mieć dostęp do interfejsu API Kubernetes. Jeśli istnieje połączenie internetowe z usługi Azure Pipelines do klastra Kubernetes usługi Azure Stack Hub, musisz wdrożyć własnego agenta kompilacji usługi Azure Pipelines.

Podczas wdrażania własnych agentów dla usługi Azure Pipelines można wdrożyć w usłudze Azure Stack Hub lub na maszynie z łącznością sieciową ze wszystkimi wymaganymi punktami końcowymi zarządzania. Zobacz szczegóły tutaj:

Sekcja zagadnień dotyczących wdrażania wzorca (CI/CD) zawiera przepływ decyzyjny, który ułatwia zrozumienie, czy używać agentów hostowanych przez firmę Microsoft, czy własnych agentów:

Diagram przedstawiający przepływ decyzji własnych agentów.

Pobierz plik programu Visio ze wszystkimi diagramami w tym artykule.

W tym przykładowym rozwiązaniu topologia zawiera własnego agenta kompilacji w każdym wystąpieniu usługi Azure Stack Hub. Agent może uzyskiwać dostęp do punktów końcowych zarządzania usługi Azure Stack Hub i punktów końcowych interfejsu API klastra Kubernetes.

Diagram przedstawiający ruch wychodzący.

Pobierz plik programu Visio ze wszystkimi diagramami w tym artykule.

Ten projekt spełnia typowe wymaganie prawne, które ma mieć tylko połączenia wychodzące z rozwiązania aplikacji.

Konfigurowanie monitorowania

Usługa Azure Monitor dla kontenerów umożliwia monitorowanie kontenerów w rozwiązaniu. Wskazuje to usługę Azure Monitor do klastra Kubernetes wdrożonego przez aparat usługi AKS w usłudze Azure Stack Hub.

Istnieją dwa sposoby włączania usługi Azure Monitor w klastrze. Oba sposoby wymagają skonfigurowania obszaru roboczego usługi Log Analytics na platformie Azure.

W przykładowej topologii jest używana metoda "Metoda pierwsza", która umożliwia łatwiejsze instalowanie automatyzacji procesu i aktualizacji.

Do następnego kroku potrzebny jest obszar roboczy usługi Azure LogAnalytics (identyfikator i klucz), Helm (wersja 3) i kubectl na maszynie.

Helm jest menedżerem pakietów Kubernetes dostępnym jako plik binarny uruchamiany w systemach macOS, Windows i Linux. Można go pobrać pod adresem helm.sh. Program Helm opiera się na pliku konfiguracji platformy Kubernetes używanego kubectl do polecenia:

helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com/
helm repo update

helm install incubator/azuremonitor-containers \
--set omsagent.secret.wsid=<your_workspace_id> \
--set omsagent.secret.key=<your_workspace_key> \
--set omsagent.env.clusterName=<my_prod_cluster> \
--generate-name

To polecenie spowoduje zainstalowanie agenta usługi Azure Monitor w klastrze Kubernetes:

kubectl get pods -n kube-system
NAME                                       READY   STATUS
omsagent-8qdm6                             1/1     Running
omsagent-r6ppm                             1/1     Running
omsagent-rs-76c45758f5-lmc4l               1/1     Running

Agent pakietu Operations Management Suite (OMS) w klastrze Kubernetes wyśle dane monitorowania do obszaru roboczego usługi Azure Log Analytics (przy użyciu wychodzącego protokołu HTTPS). Teraz możesz użyć usługi Azure Monitor, aby uzyskać szczegółowe informacje na temat klastrów Kubernetes w usłudze Azure Stack Hub. Ten projekt jest zaawansowanym sposobem zademonstrowania możliwości analizy, która może być automatycznie wdrażana przy użyciu klastrów aplikacji.

Klastry usługi Azure Stack Hub w usłudze Azure Monitor

Szczegóły klastra usługi Azure Monitor

Ważne

Jeśli usługa Azure Monitor nie wyświetla żadnych danych usługi Azure Stack Hub, upewnij się, że zostały dokładnie podane instrukcje dotyczące dodawania rozwiązania AzureMonitor-Containers do obszaru roboczego usługi Azure Log Analytics .

Wdrażanie aplikacji

Przed zainstalowaniem naszej przykładowej aplikacji istnieje kolejny krok konfigurowania kontrolera ruchu przychodzącego opartego na serwerze nginx w klastrze Kubernetes. Kontroler ruchu przychodzącego jest używany jako moduł równoważenia obciążenia warstwy 7 do kierowania ruchu w klastrze na podstawie hosta, ścieżki lub protokołu. Ruch przychodzący Nginx jest dostępny jako wykres helm. Aby uzyskać szczegółowe instrukcje, zapoznaj się z repozytorium GitHub programu Helm Chart.

Nasza przykładowa aplikacja jest również spakowana jako wykres helm, taki jak agent monitorowania platformy Azure w poprzednim kroku. W związku z tym łatwo jest wdrożyć aplikację w klastrze Kubernetes. Pliki programu Helm Chart można znaleźć w towarzyszącym repozytorium GitHub

Przykładowa aplikacja to aplikacja trójwarstwowa wdrożona w klastrze Kubernetes w każdym z dwóch wystąpień usługi Azure Stack Hub. Aplikacja używa bazy danych MongoDB. Więcej informacji na temat sposobu replikowania danych między wieloma wystąpieniami można znaleźć w temacie Zagadnienia dotyczące danych i magazynowania.

Po wdrożeniu pakietu Helm Chart dla aplikacji zobaczysz wszystkie trzy warstwy aplikacji reprezentowane jako wdrożenia i zestawy stanowe (dla bazy danych) z jednym zasobnikiem:

kubectl get pod,deployment,statefulset
NAME                                         READY   STATUS
pod/ratings-api-569d7f7b54-mrv5d             1/1     Running
pod/ratings-mongodb-0                        1/1     Running
pod/ratings-web-85667bfb86-l6vxz             1/1     Running

NAME                                         READY
deployment.extensions/ratings-api            1/1
deployment.extensions/ratings-web            1/1

NAME                                         READY
statefulset.apps/ratings-mongodb             1/1

Po stronie usług znajdziesz kontroler ruchu przychodzącego opartego na serwerze nginx i jego publiczny adres IP:

kubectl get service
NAME                                         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)
kubernetes                                   ClusterIP      10.0.0.1       <none>        443/TCP
nginx-ingress-1588931383-controller          LoadBalancer   10.0.114.180   *public-ip*   443:30667/TCP
nginx-ingress-1588931383-default-backend     ClusterIP      10.0.76.54     <none>        80/TCP
ratings-api                                  ClusterIP      10.0.46.69     <none>        80/TCP
ratings-web                                  ClusterIP      10.0.161.124   <none>        80/TCP

Adres "Zewnętrzny adres IP" to nasz "punkt końcowy aplikacji". W ten sposób użytkownicy będą łączyć się, aby otworzyć aplikację, a także będą używać go jako punktu końcowego dla następnego kroku Konfigurowanie usługi Traffic Manager.

Autoskaluj aplikację

Opcjonalnie można skonfigurować narzędzie do skalowania w poziomie zasobnika w górę lub w dół na podstawie określonych metryk, takich jak użycie procesora CPU. Następujące polecenie spowoduje utworzenie narzędzia Horizontal Pod Autoscaler, który obsługuje od 1 do 10 replik zasobników kontrolowanych przez wdrożenie ratings-web. Usługa HPA zwiększy i zmniejszy liczbę replik (za pośrednictwem wdrożenia), aby zachować średnie wykorzystanie procesora CPU we wszystkich zasobnikach wynoszących 80%:

kubectl autoscale deployment ratings-web --cpu-percent=80 --min=1 --max=10

Bieżący stan autoskalatora można sprawdzić, uruchamiając następujące polecenie:

kubectl get hpa
NAME          REFERENCE                      TARGET    MINPODS   MAXPODS   REPLICAS   AGE
ratings-web   Deployment/ratings-web/scale   0% / 80%  1         10        1          18s

Konfigurowanie usługi Traffic Manager

Aby dystrybuować ruch między dwoma (lub więcej) wdrożeniami aplikacji, użyjemy usługi Azure Traffic Manager. Usługa Azure Traffic Manager to oparty na systemie DNS moduł równoważenia obciążenia ruchu na platformie Azure.

Uwaga

Usługa Traffic Manager używa usługi DNS do kierowania żądań klientów do najbardziej odpowiedniego punktu końcowego usługi na podstawie metody routingu ruchu i kondycji punktów końcowych.

Zamiast korzystać z usługi Azure Traffic Manager, możesz również użyć innych globalnych rozwiązań do równoważenia obciążenia hostowanych lokalnie. W przykładowym scenariuszu użyjemy usługi Azure Traffic Manager do dystrybucji ruchu między dwoma wystąpieniami naszej aplikacji. Mogą one działać w wystąpieniach usługi Azure Stack Hub w tych samych lub różnych lokalizacjach:

Diagram przedstawiający lokalnego menedżera ruchu.

Pobierz plik programu Visio ze wszystkimi diagramami w tym artykule.

Na platformie Azure skonfigurujemy usługę Traffic Manager tak, aby wskazywała dwa różne wystąpienia naszej aplikacji:

Profil punktu końcowego TM

Jak widać, dwa punkty końcowe wskazują dwa wystąpienia wdrożonej aplikacji z poprzedniej sekcji.

W tym momencie:

  • Utworzono infrastrukturę platformy Kubernetes, w tym kontroler ruchu przychodzącego.
  • Klastry zostały wdrożone w dwóch wystąpieniach usługi Azure Stack Hub.
  • Skonfigurowano monitorowanie.
  • Usługa Azure Traffic Manager równoważy obciążenie ruchu między dwoma wystąpieniami usługi Azure Stack Hub.
  • Na podstawie tej infrastruktury przykładowa aplikacja trójwarstwowa została wdrożona w zautomatyzowany sposób przy użyciu narzędzi Helm Charts.

Rozwiązanie powinno być teraz dostępne dla użytkowników.

Istnieją również pewne zagadnienia operacyjne po wdrożeniu, które warto omówić, które zostały omówione w dwóch następnych sekcjach.

Upgrade Kubernetes (Uaktualnianie usługi Kubernetes)

Podczas uaktualniania klastra Kubernetes należy wziąć pod uwagę następujące tematy:

Nowsze podstawowe obrazy systemu operacyjnego zawierają aktualizacje zabezpieczeń i jądra. Operator klastra jest odpowiedzialny za monitorowanie dostępności nowszych wersji i obrazów systemu operacyjnego Kubernetes. Operator powinien planować i wykonywać te uaktualnienia przy użyciu aparatu AKS. Podstawowe obrazy systemu operacyjnego muszą zostać pobrane z witryny Azure Stack Hub Marketplace przez operatora usługi Azure Stack Hub.

Skalowanie platformy Kubernetes

Skalowanie to kolejna operacja dnia 2, którą można zorganizować przy użyciu aparatu AKS.

Polecenie skalowania ponownie używa pliku konfiguracji klastra (apimodel.json) w katalogu wyjściowym jako danych wejściowych dla nowego wdrożenia usługi Azure Resource Manager. Aparat usługi AKS wykonuje operację skalowania względem określonej puli agentów. Po zakończeniu operacji skalowania aparat usługi AKS aktualizuje definicję klastra w tym samym pliku apimodel.json. Definicja klastra odzwierciedla nową liczbę węzłów w celu odzwierciedlenia zaktualizowanej, bieżącej konfiguracji klastra.

Następne kroki