Tutorial: Configuración de redes kubenet en Azure Kubernetes Service (AKS) mediante Ansible
Importante
Para ejecutar los cuadernos de estrategias de ejemplo de este tutorial, se requiere Ansible 2.8 (o cualquier versión posterior).
Azure Kubernetes Service (AKS) simplifica la implementación en Azure de clústeres de Kubernetes administrados. AKS reduce la complejidad y la sobrecarga operativa de la administración de Kubernetes al descargar gran parte de esa responsabilidad en Azure. Como servicio hospedado de Kubernetes, Azure maneja tareas críticas como la supervisión del estado y el mantenimiento para usted. Azure administra los maestros de Kubernetes. Usted solo administra y mantiene los nodos del agente. Como servicio de Kubernetes administrado, AKS es gratuito (solo debe pagar los nodos de agente incluidos en sus clústeres, no los maestros).
Con AKS, puede implementar un clúster mediante los siguientes modelos de red:
- Redes kubenet: los recursos de red normalmente se crean y configuran cuando se implementa el clúster de AKS.
- Red de Azure Container Networking Interface (CNI): el clúster de AKS se conecta a los recursos y configuraciones de la red virtual existentes.
Para más información sobre las conexiones de red a las aplicaciones de AKS, vea Conceptos de redes de aplicaciones en Azure Kubernetes Service (AKS).
En este artículo aprenderá a:
- Creación de un clúster de AKS
- Configuración de redes kubenet de Azure
Requisitos previos
- Suscripción de Azure: si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.
- Entidad de servicio de Azure: cree una entidad de servicio y tome nota de los siguientes valores: appId, displayName, password y tenant.
Instalación de Ansible: realice una de las siguientes opciones:
- Instalar y configurar Ansible en una máquina virtual Linux
- Configurar Azure Cloud Shell y, si no tiene acceso a una máquina virtual Linux, crear una máquina virtual con Ansible.
Creación de una red virtual y una subred
El código del cuaderno de estrategias de esta sección crea los siguientes recursos de Azure:
- Virtual network
- Subred en la red virtual
Guarde el siguiente cuaderno de estrategias como 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
Creación de un clúster de AKS en la red virtual
El código del cuaderno de estrategias de esta sección crea un clúster de AKS dentro de una red virtual.
Guarde el siguiente cuaderno de estrategias como 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
Estas son algunas notas importantes que hay que tener en cuenta al trabajar con el cuaderno de estrategias de ejemplo:
Use el módulo
azure_rm_aks_versionpara buscar la versión compatible.vnet_subnet_ides la subred que creó en la sección anterior.network_profiledefine las propiedades del complemento de red de kubenet.service_cidrse usa para asignar servicios internos del clúster de AKS a una dirección IP. Este intervalo de direcciones IP debe ser un espacio de direcciones que no se use fuera de los clústeres de AKS. Sin embargo, puede volver a usar el mismo CIDR de servicio para varios clústeres de AKS.La dirección
dns_service_ipdebe ser la dirección ".10" del intervalo de direcciones IP del servicio.pod_cidrdebe ser un espacio de direcciones grande que no se use en ninguna otra parte del entorno de red. El intervalo de direcciones debe ser lo suficientemente grande como para alojar el número de nodos hasta el que pretende escalar verticalmente. No se puede cambiar este intervalo de direcciones una vez implementado el clúster. Al igual que con el CIDR del servicio, este intervalo de direcciones IP no debe existir fuera del clúster de AKS, pero se puede volver a usar de forma segura en los clústeres.El intervalo de direcciones IP para pods se usa para asignar un espacio de direcciones de /24 a cada nodo del clúster. En el ejemplo siguiente,
pod_cidrde 192.168.0.0/16 asigna el primer nodo 192.168.0.0/24, el segundo nodo 192.168.1.0/24 y el tercer nodo 192.168.2.0/24.A medida que el clúster se escala o actualiza, Azure continúa asignando un intervalo de direcciones IP para pods a cada nuevo nodo.
El cuaderno de estrategias carga
ssh_keydesde~/.ssh/id_rsa.pub. Si lo modifica, utilice el formato de línea única, empezando por "ssh-rsa" (sin las comillas).Los valores
client_idyclient_secretse cargan desde~/.azure/credentials, que es el archivo de credenciales predeterminado. Puede establecer estos valores en su entidad de servicio o cargarlos desde las variables de entorno:client_id: "{{ lookup('env', 'AZURE_CLIENT_ID') }}" client_secret: "{{ lookup('env', 'AZURE_SECRET') }}"
Asociación de los recursos de red
Al crear un clúster de AKS, también se crean un grupo de seguridad de red y una tabla de ruta. AKS se encarga de administrar estos recursos, que se actualizan al crear y exponer los servicios. Asocie el grupo de seguridad de red y la tabla de ruta con la subred de red virtual como se indica a continuación.
Guarde el siguiente cuaderno de estrategias como 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 }}"
Estas son algunas notas importantes que hay que tener en cuenta al trabajar con el cuaderno de estrategias de ejemplo:
node_resource_groupes el nombre del grupo de recursos en el que se crean los nodos de AKS.vnet_subnet_ides la subred que creó en la sección anterior.
Ejecución del cuaderno de estrategias de ejemplo
En esta sección se indica el cuaderno de estrategias de ejemplo completo que llama a las tareas que se crean en este artículo.
Guarde el siguiente cuaderno de estrategias como 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]
En la sección vars, realice los cambios siguientes:
- Para la clave
resource_group, cambie el valoraksansibletestpor el nombre del grupo de recursos. - Para la clave
name, cambie el valoraksansibletestpor el nombre de AKS. - Para la clave
Location, cambie el valoreastuspor la ubicación del grupo de recursos.
Ejecute el cuaderno de estrategias completo con el comando ansible-playbook:
ansible-playbook aks-kubenet.yml
Al ejecutar el cuaderno de estrategias, se muestran resultados similares a la salida siguiente:
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
Limpieza de recursos
Guarde el código siguiente como
delete_rg.yml.--- - hosts: localhost tasks: - name: Deleting resource group - "{{ name }}" azure_rm_resourcegroup: name: "{{ name }}" state: absent register: rg - debug: var: rgEjecute el cuaderno de estrategias mediante el comando ansible-playbook. Reemplace el marcador de posición por el nombre del grupo de recursos que se va a eliminar. Se eliminarán todos los recursos del grupo de recursos.
ansible-playbook delete_rg.yml --extra-vars "name=<resource_group>"Puntos clave:
- Debido a la variable
registery a la seccióndebugdel cuaderno de estrategias, los resultados se muestran cuando finaliza el comando.
- Debido a la variable
Pasos siguientes
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de