Wymagania systemowe dotyczące usługi AKS włączonej przez usługę Azure Arc w usłudze Azure Stack HCI 22H2

Dotyczy: Azure Stack HCI, wersje 22H2; Windows Server 2022, Windows Server 2019

W tym artykule opisano wymagania dotyczące konfigurowania Azure Kubernetes Service (AKS) włączonego przez usługę Azure Arc. Aby zapoznać się z omówieniem usługi AKS włączonej przez usługę Arc, zobacz omówienie usługi AKS.

Wymagania sprzętowe

Firma Microsoft zaleca zakup zweryfikowanego rozwiązania sprzętowego/oprogramowania usługi Azure Stack HCI od naszych partnerów. Te rozwiązania są projektowane, montowane i weryfikowane w celu uruchomienia naszej architektury referencyjnej oraz sprawdzania zgodności i niezawodności, dzięki czemu można szybko się uruchomić. Należy sprawdzić, czy używane systemy, składniki, urządzenia i sterowniki są certyfikowane w systemie Windows Server zgodnie z wykazem systemu Windows Server. Zobacz witrynę internetową rozwiązania Azure Stack HCI , aby uzyskać zweryfikowane rozwiązania.

Ważne

Systemy hostów dla wdrożeń produkcyjnych muszą być sprzętem fizycznym. Wirtualizacja zagnieżdżona, charakteryzująca się wdrażaniem rozwiązania Azure Stack HCI lub Windows Server na maszynie wirtualnej i instalowaniem usługi AKS na tej maszynie wirtualnej, nie jest obsługiwana.

Maksymalna obsługiwana specyfikacja sprzętu

Usługi AKS we wdrożeniach usługi Azure Stack HCI i Windows Server, które przekraczają następujące specyfikacje, nie są obsługiwane:

Zasób Maksimum
Serwery fizyczne na klaster 8 (Azure Stack HCI w wersji 22H2 i Windows Server)
Łączna liczba maszyn wirtualnych 200

Wymagania obliczeniowe

Minimalne wymagania dotyczące pamięci

Klaster usługi AKS można skonfigurować w następujący sposób, aby uruchomić usługę AKS w jednym węźle z ograniczoną pamięcią RAM systemu Windows Server:

Typ klastra Rozmiar maszyny wirtualnej płaszczyzny sterowania Węzeł procesu roboczego W przypadku operacji aktualizacji Moduł równoważenia obciążenia
Host usługi AKS rozmiar maszyny wirtualnej Standard_A4_v2 = 8 GB N/A — host usługi AKS nie ma węzłów roboczych. 8 GB N/A — host usługi AKS używa narzędzia kubevip do równoważenia obciążenia.
Klaster obciążeń rozmiar maszyny wirtualnej Standard_A4_v2 = 8 GB Standard_K8S3_v1 dla 1 węzła roboczego = 6 GB Można ponownie użyć tego zarezerwowanego 8 GB na potrzeby uaktualniania klastra obciążenia. N/A, jeśli narzędzie kubevip jest używane do równoważenia obciążenia (zamiast domyślnego modułu równoważenia obciążenia HAProxy).

Łączne minimalne wymaganie: 30 GB pamięci RAM.

To minimalne wymaganie dotyczy wdrożenia usługi AKS z jednym węzłem procesu roboczego do uruchamiania konteneryzowanych aplikacji. Jeśli zdecydujesz się dodać węzły robocze lub moduł równoważenia obciążenia haProxy, ostateczne wymaganie pamięci RAM zostanie odpowiednio zmienione.

Środowisko Rdzenie procesora CPU na serwer Pamięć RAM
Azure Stack HCI 32 256 GB
Klaster trybu failover systemu Windows Server 32 256 GB
System Windows Server z jednym węzłem 16 128 GB

