Udostępnij za pośrednictwem


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, wersja 22H2; Windows Server 2022, Windows Server 2019

W tym artykule opisano wymagania dotyczące konfigurowania usługi Azure Kubernetes Service (AKS) włączonej 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 pod kątem uruchamiania 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 systemu Windows Server zgodnie z wykazem systemu Windows Server. Aby uzyskać sprawdzone rozwiązania, zobacz witrynę internetową rozwiązania Azure Stack HCI.

Ważne

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

Maksymalna obsługiwana specyfikacja sprzętu

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

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

Wymagania dotyczące obliczeń

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 windows Server z ograniczoną ilością pamięci RAM:

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 Nie dotyczy — host usługi AKS nie ma węzłów roboczych. 8 GB Nie dotyczy — 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 węzła roboczego 1 = 6 GB Można ponownie użyć tego zarezerwowanego 8 GB na potrzeby uaktualniania klastra obciążenia. Nie dotyczy, 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).

Całkowite wymaganie minimalne: 30 GB pamięci RAM.

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

Środowisko Rdzenie procesora CPU na serwer Pamięć
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 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 azure Stack HCI lub klastrze systemu Windows Server lub klastrze trybu failover systemu Windows Server.

Inne wymagania dotyczące obliczeń dla 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ń serwera 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 rozwiązania 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:

Nazwisko Typ magazynu Wymagana pojemność
Klaster rozwiązania 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 Bezpośrednio dołączony magazyn 500 GB

W przypadku klastra azure Stack HCI lub Windows Server istnieją dwie obsługiwane konfiguracje magazynu do uruchamiania obciążeń maszyn wirtualnych:

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

