Lernprogramm: Konfigurieren von Azure CNI-Netzwerken in Azure Kubernetes Service (AKS) mithilfe von Ansible

Von Bedeutung

Ansible 2.8 (oder höher) ist erforderlich, um die Beispiel-Playbooks in diesem Artikel auszuführen.

Azure Kubernetes Service (AKS) vereinfacht die Bereitstellung eines verwalteten Kubernetes-Clusters in Azure. AKS verringert die Komplexität und den operativen Mehraufwand für die Kubernetes-Verwaltung, indem ein Großteil dieser Verantwortung an Azure übertragen wird. Azure als gehosteter Kubernetes-Dienst übernimmt für Sie wichtige Aufgaben wie Gesundheitsüberwachung und Wartung. Die Kubernetes-Master werden von Azure verwaltet. Sie verwalten und warten nur die Agentknoten. Als verwalteter Kubernetes-Dienst ist AKS kostenlos - Sie zahlen nur für die Agentknoten in Ihren Clustern; nicht für die Master.

Mithilfe von AKS können Sie einen Cluster mithilfe der folgenden Netzwerkmodelle bereitstellen:

Azure CNI-Netzwerk – AKS-Cluster ist mit vorhandenen VNET-Ressourcen und -Konfigurationen (Virtual Network) verbunden.

Weitere Informationen zum Netzwerk mit Ihren Anwendungen in AKS finden Sie unter Netzwerkkonzepte für Anwendungen in AKS.

In diesem Artikel erfahren Sie, wie Sie:

Erstellen eines AKS-Clusters
Konfigurieren von Azure CNI-Netzwerken

Voraussetzungen

Azure-Abonnement: Wenn Sie nicht über ein Azure-Abonnement verfügen, erstellen Sie ein kostenloses Konto , bevor Sie beginnen.

Azure-Dienstprinzipal: Erstellen Sie einen Dienstprinzipal, und notieren Sie sich die folgenden Werte: appId, displayName, Kennwort und Mandant.

Installieren Sie Ansible: Führen Sie eine der folgenden Optionen aus:
- Installieren und Konfigurieren von Ansible auf einem virtuellen Linux-Computer
- Konfigurieren Sie Azure Cloud Shell, und erstellen Sie – wenn Sie keinen Zugriff auf einen virtuellen Linux-Computer haben – einen virtuellen Computer mit Ansible.

Erstellen eines virtuellen Netzwerks und des Subnetzes

Der Beispiel-Playbook-Code in diesem Abschnitt wird zu folgendem Zweck verwendet:

Erstellen eines virtuellen Netzwerks
Erstellen eines Subnetzes innerhalb des virtuellen Netzwerks

Speichern Sie das folgende Playbook unter vnet.yml:

- name: Create vnet
  azure_rm_virtualnetwork:
      resource_group: "{{ resource_group }}"
      name: "{{ name }}"
      address_prefixes_cidr:
          - 10.0.0.0/8

- name: Create subnet
  azure_rm_subnet:
      resource_group: "{{ resource_group }}"
      name: "{{ name }}"
      address_prefix_cidr: 10.240.0.0/16
      virtual_network_name: "{{ name }}"
  register: subnet

Erstellen eines AKS-Clusters im virtuellen Netzwerk

Der Beispiel-Playbook-Code in diesem Abschnitt wird verwendet für:

Erstellen Sie einen AKS-Cluster in einem virtuellen Netzwerk.

Speichern Sie das folgende Playbook unter aks.yml:

- name: List supported kubernetes version from Azure
  azure_rm_aks_version:
      location: "{{ location }}"
  register: versions

- name: Create AKS cluster within a VNet
  azure_rm_aks:
      resource_group: "{{ resource_group }}"
      name: "{{ name }}"
      dns_prefix: "{{ name }}"
      kubernetes_version: "{{ versions.azure_aks_versions[-1] }}"
      agent_pool_profiles:
        - count: 3
          name: nodepool1
          vm_size: Standard_D2_v2
          vnet_subnet_id: "{{ vnet_subnet_id }}"
      linux_profile:
          admin_username: azureuser
          ssh_key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
      service_principal:
          client_id: "{{ lookup('ini', 'client_id section=default file=~/.azure/credentials') }}"
          client_secret: "{{ lookup('ini', 'secret section=default file=~/.azure/credentials') }}"
      network_profile:
          network_plugin: azure
          docker_bridge_cidr: 172.17.0.1/16
          dns_service_ip: 10.2.0.10
          service_cidr: 10.2.0.0/24
  register: aks

Im Folgenden finden Sie einige wichtige Hinweise, die Sie beim Arbeiten mit dem Beispiel-Playbook berücksichtigen sollten:

Verwenden Sie das azure_rm_aks_version Modul, um die unterstützte Version zu finden.
Das vnet_subnet_id ist das Subnetz, das im vorherigen Abschnitt erstellt wurde.
Das Playbook wird geladen ssh_key von ~/.ssh/id_rsa.pub. Wenn Sie es ändern, verwenden Sie das einzeilige Format – beginnend mit "ssh-rsa" (ohne anführungszeichen).
Die Werte client_id und client_secret werden aus ~/.azure/credentials geladen, bei der es sich um die Standardanmeldeinformationsdatei handelt. Sie können diese Werte auf Ihren Dienstprinzipal festlegen oder diese Werte aus Umgebungsvariablen laden:
```
client_id: "{{ lookup('env', 'AZURE_CLIENT_ID') }}"
client_secret: "{{ lookup('env', 'AZURE_SECRET') }}"
```

Führen Sie das Beispiel-Playbook aus

Der Beispiel-Playbook-Code in diesem Abschnitt wird verwendet, um verschiedene Features zu testen, die in diesem Lernprogramm gezeigt werden.

Speichern Sie das folgende Playbook unter aks-azure-cni.yml:

---
- hosts: localhost
  vars:
      resource_group: aksansibletest
      name: aksansibletest
      location: eastus
  tasks:
     - name: Ensure resource group exists
       azure_rm_resourcegroup:
           name: "{{ resource_group }}"
           location: "{{ location }}"

     - name: Create vnet
       include_tasks: vnet.yml

     - name: Create AKS
       vars:
           vnet_subnet_id: "{{ subnet.state.id }}"
       include_tasks: aks.yml

     - name: Show AKS cluster detail
       debug:
           var: aks

Im Folgenden finden Sie einige wichtige Hinweise, die Sie beim Arbeiten mit dem Beispiel-Playbook berücksichtigen sollten:

Ändern Sie den aksansibletest Wert in ihren Ressourcengruppennamen.
Ändern Sie das aksansibletest so, dass es Ihrem AKS-Namen entspricht.
Ändern Sie den eastus Wert zu dem Standort Ihrer Ressourcengruppe.

Führen Sie das Playbook mit dem Befehl "ansible-playbook" aus:

ansible-playbook aks-azure-cni.yml

Nach dem Ausführen des Playbooks wird eine Ausgabe angezeigt, die den folgenden Ergebnissen ähnelt:

PLAY [localhost] 

TASK [Gathering Facts] 
ok: [localhost]

TASK [Ensure resource group exists] 
changed: [localhost]

TASK [Create vnet] 
included: /home/devops/aks-cni/vnet.yml for localhost

TASK [Create vnet] 
changed: [localhost]

TASK [Create subnet] 
changed: [localhost]

TASK [Create AKS] 
included: /home/devops/aks-cni/aks.yml for localhost

TASK [List supported kubernetes version from Azure] 
 [WARNING]: Azure API profile latest does not define an entry for
ContainerServiceClient

ok: [localhost]

TASK [Create AKS cluster with vnet] 
changed: [localhost]

TASK [Show AKS cluster detail] 
ok: [localhost] => {
    "aks": {
        "aad_profile": {},
        "addon": {},
        "agent_pool_profiles": [
            {
                "count": 3,
                "name": "nodepool1",
                "os_disk_size_gb": 100,
                "os_type": "Linux",
                "storage_profile": "ManagedDisks",
                "vm_size": "Standard_D2_v2",
                "vnet_subnet_id": "/subscriptions/BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB/resourceGroups/aksansibletest/providers/Microsoft.Network/virtualNetworks/aksansibletest/subnets/aksansibletest"
            }
        ],
        "changed": true,
        "dns_prefix": "aksansibletest",
        "enable_rbac": false,
        "failed": false,
        "fqdn": "aksansibletest-0272707d.hcp.eastus.azmk8s.io",
        "id": "/subscriptions/BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB/resourcegroups/aksansibletest/providers/Microsoft.ContainerService/managedClusters/aksansibletest",
        "kube_config": "..."
        },
        "location": "eastus",
        "name": "aksansibletest",
        "network_profile": {
            "dns_service_ip": "10.2.0.10",
            "docker_bridge_cidr": "172.17.0.1/16",
            "network_plugin": "azure",
            "network_policy": null,
            "pod_cidr": null,
            "service_cidr": "10.2.0.0/24"
        },
        "node_resource_group": "MC_aksansibletest_aksansibletest_eastus",
        "provisioning_state": "Succeeded",
        "service_principal_profile": {
            "client_id": "AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA"
        },
        "tags": null,
        "type": "Microsoft.ContainerService/ManagedClusters",
        "warnings": [
            "Azure API profile latest does not define an entry for ContainerServiceClient",
            "Azure API profile latest does not define an entry for ContainerServiceClient"
        ]
    }
}

PLAY RECAP 
localhost                  : ok=9    changed=4    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Bereinigen von Ressourcen

Speichern Sie den folgenden Code als delete_rg.yml.

---
- hosts: localhost
  tasks:
    - name: Deleting resource group - "{{ name }}"
      azure_rm_resourcegroup:
        name: "{{ name }}"
        state: absent
      register: rg
    - debug:
        var: rg

Führen Sie das Playbook mit dem Befehl "ansible-playbook" aus. Ersetzen Sie den Platzhalter durch den Namen der zu löschenden Ressourcengruppe. Alle Ressourcen innerhalb der Ressourcengruppe werden gelöscht.
```
ansible-playbook delete_rg.yml --extra-vars "name=<resource_group>"
```
Wichtige Punkte:
- Aufgrund der register Variablen und des debug Abschnitts des Playbooks werden die Ergebnisse angezeigt, sobald der Befehl abgeschlossen ist.

Führen Sie az group delete aus, um die Ressourcengruppe zu löschen. Alle Ressourcen innerhalb der Ressourcengruppe werden gelöscht.
```
az group delete --name <resource_group>
```
Überprüfen Sie, ob die Ressourcengruppe mithilfe der az group show gelöscht wurde.
```
az group show --name <resource_group>
```

Führen Sie Remove-AzResourceGroup aus, um die Ressourcengruppe zu löschen. Alle Ressourcen innerhalb der Ressourcengruppe werden gelöscht.
```
Remove-AzResourceGroup -Name <resource_group>
```
Überprüfen Sie, ob die Ressourcengruppe mithilfe von "Get-AzResourceGroup" gelöscht wurde.
```
Get-AzResourceGroup -Name <resource_group>
```

Nächste Schritte

Lernprogramm: Konfigurieren der Microsoft Entra-ID in AKS mithilfe von Ansible

Feedback

War diese Seite hilfreich?

Last updated on 2025-10-10