W przypadku środowiska produkcyjnego ostateczne ustalanie rozmiaru zależy od aplikacji i liczby węzłów roboczych, które planujesz wdrożyć w klastrze usługi Azure Stack HCI lub Windows Server. Jeśli zdecydujesz się uruchamiać usługę AKS w systemie Windows Server z jednym węzłem, nie uzyskasz funkcji, takich jak wysoka dostępność, która jest dostępna z uruchomionym usługą AKS w klastrze usługi Azure Stack HCI lub klastrze systemu Windows Server lub klastrze trybu failover systemu Windows Server.

Inne wymagania obliczeniowe dotyczące usługi AKS w usługach Azure Stack HCI i Windows Server są zgodne z wymaganiami rozwiązania Azure Stack HCI. Aby uzyskać więcej informacji na temat wymagań dotyczących serwera usługi Azure Stack HCI, zobacz Wymagania systemowe rozwiązania Azure Stack HCI .

Należy zainstalować ten sam system operacyjny na każdym serwerze w klastrze. Jeśli używasz usługi Azure Stack HCI, ten sam system operacyjny i wersja muszą znajdować się na tym samym serwerze w klastrze. Jeśli używasz systemu Windows Server Datacenter, ten sam system operacyjny i wersja muszą być takie same na każdym serwerze w klastrze. Każdy system operacyjny musi używać regionu en-us i wyboru języka. Nie można zmienić tych ustawień po instalacji.

Wymagania dotyczące magazynowania

Usługa AKS w usłudze Azure Stack HCI i systemie Windows Server obsługuje następujące implementacje magazynu:

Nazwa Typ magazynu Wymagana pojemność
Klaster usługi Azure Stack HCI Udostępnione woluminy klastra 1 TB
Klaster trybu failover centrum danych systemu Windows Server Udostępnione woluminy klastra 1 TB
Centrum danych systemu Windows Server z jednym węzłem Magazyn dołączony bezpośrednio 500 GB

W przypadku klastra usługi Azure Stack HCI lub Windows Server istnieją dwie obsługiwane konfiguracje magazynu na potrzeby uruchamiania obciążeń maszyn wirtualnych:

  • Magazyn hybrydowy równoważy wydajność i pojemność przy użyciu magazynu flash i dysków twardych (HDD).
  • Magazyn all-flash maksymalizuje wydajność przy użyciu dysków ssd (SSD) lub NVMe.

Systemy, które mają tylko magazyn oparty na hdd, nie są obsługiwane przez usługę Azure Stack HCI, dlatego nie są zalecane do uruchamiania usługi AKS w usługach Azure Stack HCI i Windows Server. Aby uzyskać więcej informacji na temat zalecanych konfiguracji dysków, zobacz dokumentację rozwiązania Azure Stack HCI. Wszystkie systemy zweryfikowane w katalogu usługi Azure Stack HCI należą do jednej z tych dwóch obsługiwanych konfiguracji magazynu.

Platforma Kubernetes używa narzędzia etcd do przechowywania stanu klastrów. Etcd przechowuje konfigurację, specyfikacje i stan uruchomionych zasobników. Ponadto platforma Kubernetes używa magazynu do odnajdywania usług. Jako składnik koordynujący działanie platformy Kubernetes i obsługiwane przez nią obciążenia, opóźnienia i przepływność do itp. mają kluczowe znaczenie. Musisz uruchomić usługę AKS na dysku SSD. Aby uzyskać więcej informacji, zobacz Wydajność w etcd.io.

W przypadku klastra opartego na centrum danych systemu Windows Server można wdrożyć za pomocą magazynu lokalnego lub magazynu opartego na sieci SAN. W przypadku magazynu lokalnego zaleca się użycie wbudowanego Bezpośrednie miejsca do magazynowania lub równoważnego certyfikowanego rozwiązania wirtualnej sieci SAN w celu utworzenia infrastruktury hiperkonwergentnej, która przedstawia udostępnione woluminy klastra do użycia przez obciążenia. W przypadku Bezpośrednie miejsca do magazynowania wymagane jest, aby magazyn był hybrydowy (flash + HDD), który równoważy wydajność i pojemność, lub wszystkie elementy flash (SSD, NVMe), które maksymalizują wydajność. Jeśli zdecydujesz się wdrożyć za pomocą magazynu opartego na sieci SAN, upewnij się, że magazyn SAN może zapewnić wystarczającą wydajność, aby uruchomić kilka obciążeń maszyn wirtualnych. Starszy magazyn SIECI SAN oparty na hdd może nie dostarczać wymaganych poziomów wydajności do uruchamiania wielu obciążeń maszyn wirtualnych i mogą wystąpić problemy z wydajnością i przekroczenia limitu czasu.

W przypadku wdrożeń systemu Windows Server z jednym węzłem przy użyciu magazynu lokalnego użycie magazynu all-flash (SSD, NVMe) jest zdecydowanie zalecane w celu zapewnienia wymaganej wydajności do hostowania wielu maszyn wirtualnych na jednym hoście fizycznym. Bez magazynu flash niższe poziomy wydajności dysków HDD mogą powodować problemy z wdrażaniem i przekroczenia limitu czasu.

Wymagania dotyczące sieci

Poniższe wymagania dotyczą klastra usługi Azure Stack HCI 22H2 i klastra centrum danych systemu Windows Server. Aby uzyskać wymagania dotyczące sieci w usłudze Azure Stack HCI 23H2, zobacz Wymagania dotyczące sieci.

  • W przypadku usług Azure Stack HCI 22H2 i Windows Server sprawdź, czy masz istniejący zewnętrzny przełącznik wirtualny skonfigurowany, jeśli używasz Windows Admin Center. W przypadku klastrów HCI lub Windows Server ten przełącznik i jego nazwa muszą być takie same we wszystkich węzłach klastra. W przypadku rozwiązania HCI 23H2 zobacz wymagania systemowe sieci.
  • Sprawdź, czy na wszystkich kartach sieciowych wyłączono protokół IPv6.
  • W przypadku pomyślnego wdrożenia węzły klastra usługi Azure Stack HCI lub Windows Server oraz maszyny wirtualne klastra Kubernetes muszą mieć zewnętrzną łączność z Internetem.
  • Upewnij się, że wszystkie podsieci zdefiniowane dla klastra są routingowe między sobą a Internetem.
  • Upewnij się, że istnieje łączność sieciowa między hostami usługi Azure Stack HCI i maszynami wirtualnymi dzierżawy.
  • Rozpoznawanie nazw DNS jest wymagane, aby wszystkie węzły mogły komunikować się ze sobą.
  • (Zalecane) Włącz dynamiczne aktualizacje DNS w środowisku DNS, aby umożliwić usłudze AKS zarejestrowanie ogólnej nazwy klastra agenta w chmurze w systemie DNS na potrzeby odnajdywania.

Przypisanie adresu IP

W usłudze AKS włączonej przez usługę Arc sieci wirtualne są używane do przydzielania adresów IP do zasobów platformy Kubernetes, które ich wymagają, jak opisano wcześniej. Istnieją dwa modele sieciowe do wyboru, w zależności od żądanej architektury sieci usługi AKS.

Uwaga

Architektura sieci wirtualnej zdefiniowana tutaj dla wdrożeń usługi AKS różni się od podstawowej architektury sieci fizycznej w centrum danych.

  • Sieć statycznych adresów IP: sieć wirtualna przydziela statyczne adresy IP do serwera interfejsu API klastra Kubernetes, węzłów Kubernetes, bazowych maszyn wirtualnych, modułów równoważenia obciążenia i wszystkich usług Kubernetes uruchamianych w klastrze.
  • Sieć DHCP: sieć wirtualna przydziela dynamiczne adresy IP do węzłów Kubernetes, podstawowych maszyn wirtualnych i modułów równoważenia obciążenia przy użyciu serwera DHCP. Serwer interfejsu API klastra Kubernetes i wszystkie usługi Kubernetes uruchamiane w klastrze są nadal przydzielane statyczne adresy IP.

Minimalna rezerwacja adresu IP

Co najmniej należy zarezerwować następującą liczbę adresów IP dla wdrożenia:

Typ klastra Węzeł płaszczyzny sterowania Węzeł procesu roboczego W przypadku operacji aktualizacji Moduł równoważenia obciążenia
AKS Host 1 adres IP NA 2 adresy IP NA
Klaster obciążeń 1 adres IP na węzeł 1 adres IP na węzeł 5 adresów IP 1 adres IP

Ponadto należy zarezerwować następującą liczbę adresów IP dla puli adresów VIP:

Typ zasobu Liczba adresów IP
Serwer interfejsu API klastra 1 na klaster
Usługi Kubernetes 1 na usługę

Jak widać, liczba wymaganych adresów IP jest zmienna w zależności od architektury usługi AKS i liczby usług uruchamianych w klastrze Kubernetes. Zalecamy zarezerwowanie łącznie 256 adresów IP (/24 podsieci) dla wdrożenia.

Aby uzyskać więcej informacji na temat wymagań dotyczących sieci, zobacz pojęcia dotyczące sieci węzłów w usłudze AKS i pojęcia dotyczące sieci kontenerów w usłudze AKS.

Wymagania dotyczące portu sieciowego i adresu URL

Usługa AKS włączona przez wymagania usługi Arc

Podczas tworzenia klastra Kubernetes w usłudze Azure Stack HCI następujące porty zapory są automatycznie otwierane na każdym serwerze w klastrze.

Jeśli węzły klastra fizycznego usługi Azure Stack HCI i maszyny wirtualne klastra Azure Kubernetes znajdują się w dwóch izolowanych sieciach vlan, te porty muszą zostać otwarte w zaporze między nimi:

Port Źródło Opis Uwagi zapory
22 Maszyny wirtualne usługi AKS Wymagane do zbierania dzienników w przypadku korzystania z programu Get-AksHciLogs. Jeśli używasz oddzielnych sieci VLAN, fizyczne hosty funkcji Hyper-V muszą uzyskiwać dostęp do maszyn wirtualnych usługi AKS na tym porcie.
6443 Maszyny wirtualne usługi AKS Wymagane do komunikowania się z interfejsami API platformy Kubernetes. Jeśli używasz oddzielnych sieci VLAN, fizyczne hosty funkcji Hyper-V muszą uzyskiwać dostęp do maszyn wirtualnych usługi AKS na tym porcie.
45000 Fizyczne hosty funkcji Hyper-V serwer gRPC programu wssdAgent. Nie są potrzebne żadne reguły między sieciami VLAN.
45001 Fizyczne hosty funkcji Hyper-V uwierzytelnianie wssdAgent gRPC. Nie są potrzebne żadne reguły między sieciami VLAN.
46000 Maszyny wirtualne usługi AKS wssdCloudAgent do lbagent. Jeśli używasz oddzielnych sieci VLAN, fizyczne hosty funkcji Hyper-V muszą uzyskiwać dostęp do maszyn wirtualnych usługi AKS na tym porcie.
55000 Zasób klastra (CloudServiceCIDR) Serwer gRPC agenta chmury. Jeśli używasz oddzielnych sieci VLAN, maszyny wirtualne usługi AKS muszą uzyskać dostęp do adresu IP zasobu klastra na tym porcie.
65000 Zasób klastra (CloudServiceCIDR) Uwierzytelnianie gRPC agenta w chmurze. Jeśli używasz oddzielnych sieci VLAN, maszyny wirtualne usługi AKS muszą uzyskać dostęp do adresu IP zasobu klastra na tym porcie.

Jeśli sieć wymaga użycia serwera proxy do nawiązania połączenia z Internetem, zobacz Korzystanie z ustawień serwera proxy w usłudze AKS.

Do listy dozwolonych należy dodać następujące adresy URL:

Adres URL Port Uwagi
msk8s.api.cdp.microsoft.com 443 Używany podczas pobierania usługi AKS w katalogu produktów azure Stack HCI, bitów produktów i obrazów systemu operacyjnego z usługi SFS. Występuje podczas uruchamiania Set-AksHciConfig i w dowolnym momencie pobierania z usługi SFS.

msk8s.b.tlu.dl.delivery.mp.microsoft.com msk8s.f.tlu.dl.delivery.mp.microsoft.com
80 Używany podczas pobierania usługi AKS w katalogu produktów azure Stack HCI, bitów produktów i obrazów systemu operacyjnego z usługi SFS. Występuje podczas uruchamiania Set-AksHciConfig i w dowolnym momencie pobierania z usługi SFS.

login.microsoftonline.com login.windows.net
management.azure.com
msft.sts.microsoft.com graph.windows.net
443 Służy do logowania się do platformy Azure podczas uruchamiania polecenia Set-AksHciRegistration.

ecpacr.azurecr.io mcr.microsoft.com
*.mcr.microsoft.com
*.data.mcr.microsoft.com
*.blob.core.windows.net
punkt końcowy USA: wus2replica*.blob.core.windows.net
443 Wymagane do ściągnięcia obrazów kontenerów podczas uruchamiania polecenia Install-AksHci.
<region.dp.kubernetesconfiguration.azure.com> 443 Wymagane do dołączenia klastrów hybrydowych usługi AKS do usługi Azure Arc.
gbl.his.arc.azure.com 443 Wymagane do pobrania regionalnego punktu końcowego na potrzeby ściągania certyfikatów tożsamości zarządzanej przypisanej przez system.
*.his.arc.azure.com 443 Wymagane do ściągnięcia certyfikatów tożsamości zarządzanej przypisanej przez system.
k8connecthelm.azureedge.net 443 Platforma Kubernetes z obsługą usługi Arc używa programu Helm 3 do wdrażania agentów usługi Azure Arc w klastrze zarządzania AKS-HCI. Ten punkt końcowy jest wymagany do pobrania klienta programu Helm w celu ułatwienia wdrażania pakietu helm agenta.
*.arc.azure.net 443 Wymagane do zarządzania klastrami hybrydowymi usługi AKS w Azure Portal.
dl.k8s.io 443 Wymagane do pobrania i zaktualizowania plików binarnych kubernetes dla usługi Azure Arc.
akshci.azurefd.net 443 Wymagane w przypadku rozliczeń usługi AKS w usłudze Azure Stack HCI podczas uruchamiania polecenia Install-AksHci.

gcs.prod.monitoring.core.windows.net v20.events.data.microsoft.com
443 Okresowo używane do wysyłania danych diagnostycznych firmy Microsoft z hosta rozwiązania Azure Stack HCI lub Windows Server.

Uwaga

Usługa AKS włączona przez usługę Arc przechowuje i przetwarza dane klientów. Domyślnie dane klientów pozostają w regionie, w którym klient wdraża wystąpienie usługi. Te dane są przechowywane w regionalnych centrach danych obsługiwanych przez firmę Microsoft. W przypadku regionów z wymaganiami dotyczącymi rezydencji danych dane klientów są zawsze przechowywane w tym samym regionie.

Dodatkowe wymagania dotyczące adresów URL dla funkcji usługi Azure Arc

Poprzednia lista adresów URL obejmuje minimalne wymagane adresy URL, które umożliwiają połączenie usługi AKS z platformą Azure na potrzeby rozliczeń. Musisz zezwolić na dodatkowe adresy URL, jeśli chcesz używać połączenia klastra, lokalizacji niestandardowych, kontroli dostępu opartej na rolach platformy Azure i innych usług platformy Azure, takich jak Azure Monitor itp., w klastrze obciążenia usługi AKS. Aby uzyskać pełną listę adresów URL usługi Arc, zobacz Wymagania sieciowe platformy Kubernetes z obsługą usługi Azure Arc.

Należy również przejrzeć adresy URL rozwiązania Azure Stack HCI. Ponieważ usługa Arc dla agentów serwera jest teraz instalowana domyślnie w węzłach rozwiązania Azure Stack HCI z usługi Azure Stack HCI 21H2 i nowszych, należy również przejrzeć adresy URL agentów serwera usługi Arc.

Klastry rozproszone w usłudze AKS

Jak opisano w omówieniu klastrów rozproszonych, wdrażanie usługi AKS w usłudze Azure Stack HCI i systemie Windows Server przy użyciu klastrów rozproszonych systemu Windows nie jest obsługiwane. Zalecamy użycie podejścia do tworzenia kopii zapasowych i odzyskiwania po awarii dla ciągłości działania centrum danych. Aby uzyskać więcej informacji, zobacz Perform workload cluster backup or restore using Velero and Azure Blob Storage on Azure Stack HCI and Windows Server (Wykonywanie kopii zapasowych lub przywracanie klastra obciążeń przy użyciu usług Velero i Azure Blob Storage w usługach Azure Stack HCI i Windows Server) oraz Deploy configurations on AksHci using GitOps with Flux v2 for application continuity (Wdrażanie konfiguracji w usłudze AksHci przy użyciu metody GitOps z rozwiązaniem Flux v2 w celu zapewnienia ciągłości aplikacji).

wymagania dotyczące Windows Admin Center

Windows Admin Center to interfejs użytkownika do tworzenia usługi AKS włączonej przez usługę Azure Arc i zarządzania nią. Aby używać Windows Admin Center z usługą AKS w usługach Azure Stack HCI i Windows Server, należy spełnić wszystkie kryteria na poniższej liście.

Są to wymagania dotyczące maszyny z bramą Windows Admin Center:

  • Windows 10 lub Windows Server.
  • Zarejestrowane na platformie Azure.
  • W tej samej domenie co klaster Azure Stack HCI lub Windows Server Datacenter.
  • Subskrypcja platformy Azure, w której masz prawa właściciela. Poziom dostępu możesz sprawdzić, przechodząc do subskrypcji i wybierając pozycję Kontrola dostępu (Zarządzanie dostępem i tożsamościami) po lewej stronie Azure Portal, a następnie wybierając pozycję Wyświetl mój dostęp.

Wymagania systemu Azure

Musisz nawiązać połączenie z kontem platformy Azure.

Konto i subskrypcja platformy Azure

Jeśli nie masz jeszcze konta platformy Azure, utwórz je. Możesz użyć istniejącej subskrypcji dowolnego typu:

Microsoft Entra uprawnienia, rola i poziom dostępu

Aby zarejestrować aplikację w dzierżawie Microsoft Entra, musisz mieć wystarczające uprawnienia.

Aby sprawdzić, czy masz wystarczające uprawnienia, postępuj zgodnie z poniższymi informacjami:

  • Przejdź do Azure Portal i wybierz pozycję Role i administratorzy w obszarze Tożsamość Microsoft Entra, aby sprawdzić swoją rolę.
  • Jeśli twoja rola to Użytkownik, musisz upewnić się, że użytkownicy niebędący administratorami mogą rejestrować aplikacje.
  • Aby sprawdzić, czy możesz zarejestrować aplikacje, przejdź do pozycji Ustawienia użytkownika w usłudze Microsoft Entra, aby sprawdzić, czy masz uprawnienia do rejestrowania aplikacji.

Jeśli ustawienie rejestracji aplikacji ma wartość Nie, tylko użytkownicy z rolą administratora mogą rejestrować tego typu aplikacje. Aby dowiedzieć się więcej o dostępnych rolach administratora i określonych uprawnieniach w Tożsamość Microsoft Entra, które są przekazywane do każdej roli, zobacz Microsoft Entra wbudowanych ról. Jeśli twoje konto ma przypisaną rolę Użytkownika , ale ustawienie rejestracji aplikacji jest ograniczone do użytkowników administracyjnych, poproś administratora o przypisanie Ci jednej z ról administratora, które mogą tworzyć wszystkie aspekty rejestracji aplikacji i zarządzać nimi, lub aby umożliwić użytkownikom rejestrowanie aplikacji.

Jeśli nie masz wystarczających uprawnień do zarejestrowania aplikacji, a administrator nie może udzielić Ci tych uprawnień, najprostszym sposobem wdrożenia usługi AKS jest poprosić administratora platformy Azure o utworzenie jednostki usługi z odpowiednimi uprawnieniami. Administratorzy mogą sprawdzić poniższą sekcję, aby dowiedzieć się, jak utworzyć jednostkę usługi.

Rola subskrypcji platformy Azure i poziom dostępu

Aby sprawdzić poziom dostępu, przejdź do subskrypcji, wybierz pozycję Kontrola dostępu (Zarządzanie dostępem i tożsamościami) po lewej stronie Azure Portal, a następnie wybierz pozycję Wyświetl mój dostęp.

  • Jeśli używasz Windows Admin Center do wdrażania hosta usługi AKS lub klastra obciążeń usługi AKS, musisz mieć subskrypcję platformy Azure, w której jesteś właścicielem.
  • Jeśli używasz programu PowerShell do wdrożenia hosta usługi AKS lub klastra obciążenia usługi AKS, użytkownik rejestrujący klaster musi mieć co najmniej jedną z następujących opcji:
    • Konto użytkownika z wbudowaną rolą Właściciela .
    • Jednostka usługi z jednym z następujących poziomów dostępu:

Jeśli Twoja subskrypcja platformy Azure korzysta z umowy EA lub dostawcy CSP, najprostszym sposobem wdrożenia usługi AKS jest poprosić administratora platformy Azure o utworzenie jednostki usługi z odpowiednimi uprawnieniami. Administratorzy mogą sprawdzić poniższą sekcję dotyczącą tworzenia jednostki usługi.

Opcjonalnie: utwórz nową jednostkę usługi

Uruchom następujące kroki, aby utworzyć nową jednostkę usługi z wbudowaną rolą Właściciel . Tylko właściciele subskrypcji mogą tworzyć jednostki usługi z odpowiednim przypisaniem roli. Poziom dostępu możesz sprawdzić, przechodząc do subskrypcji, wybierając pozycję Kontrola dostępu (Zarządzanie dostępem i tożsamościami) po lewej stronie Azure Portal, a następnie wybierając pozycję Wyświetl mój dostęp.

Ustaw następujące zmienne programu PowerShell w oknie administratora programu PowerShell. Sprawdź, czy subskrypcja i dzierżawa mają być używane do rejestrowania hosta usługi AKS na potrzeby rozliczeń:

$subscriptionID = "<Your Azure subscrption ID>"
$tenantID = "<Your Azure tenant ID>"

Zainstaluj i zaimportuj moduł programu PowerShell usługi AKS:

Install-Module -Name AksHci

Zaloguj się do platformy Azure przy użyciu polecenia Connect-AzAccount programu PowerShell:

Connect-AzAccount -tenant $tenantID

Ustaw subskrypcję, której chcesz użyć do zarejestrowania hosta usługi AKS na potrzeby rozliczeń jako subskrypcji domyślnej, uruchamiając polecenie Set-AzContext :

Set-AzContext -Subscription $subscriptionID

Sprawdź, czy kontekst logowania jest poprawny, uruchamiając polecenie Get-AzContext programu PowerShell. Sprawdź, czy subskrypcja, dzierżawa i konto mają być używane do rejestrowania hosta usługi AKS na potrzeby rozliczeń:

