KubeClipper – 文档

Docs: 操作与日志

Mon, 01 Jan 0001 00:00:00 +0000

1.6 的 Operation 通过旧版任务模型和 NATS 执行。查询当前操作，复制实际 ID 查看详情和日志：

kcctl operation list
kcctl operation list -c demo
OPERATION_ID='<实际操作 ID>'
kcctl operation describe "$OPERATION_ID"
kcctl operation logs "$OPERATION_ID"
kcctl operation logs "$OPERATION_ID" --follow
kcctl operation logs "$OPERATION_ID" --summary

在交互式终端中，按集群进入 TUI：

kcctl operation logs --cluster demo

保留失败节点和步骤的日志，处理原因后再重试。1.6 的 retry 只接受 failed 状态：

kcctl operation retry "$OPERATION_ID"

终止 running 状态的操作使用 terminate，不是 1.7 的 cancel：

kcctl operation terminate "$OPERATION_ID"
kcctl operation describe "$OPERATION_ID"

终止请求不代表节点变更已回滚。检查任务、集群和实际节点状态后再清理。命令来源：v1.6.0 Operation CLI。

Docs: 镜像仓库

Mon, 01 Jan 0001 00:00:00 +0000

Registry 资源描述 Kubernetes 镜像源或 containerd 拉取配置。注册仓库不会自动复制镜像，离线组件包也需独立准备。

kcctl create registry --name internal --host registry.example.com:5000 --scheme http
kcctl get registry
kcctl create registry -h
kcctl registry -h

上例是管理网络中的 HTTP 仓库；生产环境按实际仓库配置 HTTPS、CA 和认证。1.6 还支持持久化 kcctl registry 的节点和 SSH 配置，后续操作前核对已有配置。

创建集群时，--image-registry internal 选择 Kubernetes 镜像源，--cri-registry internal 配置 containerd 镜像拉取。先准备镜像，再检查节点到仓库的连通性、证书和认证。参数来源：v1.6.0 Registry CLI。

Docs: 诊断与升级检查

Mon, 01 Jan 0001 00:00:00 +0000

1.6 不包含 1.7 的 kcctl status 和 kcctl doctor。从版本、API、节点服务和任务日志开始排查。

kcctl version
kcctl get node
kcctl get cluster
kcctl operation list
kcctl resource list

在 Linux 节点按实际角色检查 systemd 服务，保留错误日志。NATS、平台 etcd 和 Server 的故障需要分别定位。

sudo systemctl status kc-server kc-agent kc-etcd kc-nats --no-pager
sudo journalctl -u kc-server -n 100 --no-pager
sudo journalctl -u kc-agent -n 100 --no-pager
sudo journalctl -u kc-nats -n 100 --no-pager

Agent 节点不一定部署 Server、etcd 或 NATS，使用外部 NATS 时也不会有本地 kc-nats 服务。核对实际角色及部署配置。

升级到 1.7 前

备份平台 etcd、配置、证书、认证密钥及受管集群数据。在可恢复的测试环境验证升级路径，重点核对 NATS 到 Operation v2 的差异、运行中任务及旧操作记录。查看1.7 升级检查，并确认实际运行的全部组件版本。

本页不承诺所有 1.6 部署都可直接原地升级。失败时先保留日志并按演练过的恢复步骤处理。