Wdrażanie kontenera systemu Windows Server w klastrze usługi Azure Kubernetes Service (AKS) przy użyciu interfejsu wiersza polecenia platformy Azure

Azure Kubernetes Service (AKS) to zarządzana usługa platformy Kubernetes, która umożliwia szybkie wdrażanie klastrów i zarządzanie nimi. W tym artykule użyjesz interfejsu wiersza polecenia platformy Azure do wdrożenia klastra usługi AKS z uruchomionymi kontenerami systemu Windows Server. W klastrze wdrożysz również przykładową aplikację ASP.NET w kontenerze systemu Windows Server.

Uwaga

Aby rozpocząć szybkie aprowizowanie klastra usługi AKS, ten artykuł zawiera kroki wdrażania klastra z ustawieniami domyślnymi tylko do celów ewaluacyjnych. Przed wdrożeniem klastra gotowego do produkcji zalecamy zapoznanie się z naszą architekturą referencyjną punktu odniesienia, aby wziąć pod uwagę, jak jest ona zgodna z wymaganiami biznesowymi.

Zanim rozpoczniesz

W tym przewodniku Szybki start założono, że masz podstawową wiedzę na temat pojęć związanych z rozwiązaniem Kubernetes. Aby uzyskać więcej informacji, zobacz temat Kubernetes core concepts for Azure Kubernetes Service (AKS) (Kubernetes — podstawowe pojęcia dotyczące usługi Azure Kubernetes Service (AKS)).

Tworzenie grupy zasobów

Grupa zasobów platformy Azure to grupa logiczna, w której zasoby platformy Azure są wdrażane i zarządzane. Podczas tworzenia grupy zasobów zostanie wyświetlony monit o określenie lokalizacji. Ta lokalizacja polega na tym, że metadane grupy zasobów są przechowywane i gdzie zasoby są uruchamiane na platformie Azure, jeśli nie określisz innego regionu podczas tworzenia zasobów.

  • Utwórz grupę zasobów przy użyciu polecenia az group create. W poniższym przykładzie tworzona jest grupa zasobów o nazwie myResourceGroup w lokalizacji eastus. Wprowadź to polecenie i inne polecenia w tym artykule w powłoce BASH:

    az group create --name myResourceGroup --location eastus
    

    Następujące przykładowe dane wyjściowe przedstawiają pomyślnie utworzoną grupę zasobów:

    {
      "id": "/subscriptions/<guid>/resourceGroups/myResourceGroup",
      "location": "eastus",
      "managedBy": null,
      "name": "myResourceGroup",
      "properties": {
        "provisioningState": "Succeeded"
      },
      "tags": null,
      "type": null
    }
    

Tworzenie klastra AKS

W tej sekcji utworzymy klaster usługi AKS z następującą konfiguracją:

  • Klaster jest skonfigurowany z dwoma węzłami w celu zapewnienia, że działa niezawodnie. Węzeł to maszyna wirtualna platformy Azure, która uruchamia składniki węzła kubernetes i środowisko uruchomieniowe kontenera.
  • Parametry --windows-admin-password i --windows-admin-username ustawiają poświadczenia administratora dla wszystkich węzłów systemu Windows Server w klastrze i muszą spełniać wymagania dotyczące haseł systemu Windows Server.
  • Pula węzłów używa metody VirtualMachineScaleSets.

Aby utworzyć klaster usługi AKS za pomocą interfejsu wiersza polecenia platformy Azure, wykonaj następujące kroki:

  1. Utwórz nazwę użytkownika do użycia jako poświadczenia administratora dla węzłów systemu Windows Server w klastrze. Następujące polecenia wyświetlają monit o podanie nazwy użytkownika i ustaw ją na WINDOWS_USERNAME do użycia w późniejszym poleceniu.

    echo "Please enter the username to use as administrator credentials for Windows Server nodes on your cluster: " && read WINDOWS_USERNAME
    
  2. Utwórz hasło dla nazwy użytkownika administratora utworzonej w poprzednim kroku. Hasło musi zawierać co najmniej 14 znaków i spełniać wymagania dotyczące złożoności hasła systemu Windows Server.

    echo "Please enter the password to use as administrator credentials for Windows Server nodes on your cluster: " && read WINDOWS_PASSWORD
    
  3. Utwórz klaster przy użyciu polecenia az aks create i określ --windows-admin-username parametry i --windows-admin-password . Poniższe przykładowe polecenie tworzy klaster przy użyciu wartości z WINDOWS_USERNAME ustawionej w poprzednim poleceniu. Alternatywnie możesz podać inną nazwę użytkownika bezpośrednio w parametrze zamiast używać WINDOWS_USERNAME.

    az aks create \
        --resource-group myResourceGroup \
        --name myAKSCluster \
        --node-count 2 \
        --enable-addons monitoring \
        --generate-ssh-keys \
        --windows-admin-username $WINDOWS_USERNAME \
        --windows-admin-password $WINDOWS_PASSWORD \
        --vm-set-type VirtualMachineScaleSets \
        --network-plugin azure
    

    Po kilku minutach polecenie zostanie wykonane i zwróci informacje o klastrze w formacie JSON. Czasami aprowizacja klastra może potrwać dłużej niż kilka minut. Aprowizacja może potrwać do 10 minut.

    Jeśli wystąpi błąd weryfikacji hasła, a ustawione hasło spełnia wymagania dotyczące długości i złożoności, spróbuj utworzyć grupę zasobów w innym regionie. Następnie spróbuj utworzyć klaster przy użyciu nowej grupy zasobów.

    Jeśli nie określisz nazwy użytkownika i hasła administratora podczas tworzenia puli węzłów, nazwa użytkownika zostanie ustawiona na azureuser , a hasło zostanie ustawione na wartość losową. Aby uzyskać więcej informacji, zobacz Jak mogę zmienić hasło administratora dla węzłów systemu Windows Server w klastrze?.

    Nie można zmienić nazwy użytkownika administratora, ale można zmienić hasło administratora używane przez klaster usługi AKS dla węzłów systemu Windows Server przy użyciu polecenia az aks update. Aby uzyskać więcej informacji, zobacz Często zadawane pytania dotyczące pul węzłów systemu Windows Server.

    Aby uruchomić klaster usługi AKS obsługujący pule węzłów dla kontenerów systemu Windows Server, klaster musi używać zasad sieciowych korzystających z wtyczki sieciowej azure CNI (advanced). Parametr --network-plugin azure określa usługę Azure CNI.

Dodawanie puli węzłów

Domyślnie klaster usługi AKS jest tworzony z pulą węzłów, która może uruchamiać kontenery systemu Linux. Należy dodać kolejną pulę węzłów, która może uruchamiać kontenery systemu Windows Server wraz z pulą węzłów systemu Linux.

System Windows Server 2022 jest domyślnym systemem operacyjnym dla platformy Kubernetes w wersji 1.25.0 lub nowszej. System operacyjny Windows Server 2019 jest domyślnym systemem operacyjnym dla wcześniejszych wersji. Jeśli nie określisz konkretnej jednostki SKU systemu operacyjnego, platforma Azure utworzy nową pulę węzłów z domyślną jednostkę SKU dla wersji rozwiązania Kubernetes używanej przez klaster.

Aby użyć domyślnej jednostki SKU systemu operacyjnego, utwórz pulę węzłów bez określania jednostki SKU systemu operacyjnego. Pula węzłów jest skonfigurowana dla domyślnego systemu operacyjnego na podstawie wersji rozwiązania Kubernetes klastra.

Dodaj pulę węzłów systemu Windows przy użyciu az aks nodepool add polecenia . Następujące polecenie tworzy nową pulę węzłów o nazwie npwin i dodaje ją do folderu myAKSCluster. Polecenie używa również domyślnej podsieci w domyślnej sieci wirtualnej utworzonej podczas uruchamiania polecenia az aks create. Jednostka SKU systemu operacyjnego nie jest określona, więc pula węzłów jest ustawiona na domyślny system operacyjny na podstawie wersji kubernetes klastra:

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --os-type Windows \
    --name npwin \
    --node-count 1

Łączenie z klastrem

Do zarządzania klastrami Kubernetes używasz narzędzia kubectl, klienta wiersza polecenia Kubernetes. Jeśli korzystasz z usługi Azure Cloud Shell, narzędzie kubectl jest już zainstalowane. Jeśli chcesz zainstalować i uruchomić kubectl lokalnie, wywołaj polecenie az aks install-cli .

  1. Skonfiguruj, kubectl aby nawiązać połączenie z klastrem Kubernetes przy użyciu polecenia az aks get-credentials . To polecenie powoduje pobranie poświadczeń i zastosowanie ich w konfiguracji interfejsu wiersza polecenia Kubernetes.

    az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
    
  2. Sprawdź połączenie z klastrem przy użyciu polecenia kubectl get , które zwraca listę węzłów klastra.

    kubectl get nodes -o wide
    

    Poniższe przykładowe dane wyjściowe pokazują wszystkie węzły w klastrze. Upewnij się, że stan wszystkich węzłów to Gotowe:

    NAME                                STATUS   ROLES   AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                         KERNEL-VERSION      CONTAINER-RUNTIME
    aks-nodepool1-20786768-vmss000000   Ready    agent   22h   v1.27.7   10.224.0.4    <none>        Ubuntu 22.04.3 LTS               5.15.0-1052-azure   containerd://1.7.5-1
    aks-nodepool1-20786768-vmss000001   Ready    agent   22h   v1.27.7   10.224.0.33   <none>        Ubuntu 22.04.3 LTS               5.15.0-1052-azure   containerd://1.7.5-1
    aksnpwin000000                      Ready    agent   20h   v1.27.7   10.224.0.62   <none>        Windows Server 2022 Datacenter   10.0.20348.2159     containerd://1.6.21+azure
    

    Uwaga

    Środowisko uruchomieniowe kontenera dla każdej puli węzłów jest wyświetlane w obszarze CONTAINER-RUNTIME. Wartości środowiska uruchomieniowego kontenera zaczynają się od containerd://, co oznacza, że każdy z nich jest używany containerd dla środowiska uruchomieniowego kontenera.

Wdrażanie aplikacji

Plik manifestu platformy Kubernetes definiuje żądany stan klastra, w tym informacje o obrazach kontenera do uruchomienia. W tym artykule użyjesz manifestu, aby utworzyć wszystkie obiekty potrzebne do uruchomienia przykładowej aplikacji ASP.NET w kontenerze systemu Windows Server. Ten manifest obejmuje wdrożenie platformy Kubernetes dla przykładowej aplikacji ASP.NET oraz zewnętrzną usługę Kubernetes w celu uzyskania dostępu do aplikacji z Internetu.

