Tutoriel : Configurer la mise en réseau Azure CNI dans Azure Kubernetes Service (AKS) à l’aide d’Ansible
Important
Ansible 2.8 (ou version ultérieure) est nécessaire pour exécuter les exemples de playbooks dans cet article.
Azure Kubernetes Service (AKS) simplifie le déploiement dans Azure d’un cluster Kubernetes managé. AKS permet de réduire la complexité et la surcharge opérationnelle de la gestion d’un cluster Kubernetes en déléguant une grande partie de cette responsabilité à Azure. En tant que service Kubernetes hébergé, Azure gère pour vous des tâches critiques telles que l’analyse de l'intégrité et la maintenance. Les maîtres Kubernetes sont gérés par Azure. Vous gérez uniquement les nœuds de l’agent. En tant que service Kubernetes managé, AKS est gratuit. Vous payez uniquement pour les nœuds de l’agent au sein de vos clusters, pas pour les maîtres.
À l’aide d’AKS, vous pouvez déployer un cluster à l’aide des modèles de réseau suivants :
- Mise en réseau Kubenet : les ressources réseau sont généralement créées et configurées lors du déploiement du cluster AKS.
- Mise en réseau de Azure CNI: le cluster AKS est connecté à des ressources de réseau virtuel (VNET) et à des configurations existantes.
Pour plus d’informations sur la mise en réseau avec vos applications dans AKS, consultez Concepts réseau pour les applications dans AKS.
Dans cet article, vous apprendrez comment :
- Créer un cluster AKS
- Configurer le réseau Azure CNI
Prérequis
- Abonnement Azure : Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.
- Principal de service Azure : créez un principal de service en notant les valeurs suivantes : appId, displayName, password et tenant.
Installer Ansible. Pour cela, choisissez l’une des options suivantes :
- Installez et configurez Ansible sur une machine virtuelle Linux
- Configurez Azure Cloud Shell et, si vous n’avez pas accès à une machine virtuelle Linux, créez une machine virtuelle avec Ansible.
Créer un réseau virtuel et un sous-réseau
L’exemple de code de playbook dans cette section est utilisé pour :
- Créez un réseau virtuel
- créer un sous-réseau au sein du réseau virtuel
Enregistrez le playbook suivant en tant que 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
Créer un cluster AKS dans le réseau virtuel
L’exemple de code de playbook dans cette section est utilisé pour :
- créer un cluster AKS au sein d’un réseau virtuel.
Enregistrez le playbook suivant en tant que 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
Voici quelques remarques importantes à prendre en compte lorsque vous travaillez avec l’exemple de playbook :
Utilisez le module
azure_rm_aks_version
pour rechercher la version prise en charge.vnet_subnet_id
est le sous-réseau créé dans la section précédente.Le playbook charge
ssh_key
à partir de~/.ssh/id_rsa.pub
. Si vous le modifiez, utilisez le format single-line en commençant par « ssh-rsa » (sans les guillemets).Les valeurs
client_id
etclient_secret
sont chargées à partir de~/.azure/credentials
, qui est le fichier d’informations d’identification par défaut. Vous pouvez définir ces valeurs pour votre service principal ou les charger à partir de variables d’environnement :client_id: "{{ lookup('env', 'AZURE_CLIENT_ID') }}" client_secret: "{{ lookup('env', 'AZURE_SECRET') }}"
Exécutez l’exemple de playbook
L’exemple de code de playbook dans cette section est utilisé pour tester les différentes fonctionnalités présentées dans ce tutoriel.
Enregistrez le playbook suivant en tant que 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
Voici quelques remarques importantes à prendre en compte lorsque vous travaillez avec l’exemple de playbook :
- Modifiez la valeur
aksansibletest
et donnez-lui le nom de votre groupe de ressources. - Modifiez la valeur
aksansibletest
et donnez-lui le nom de votre AKS. - Modifiez la valeur
eastus
et donnez-lui le nom de l’emplacement de votre groupe de ressources.
Exécutez le playbook à l’aide de la commande ansible-playbook :
ansible-playbook aks-azure-cni.yml
Après avoir exécuté le playbook, vous voyez une sortie similaire aux résultats suivants :
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
Nettoyer les ressources
Enregistrez le code suivant en tant que
delete_rg.yml
.--- - hosts: localhost tasks: - name: Deleting resource group - "{{ name }}" azure_rm_resourcegroup: name: "{{ name }}" state: absent register: rg - debug: var: rg
Exécutez le playbook en utilisant la commande ansible-playbook. Remplacez l’espace réservé par le nom du groupe de ressources à supprimer. Toutes les ressources du groupe de ressources seront supprimées.
ansible-playbook delete_rg.yml --extra-vars "name=<resource_group>"
Points essentiels :
- En raison de la variable
register
et de la sectiondebug
du playbook, les résultats s’affichent quand la commande se termine.
- En raison de la variable