Kubeclipper – Tutorials

Docs: Operations and logs

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

1.6 Operations use the older task model and NATS. List operations, then copy the actual ID to inspect details and logs:

kcctl operation list
kcctl operation list -c demo
OPERATION_ID='<actual operation ID>'
kcctl operation describe "$OPERATION_ID"
kcctl operation logs "$OPERATION_ID"
kcctl operation logs "$OPERATION_ID" --follow
kcctl operation logs "$OPERATION_ID" --summary

Open the cluster-wide TUI in an interactive terminal:

kcctl operation logs --cluster demo

Preserve failed-step and node logs and resolve the cause before retrying. 1.6 only retries operations in failed status:

kcctl operation retry "$OPERATION_ID"

Use terminate for running operations, rather than the 1.7 cancel command:

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

A termination request does not roll back node changes. Inspect task, cluster, and node state before cleanup. Source: v1.6.0 Operation CLI.

Docs: Image registries

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

Registry resources describe Kubernetes image sources or containerd pull settings. Registering a registry does not copy images into it. Offline component packages are prepared separately.

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

This example uses an HTTP registry on a management network. Configure HTTPS, CA trust, and authentication for production. 1.6 also persists node and SSH configuration for kcctl registry; check existing configuration before subsequent operations.

During cluster creation, --image-registry internal selects the Kubernetes image source, and --cri-registry internal configures containerd pulls. Populate images first and verify node connectivity, certificates, and authentication. Source: v1.6.0 Registry CLI.

Docs: Diagnostics and upgrade checks

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

1.6 does not include the 1.7 kcctl status and kcctl doctor commands. Start with versions, API access, node services, and operation logs.

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

Inspect services according to each Linux node’s role. Diagnose NATS, platform etcd, and Server failures separately.

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 nodes may not run Server, etcd, or NATS. External NATS deployments have no local kc-nats service. Check actual roles and deployment configuration.

Before upgrading to 1.7

Back up platform etcd, configuration, certificates, authentication keys, and managed-cluster data. Rehearse the upgrade in a recoverable test environment, checking the NATS to Operation v2 transition, active tasks, and old operation records. Consult the 1.7 upgrade checklist and verify versions running across all components.

This page does not guarantee an in-place upgrade for every 1.6 deployment. Preserve errors and follow the recovery steps you rehearsed.