Systemy z magazynem opartym na dyskach HDD nie są obsługiwane przez rozwiązanie Azure Stack HCI, dlatego nie są zalecane do uruchamiania usługi AKS w usłudze 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 przechowuje stan klastrów itp. 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 niego obciążenia opóźnienia i przepływność są krytyczne. Musisz uruchomić usługę AKS na dysku SSD. Aby uzyskać więcej informacji, zobacz Performance at etcd.io (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 rozwiązania Miejsca do magazynowania Direct lub równoważnego certyfikowanego wirtualnego rozwiązania SIECI SAN w celu utworzenia infrastruktury hiperkonwergentnej, która przedstawia udostępnione woluminy klastra do użycia przez obciążenia. W przypadku Miejsca do magazynowania Direct wymagane jest, aby magazyn był hybrydowy (flash + HDD), który równoważy wydajność i pojemność, lub wszystkie dyski flash (SSD, NVMe), które maksymalizuje 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 SAN oparty na dyskach 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 korzystających z 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 pamięci 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 windows Server Datacenter. Aby uzyskać informacje o wymaganiach dotyczących 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 centrum administracyjnego systemu Windows. 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 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 rozwiązania 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 rejestrowanie 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 pokazano 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.

  • Statyczna sieć 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 na podstawie klastra.
  • Sieć DHCP: sieć wirtualna przydziela dynamiczne adresy IP do węzłów Kubernetes, bazowych 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 na 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 rezerwowanie łącznie 256 adresów IP (/24 podsieci) dla danego 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ęciach związanych z siecią kontenerów w usłudze AKS.

Wymagania dotyczące portu i adresu URL sieci

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 fizyczne węzły klastra usługi Azure Stack HCI i maszyny wirtualne klastra Azure Kubernetes znajdują się w dwóch izolowanych sieciach vlan, te porty muszą być otwarte w zaporze między nimi:

Port Lokalizacja źródłowa opis Uwagi dotyczące zapory
22 Maszyny wirtualne usługi AKS Wymagane do zbierania dzienników w przypadku używania polecenia Get-AksHciLogs. W przypadku używania 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. W przypadku używania 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 wssdAgent gRPC. 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. W przypadku używania 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. W przypadku używania oddzielnych sieci VLAN maszyny wirtualne usługi AKS muszą uzyskiwać dostęp do adresu IP zasobu klastra na tym porcie.
65000 Zasób klastra (-CloudServiceCIDR) Uwierzytelnianie gRPC agenta chmury. W przypadku używania oddzielnych sieci VLAN maszyny wirtualne usługi AKS muszą uzyskiwać 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 Używanie ustawień serwera proxy w usłudze AKS.

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

URL Port Uwagi
msk8s.api.cdp.microsoft.com 443 Używany podczas pobierania usługi AKS w lokalnym katalogu produktów platformy Azure, 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 lokalnym katalogu produktów platformy Azure, 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ę na platformie Azure podczas uruchamiania polecenia Set-AksHciRegistration.

ecpacr.azurecr.io mcr.microsoft.com
*.mcr.microsoft.com
*.data.mcr.microsoft.com
*.blob.core.windows.net
punktu końcowego USA: wus2replica*.blob.core.windows.net
443 Wymagane do ściągnięcia obrazów kontenera 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 Wymagany 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 narzędzia Helm 3 do wdrażania agentów usługi Azure Arc w usłudze AKS w lokalnym klastrze zarządzania platformy Azure. Ten punkt końcowy jest potrzebny 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 witrynie 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 dla usługi AKS w rozliczeniach lokalnych platformy Azure podczas uruchamiania polecenia Install-AksHci.

v20.events.data.microsoft.com gcs.prod.monitoring.core.windows.net
443 Okresowo używane do wysyłania wymaganych danych diagnostycznych firmy Microsoft z hosta lokalnego platformy Azure lub systemu 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, aby połączyć usługę 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 domyślnie instalowana w węzłach rozwiązania Azure Stack HCI z usługi Azure Stack HCI 21H2 lub 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 rozproszonych klastrów systemu Windows nie jest obsługiwane. Zalecamy użycie podejścia do tworzenia kopii zapasowych i odzyskiwania po awarii dla ciągłości operacyjnej centrum danych. Aby uzyskać więcej informacji, zobacz Wykonywanie kopii zapasowej lub przywracania klastra obciążenia przy użyciu usług Velero i Azure Blob Storage w usługach Azure Stack HCI i Windows Server oraz Wdrażanie konfiguracji w usłudze AksHci przy użyciu usługi GitOps z rozwiązaniem Flux v2 w celu zapewnienia ciągłości aplikacji.

Wymagania dotyczące programu 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ć programu 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 uruchomioną bramą programu 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 witryny 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:

Uprawnienia, rola i poziom dostępu firmy Microsoft

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

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

  • Przejdź do witryny Azure Portal i wybierz pozycję Role i administratorzy w obszarze Microsoft Entra ID , 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 obszaru Ustawienia użytkownika w usłudze Microsoft Entra, aby sprawdzić, czy masz uprawnienia do rejestrowania aplikacji.

Jeśli ustawienie rejestracje aplikacji ma wartość Nie, tylko użytkownicy z rolą administratora mogą rejestrować te typy aplikacji. Aby dowiedzieć się więcej o dostępnych rolach administratora i określonych uprawnieniach w identyfikatorze Entra firmy Microsoft, które są podane dla każdej roli, zobacz Role wbudowane firmy Microsoft Entra. 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 poproś 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 i poziom dostępu subskrypcji platformy Azure

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

  • Jeśli używasz centrum administracyjnego systemu Windows do wdrożenia hosta usługi AKS lub klastra obciążenia usługi AKS, musisz mieć subskrypcję platformy Azure, na której jesteś właścicielem.
  • Jeśli używasz programu PowerShell do wdrażania 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 czynności:
    • Konto użytkownika z wbudowaną rolą Właściciel .
    • 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 usług w chmurze, najprostszym sposobem wdrożenia usługi AKS jest poproś 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 witryny 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 domyślnej subskrypcji, 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 za pomocą programu 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 dla 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 w witrynie Azure Portal w obszarze Subskrypcje, Kontrola dostępu, 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 platformy Azure

Ostrzeżenie

Usługa AKS Arc obecnie obsługuje tworzenie klastra wyłącznie w następujących określonych regionach świadczenia usługi Azure. W przypadku próby wdrożenia w regionie spoza tej listy 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:

  • Wschodnie stany USA
  • 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ń usługi Azure Stack HCI lub 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 AKS lub Windows Server Datacenter mają odpowiednie uprawnienia w usłudze Active Directory. Jeśli używasz jednostek organizacyjnych 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 przez klastry AKS lub Windows Server Datacenter. Użycie oddzielnej jednostki organizacyjnej umożliwia kontrolowanie dostępu i uprawnień przy użyciu bardziej szczegółowego poziomu.
  • 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: