资讯动态

使用 Terraform 在 Exoscale 上部署 Kubespray 生产级 Kubernetes 集群

发布时间:2026/9/13 4:01:10 来源:尧图企业网站定制
使用 Terraform 在 Exoscale 上部署 Kubespray 生产级 Kubernetes 集群【免费下载链接】kubesprayDeploy a Production Ready Kubernetes Cluster项目地址: https://gitcode.com/GitHub_Trending/ku/kubespray导读本文讲解 Kubespray 仓库中contrib/terraform/exoscale目录提供的完整基础设施即代码IaC方案通过 Terraform 在 Exoscale 云平台上一次性创建包含私有网络、安全组、弹性 IP 负载均衡器与 master/worker 节点的 Kubernetes 集群底座并自动生成可直接交付给 Kubespray 的 Ansible 动态清单inventory.ini。读完本文你将掌握从复制示例配置、配置云凭证含 sops 加密、执行terraform apply到运行ansible-playbook cluster.yml完成集群初始化的完整实战链路并深入理解单磁盘分区Rook / node-local-storage与无云控制器Cloud Controller Manager架构下的负载均衡和 Ingress 部署约束。一、方案总览与架构拓扑该方案由 contrib/terraform/exoscale/main.tf 作为顶层入口它仅负责声明 Exoscale Provider、调用modules/kubernetes-cluster子模块并通过null_resource将渲染后的 Ansible 清单写入本地文件。整体部署拓扑如下Kubernetes cluster ----------------------- --------------- | -------------- | | | | | -------------- | | API server LB --------- | | | | | | | | | Master/etcd | | --------------- | | | node(s) | | | - | | | -------------- | | ^ | | | | | v | --------------- | -------------- | | | | | -------------- | | Ingress LB --------- | | | | | | | | | Worker | | --------------- | - | | | -------------- | -----------------------从 modules/kubernetes-cluster/main.tf 的实现可以看出该拓扑由以下几类资源构成两台弹性 IPElastic IP充当负载均衡器exoscale_elastic_ip.control_plane_lb面向 Kubernetes API ServerTCP 健康检查端口 6443exoscale_elastic_ip.ingress_controller_lb面向 Ingress 流量HTTP 健康检查路径/healthz端口 80私有网络exoscale_private_network.private_network为全部节点提供内网互通CIDR 默认为172.0.10.0/24见 modules/kubernetes-cluster/variables.tfmaster 节点与 worker 节点按machines变量中node_type字段拆分为两组exoscale_compute_instance分别绑定 master 安全组和 worker 安全组安全组规则master 组放行 SSH(22) 与 K8s API(6443)worker 组放行 SSH(22)、HTTP/HTTPS(80/443对所有来源开放) 以及 Kubernetes NodePort 区间30000–32767。二、环境要求Terraform 0.13.0 或更新版本。若你仍在使用 Terraform 0.12可以修改 provider 块显式声明 provider 版本并删除所有versions.tf文件后使用。一个 Exoscale 账号及其 API 凭证API Key / API Secret。一个可用的 SSH 公钥用于注入到所有实例上。可选若需要使用加密凭证还需要安装 sops。仓库通过 contrib/terraform/exoscale/versions.tf 锁定了 provider 依赖Exoscale provider 要求 0.21source 为exoscale/exoscale并依赖hashicorp/null与hashicorp/template两个 providerrequired_version为 0.13。三、快速上手Quickstart以下命令假设你位于 kubespray 仓库根目录。1. 复制示例清单与默认变量CLUSTERmy-exoscale-cluster cp -r inventory/sample inventory/$CLUSTER cp contrib/terraform/exoscale/default.tfvars inventory/$CLUSTER/ cd inventory/$CLUSTER仓库预置了可用的示例清单 inventory/sample/inventory.ini而 contrib/terraform/exoscale/default.tfvars 提供了完整的变量示例默认区域ch-gva-2、1 台 master-0 与 3 台 worker 节点。2. 编辑集群变量# Ensure $EDITOR points to your favorite editor, e.g., vim, emacs, VS Code, etc. $EDITOR default.tfvars最低要求至少修改ssh_public_keys把示例中的占位公钥替换为你自己的真实公钥。示例文件中ssh-rsa I-did-not-read-the-docs之类的占位值不会真正可用。3. 配置云凭证认证可以使用位于~/.cloudstack.ini或当前目录./cloudstack.ini的凭证文件Exoscale 的 API 兼容 CloudStack 凭证格式[cloudstack] key API key secret API secretAPI Key 的生成方式参见 Exoscale IAM 快速入门文档。Terraform 在运行时会自动读取该文件完成认证。4.可选使用 sops 加密凭证为了让凭证在磁盘上静态加密、仅运行时解密可以结合 sops 使用cat EOF cloudstack.ini [cloudstack] key secret EOF sops --encrypt --in-place --pgp PGP key fingerprint cloudstack.ini sops cloudstack.inisops cloudstack.ini会打开编辑器让你在解密视图下填入真实的 key 与 secret保存后文件以加密形式落盘。5. 初始化并创建基础设施terraform init ../../contrib/terraform/exoscale terraform apply -var-file default.tfvars ../../contrib/terraform/exoscale若凭证文件已用 sops 加密则用sops exec-file在运行时动态解密把解密后的文件路径注入CLOUDSTACK_CONFIG环境变量后再执行 applyterraform init ../../contrib/terraform/exoscale sops exec-file -no-fifo cloudstack.ini CLOUDSTACK_CONFIG{} terraform apply -var-file default.tfvars ../../contrib/terraform/exoscaleapply 成功后会在当前目录生成名为inventory.ini的清单文件。该文件由 contrib/terraform/exoscale/templates/inventory.tpl 模板渲染生成其中master 节点写入[all]、[kube_control_plane]与[etcd]组并设置supplementary_addresses_in_ssl_keys [ API LB IP ]确保 kubeadm 签发的 API Server 证书 SAN 中包含负载均衡器地址worker 节点写入[all]与[kube_node]组[k8s_cluster:children]聚合kube_control_plane与kube_node每台节点都带有ansible_userubuntu ansible_host公网IP ip私网IP等连接参数etcd 节点额外带有etcd_member_name。主清单生成后可通过terraform output查看各节点的公网/私网 IP、control_plane_lb_ip_address与ingress_controller_lb_ip_address对应 contrib/terraform/exoscale/output.tf 中定义的输出项。6. 验证 SSH 连通性并部署集群建议先用 ping 检查节点 SSH 连通性ansible -i inventory.ini -m ping all连通性确认后即可基于该清单直接使用 Kubespray 主 playbook 完成集群部署-b以 root 提权-v输出详细日志ansible-playbook -i inventory.ini ../../cluster.yml -b -v../../cluster.yml即仓库根目录下的 cluster.yml它将依次执行 etcd、Kubernetes 控制面、worker 节点及集群附加组件等全部角色。四、拆除集群Teardown由于该方案未使用云负载均衡/持久化磁盘等会导致遗留资源的外部服务Kubernetes 集群自身也不会主动创建 Exoscale 负载均衡器或磁盘因此拆除只需执行 Terraform destroyterraform destroy -var-file default.tfvars ../../contrib/terraform/exoscale五、变量说明必填变量变量说明ssh_public_keys注入到所有实例的公钥列表list(string)zone集群所在区域machines待创建的机器映射key 即机器名每项含node_typemaster或worker、size、boot_disk三个子字段ssh_whitelist允许 SSH 连接到节点的 IP 范围CIDR列表api_server_whitelist允许访问 API Server6443 端口的 IP 范围CIDR列表nodeport_whitelist允许访问 Kubernetes NodePort30000–32767的 IP 范围CIDR列表machines中boot_disk的完整子字段image_name操作系统镜像名称例如Linux Ubuntu 20.04 LTS 64-bitmodules/kubernetes-cluster/main.tf 会通过exoscale_template数据源按名称在指定 zone 中查找对应模板root_partition_size根分区大小GBceph_partition_size供 Rook 用作 Ceph 存储的分区大小GB设为0表示禁用node_local_partition_size供 node-local-storage 使用的分区大小GB设为0表示禁用。从 contrib/terraform/exoscale/variables.tf 的类型定义可以看出ssh_public_keys、ssh_whitelist、api_server_whitelist、nodeport_whitelist均为list(string)machines为map(object({...}))其中boot_disk的四个分区字段均为number。可选变量变量说明prefix所有资源名称的前缀同一项目下多个集群必须保持唯一默认defaultinventory_file生成的 Ansible 清单文件路径默认inventory.iniprivate_network_cidr集群私有网络网段模块内默认172.0.10.0/24完整的可参考示例见 contrib/terraform/exoscale/default.tfvars其中inventory_file inventory.ini、zone ch-gva-2并定义了一主三从的节点组master-0使用standard.medium三个worker-*使用standard.large全部基于 Ubuntu 20.04 镜像、根分区 50GB且默认关闭 Rook 与 node-local-storage 分区。三个白名单在示例中均为0.0.0.0/0即对公网开放生产环境请务必收窄。六、已知限制与应对方案1. 单磁盘限制Only single diskExoscale 不支持为实例挂载额外的数据盘因此该方案在创建实例时把所有分区大小根分区 Rook 分区 node-local 分区合并计算为实例的总disk_size再由 cloud-init 在首启时完成分区。这一逻辑在 modules/kubernetes-cluster/templates/cloud-init.tmpl 中实现当ceph_partition_size或node_local_partition_size大于 0 时首先用sgdisk --move-second-header移动 GPT 备份头为后续分区腾出空间node_local_partition_size 0时用parted创建扩展分区并用mkfs.ext4格式化为/dev/vda2随后在runcmd中挂载到/mnt/disks/node-local-storage并设置nobody:nogroup属主以便 Kubernetes local PV 使用ceph_partition_size 0时再在剩余空间上创建供 Rook 使用的分区。因此Rook 与 node-local-storage 的容量需求都以“分区”而非“独立磁盘”的形式满足。2. 无 Kubernetes APINo Kubernetes API当前方案没有启用 Exoscale Kubernetes 云控制器exoscale-cloud-controller-manager意味着集群内的LoadBalancer类型 Service 不会自动在 Exoscale 创建云负载均衡器必须自行在所有 worker 节点前架设一台 HTTP(S) 负载均衡器即拓扑图中的 Ingress LB把外部流量分发到各 workerIngress 控制器需设置为DaemonSet 模式保证每个 worker 节点上都运行一个 Ingress Pod从而让负载均衡器将请求均匀转发到任意节点。Cloud-init 模板中还包含一个值得注意的细节/etc/netplan/20-eip-fix.yaml当 worker 被判定为健康并被加入 EIP 负载均衡池后它无法通过 EIP 地址回发自身流量因此在 worker 的 loopback 接口lo:0上绑定了 EIP 的/32地址来规避该问题。源码注释中注明这是临时方案若 Exoscale 侧解决该行为可移除。七、源码级实现梳理顶层入口 contrib/terraform/exoscale/main.tf声明 provider、调用子模块、渲染并落盘inventory.ini变量定义 contrib/terraform/exoscale/variables.tf 与 provider 约束 contrib/terraform/exoscale/versions.tf输出定义 contrib/terraform/exoscale/output.tf暴露 master/worker IP 与两个负载均衡器地址核心资源 modules/kubernetes-cluster/main.tf私有网络、计算实例、安全组、弹性 IP 与健康检查清单模板 templates/inventory.tpl生成 Kubespray 可识别的 Ansible 动态清单初始化脚本 templates/cloud-init.tmpl注入 SSH 公钥、配置网卡netplan并完成 Rook / node-local 分区示例变量 contrib/terraform/exoscale/default.tfvars可直接复制后修改使用的完整参考配置。整体流程可以概括为terraform apply创建基础架构并生成清单 →ansible -i inventory.ini -m ping all验证连通 →ansible-playbook -i inventory.ini cluster.yml -b -v完成 Kubernetes 部署 → 需要时以terraform destroy一键回收全部资源。【免费下载链接】kubesprayDeploy a Production Ready Kubernetes Cluster项目地址: https://gitcode.com/GitHub_Trending/ku/kubespray创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价