国产 K8s 部署与管理平台运维指令手册

覆盖范围：KubeKey / KubeOperator / kubeasz（部署器）、Kuboard v4 / Rainbond v6（管理与 PaaS）、DaoCloud DCE / 灵雀云 ACP / KubeCube / Karmada 等概览 底座：Kubernetes 1.26 ~ 1.37、containerd 1.7/2.x、Docker 24~29 宿主系统：Ubuntu 20.04/22.04/24.04、Debian 11/12、CentOS 7/8、RHEL 8/9、Rocky/Alma、openEuler、麒麟 V10、统信 UOS 约定：# root 或 sudo，$ 普通用户，<xxx> 为占位符，kubectl 简写 k（仅说明用，命令一律写全）。 边界说明：KubeKey 的完整用法在 KubeSphere 分册，本文只讲它独立使用时的差异；Sealos 见独立分册。 更新时间：2026-11（版本事实核对至 2026-11-05）

目录

1. 全景与选型
2. 部署前通用前置
3. KubeKey（独立使用）
4. KubeOperator
5. kubeasz
6. Kuboard v4
7. Rainbond v6
8. 其他国产平台概览
9. 纳管已有集群
10. 离线交付共性问题
11. 升级、迁移与跨工具切换
12. 卸载通用清单
13. 故障速查
14. 安全基线与危险红线
15. 附录

1. 全景与选型

1.1 三类工具，别混着比

常见误区：把 Kuboard 当"安装 K8s 的工具"（它需要先有集群），或把 KubeKey 当"长期运维平台"（部署完就用不上了）。先定类别，再选产品。

1.2 选型对照

风险提示：开源项目的维护状态会变。选型时务必看最近 6 个月的 release / commit 与 issue 响应，尤其是要上生产的部署器——一个停更的部署器会让你卡在某个 K8s 版本上，安全补丁跟不上。

1.3 先判断手上这套是什么

# 部署器痕迹
ls -la /root/.kubekey/ /etc/kubeasz/ /usr/local/bin/kk /usr/local/bin/ezctl 2>/dev/null
systemctl list-units --all | grep -iE 'kubeoperator|kuboard|rainbond'
docker ps --format '{{.Names}} {{.Image}}' | grep -iE 'kuboard|rainbond|kubeoperator'

# 集群是否标准 kubeadm 产物
ls /etc/kubernetes/manifests/
kubeadm certs check-expiration 2>/dev/null

# 管理平台的命名空间
kubectl get ns | grep -iE 'kuboard|rainbond|kubesphere|kube-operator'

2. 部署前通用前置

无论用哪个部署器，下面这些是所有节点都要过的：

# 1) 主机名唯一、DNS/hosts 可达
hostnamectl set-hostname k8s-master-01
cat >> /etc/hosts <<'EOF'
10.0.0.11 k8s-master-01
10.0.0.12 k8s-master-02
10.0.0.21 k8s-worker-01
EOF

# 2) 时间同步
timedatectl set-timezone Asia/Shanghai
systemctl enable --now chronyd 2>/dev/null || systemctl enable --now systemd-timesyncd
chronyc sources 2>/dev/null || timedatectl

# 3) 关闭 swap
swapoff -a
sed -ri 's/^([^#].*swap.*)$/#\1/' /etc/fstab

# 4) 内核模块与参数（二进制部署尤其要手工做）
cat > /etc/modules-load.d/k8s.conf <<'EOF'
overlay
br_netfilter
ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_sh
nf_conntrack
EOF
modprobe overlay br_netfilter

cat > /etc/sysctl.d/k8s.conf <<'EOF'
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF
sysctl --system

# 5) 依赖
yum install -y socat conntrack ebtables ipset ipvsadm \
               curl wget tar device-mapper-persistent-data lvm2    # RHEL 系
apt install -y socat conntrack ebtables ipset ipvsadm curl wget tar # Debian 系

# 6) cgroup 版本（K8s 1.35+ 对 v1 默认失败）
stat -fc %T /sys/fs/cgroup/        # cgroup2fs = v2，tmpfs = v1

# 7) 端口不冲突
ss -tunlp | grep -E ':6443|:2379|:2380|:10250|:10257|:10259'

# 8) 无旧集群残留
ls -la /etc/kubernetes /var/lib/etcd /etc/cni/net.d 2>/dev/null

坑：网段冲突是内网部署第一大坑。部署前把 podSubnet（默认常见 10.244.0.0/16、100.64.0.0/17、10.233.64.0/18）和 serviceSubnet 与内网、VPN、办公网、已有集群逐一比对；改成 100.64.0.0/10 段的一部分通常最安全。

3. KubeKey（独立使用）

KubeKey 的完整安装、配置、HA、离线 artifact 见 KubeSphere 常用运维指令手册第 3、6 章。本节只讲"不用 KubeSphere，只拿 kk 装 K8s"时的要点。

3.1 独立部署

export KKZONE=cn
curl -sfL https://get-kk.kubesphere.io | sh -
chmod +x kk
./kk version
./kk create config --with-kubernetes v1.30.6
vi config-sample.yaml             # 只填 hosts / roleGroups / network / kubernetes
./kk create cluster -f config-sample.yaml

别加 --with-kubesphere：那是 v3 时代让 KubeKey 顺手装 KubeSphere 的参数，只装 K8s 时不需要；在 v4 场景用了反而会装出不需要的组件。

3.2 常用操作

./kk add nodes -f config-sample.yaml
./kk delete node <node> -f config-sample.yaml
./kk upgrade --with-kubernetes v1.31.x -f config-sample.yaml
./kk create manifest --with-kubernetes v1.30.6        # 生成离线清单
./kk artifact export -m manifest-sample.yaml -o k8s-artifact.tar.gz
./kk create cluster -f config-sample.yaml --with-packages
./kk delete cluster -f config-sample.yaml

3.3 addons 机制

spec:
  addons:
  - name: nfs-client
    namespace: kube-system
    sources:
      chart:
        name: nfs-client-provisioner
        repo: https://charts.helm.sh/stable
        values:
        - storageClass.defaultClass=true
  - name: custom-yaml
    sources:
      yaml:
        path: [/data/myapp.yaml]

addons 在集群创建后由 KubeKey 应用。离线环境里 addon 的 chart/yaml 也要提前放到本地路径，否则 kk create cluster 最后一步卡住。

3.4 与 kubeadm 产物的关系

KubeKey 生成的集群本质仍是 kubeadm 集群（部分版本走自研二进制分发），/etc/kubernetes/manifests/、kubeadm certs、kubectl、crictl 都能用。节点变更优先用 kk add/delete，别直接 kubeadm join，否则配置文件与实际拓扑会漂移。

4. KubeOperator

4.1 定位

飞致云开源的 Kubernetes 集群生命周期管理平台：通过 Web UI 完成「机器 → 规划 → 部署 → 扩缩容 → 升级 → 备份 → 销毁」，底层用 Ansible 下发，支持 VMware / OpenStack / 公有云 IaaS 与裸机，提供离线安装包。适合需要"集群台账 + 审批流 + 重复交付"的传统企业。

维护状态提示：KubeOperator 的项目活跃度与飞致云产品线重心（近年明显偏向 1Panel / MaxKB 等）相关，上生产前以官方 GitHub 最近 release 与 issue 响应为准，并确认它支持你需要的 K8s 版本。若只支持到较旧的 K8s，不建议用于新建生产集群。

4.2 安装（典型形态）

# 在线安装（以官方发布脚本为准）
curl -sSL https://github.com/KubeOperator/KubeOperator/releases/latest/download/install.sh | bash
# 或离线包上传后执行
tar zxf kubeoperator-offline-<ver>.tar.gz && cd kubeoperator-offline && bash install.sh

安装后一般会启动一组容器（Web、API、Ansible 执行器、内置数据库/注册表）：

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Ports}}'
ss -tunlp | grep -E ':80 |:8080|:443 '
docker compose -f <安装目录>/docker-compose.yml logs -f

4.3 运维要点

# 排障常用
docker compose -f <安装目录>/docker-compose.yml ps
docker compose -f <安装目录>/docker-compose.yml logs --tail=200 <service>
ssh root@<目标节点> 'journalctl -u kubelet -n 100 --no-pager'

坑：KubeOperator 部署失败最常见的根因不是产品 bug，而是目标主机的 SSH 凭据/权限/sudo 配置、离线包镜像没导全、时间不同步。先在部署器容器里手工 ssh 一次目标机，再点部署。

4.4 卸载

cd <安装目录>
docker compose down            # 不要加 -v，除非确认集群元数据不需要
# 卸载目标节点上的 K8s 走 UI 的"销毁集群"，或按第 12 章通用清单清理

5. kubeasz

5.1 定位

基于 Ansible + 二进制 的 K8s 部署项目（easysz 生态），所有组件以二进制 + systemd 方式落地，配置全部可见，适合想彻底掌控每个组件参数、做等保加固、适配信创环境的团队。代价是上手门槛最高。

5.2 目录与命令

# 部署机
ls /etc/kubeasz/
# clusters/<集群名>/hosts     主机清单
# clusters/<集群名>/config.yml  集群参数（CNI、网段、版本、运行时…）
# roles/                     ansible roles
# playbooks/                 各阶段 playbook
# bin/                       二进制与容器镜像缓存
# ezctl / ezdown             主命令 / 离线下载工具

ezdown -D                    # 下载离线资源（镜像、二进制）到 bin/
ezctl new <cluster>          # 生成新集群配置目录
ezctl checkout <cluster>     # 切换当前集群
ezctl setup <cluster> all    # 一键部署
ezctl setup <cluster> 01     # 分阶段：01 创建证书 & 系统初始化
ezctl setup <cluster> 02     # 02 部署 etcd
ezctl setup <cluster> 03     # 03 部署容器运行时
ezctl setup <cluster> 04     # 04 部署 master
ezctl setup <cluster> 05     # 05 部署 node
ezctl setup <cluster> 06     # 06 部署网络插件
ezctl setup <cluster> 07     # 07 部署集群插件（coredns、metrics-server…）
ezctl add-node <cluster> <ip>
ezctl del-node <cluster> <ip>
ezctl add-master <cluster> <ip>
ezctl upgrade <cluster>
ezctl destroy <cluster>
ezctl backup <cluster>       # etcd 备份
ezctl restore <cluster>

5.3 关键配置

# /etc/kubeasz/clusters/<cluster>/config.yml（节选）
CLUSTER_NAME: "cluster1"
K8S_VER: "1.30.6"
CONTAINER_RUNTIME: "containerd"
CLUSTER_CIDR: "100.64.0.0/17"
SERVICE_CIDR: "10.96.0.0/18"
CLUSTER_DNS_DOMAIN: "cluster.local"
PROXY_MODE: "ipvs"          # ★ 见下方提示
CNI: "calico"
ETCD_DATA_DIR: "/var/lib/etcd"
BIN_DIR: "/opt/kube/bin"
CA_EXPIRY: "876000h"
CERT_EXPIRY: "438000h"

# /etc/kubeasz/clusters/<cluster>/hosts（节选）
[etcd]
10.0.0.11 NODE_NAME=etcd1
10.0.0.12 NODE_NAME=etcd2
10.0.0.13 NODE_NAME=etcd3
[kube_master]
10.0.0.11 K8S_MASTER_NAME=master1
[kube_node]
10.0.0.21 K8S_NODE_NAME=node1
[harbor]
[ex_lb]
[chrony]

版本提示：PROXY_MODE: "ipvs" 在老版本 kubeasz 里是常见默认，但 kube-proxy 的 ipvs 模式已被上游弃用。新集群建议用 iptables/nftables 或换成 eBPF 方案（Cilium），并在配置里显式确认，别照抄旧模板。

5.4 运维要点

# 逐阶段部署便于定位（生产推荐分阶段而非 all）
ezctl setup <cluster> 01 && ezctl setup <cluster> 02 && ...

# 服务是 systemd 单元，不是静态 Pod（与 kubeadm 的区别）
systemctl status etcd kube-apiserver kube-controller-manager kube-scheduler kubelet containerd
journalctl -u kube-apiserver -f

# 证书
ls -la /etc/kubernetes/ssl/
openssl x509 -in /etc/kubernetes/ssl/ca.pem -noout -dates

因为是二进制 + systemd，kubeadm certs 这类命令不适用，证书轮换要走 kubeasz 自己的流程或手工签发。CERT_EXPIRY 可设长一些（如上例 50 年），但仍要纳管到期监控。

5.5 卸载

ezctl destroy <cluster>
# 再按第 12 章通用清单清残留

6. Kuboard v4

6.1 定位与架构

Kuboard 是国内使用很广的 Kubernetes 多集群管理控制台。v4 与 v3 是完全不同的产品：

v4 把集群对象缓存在自己的数据库里，所以"控制台显示的状态"与"集群真实状态"可能有秒级~分钟级差异。v4.3.x 修了一系列缓存同步（大集群分页截断、增量同步 410 循环、watch 连接不关闭等）问题。排障以 kubectl 为准，控制台只作辅助。

6.2 安装（官方 docker run 基线）

先建库（以 MySQL 为例）：

CREATE DATABASE kuboard DEFAULT CHARACTER SET = 'utf8mb4' DEFAULT COLLATE = 'utf8mb4_unicode_ci';
CREATE USER 'kuboard'@'%' IDENTIFIED BY '<强密码>';
GRANT ALL PRIVILEGES ON kuboard.* TO 'kuboard'@'%';
FLUSH PRIVILEGES;

坑：v4.3.3.0 起数据库字符集非 utf8mb4 会直接拒绝启动并给出修复提示。建库时就写死 utf8mb4，别用默认 latin1/utf8mb3。

docker run -d \
  --restart=unless-stopped \
  --name=kuboard \
  -p 80:80/tcp \
  -e TZ="Asia/Shanghai" \
  -e DB_DRIVER=com.mysql.cj.jdbc.Driver \
  -e DB_URL="jdbc:mysql://10.0.0.8:3306/kuboard?serverTimezone=Asia/Shanghai" \
  -e DB_USERNAME=kuboard \
  -e DB_PASSWORD='<强密码>' \
  -v /data/kuboard-log:/app/logs \
  swr.cn-east-2.myhuaweicloud.com/kuboard/kuboard:v4
# 备选镜像：eipwork/kuboard:v4

其他数据库驱动：

openGauss 建库：

CREATE DATABASE kuboard OWNER=kuboard ENCODING='UTF8' DBCOMPATIBILITY='PG';
\c kuboard
CREATE SCHEMA kuboard AUTHORIZATION kuboard;

docker logs -f kuboard | tail -100
curl -I http://127.0.0.1/login
# 默认账号 admin / Kuboard123 —— 首次登录立刻改

DB_URL 里不要写 localhost（指容器自己），要写数据库实际可达 IP。这是 v4 部署失败第一名。

6.3 反向代理与 HTTPS（生产必配）

location / {
    proxy_pass http://<kuboard>:80;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_read_timeout 3600s;
}

官方明确两条：Kuboard 必须挂在根路径（https://kuboard.example.com/，不支持 /kuboard/ 子路径），且终端/日志依赖 WebSocket Upgrade。v4.3.3.0 专门加了"反向代理诊断页"，用来定位"终端/日志打不开"。

6.4 HA

v4 支持多副本 + 负载均衡，实例间通过 Redis 分布式缓存共享状态。要点：

• 多副本共享同一个外部数据库。
• Redis 6+ 支持 ACL 用户（v4.3.4.0 起），可给 Kuboard 单独账号。
• 多副本首次启动曾有过 schema 脚本并发执行的 bug（v4.3.4.0 已修），老版本建议先起 1 副本再扩。
• 反代要开会话保持或依赖共享缓存。

6.5 v4.3.x 运维相关能力（2026-10 ~ 11）

# 版本确认
docker inspect kuboard --format '{{.Config.Image}}'
curl -s http://127.0.0.1/actuator/info 2>/dev/null | head   # 以实际暴露端点为准

安全提醒：v4 引入了 MCP（AI 变更计划）。v4.3.4.0 之前存在"MCP 资源目录未按用户裁剪，跨租户泄露"的问题，已修复。生产上仍应把 AI/MCP 入口限制到专用账号、开启审计、把变更计划审批设为人工。

6.6 纳管集群

1. 控制台「添加集群」→ 填 kubeconfig 或 ServiceAccount Token。
2. 按最小权限创建专用 SA（见第 9 章）。
3. 导入后看「集群管理 → 同步状态 / 缓存状态」，等全量同步跑完再用全局搜索。
4. 大集群（数千对象）首次全量同步可能较慢，老版本曾有分页截断导致缓存为空的 bug，建议直接上 v4.3.4.0+。

6.7 备份与恢复

# 1) 控制台「系统设置 → 配置导出/导入」：角色、用户、授权、系统配置、集群等
# 2) 数据库冷备（命令行兜底，更可靠）
mysqldump -h<db> -ukuboard -p'<pwd>' --single-transaction kuboard | gzip > /root/kuboard-$(date +%F).sql.gz
pg_dump -h <db> -U kuboard -n kuboard -Fc > /root/kuboard-$(date +%F).dump

# 3) 日志与镜像 tag
docker inspect kuboard --format '{{.Config.Image}}' > /root/kuboard-image.txt
tar czf /root/kuboard-log-$(date +%F).tgz /data/kuboard-log

6.8 升级

v4.x 内部升级只需换镜像 tag（官方明确说明）：

docker pull swr.cn-east-2.myhuaweicloud.com/kuboard/kuboard:v4
docker stop kuboard && docker rm kuboard
# 用完全相同的 -e 参数重新 docker run（建议先写成 compose 或脚本）

坑：docker rm 之前把启动参数完整存档（尤其 DB_URL、密码、卷路径）。建议一开始就用 docker-compose.yml 或 Ansible 管理，别靠一条历史命令。

6.9 卸载

docker stop kuboard && docker rm kuboard
# 数据库按需保留或删除（★ 先导出配置备份）
# mysql -e "DROP DATABASE kuboard;"   ← 危险，确认后执行
rm -rf /data/kuboard-log

7. Rainbond v6

7.1 定位

Rainbond 是云原生应用管理平台（PaaS）：把源码 / 镜像 / Helm 包变成可运行应用，屏蔽 K8s 细节，提供服务编排、微服务治理、应用模板交付。v6 起基于标准 K8s 部署，不再自带封闭集群。

v6.9.0（2026-06）重点：

7.2 部署形态

# 生产前置检查
kubectl get nodes -o wide
kubectl get sc                  # 必须有可用默认 StorageClass
kubectl get ingressclass        # 网关/Ingress 控制器
helm version --short

# 安装（以官方当前文档为准，命令形态示意）
helm repo add rainbond https://chart.rainbond.com
helm repo update
helm install rainbond rainbond/rainbond-cluster \
  -n rbd-system --create-namespace -f values.yaml

坑：Rainbond 是"平台中的平台"，会装一整套组件（控制台、API、构建、网关、监控、数据库、镜像仓库…）。别把它塞进一个资源紧张的小集群，也别和已有的 Ingress Controller 抢 80/443。先规划命名空间、StorageClass、网关端口、资源配额。

7.3 运维排查

kubectl get pods -n rbd-system -o wide
kubectl get pods -n rbd-system | grep -v Running
kubectl -n rbd-system get deploy,sts,ds,svc,ing
kubectl -n rbd-system logs deploy/rbd-api --tail=200
kubectl -n rbd-system get events --sort-by=.lastTimestamp | tail -30
kubectl get pvc -A | grep -v Bound

# 组件健康（不同版本组件名有差异，以实际为准）
kubectl -n rbd-system get pod -l name=rbd-api
kubectl -n rbd-system get pod -l name=rainbond-console

应用起不来时按这条链走：应用构建日志 → 组件 Pod 事件 → PVC 是否绑定 → 网关路由 → 端口/域名。先看 kubectl describe pod，再看平台日志，平台 UI 的错误信息往往被包装过。

7.4 AI 模型实例运维（v6.9+）

# 模型实例本质是带 GPU 资源请求的 Deployment/StatefulSet
kubectl get pods -n <模型所在团队命名空间> -o wide
kubectl describe pod <model-pod> | grep -A5 -i 'nvidia.com/gpu'
kubectl logs -f <model-pod> --tail=100
nvidia-smi                       # 节点侧看 GPU 占用
kubectl top nodes

注意：vLLM 实例首次拉模型权重可能几分钟到几十分钟，且需要足够磁盘（模型缓存 PVC）。就绪探针超时设太短会导致反复重启。

7.5 升级与备份

# 升级前
helm -n rbd-system get values rainbond > /root/rbd-values-$(date +%F).yaml
kubectl get pvc -n rbd-system
# 导出应用模板 / 数据库备份 / 镜像仓库数据
helm -n rbd-system upgrade rainbond rainbond/rainbond-cluster -f /root/rbd-values-*.yaml

平台自带的"应用模板交付"是很好的逻辑备份手段，但模板不含业务数据。数据库、对象存储、镜像仓库必须单独备份。

7.6 卸载

helm -n rbd-system uninstall rainbond
kubectl delete ns rbd-system --ignore-not-found
# 团队命名空间 / CRD / PVC 需逐一确认后再删
kubectl get crd | grep -i rainbond
kubectl get pvc -A | grep rbd-

8. 其他国产平台概览

商业平台的部分：不要试图用开源社区的通用命令去"修"厂商交付的组件，升级与配置走厂商 SOP，否则可能失去支持。把它们纳入统一的监控、备份、权限审计体系即可。

9. 纳管已有集群

Kuboard / KubeOperator / KubeSphere 都能"导入已有集群"。共同要点：

9.1 最小权限 SA（推荐，别用 admin kubeconfig）

kubectl create ns platform-mgmt
kubectl create sa cluster-reader -n platform-mgmt
cat <<'EOF' | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: platform-viewer
rules:
- apiGroups: ["", "apps", "batch", "networking.k8s.io", "storage.k8s.io", "metrics.k8s.io"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: platform-viewer
roleRef: {apiGroup: rbac.authorization.k8s.io, kind: ClusterRole, name: platform-viewer}
subjects:
- {kind: ServiceAccount, name: cluster-reader, namespace: platform-mgmt}
EOF

# 取长期 token（K8s 1.24+ 不再自动创建 secret）
kubectl -n platform-mgmt create token cluster-reader --duration=8760h

需要平台执行写操作（部署应用、终端、重启）时，再按功能追加 create/update/patch/delete 与 pods/exec、pods/log 权限。别一上来给 cluster-admin，控制台一旦被攻破就是全集群失守。

9.2 连通性检查

# 从平台所在容器/节点测 apiserver
curl -k https://<apiserver>:6443/version
kubectl --server=https://<apiserver>:6443 --token=<token> --insecure-skip-tls-verify get ns
# 时间同步（证书校验）
timedatectl
# WebSocket 通路（终端/日志功能）

9.3 常见失败

10. 离线交付共性问题

不管用哪个工具，内网交付都要备齐这六类：

# 交付前在内网 Registry 上逐项验证
crictl pull <内网仓库>/<镜像>:<tag>
curl -I --connect-timeout 5 https://<内网仓库>/v2/
# 所有节点信任 CA
cp ca.crt /usr/local/share/ca-certificates/ && update-ca-certificates
mkdir -p /etc/containerd/certs.d/<内网仓库>

坑：只同步"部署器要用的镜像"，不同步"部署完之后平台要跑的镜像"，是离线交付最典型的返工原因。判据很简单：在完全断网的测试机上从零跑一遍全流程，能跑通才算交付完成。

11. 升级、迁移与跨工具切换

11.1 升级顺序

部署器 / 平台自身（小版本）
   → K8s（一次一个 minor，先测试集群）
   → CNI / CSI
   → 平台组件（兼容矩阵）
   → 业务应用

跨平台没有通用升级命令。KubeKey 用 kk upgrade，kubeasz 用 ezctl upgrade，KubeOperator 在 UI 里，Kuboard 换镜像 tag，Rainbond 走 Helm。

11.2 跨工具切换的现实

铁律：换管理平台可以"热切"（业务 Pod 不动）；换部署器基本都要"重建"。把这两类变更分开排期，别放进同一个维护窗口。

11.3 迁移检查清单

• 目标集群版本与业务用到的 API 版本兼容（kubectl api-resources / pluto 类工具查废弃 API）
• 全部 Helm release、Ingress、PVC、ConfigMap、Secret、CRD 清单
• 数据库与对象存储的数据备份已验证可恢复
• 证书、域名、白名单、监控告警规则迁移
• DNS TTL 提前调低，回滚窗口 ≥ 72 小时

12. 卸载通用清单

12.1 卸载"平台"（保留集群与业务）

# 确认删的是平台命名空间，不是业务命名空间
kubectl get ns
helm list -A
helm -n <平台ns> uninstall <release>
kubectl delete ns <平台ns> --ignore-not-found
kubectl get crd | grep -i <平台> | awk '{print $1}' | xargs -r kubectl delete crd
docker stop kuboard 2>/dev/null && docker rm kuboard 2>/dev/null   # Kuboard 独立容器

12.2 卸载"集群"（所有节点）

# 优先用原部署器的 destroy/reset
kk delete cluster -f config-sample.yaml
ezctl destroy <cluster>
sealos reset
# kubeadm 兜底
kubeadm reset -f

# 通用残留清理（逐项确认）
systemctl stop kubelet containerd etcd kube-apiserver kube-controller-manager kube-scheduler kube-proxy 2>/dev/null
rm -rf /etc/kubernetes /var/lib/etcd /var/lib/kubelet /root/.kube \
       /etc/cni/net.d /opt/cni/bin /var/lib/cni /etc/containerd/certs.d
for i in cni0 flannel.1 flannel-vxlan cali* tunl0 vxlan.calico kube-ipvs0 dummy0; do
  ip link del "$i" 2>/dev/null || true
done
iptables -F; iptables -t nat -F; iptables -X
ipvsadm --clear 2>/dev/null || true
systemctl daemon-reload

坑：kubeadm reset / sealos reset 不清 CNI 网桥和 iptables 规则。同 IP 重建集群时，旧的 cni0/flannel.1/cali*、残留的 Pod 网段路由会造成"节点 Ready 但 Pod 不通"。重建前必须按上面清单逐项验证为空。

12.3 残留验证

systemctl list-units --all | grep -iE 'kube|etcd|containerd'
ps -ef | grep -E 'kube-|etcd|containerd' | grep -v grep
ip link show | grep -E 'cni|flannel|cali|kube-ipvs'
iptables -L -n | grep -iE 'KUBE|CNI|cali'
ls -la /etc/kubernetes /var/lib/etcd /etc/cni/net.d 2>/dev/null
ss -tunlp | grep -E ':6443|:10250|:2379'

13. 故障速查

13.1 三分钟定位脚本

kubectl get nodes -o wide
kubectl get pods -A --field-selector=status.phase!=Running | grep -v Completed
kubectl get events -A --sort-by=.lastTimestamp | tail -20
kubectl get sc; kubectl get pvc -A | grep -v Bound
journalctl -u kubelet --since '10 min ago' --no-pager | grep -iE 'error|fail' | tail -20
crictl ps -a | head
docker ps --format '{{.Names}} {{.Status}}' | grep -iE 'kuboard|rainbond|operator'

14. 安全基线与危险红线

14.1 基线

• 管理平台不暴露公网，走 VPN / 堡垒机 / 反代 + SSO（OIDC/LDAP）
• 默认口令全改：Kuboard admin/Kuboard123、KubeSphere admin/P@88w0rd 等
• 纳管集群使用最小权限 SA，不用 cluster-admin kubeconfig
• 数据库（Kuboard 等）独立账号、utf8mb4、定期备份、不暴露公网
• 平台自身镜像来自可信仓库；内网 Harbor 启用 TLS 与最小权限
• 操作审计与命令历史保留 ≥ 180 天
• AI/MCP 能力（Kuboard v4.3.4+、KubeSphere Copilot）限账号、人工审批、留痕
• K8s 版本与部署器支持矩阵对齐，定期打安全补丁
• 离线交付包校验值入交付单，防止供应链篡改

14.2 危险红线

15. 附录

15.1 命令对照速查

15.2 版本与默认端口速查

15.3 与其他手册的配合

维护建议：国产开源项目的版本号、维护活跃度、命令细节变化快，本文的版本事实核对至 2026-11-05。落地时把「部署器版本 + K8s 版本 + 各组件 tag + 集群配置 + 离线包校验值」写进集群交付单；任何工具切换都先在测试环境从零跑通全流程再动生产。