Get-AzContext
Name                                     Account                      SubscriptionName             Environment                  TenantId
----                                     -------                      ----------------             -----------                  --------
myAzureSubscription (92391anf-...        user@contoso.com             myAzureSubscription          AzureCloud                   xxxxxx-xxxx-xxxx-xxxxxx

Utwórz jednostkę usługi, uruchamiając polecenie New-AzADServicePrincipal programu PowerShell. To polecenie tworzy jednostkę usługi z rolą Właściciel i ustawia zakres na poziomie subskrypcji. Aby uzyskać więcej informacji na temat tworzenia jednostek usługi, zobacz tworzenie jednostki usługi platformy Azure przy użyciu Azure PowerShell.

$sp = New-AzADServicePrincipal -role "Owner" -scope /subscriptions/$subscriptionID

Pobierz hasło dla jednostki usługi, uruchamiając następujące polecenie. Należy pamiętać, że to polecenie działa tylko w przypadku modułu Az.Accounts 2.6.0 lub nowszego. Automatycznie pobieramy moduł Az.Accounts 2.6.0 podczas instalowania modułu programu PowerShell usługi AksHci:

$secret = $sp.PasswordCredentials[0].SecretText
Write-Host "Application ID: $($sp.ApplicationId)"
Write-Host "App Secret: $secret"

Z poprzednich danych wyjściowych masz teraz identyfikator aplikacji i klucz tajny dostępny podczas wdrażania usługi AKS. Należy zanotować te elementy i bezpiecznie je przechowywać. Po utworzeniu tej funkcji w Azure Portal w obszarze SubskrypcjeAccess Control, a następnie Przypisania ról powinna zostać wyświetlona nowa jednostka usługi.

Grupa zasobów platformy Azure

Przed rejestracją musisz mieć grupę zasobów platformy Azure w regionie świadczenia usługi Azure Australia Wschodnia, Wschodnie stany USA, Azja Południowo-Wschodnia lub Europa Zachodnia.

Regiony świadczenia usługi Azure

Ostrzeżenie

Usługa AKS Arc obsługuje obecnie tworzenie klastra wyłącznie w następujących określonych regionach świadczenia usługi Azure. W przypadku próby wdrożenia w regionie poza tą listą wystąpi błąd wdrożenia.

Usługa AKS Arc służy do rejestracji, rozliczeń i zarządzania. Jest ona obecnie obsługiwana w następujących regionach:

  • East US
  • South Central US
  • West Europe

Wymagania dotyczące usługi Active Directory

Aby klaster trybu failover usługi AKS z co najmniej 2 węzłami fizycznymi działał optymalnie w środowisku usługi Active Directory, upewnij się, że spełnione są następujące wymagania:

Uwaga

Usługa Active Directory nie jest wymagana w przypadku wdrożeń rozwiązania Azure Stack HCI ani systemu Windows Server z jednym węzłem.

  • Skonfiguruj synchronizację czasu, aby rozbieżność nie przekraczała 2 minut we wszystkich węzłach klastra i kontrolerze domeny. Aby uzyskać informacje o ustawianiu synchronizacji czasu, zobacz Usługa czasowa systemu Windows.
  • Upewnij się, że konta użytkowników używane do dodawania aktualizacji oraz zarządzania klastrami usługi AKS lub Windows Server Datacenter mają odpowiednie uprawnienia w usłudze Active Directory. Jeśli używasz jednostek organizacyjnych (OU) do zarządzania zasadami grupy dla serwerów i usług, konta użytkowników wymagają listy, odczytu, modyfikowania i usuwania uprawnień do wszystkich obiektów w jednostki organizacyjnej.
  • Użyj oddzielnej jednostki organizacyjnej (OU) dla serwerów i usług w klastrach AKS lub Windows Server Datacenter. Użycie oddzielnej jednostki organizacyjnej umożliwia kontrolowanie dostępu i uprawnień z większą szczegółowością.
  • Jeśli używasz szablonów obiektów zasad grupy w kontenerach w usłudze Active Directory, upewnij się, że wdrażanie usługi AKS w usłudze Azure Stack HCI i systemie Windows Server jest wykluczone z zasad.

Następne kroki

Po spełnieniu wszystkich powyższych wymagań wstępnych można skonfigurować hosta usługi AKS w usłudze Azure Stack HCI przy użyciu następujących elementów: