Kubeclipper – Getting started

Docs: All-in-One deployment

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

All-in-One runs the Server and Agent on the same Linux host for evaluation and testing.

Follow Getting started to prepare the host, install v1.7.0 kcctl, download the complete package, deploy the platform, and create a test cluster.

For production, plan separate Server and workload nodes and see high availability.

Docs: Offline clusters

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

Offline installation needs a platform deployment package and component resources for Kubernetes, the CRI, and the CNI. Registry resources describe image repositories; they do not replace offline packages.

Check resources

After deploying the platform, log in and inspect resources and nodes:

kcctl resource list
kcctl get node

Match package architecture to the target nodes. The 1.7 matrix uses Kubernetes v1.37.0 / v1.36.4 / v1.35.8, containerd 2.2.4, and Calico v3.31.5. See offline component packages when more resources are needed.

Create the cluster

kcctl create cluster defaults to offline installation. This example uses one test node:

kcctl create cluster --name offline-demo --master 192.168.10.21 --untaint-master \
 --k8s-version v1.37.0 --cri containerd --cri-version 2.2.4 \
 --cni calico --cni-version v3.31.5
kcctl operation list -c offline-demo
kcctl get cluster offline-demo -o yaml

In the Console wizard, select prepared component versions, target nodes, and offline installation. Populate any image repository and configure its Registry resource first. Select storage plugins according to actual requirements; a particular NFS plugin is not a mandatory cluster-creation step.

Confirm installation

Use Operations and node logs to locate failures. After obtaining kubeconfig, check Ready nodes, system Pods, and API readiness. Resolve missing resources, architecture mismatches, and unreachable image paths before retrying. See operations and logs.

Docs: Offline component packages

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

The full 1.7.0 deployment package installs the platform. Additional Kubernetes, CRI, and CNI packages provide cluster resources. Deploy the platform using Getting started first.

Choose versions and architecture

Use the 1.7 matrix. This Bash example prepares Kubernetes v1.37.0 for amd64. Prepare arm64 packages for arm64 nodes.

set -e
ARCH=amd64
VERSION=v1.37.0
PKG_DIR="$(mktemp -d)"
COMPONENT_DIR="k8s/${VERSION}/${ARCH}"
mkdir -p "${PKG_DIR}/${COMPONENT_DIR}"
for FILE in manifest.json configs.tar.gz images.tar.gz; do
 curl -fL -o "${PKG_DIR}/${COMPONENT_DIR}/${FILE}" \
 "https://kubeclipper.oss-ap-southeast-1.aliyuncs.com/packages/${COMPONENT_DIR}/${FILE}"
done
tar -czf "k8s-${VERSION}-${ARCH}.tar.gz" -C "$PKG_DIR" k8s
tar -tzf "k8s-${VERSION}-${ARCH}.tar.gz"

Preserve the k8s/version/architecture/ hierarchy. Keep certificate and HTTP verification enabled. The download directory remains at $PKG_DIR for inspection and subsequent cleanup.

Other components use the same hierarchy. Archive the component directory with the following files:

Directory	Version	Required files	Upload type
k8s	v1.37.0	manifest.json, configs.tar.gz, images.tar.gz	k8s
containerd	2.2.4	manifest.json, configs.tar.gz	cri
calico	v3.31.5	manifest.json, images.tar.gz, charts.tgz	cni

For example, Calico uses packages/calico/v3.31.5/amd64/manifest.json. Packaging existing resources does not imply support for arbitrary custom versions.

Upload in the offline environment

Transfer the archive to a deployment machine that can reach the platform and has the deployment configuration and Server SSH credentials.

kcctl resource push --pkg k8s-v1.37.0-amd64.tar.gz --type k8s
kcctl resource list

Use --type cri for containerd and --type cni for Calico. Confirm the versions and architecture in the resource list before creating an offline cluster. See Registry configuration for image registry settings.