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
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:
- Zapoznaj się z artykułem Wzorzec klastra Kubernetes o wysokiej dostępności .
- Przejrzyj zawartość towarzyszącego repozytorium GitHub zawierającego dodatkowe zasoby, do których odwołuje się ten artykuł.
- Masz konto, które może uzyskiwać dostęp do portalu użytkowników usługi Azure Stack Hub z uprawnieniami co najmniej "współautora".
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:
- Instalowanie aparatu AKS w systemie Linux w usłudze Azure Stack Hub (lub przy użyciu systemu Windows)
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:
- Co to jest aparat AKS w usłudze Azure Stack Hub?
- Aparat usługi AKS w usłudze Azure Stack Hub (w usłudze GitHub)
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:
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).
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.
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.
- 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>
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:
- Agenci usługi Azure Pipelines w systemie Windows lub Linux
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:
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.
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.
- Metoda, która używa wykresu Helm
- Metoda druga w ramach specyfikacji klastra aparatu usługi AKS
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.
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:
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:
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:
- Uaktualnianie klastra Kubernetes to złożona operacja dnia 2, którą można wykonać przy użyciu aparatu AKS. Aby uzyskać więcej informacji, zobacz Uaktualnianie klastra Kubernetes w usłudze Azure Stack Hub.
- Aparat AKS umożliwia uaktualnianie klastrów do nowszych wersji obrazów systemu operacyjnego Kubernetes i podstawowych. Aby uzyskać więcej informacji, zobacz Kroki uaktualniania do nowszej wersji platformy Kubernetes.
- Można również uaktualnić tylko węzły bazowe do nowszych wersji obrazu podstawowego systemu operacyjnego. Aby uzyskać więcej informacji, zobacz Kroki uaktualniania tylko obrazu systemu operacyjnego.
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
- Dowiedz się więcej o zagadnieniach dotyczących projektowania aplikacji hybrydowych.
- Przejrzyj i zaproponuj ulepszenia kodu dla tego przykładu w usłudze GitHub.
Opinia
https://aka.ms/ContentUserFeedback.
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź:Prześlij i wyświetl opinię dla