Zelfstudie: Kubenet-netwerken configureren in Azure Kubernetes Service (AKS) met ansible
Belangrijk
Ansible 2.8 (of hoger) is vereist om de voorbeeldplaybooks in dit artikel uit te voeren.
Met Azure Kubernetes Service (AKS) kunt u eenvoudig een beheerd Kubernetes-cluster implementeren in Azure. AKS verkleint de complexiteit en de operationele overhead die gepaard gaan met het beheer van Kubernetes door veel van deze taken naar Azure over te hevelen. Azure handelt als een gehoste Kubernetes-service cruciale taken voor u af zoals statuscontrole en onderhoud. De Kubernetes-modellen worden beheerd door Azure. U beheert en onderhoudt alleen de agentknooppunten. Als beheerde Kubernetes-service is AKS gratis. U betaalt alleen voor de agentknooppunten binnen uw clusters; niet voor de masters.
Met AKS kunt u een cluster implementeren met behulp van de volgende netwerkmodellen:
- Kubenet-netwerken : netwerkresources worden doorgaans gemaakt en geconfigureerd als het AKS-cluster wordt geïmplementeerd.
- CNI-netwerken (Azure Container Networking Interface): AKS-cluster is verbonden met bestaande virtuele netwerkresources en -configuraties.
Zie Netwerkconcepten voor toepassingen in AKS voor meer informatie over netwerken met uw toepassingen in AKS.
In dit artikel leert u het volgende:
- Een AKS-cluster maken
- Azure Kubenet-netwerken configureren
Vereisten
- Azure-abonnement: als u nog geen abonnement op Azure hebt, maakt u een gratis Azure-account aan voordat u begint.
- Azure-service-principal: maak een service-principal, noteer de volgende waarden: appId, displayName, wachtwoord en tenant.
Ansible installeren: Voer een van de volgende opties uit:
- Ansible installeren en configureren op een virtuele Linux-machine
- Configureer Azure Cloud Shell en maak een virtuele machine met Ansible als u geen toegang hebt tot een virtuele Linux-machine.
Een virtueel netwerk en een subnet maken
Met de playbookcode in deze sectie worden de volgende Azure-resources gemaakt:
- Virtueel netwerk
- Subnet binnen het virtuele netwerk
Sla het volgende playbook op als 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
Een AKS-cluster maken in het virtuele netwerk
Met de playbookcode in deze sectie maakt u een AKS-cluster in een virtueel netwerk.
Sla het volgende playbook op als 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
Hier volgen enkele belangrijke opmerkingen die u moet overwegen bij het werken met het voorbeeldplaybook:
Gebruik
azure_rm_aks_versionde module om de ondersteunde versie te vinden.Dit
vnet_subnet_idis het subnet dat in de vorige sectie is gemaakt.Hiermee
network_profiledefinieert u de eigenschappen voor de kubenet-netwerkinvoegtoepassing.Deze
service_cidrwordt gebruikt om interne services in het AKS-cluster toe te wijzen aan een IP-adres. Dit IP-adresbereik moet een adresruimte zijn die niet buiten de AKS-clusters wordt gebruikt. U kunt dezelfde service-CIDR echter opnieuw gebruiken voor meerdere AKS-clusters.Het
dns_service_ipadres moet het adres '.10' van het IP-adresbereik van uw service zijn.De
pod_cidrnaam moet een grote adresruimte zijn die niet elders in uw netwerkomgeving wordt gebruikt. Het adresbereik moet groot genoeg zijn om tegemoet te komen aan het aantal knooppunten dat u verwacht op te schalen. U kunt dit adresbereik niet wijzigen zodra het cluster is geïmplementeerd. Net als bij de service-CIDR mag dit IP-bereik niet bestaan buiten het AKS-cluster, maar kan het veilig worden hergebruikt in clusters.Het IP-adresbereik van de pod wordt gebruikt om een /24-adresruimte toe te wijzen aan elk knooppunt in het cluster. In het volgende voorbeeld
pod_cidrwijst 192.168.0.0/16 het eerste knooppunt 192.168.0.0/24, het tweede knooppunt 192.168.1.0/24 en het derde knooppunt 192.168.2.0/24 toe.Naarmate het cluster wordt geschaald of bijgewerkt, blijft Azure een IP-adresbereik voor pods toewijzen aan elk nieuw knooppunt.
Het playbook wordt geladen
ssh_keyvan~/.ssh/id_rsa.pub. Als u deze wijzigt, gebruikt u de indeling met één regel, te beginnen met 'ssh-rsa' (zonder de aanhalingstekens).De
client_idwaarden enclient_secretwaarden worden geladen van~/.azure/credentials, wat het standaardreferentiebestand is. U kunt deze waarden instellen op uw service-principal of deze waarden laden vanuit omgevingsvariabelen:client_id: "{{ lookup('env', 'AZURE_CLIENT_ID') }}" client_secret: "{{ lookup('env', 'AZURE_SECRET') }}"
De netwerkbronnen koppelen
Wanneer u een AKS-cluster maakt, worden er een netwerkbeveiligingsgroep en routetabel gemaakt. Deze resources worden beheerd door AKS en bijgewerkt wanneer u services maakt en beschikbaar maakt. Koppel de netwerkbeveiligingsgroep en routetabel als volgt aan het subnet van het virtuele netwerk.
Sla het volgende playbook op als 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 }}"
Hier volgen enkele belangrijke opmerkingen die u moet overwegen bij het werken met het voorbeeldplaybook:
- Dit
node_resource_groupis de naam van de resourcegroep waarin de AKS-knooppunten worden gemaakt. - Dit
vnet_subnet_idis het subnet dat in de vorige sectie is gemaakt.
Het voorbeeldplaybook uitvoeren
In deze sectie wordt het volledige voorbeeldplaybook weergegeven dat de taken aanroept die in dit artikel worden gemaakt.
Sla het volgende playbook op als 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]
Breng in de vars sectie de volgende wijzigingen aan:
- Wijzig voor de
resource_groupsleutel de waarde in deaksansibletestnaam van de resourcegroep. - Wijzig voor de
namesleutel de waarde in uwaksansibletestAKS-naam. - Wijzig voor de
Locationsleutel de waarde in deeastuslocatie van de resourcegroep.
Voer het volledige playbook uit met behulp van de ansible-playbook opdracht:
ansible-playbook aks-kubenet.yml
Als u het playbook uitvoert, ziet u resultaten die vergelijkbaar zijn met de volgende uitvoer:
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
Resources opschonen
Sla de volgende code op als
delete_rg.yml.--- - hosts: localhost tasks: - name: Deleting resource group - "{{ name }}" azure_rm_resourcegroup: name: "{{ name }}" state: absent register: rg - debug: var: rgVoer het playbook uit met behulp van de ansible-playbook-opdracht . Vervang de tijdelijke aanduiding door de naam van de resourcegroep die u wilt verwijderen. Alle resources in de resourcegroep worden verwijderd.
ansible-playbook delete_rg.yml --extra-vars "name=<resource_group>"Belangrijkste punten:
- Vanwege de
registervariabele endebugsectie van het playbook worden de resultaten weergegeven wanneer de opdracht is voltooid.
- Vanwege de