使用 Azure Resource Manager 模板在 Azure 上部署 Kubespray Kubernetes 集群基础设施【免费下载链接】kubesprayDeploy a Production Ready Kubernetes Cluster项目地址: https://gitcode.com/GitHub_Trending/ku/kubespray导读本文基于 Kubespray 仓库中的 contrib/azurerm 组件系统讲解如何借助 Azure Resource ManagerARM模板在 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 可用的 inventorygenerate-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提前铺路。前置条件开始之前需要准备以下环境安装 azure-cli需要 Azure 命令行工具来登录并执行资源操作使用 azure-cli 完成登录执行登录流程让 CLI 具备对目标订阅的操作权限创建独立的资源组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-vwfsdell-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: 1000number_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_sizeAzure 虚拟机规格默认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: trueadmin_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_keyssshKeyPath变量。模板生成机制从 Jinja2 到 ARM 模板apply-rg.sh的第一步是执行ansible-playbook generate-templates.yml它调用roles/generate-templates任务定义见 roles/generate-templates/tasks/main.yml。该角色会创建.generated/目录把 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 创建静态公网 IPkubernetes-api-pubipDNS 名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.vhdOS 盘按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先渲染生成全部模板再按「网络 → 存储 → 可用性集 → 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.0az命令执行generate-inventory_2.yml否则若存在 Azure CLI 1.0azure命令执行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然后将结果渲染为两个文件./inventoryKubespray 使用的 Ansible inventory./loadbalancer_vars.yml外部负载均衡器变量文件。inventory 的生成逻辑从 roles/generate-inventory_2/templates/inventory.j2 可以看到分组逻辑每个 VM 生成一行主机名 ansible_ssh_hostIP 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.comloadbalancer_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」路径安装并登录 azure-cli创建专用资源组修改 contrib/azurerm/group_vars/all 中的cluster_name、ssh_public_keys并按需调整节点数、VM 规格、网络 CIDR、use_bastion等参数执行./apply-rg.sh resource_group_name生成并应用全部 ARM 模板按 docs/ansible/ansible.md 安装 Ansible 与依赖执行./generate-inventory.sh resource_group_name生成 inventory 与负载均衡变量在 Kubespray 仓库根目录运行ansible-playbook ... cluster.yml安装 Kubernetes需要回收环境时执行./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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考