Tutoriel : Configurer la mise en réseau kubenet 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.
- Interface de mise en réseau de conteneur (CNI) Azure : le cluster AKS est connecté à des ressources de réseau virtuel 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 la mise en réseau Azure kubenet
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
Le code de playbook dans cette section crée les ressources Azure suivantes :
- Réseau virtuel
- 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
Le code de playbook dans cette section crée 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 with 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: kubenet
pod_cidr: 192.168.0.0/16
docker_bridge_cidr: 172.17.0.1/16
dns_service_ip: 10.0.0.10
service_cidr: 10.0.0.0/16
register: aks
Voici quelques remarques importantes à prendre en compte lorsque vous travaillez avec l’exemple de playbook :
Utilisez le module
azure_rm_aks_versionpour rechercher la version prise en charge.vnet_subnet_idest le sous-réseau créé dans la section précédente.Le
network_profiledéfinit les propriétés du plug-in de réseau kubenet.Le
service_cidrest utilisé pour affecter des services internes dans le cluster AKS à une adresse IP. Cette plage d’adresses IP doit être un espace d’adressage qui n’est pas utilisé en dehors des clusters AKS. Toutefois, vous pouvez réutiliser le même CIDR de service pour plusieurs clusters AKS.L’adresse
dns_service_ipdoit être l’adresse « . 10 » de la plage d’adresses IP de votre service.Le
pod_cidrdoit être un vaste espace d’adresses qui n’est pas utilisé ailleurs dans votre environnement réseau. La plage d’adresses doit être suffisamment grande pour contenir le nombre de nœuds que vous prévoyez pour une montée en puissance. Vous ne pouvez pas modifier cette plage d’adresses une fois que le cluster est déployé. Comme pour le service CIDR, cette plage d’adresses IP ne doit pas exister en dehors du cluster AKS, mais elle peut être réutilisée sans danger dans les clusters.La plage d’adresses IP de pod est utilisée pour attribuer un espace d’adressage /24 pour chaque nœud du cluster. Dans l’exemple suivant, le
pod_cidrde 192.168.0.0/16 attribue le premier nœud 192.168.0.0/24, le deuxième nœud 192.168.1.0/24 et le troisième nœud 192.168.2.0/24.À mesure que le cluster est mis à l’échelle ou évolue, Azure continue à attribuer une plage d’adresses IP pod à chaque nouveau nœud.
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_idetclient_secretsont 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') }}"
Associer les ressources réseau
Quand vous créez un cluster AKS, un groupe de sécurité réseau et une table de routage sont créés. Ces ressources sont gérées par AKS et mises à jour lorsque vous créez et exposez des services. Associez le groupe de sécurité réseau et la table d’itinéraire à votre sous-réseau virtuel comme suit.
Enregistrez le playbook suivant en tant que associate.yml.
- name: Get route table
azure_rm_routetable_facts:
resource_group: "{{ node_resource_group }}"
register: routetable
- name: Get network security group
azure_rm_securitygroup_facts:
resource_group: "{{ node_resource_group }}"
register: nsg
- name: Parse subnet id
set_fact:
subnet_name: "{{ vnet_subnet_id | regex_search(subnet_regex, '\\1') }}"
subnet_rg: "{{ vnet_subnet_id | regex_search(rg_regex, '\\1') }}"
subnet_vn: "{{ vnet_subnet_id | regex_search(vn_regex, '\\1') }}"
vars:
subnet_regex: '/subnets/(.+)'
rg_regex: '/resourceGroups/(.+?)/'
vn_regex: '/virtualNetworks/(.+?)/'
- name: Associate network resources with the node subnet
azure_rm_subnet:
name: "{{ subnet_name[0] }}"
resource_group: "{{ subnet_rg[0] }}"
virtual_network_name: "{{ subnet_vn[0] }}"
security_group: "{{ nsg.ansible_facts.azure_securitygroups[0].id }}"
route_table: "{{ routetable.route_tables[0].id }}"
Voici quelques remarques importantes à prendre en compte lorsque vous travaillez avec l’exemple de playbook :
- Le
node_resource_groupest le nom du groupe de ressources dans lequel les nœuds AKS sont créés. - Le
vnet_subnet_idest le sous-réseau créé dans la section précédente.
Exécutez l’exemple de playbook
Cette section répertorie l’exemple de playbook complet qui appelle les tâches de création dans cet article.
Enregistrez le playbook suivant en tant que aks-kubenet.yml :
---
- hosts: localhost
vars:
resource_group: aksansibletest
name: aksansibletest
location: eastus
tasks:
- name: Ensure resource group exist
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: Associate network resources with the node subnet
vars:
vnet_subnet_id: "{{ subnet.state.id }}"
node_resource_group: "{{ aks.node_resource_group }}"
include_tasks: associate.yml
- name: Get details of the AKS
azure_rm_aks_facts:
name: "{{ name }}"
resource_group: "{{ resource_group }}"
show_kubeconfig: user
register: output
- name: Show AKS cluster detail
debug:
var: output.aks[0]
Dans la section vars, apportez les modifications suivantes :
- Pour la clé
resource_group, modifiez la valeuraksansibletestet donnez-lui le nom de votre groupe de ressources. - Pour la clé
name, modifiez la valeuraksansibletestet donnez-lui le nom de votre AKS. - Pour la clé
Location, modifiez la valeureastuset donnez-lui le nom de l’emplacement de votre groupe de ressources.
Exécutez le playbook complet en utilisant la commande ansible-playbook :
ansible-playbook aks-kubenet.yml
L’exécution du playbook donne des résultats similaires à la sortie suivante :
PLAY [localhost]
TASK [Gathering Facts]
ok: [localhost]
TASK [Ensure resource group exist]
ok: [localhost]
TASK [Create vnet]
included: /home/devops/aks-kubenet/vnet.yml for localhost
TASK [Create vnet]
ok: [localhost]
TASK [Create subnet]
ok: [localhost]
TASK [Create AKS]
included: /home/devops/aks-kubenet/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 [Associate network resources with the node subnet]
included: /home/devops/aks-kubenet/associate.yml for localhost
TASK [Get route table]
ok: [localhost]
TASK [Get network security group]
ok: [localhost]
TASK [Parse subnet id]
ok: [localhost]
TASK [Associate network resources with the node subnet]
changed: [localhost]
TASK [Get details of the AKS]
ok: [localhost]
TASK [Show AKS cluster detail]
ok: [localhost] => {
"output.aks[0]": {
"id": /subscriptions/BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB/resourcegroups/aksansibletest/providers/Microsoft.ContainerService/managedClusters/aksansibletest",
"kube_config": "apiVersion: ...",
"location": "eastus",
"name": "aksansibletest",
"properties": {
"agentPoolProfiles": [
{
"count": 3,
"maxPods": 110,
"name": "nodepool1",
"osDiskSizeGB": 100,
"osType": "Linux",
"storageProfile": "ManagedDisks",
"vmSize": "Standard_D2_v2",
"vnetSubnetID": "/subscriptions/BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB/resourceGroups/aksansibletest/providers/Microsoft.Network/virtualNetworks/aksansibletest/subnets/aksansibletest"
}
],
"dnsPrefix": "aksansibletest",
"enableRBAC": false,
"fqdn": "aksansibletest-cda2b56c.hcp.eastus.azmk8s.io",
"kubernetesVersion": "1.12.6",
"linuxProfile": {
"adminUsername": "azureuser",
"ssh": {
"publicKeys": [
{
"keyData": "ssh-rsa ..."
}
]
}
},
"networkProfile": {
"dnsServiceIP": "10.0.0.10",
"dockerBridgeCidr": "172.17.0.1/16",
"networkPlugin": "kubenet",
"podCidr": "192.168.0.0/16",
"serviceCidr": "10.0.0.0/16"
},
"nodeResourceGroup": "MC_aksansibletest_pcaksansibletest_eastus",
"provisioningState": "Succeeded",
"servicePrincipalProfile": {
"clientId": "AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA"
}
},
"type": "Microsoft.ContainerService/ManagedClusters"
}
}
PLAY RECAP
localhost : ok=15 changed=2 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: rgExé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
registeret de la sectiondebugdu playbook, les résultats s’affichent quand la commande se termine.
- En raison de la variable
Étapes suivantes
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour