1.6 平台的操作、镜像仓库和维护。
1 - 操作与日志
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。
2 - 镜像仓库
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。
3 - 诊断与升级检查
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 部署都可直接原地升级。失败时先保留日志并按演练过的恢复步骤处理。