使用 Azure Resource Manager 模板在 Azure 上部署 Kubespray Kubernetes 集群基础设施

使用 Azure Resource Manager 模板在 Azure 上部署 Kubespray Kubernetes 集群基础设施

【免费下载链接】kubesprayDeploy a Production Ready Kubernetes Cluster项目地址: https://gitcode.com/GitHub_Trending/ku/kubespray

导读

本文基于 Kubespray 仓库中的 contrib/azurerm 组件，系统讲解如何借助 Azure Resource Manager（ARM）模板在 Azure 上预置一套生产可用的 Kubernetes 基础网络与计算设施（VNet、子网、NIC、公网 IP、负载均衡器、虚拟机、存储与可用性集），并衔接 Kubespray 完成集群安装。通过阅读本文，你将掌握 azurerm 组件所需的 azure-cli 前置条件、group_vars/all关键配置项的语义、模板的生成与幂等应用流程、资源组的清空回收方法，以及由 Azure 资源自动生成 kubespray inventory 与负载均衡器变量文件的完整实操路径。

组件定位与工作边界

contrib/azurerm是 Kubespray 仓库中面向 Microsoft Azure 的基础设施预置方案。其核心思路是：只负责把集群运行所需的底层 Azure 资源创建出来，不负责安装 Kubernetes。这一点在官方 README 中有明确说明——它只预置 vnet、vms、nics、ips 等基础设施，Kubernetes 本身的安装要由后续步骤通过 Kubespray 完成。

整个组件由以下几部分构成：

• apply-rg.sh：生成并应用全部 ARM 模板的入口脚本；
• clear-rg.sh：以 Complete 模式重新部署清理模板，删除资源组内全部资源；
• generate-inventory.sh：调用 Ansible 生成 Kubespray 可用的 inventory；
• generate-templates.yml/generate-inventory.yml/generate-inventory_2.yml：三个本地 Ansible playbook 入口；
• group_vars/all：所有可调参数的集中配置文件；
• roles/generate-templates：负责把 Jinja2 模板渲染为最终的 JSON 部署模板；
• roles/generate-inventory/roles/generate-inventory_2：负责查询 Azure 并渲染 inventory 与负载均衡变量。

从文件布局（contrib/azurerm）可以看出，该方案以「模板生成 → 模板应用 → 数据查询 → inventory 生成」四步闭环完成从零到可安装的状态，这与仓库内 contrib/terraform 等其它基础设施方案的定位一致，都是为 Kubespray 主安装流程（cluster.yml）提前铺路。

前置条件

开始之前需要准备以下环境：

1. 安装 azure-cli：需要 Azure 命令行工具来登录并执行资源操作；
2. 使用 azure-cli 完成登录：执行登录流程让 CLI 具备对目标订阅的操作权限；
3. 创建独立的资源组（Resource Group）：可以在 Azure Portal 中创建，也可以通过 azure-cli 创建，后续所有模板都部署到这个专用资源组中。

注意：执行模板应用与清理脚本时，资源组名称会作为唯一参数传入，因此建议将资源组与集群配置一一对应，便于后续的部署与回收管理。

核心配置：group_vars/all

所有可调参数集中在 contrib/azurerm/group_vars/all 中。README 强调至少需要修改两个变量，其余多数变量对有一定 Kubernetes 经验的使用者来说语义自明。

必改变量

• cluster_name：由于 Azure 存在全局唯一性限制（例如存储账户名必须全局唯一），该名称会被用作 Azure 组件的前缀，因此必须保证全局唯一。例如默认值example仅作演示。
• ssh_public_keys：必须替换为你自己的 SSH 公钥，否则无法登录 Azure 虚拟机。配置文件中该字段是一个列表，支持传入多个公钥。

cluster_name: example # MAKE SURE TO CHANGE THIS TO YOUR PUBLIC KEY to access your azure machines ssh_public_keys: - "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ...your-public-key ablock-vwfs@dell-lappy"

集群规模与规格

number_of_k8s_masters: 3 number_of_k8s_nodes: 3 masters_vm_size: Standard_A2 masters_os_disk_size: 1000 minions_vm_size: Standard_A2 minions_os_disk_size: 1000

• number_of_k8s_masters/number_of_k8s_nodes：控制 master 与 node 的数量。注意它们同时驱动模板中的 Jinja2 循环（例如 masters.json 中{% for i in range(number_of_k8s_masters) %}），修改后需要重新生成并应用模板。
• masters_vm_size/minions_vm_size：Azure 虚拟机规格，默认Standard_A2。
• masters_os_disk_size/minions_os_disk_size：系统盘大小（单位 GB）。

登录凭据与认证方式

admin_username: devops admin_password: changeme # Disable using ssh using password. Change it to false to allow to connect to ssh by password disablePasswordAuthentication: true

• admin_username/admin_password：虚拟机的管理员账号与密码，部署前务必修改默认密码。
• disablePasswordAuthentication：默认true表示禁止密码登录、只允许密钥认证。若需密码登录可改为false。该值会原样渲染进模板的linuxConfiguration.disablePasswordAuthentication字段。

Azure 网络规划

# Azure CIDRs azure_vnet_cidr: 10.0.0.0/8 azure_admin_cidr: 10.241.2.0/24 azure_masters_cidr: 10.0.4.0/24 azure_minions_cidr: 10.240.0.0/16 # Azure loadbalancer port to use to access your cluster kube_apiserver_port: 6443

四个 CIDR 分别定义虚拟网络、管理子网、master 子网与 minion 子网的地址范围，需要根据实际网络规划调整，避免与本地办公网络冲突。

kube_apiserver_port是访问集群的 apiserver 端口，默认 6443。它同时被渲染进 masters.json 中的负载均衡规则（frontendPort/backendPort）与健康探测（probe.port）。

Bastion 主机

# Set this to true if you do not want to have public IPs for your masters and minions. This will provision a bastion # node that can be used to access the masters and minions use_bastion: false # Set this to a preferred name that will be used as the first part of the dns name for your bastion host. # bastion_domain_prefix: k8s-bastion

将use_bastion设为true后，生成模板会额外包含一台 bastion 虚拟机（默认规格Standard_A0，见 roles/generate-templates/defaults/main.yml），同时移除其它所有 VM 的公网 IP，访问 master 与 node 都必须经由 bastion 跳转。bastion_domain_prefix用于设置 bastion 的 DNS 名前缀，便于在防火墙中为固定域名放行 SSH，例如k8s-bastion.<区域>.cloudapp.azure.com。

可选命名与存储配置

# Azure Netwoking and storage naming to use with inventory/all.yml #azure_virtual_network_name: KubeVNET #azure_subnet_admin_name: ad-subnet #azure_subnet_masters_name: master-subnet #azure_subnet_minions_name: minion-subnet #azure_route_table_name: routetable #azure_security_group_name: secgroup # Storage types available are: "Standard_LRS","Premium_LRS" #azure_storage_account_type: Standard_LRS

这些被注释掉的变量用于自定义 Azure 资源命名与存储类型，取消注释即可生效。从 roles/generate-templates/defaults/main.yml 可以看到它们均有默认值：

• 虚拟网络默认KubeVNET，三个子网默认ad-subnet/master-subnet/minion-subnet；
• 路由表默认routetable，安全组默认secgroup；
• 存储账户名由sa{{ nameSuffix | replace('-', '') }}推导而来（即sa+ 去掉连字符后的cluster_name），存储类型默认Standard_LRS，可选Premium_LRS。

模板中的镜像与可用性配置

同样在 roles/generate-templates/defaults/main.yml 中还有一组由模板层固定的配置：

apiVersion: "2015-06-15" imageReference: publisher: "OpenLogic" offer: "CentOS" sku: "7.5" version: "latest" availabilitySetMasters: "master-avs" availabilitySetMinions: "minion-avs" faultDomainCount: 3 updateDomainCount: 10

虚拟机默认使用 OpenLogic CentOS 7.5 镜像；master 与 minion 分属两个可用性集，故障域 3、更新域 10，为控制面与数据面提供基本的可用性保障。SSH 公钥被写入/home/{{ admin_username }}/.ssh/authorized_keys（sshKeyPath变量）。

模板生成机制：从 Jinja2 到 ARM 模板

apply-rg.sh的第一步是执行ansible-playbook generate-templates.yml，它调用roles/generate-templates（任务定义见 roles/generate-templates/tasks/main.yml）。该角色会：

1. 创建.generated/目录；
2. 把 roles/generate-templates/templates 下的 7 个 Jinja2 模板（network.json、storage.json、availability-sets.json、bastion.json、masters.json、minions.json、clear-rg.json）渲染为同名的 JSON 文件写入.generated/。

也就是说，group_vars/all中的变量通过 Jinja2 渲染进入最终 ARM 模板。以masters.json为例，渲染后：

• 为 API Server 创建静态公网 IP（kubernetes-api-pubip，DNS 名<cluster_name>-api）与负载均衡器kubernetes-api，规则将kube_apiserver_port同时作为前端与后端端口，并附带 TCP 健康探测（间隔 5 秒、失败 2 次）；
• 为每个 master 创建 NIC 与虚拟机，NIC 挂载到负载均衡后端池，并启用 IP 转发（enableIPForwarding: true）；
• 虚拟机通过tags.roles（如kube_control_plane,etcd）标记角色，这一标签正是后续生成 inventory 时划分主机组的依据；
• 虚拟机的 VHD 指向存储账户（http://<storageAccountName>.blob.core.windows.net/vhds/master-<i>.vhd），OS 盘按masters_os_disk_size设置大小。

minions.json采用同样的结构为 node 组生成资源；network.json/storage.json/availability-sets.json分别负责 VNet 与子网、存储账户、可用性集；bastion.json在use_bastion: true时生成跳板机；clear-rg.json则专门用于资源清理（见下文）。

生成并应用模板：apply-rg.sh

配置好group_vars/all之后，即可执行：

./apply-rg.sh <resource_group_name>

脚本内容（apply-rg.sh）会依次完成以下工作：

ansible-playbook generate-templates.yml az deployment group create --template-file ./.generated/network.json -g $AZURE_RESOURCE_GROUP az deployment group create --template-file ./.generated/storage.json -g $AZURE_RESOURCE_GROUP az deployment group create --template-file ./.generated/availability-sets.json -g $AZURE_RESOURCE_GROUP az deployment group create --template-file ./.generated/bastion.json -g $AZURE_RESOURCE_GROUP az deployment group create --template-file ./.generated/masters.json -g $AZURE_RESOURCE_GROUP az deployment group create --template-file ./.generated/minions.json -g $AZURE_RESOURCE_GROUP

1. 先渲染生成全部模板；
2. 再按「网络 → 存储 → 可用性集 → bastion → masters → minions」的依赖顺序，把每个模板作为一次资源组部署提交给 Azure。

其中set -e保证任一步失败即终止。幂等性是该方案的关键特性：如果之后修改了配置（例如增加节点数量），再次运行./apply-rg.sh即可，Azure 会自行创建或修改需要的资源，无需手动删除重建。

清理资源组：clear-rg.sh

需要删除资源组内所有资源时执行：

./clear-rg.sh <resource_group_name>

脚本（clear-rg.sh）先重新生成模板，然后以Complete 部署模式部署清理模板：

az group deployment create -g "$AZURE_RESOURCE_GROUP" --template-file ./.generated/clear-rg.json --mode Complete

--mode Complete意味着模板中没有声明的资源都会被删除，因此该命令会删除资源组中的一切资源，包括你后来手动创建的内容。README 对此给出了明确警告，使用前务必确认该资源组下没有其它需要保留的数据。

安装 Ansible 与依赖

Kubespray 的安装过程依赖 Ansible。请参照仓库内的 Ansible 安装指南 docs/ansible/ansible.md 完成安装，其中包含了针对 Kubespray 的版本与依赖要求说明。安装完成后，即可在仓库根目录使用 Kubespray 的各类 playbook。

生成 Kubespray inventory

模板应用成功后，即可生成 inventory：

./generate-inventory.sh <resource_group_name>

脚本（generate-inventory.sh）会根据环境自动选择 CLI 版本：

• 若存在 Azure CLI 2.0（az命令），执行generate-inventory_2.yml；
• 否则若存在 Azure CLI 1.0（azure命令），执行generate-inventory.yml；
• 两者都找不到则提示Azure cli not found。

以 2.0 版本对应的 playbook generate-inventory_2.yml（角色任务见 roles/generate-inventory_2/tasks/main.yml）为例，它依次执行：

az vm list-ip-addresses -o json --resource-group <资源组> az vm list -o json --resource-group <资源组> az network public-ip show -o json -g <资源组> -n kubernetes-api-pubip

分别查询 VM 的 IP、VM 的角色标签，以及负载均衡器的公网 IP，然后将结果渲染为两个文件：

• ./inventory：Kubespray 使用的 Ansible inventory；
• ./loadbalancer_vars.yml：外部负载均衡器变量文件。

inventory 的生成逻辑

从 roles/generate-inventory_2/templates/inventory.j2 可以看到分组逻辑：

• 每个 VM 生成一行主机名 ansible_ssh_host=<IP> ip=<私网IP>：未启用 bastion 时ansible_ssh_host使用公网 IP；启用 bastion 后只有 bastion 自身使用公网 IP，其余主机使用私网 IP；
• 依据模板部署时写入的tags.roles标签，将主机分别归入[kube_control_plane]、[etcd]、[kube_node]三个组；
• [k8s_cluster:children]由kube_node与kube_control_plane组成，符合 Kubespray 默认的 inventory 结构。

负载均衡器变量的生成逻辑

roles/generate-inventory_2/templates/loadbalancer_vars.j2 生成的变量把 Azure 负载均衡器对接为 Kubespray 的外部负载均衡：

## External LB example config apiserver_loadbalancer_domain_name: <lb_pubip.dnsSettings.fqdn> loadbalancer_apiserver: address: <lb_pubip.ipAddress> port: 6443 ## Internal loadbalancers for apiservers loadbalancer_apiserver_localhost: false

其中apiserver_loadbalancer_domain_name取自负载均衡器公网 IP 的 DNS FQDN（即<cluster_name>-api.<区域>.cloudapp.azure.com），loadbalancer_apiserver.address取自其公网 IP，端口与kube_apiserver_port一致（默认 6443）。

用 Kubespray 安装集群

生成 inventory 后，即可在 Kubespray 仓库根目录使用标准流程安装集群：

cd kubespray-root-dir ansible-playbook -i contrib/azurerm/inventory -u devops --become -e "@inventory/sample/group_vars/all/all.yml" cluster.yml

命令说明：

• -i contrib/azurerm/inventory：指定刚才生成的 inventory 文件；
• -u devops：以admin_username配置的用户名登录；
• --become：需要提权执行安装任务；
• -e "@inventory/sample/group_vars/all/all.yml"：加载 Kubespray 的全局默认变量；
• 集群安装入口是根目录的 cluster.yml，而contrib/azurerm生成的基础设施正好满足其中对主机、网络与角色的假设。

若启用了 bastion，记得结合 roles/bastion-ssh-config 配置 SSH 跳转；若集群规模较大或需要自定义 apiserver 负载均衡，可将生成的loadbalancer_vars.yml合并进 playbook 变量（例如通过-e "@contrib/azurerm/loadbalancer_vars.yml"），让 Kubespray 直接使用 Azure 负载均衡器作为集群访问入口。

典型操作流程回顾

总结一条完整的「Azure 上跑通 Kubespray」路径：

1. 安装并登录 azure-cli，创建专用资源组；
2. 修改 contrib/azurerm/group_vars/all 中的cluster_name、ssh_public_keys，并按需调整节点数、VM 规格、网络 CIDR、use_bastion等参数；
3. 执行./apply-rg.sh <resource_group_name>生成并应用全部 ARM 模板；
4. 按 docs/ansible/ansible.md 安装 Ansible 与依赖；
5. 执行./generate-inventory.sh <resource_group_name>生成 inventory 与负载均衡变量；
6. 在 Kubespray 仓库根目录运行ansible-playbook ... cluster.yml安装 Kubernetes；
7. 需要回收环境时执行./clear-rg.sh <resource_group_name>（注意该命令会删除资源组内全部资源）。

这套「ARM 模板 + Kubespray」的协作模式，把云上基础设施的声明式管理与 Kubernetes 集群的自动化安装解耦：基础设施的变更（扩缩容、调规格）通过重跑apply-rg.sh幂等完成，集群安装与升级则交给 Kubespray 的 cluster.yml、upgrade_cluster.yml 等 playbook，两个环节互不干扰、可独立演进。

【免费下载链接】kubesprayDeploy a Production Ready Kubernetes Cluster项目地址: https://gitcode.com/GitHub_Trending/ku/kubespray