Tutorial: Configurar a rede kubenet no Serviço Kubernetes do Azure (AKS) usando o Ansible
Importante
O Ansible 2.8 (ou posterior) é necessário para executar os playbooks de exemplo neste artigo.
O Serviço Kubernetes do Azure (AKS) simplifica a implantação de um cluster Kubernetes gerenciado no Azure. O AKS reduz a complexidade e a sobrecarga operacional de gerir o Kubernetes ao descarregar grande parte dessa responsabilidade para o Azure. Enquanto serviço alojado do Kubernetes, o Azure lida com tarefas críticas para si, como a monitorização do estado de funcionamento e a manutenção. Os mestres do Kubernetes são geridos pelo Azure. Pode apenas gerir e manter os nós dos agentes. Como um serviço Kubernetes gerenciado, o AKS é gratuito - você paga apenas pelos nós do agente dentro de seus clusters; não para os mestres.
Usando o AKS, você pode implantar um cluster usando os seguintes modelos de rede:
- Rede Kubenet - Os recursos de rede são normalmente criados e configurados à medida que o cluster AKS é implantado.
- Rede CNI (Container Networking Interface) do Azure - O cluster AKS está conectado a recursos e configurações de rede virtual existentes.
Para obter mais informações sobre a rede para seus aplicativos no AKS, consulte Conceitos de rede para aplicativos no AKS.
Neste artigo, vai aprender a:
- Criar um cluster do AKS
- Configurar a rede kubenet do Azure
Pré-requisitos
- Subscrição do Azure: se não tem uma subscrição do Azure, crie uma conta gratuita antes de começar.
- Entidade de serviço do Azure: crie uma entidade de serviço, anotando os seguintes valores: appId, displayName, senha e locatário.
Instale o Ansible: execute uma das seguintes opções:
- Instalar e configurar o Ansible em uma máquina virtual Linux
- Configure o Azure Cloud Shell e, se você não tiver acesso a uma máquina virtual Linux, crie uma máquina virtual com o Ansible.
Criar uma rede virtual e uma sub-rede
O código do playbook nesta seção cria os seguintes recursos do Azure:
- Rede virtual
- Sub-rede dentro da rede virtual
Guarde o manual de procedimentos seguinte 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
Criar um cluster AKS na rede virtual
O código do playbook nesta seção cria um cluster AKS dentro de uma rede virtual.
Guarde o manual de procedimentos seguinte 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
Aqui estão algumas notas-chave a considerar ao trabalhar com o manual de exemplo:
Use
azure_rm_aks_versiono módulo para encontrar a versão suportada.A
vnet_subnet_idé a sub-rede criada na seção anterior.O
network_profiledefine as propriedades para o plug-in de rede kubenet.O
service_cidré usado para atribuir serviços internos no cluster AKS a um endereço IP. Esse intervalo de endereços IP deve ser um espaço de endereçamento que não seja usado fora dos clusters AKS. No entanto, você pode reutilizar o mesmo CIDR de serviço para vários clusters AKS.O
dns_service_ipendereço deve ser o endereço ".10" do intervalo de endereços IP do seu serviço.O
pod_cidrdeve ser um grande espaço de endereçamento que não está em uso em outro lugar em seu ambiente de rede. O intervalo de endereços deve ser grande o suficiente para acomodar o número de nós que você espera dimensionar. Não é possível alterar esse intervalo de endereços depois que o cluster é implantado. Tal como acontece com o CIDR de serviço, este intervalo de IP não deve existir fora do cluster AKS, mas pode ser reutilizado com segurança entre clusters.O intervalo de endereços IP do pod é usado para atribuir um espaço de endereço /24 a cada nó do cluster. No exemplo a seguir, o de 192.168.0.0/16 atribui o primeiro nó 192.168.0.0/24, o segundo nó 192.168.1.0/24 e o
pod_cidrterceiro nó 192.168.2.0/24.À medida que o cluster é dimensionado ou atualizado, o Azure continua a atribuir um intervalo de endereços IP de pod a cada novo nó.
O manual é carregado
ssh_keya partir de~/.ssh/id_rsa.pub. Se você modificá-lo, use o formato de linha única - começando com "ssh-rsa" (sem as aspas).Os
client_idvalores eclient_secretsão carregados de , que é o arquivo de~/.azure/credentialscredenciais padrão. Você pode definir esses valores para sua entidade de serviço ou carregar esses valores de variáveis de ambiente:client_id: "{{ lookup('env', 'AZURE_CLIENT_ID') }}" client_secret: "{{ lookup('env', 'AZURE_SECRET') }}"
Associar os recursos da rede
Quando você cria um cluster AKS, um grupo de segurança de rede e uma tabela de rotas são criados. Esses recursos são gerenciados pelo AKS e atualizados quando você cria e expõe serviços. Associe o grupo de segurança de rede e a tabela de rotas à sua sub-rede de rede virtual da seguinte maneira.
Salve o seguinte manual 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 }}"
Aqui estão algumas notas-chave a considerar ao trabalhar com o manual de exemplo:
- O
node_resource_groupé o nome do grupo de recursos no qual os nós AKS são criados. - O
vnet_subnet_idé a sub-rede criada na seção anterior.
Execute o playbook de exemplo
Esta seção lista o exemplo completo de manual que chama as tarefas criadas neste artigo.
Guarde o manual de procedimentos seguinte 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]
vars Na seção , faça as seguintes alterações:
- Para a chave, altere o valor para o nome do
resource_groupaksansibletestgrupo de recursos. - Para a
namechave, altere o valor para oaksansibletestseu nome AKS. - Para a chave, altere o valor para o local do
Locationeastusgrupo de recursos.
Execute o playbook completo usando o ansible-playbook comando:
ansible-playbook aks-kubenet.yml
A execução do playbook mostra resultados semelhantes à seguinte saída:
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
Clean up resources (Limpar recursos)
Salve o código a seguir como
delete_rg.yml.--- - hosts: localhost tasks: - name: Deleting resource group - "{{ name }}" azure_rm_resourcegroup: name: "{{ name }}" state: absent register: rg - debug: var: rgExecute o playbook usando o comando ansible-playbook . Substitua o espaço reservado pelo nome do grupo de recursos a ser excluído. Todos os recursos dentro do grupo de recursos serão excluídos.
ansible-playbook delete_rg.yml --extra-vars "name=<resource_group>"Pontos principais:
- Devido à variável e
debugàregisterseção do playbook, os resultados são exibidos quando o comando é concluído.
- Devido à variável e
Próximos passos
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários