1 - 高可用部署
本文部署 KubeClipper 平台的高可用控制面。平台 Server 的高可用与受管 Kubernetes 集群的高可用是两件事,需分别规划。
准备节点与网络
准备三个 Linux Server 节点,以及需要纳管的 Agent 节点。部署用户通过同一 SSH 私钥访问所有节点,并具备 sudo 权限。时间同步和端口要求见架构与网络。
Server 节点部署平台 etcd,节点数量和故障容忍按 etcd 仲裁要求规划。生产环境建议将平台 Server 与运行 Kubernetes 工作负载的节点分开。
安装和下载
按照快速开始安装 v1.7.0 kcctl,下载与目标架构匹配的完整 kc-amd64.tar.gz 或 kc-arm64.tar.gz 部署包。不要将 GitHub Release 的客户端二进制包传给 --pkg。
部署三个 Server 和 Agent
将示例 IP、私钥和部署包路径替换为实际值。--server 使用逗号分隔地址,--agent 可按区域填写。
read -r -s -p '设置 admin 密码: ' KC_ADMIN_PASSWORD
printf '\n'
kcctl deploy \
--server 192.168.10.11,192.168.10.12,192.168.10.13 \
--agent default:192.168.10.21,192.168.10.22 \
--user root --pk-file "$HOME/.ssh/id_rsa" \
--pkg "$PWD/kc-amd64.tar.gz" \
--initial-password "$KC_ADMIN_PASSWORD"
unset KC_ADMIN_PASSWORD
保持 TLS 开启。多网卡环境通过 --ip-detect 与 --node-ip-detect 显式选择可达地址;可使用 kcctl deploy -h 核对参数。默认平台 etcd 端口为 12379、12380、12381。
验证结果
kcctl login --host https://192.168.10.11:8080 --username admin
kcctl status
kcctl doctor
kcctl get node
检查三个 Server 的服务状态、平台 etcd 成员和 Agent 是否正常。在其他 Server 地址重复检查 API 可达性。需要统一域名或 VIP 时,另行配置入口负载均衡和证书;部署三个 Server 不会自动创建入口 VIP。
浏览器默认访问各 Server 的 HTTP 80 控制台入口;CLI 使用 HTTPS 8080 API。生产入口应配置 HTTPS,并按实际网络限制管理端口访问。
添加和移除 Agent
kcctl join --agent default:192.168.10.23
kcctl get node
确认节点没有需要保留的集群和工作负载后,再执行移除:
kcctl drain --agent 192.168.10.23
先查看正常 drain 的错误原因,再决定后续处理;不要默认使用强制参数。升级前参见升级检查。
2 - 升级检查
平台升级与受管 Kubernetes 集群升级分别处理。本文介绍 KubeClipper 平台升级前后的检查,不承诺任意旧版本都可直接升级到 1.7。
升级前
- 记录 Server、Agent、kcctl 和 Console 的版本及节点拓扑,确认目标包的 CPU 架构。
- 查看目标版本的 Release、安全公告和配置变化。1.7 改用 Operation v2,旧操作记录和任务状态需要在测试环境核对。
- 在没有运行中安装、升级、备份等操作的窗口执行。先处理未完成或失败的操作。
- 备份平台 etcd、Server/Agent 配置、证书与持久化认证密钥,并验证恢复方法。受管集群的数据备份需要单独安排。
- 在可恢复的测试环境演练目标升级路径,记录服务中断和恢复步骤。
kcctl version
kcctl status
kcctl doctor
kcctl operation list
kcctl upgrade -h
执行升级
kcctl upgrade 支持整个平台或组件升级。目标包应满足命令帮助中的目录结构,并已经在测试环境验证;不要把客户端包当成平台升级包。
UPGRADE_PACKAGE=/path/to/validated-upgrade-package.tar.gz
kcctl upgrade all --pkg "$UPGRADE_PACKAGE"
只有 Release 或已验证部署流程明确支持时,才使用在线升级或组件独立替换。不要把替换一个二进制文件视为整个升级完成。
升级后
再次检查 kcctl status、kcctl doctor,核对各节点实际运行版本。验证登录、节点信息、操作详情与日志、受管集群访问及 Console 基本流程。测试一个受控的生命周期操作,确认 Operation 和实际集群状态一致。
升级失败时保留错误和日志,按事先验证的恢复步骤处理。恢复旧二进制前先判断数据和配置是否仍兼容,不要在未知状态下反复覆盖服务。