Przykładowa aplikacja ASP.NET jest udostępniana jako część przykładów programu .NET Framework i działa w kontenerze systemu Windows Server. Usługa AKS wymaga, aby kontenery systemu Windows Server opierały się na obrazach systemu Windows Server 2019 lub nowszych. Plik manifestu kubernetes musi również zdefiniować selektor węzła, aby poinformować klaster usługi AKS o uruchomieniu zasobnika przykładowej aplikacji ASP.NET w węźle, który może uruchamiać kontenery systemu Windows Server.

  1. Utwórz plik o nazwie sample.yaml i skopiuj go do poniższej definicji YAML.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: sample
      labels:
        app: sample
    spec:
      replicas: 1
      template:
        metadata:
          name: sample
          labels:
            app: sample
        spec:
          nodeSelector:
            "kubernetes.io/os": windows
          containers:
          - name: sample
            image: mcr.microsoft.com/dotnet/framework/samples:aspnetapp
            resources:
              limits:
                cpu: 1
                memory: 800M
            ports:
              - containerPort: 80
      selector:
        matchLabels:
          app: sample
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: sample
    spec:
      type: LoadBalancer
      ports:
      - protocol: TCP
        port: 80
      selector:
        app: sample
    

    Aby uzyskać podział plików manifestu YAML, zobacz Wdrożenia i manifesty YAML.

    Jeśli tworzysz i zapisujesz plik YAML lokalnie, możesz przekazać plik manifestu do katalogu domyślnego w programie CloudShell, wybierając przycisk Przekaż/Pobierz pliki i wybierając plik z lokalnego systemu plików.

  2. Wdróż aplikację przy użyciu polecenia kubectl apply i określ nazwę manifestu YAML.

    kubectl apply -f sample.yaml
    

    Następujące przykładowe dane wyjściowe pokazują pomyślne utworzenie wdrożenia i usługi:

    deployment.apps/sample created
    service/sample created
    

Testowanie aplikacji

Podczas uruchamiania aplikacji usługa Kubernetes uwidacznia fronton aplikacji w Internecie. Ten proces może potrwać kilka minut. Czasami aprowizacja usługi może potrwać dłużej niż kilka minut. Aprowizacja może potrwać do 10 minut.

  1. Sprawdź stan wdrożonych zasobników przy użyciu polecenia kubectl get pods . Przed kontynuowaniem wykonaj wszystkie zasobniki Running .

    kubectl get pods
    
  2. Monitoruj postęp przy użyciu polecenia kubectl get service za pomocą argumentu --watch .

    kubectl get service sample --watch
    

    Początkowo dane wyjściowe przedstawiają adres EXTERNAL-IP dla przykładowej usługi jako oczekujące:

    NAME               TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
    sample             LoadBalancer   10.0.37.27   <pending>     80:30572/TCP   6s
    

    Gdy dla adresu EXTERNAL-IP wartość oczekujący zmieni się na rzeczywisty publiczny adres IP, naciśnij klawisze CTRL-C, aby zatrzymać proces śledzenia narzędzia kubectl. Następujące przykładowe dane wyjściowe pokazują prawidłowy publiczny adres IP przypisany do usługi:

    sample  LoadBalancer   10.0.37.27   52.179.23.131   80:30572/TCP   2m
    
  3. Zobacz przykładową aplikację w działaniu, otwierając przeglądarkę internetową na zewnętrzny adres IP usługi.

    Zrzut ekranu przedstawiający przechodzenie do przykładowej aplikacji ASP.NET.

Usuwanie zasobów

Jeśli nie planujesz przechodzenia przez samouczek usługi AKS, usuń klaster, aby uniknąć naliczania opłat za platformę Azure.

Usuń grupę zasobów, usługę kontenera i wszystkie powiązane zasoby przy użyciu polecenia az group delete .

az group delete --name myResourceGroup --yes --no-wait

Uwaga

Klaster usługi AKS został utworzony przy użyciu tożsamości zarządzanej przypisanej przez system (domyślna opcja tożsamości używana w tym przewodniku Szybki start). Platforma Azure zarządza tą tożsamością, więc nie wymaga usunięcia.

Następne kroki

W tym przewodniku Szybki start wdrożono klaster Kubernetes, a następnie wdrożono w nim przykładową aplikację ASP.NET w kontenerze systemu Windows Server. Ta przykładowa aplikacja służy tylko do celów demonstracyjnych i nie reprezentuje wszystkich najlepszych rozwiązań dla aplikacji Kubernetes. Aby uzyskać wskazówki dotyczące tworzenia pełnych rozwiązań za pomocą usługi AKS dla środowiska produkcyjnego, zobacz Wskazówki dotyczące rozwiązania AKS.

Aby dowiedzieć się więcej na temat usługi AKS i zapoznać się z kompletnym przykładem kodu do wdrożenia, przejdź do samouczka dotyczącego klastra Kubernetes.