这是 kubesphere/kubekey 的 fork，在官方版本基础上打了私有补丁，并附带一键同步工具。下方为补丁说明与使用方法，官方原始 README 内容见 本节之后。

本仓库当前维护十一个私有补丁：

例如 harbor.example.com:7000/library/nginx:latest。

官方 bug：normalizeImageName 用 govalidator.IsHost() 判断首段是否为 registry 域名，但该函数对含 :（端口）的字符串返回 false，导致 harbor.example.com:7000 被误判为 project 名，被错误补上 docker.io/ 前缀，最终报错：

failed to parse reference "docker.io/harbor.example.com:7000/library/nginx:latest":
invalid reference: invalid tag "7000/library/nginx:latest"

修复方式（pkg/modules/image/image.go）：

- if govalidator.IsHost(firstPart) {
+ if strings.ContainsAny(firstPart, ".:") || firstPart == "localhost" {

首段含 .（域名）或 :（端口）或等于 localhost 即视为 registry host，与 oras registry.ParseReference 的判定规则一致。

官方 bug：kk create cluster 部署的 etcd 定时备份脚本（backup_etcd.sh，由 systemd timer 每 30 分钟触发）从集群创建第一天起就全部失败，从未产出过一份可用快照。两个叠加 bug：

1. 变量名写错：脚本定义的是 ETCD_ENDPOINTS，但 etcdctl snapshot save 那行引用的是 $ENDPOINTS（未定义）。配合 set -o nounset，每次必然报 ENDPOINTS: unbound variable。
2. 多端点不支持：即使修好变量名，etcdctl snapshot save 也只接受单个 endpoint，而模板渲染出的是 3 节点列表，会报 snapshot must be requested to one selected node, not multiple。

修复方式（builtin/core/roles/etcd/install/templates/backup.sh）：把 snapshot save 那一行的 endpoints 改为本机单点 https://localhost:{{ .etcd.port }}，与 kk 安装时一次性备份 role（roles/etcd/backup）的做法一致。一次改动同时解决两个 bug。

⚠️ 已部署的集群：升级到补丁版 kk 只能保证新装的集群备份正常；旧集群需手动把修好的 backup.sh 同步到每台 etcd 节点的 /usr/local/bin/kube-scripts/backup_etcd.sh。

官方 bug：kk create cluster 部署的 k8s 控制面证书自动续期定时任务（k8s-certs-renew.timer，每周触发）从集群创建起就全部失败，证书到期前不会被自动续期。三个叠加 bug：

1. Go template trim 吃掉换行：续期脚本模板 renew_script.sh 的 {{- if/else/end -}} 贪婪 trim，渲染后 #!/bin/bash、kubeadmCerts=...、函数定义挤成一行，bash 语法损坏。
2. systemd ExecStart 路径不匹配：service 指向 k8s-certs-renew.sh（不存在），实际部署的是 renew_script.sh，每次必然 status=203/EXEC。
3. 日期解析正则失效：grep 用了 PCRE 的 \s \w（BRE 不支持），永远匹配空 → 算出负数天数 → 每次都误触发续期（或反过来静默跳过）。

修复方式（3 处改动）：

• builtin/core/roles/kubernetes/certs/templates/k8s-certs-renew.sh（原 renew_script.sh）：删除 <v1.20.0 死代码分支（kubekey v4 最低支持 v1.23），固定用 kubeadm certs；getCertValidDays() 改用 kubeadm 输出的 RESIDUAL TIME 列（NNNd），解析失败兜底返回 9999（跳过续期）；加 set -euo pipefail。
• builtin/core/roles/kubernetes/certs/files/k8s-certs-renew.service：ExecStart 为 /usr/local/bin/kube-scripts/k8s-certs-renew.sh。
• 改名：把脚本从 renew_script.sh 改名为 k8s-certs-renew.sh，让模板、部署文件、systemd ExecStart 三者名称一致（原 service 引用的 k8s-certs-renew.sh 本就不存在，改名后名实相符）。tasks/main.yaml 同步更新 src/dest。

⚠️ 已部署的集群：升级补丁版 kk 只保证新装的集群续期正常；旧集群需手动同步脚本和 service 文件并重启 timer（注意旧集群脚本名是 renew_script.sh，要一并改成 k8s-certs-renew.sh）。

ℹ️ 这是控制面组件证书（kube-apiserver 等，1 年有效期）的自动续期。kubelet 客户端证书由 rotateCertificates: true 自动轮转，无需此补丁；CA/etcd 证书由 kk 签发，有效期 10 年。详见 CERTS-GUIDE.md。

官方 bug：NFS StorageClass 的 Helm values 模板 builtin/core/roles/storageclass/nfs/templates/values.yaml 第 12 行引用了错误的变量：

defaultClass: {{ .storage_class.local.default }}   # ❌ 读的是 local.default，不是 nfs.default

导致在 config 里设置 storage_class.nfs.default: true 完全不生效——渲染出的 defaultClass: false，NFS StorageClass 不会被标记为默认。集群没有默认 SC → 所有 storageClassName 为空的 PVC 永远 Pending（连带 Jenkins、Prometheus 等 Pod 起不来）。

修复方式（builtin/core/roles/storageclass/nfs/templates/values.yaml，1 行）：

- defaultClass: {{ .storage_class.local.default }}
+ defaultClass: {{ .storage_class.nfs.default }}

⚠️ 已部署的集群：代码修复只对新装集群生效。旧集群可紧急止血（不改代码）：kubectl patch sc nfs-client -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

官方 bug：kk certs renew 启动即报 failed to find role，命令完全不可用。两处 role 引用都少写了 certs/ 前缀：playbooks/certs_renew.yaml 写成 cert/init（单数，目录不存在）；certs/renew/meta/main.yaml 的三个 dependency 写成 renew/xxx（缺 certs/）。其他所有 playbook 和 role 的 dependency 都正确使用完整路径前缀。

修复方式：cert/init → certs/init；renew/xxx → certs/renew/xxx。

⚠️ 只影响 kk 二进制（playbook 和 role 都是 //go:embed 编译进二进制的）。重新编译带此补丁的 kk 即可，已部署的集群本身不受影响。

官方 bug：HCE 2.0（Huawei Cloud EulerOS，ID=hce，基于 openEuler 22.03 LTS 的 RHEL 系发行版）在 kubekey 中完全不被识别，add-node 时 HCE 节点会失败。两个叠加问题：

1. OS 白名单不含 HCE：01-cluster_require.yaml 的 supported_os_distributions 只有 ubuntu/centos/kylin/rocky，precheck 直接拒绝 HCE 节点。
2. OS 分类无 HCE 特判：HCE 的 /etc/os-release 没有 ID_LIKE 字段（不像普通 RHEL 系是 rhel fedora），install_package.yaml 的 current_host_type 三个分支都不命中 → 结果为空 → yum 仓库初始化和 socat/conntrack/ipset/ebtables/chrony/ipvsadm 等系统依赖整段被跳过，join 后节点异常。

修复方式（2 处）：

• 01-cluster_require.yaml：白名单加 hce 和 '"hce"'（带引号变体，因 Go 端解析 /etc/os-release 保留引号，与 ubuntu/centos/kylin 写法一致）。
• install_package.yaml：加 ID == hce → centos 特判分支（与 kylin 同样的处理）。

ISO 文件名天然吻合：HCE 的 ID=hce + VERSION_ID=2.0 + 空 ID_LIKE 命中 repository/tasks/main.yaml 的 else 分支，产出 system_string=hce-2.0，正好匹配预构建的 hce-2.0-rpms-{amd64,arm64}.iso（由 hack/gen-repository-iso/dockerfile.hce20 构建）。

⚠️ 只影响 kk 二进制。重新编译带此补丁的 kk 后，新增 HCE 节点即可正常 add-node；已部署的集群不受影响。

官方 bug：离线打包（kk artifact export）时，ISO 依赖包（如 hce-2.0-rpms-{amd64,arm64}.iso、kylin-v10SP3-rpms-*.iso）的下载 URL https://github.com/kubesphere/kubekey/releases/download/iso-latest/... 硬编码在 download/tasks/iso.yaml 里，没有任何 config 字段可以配置。download.iso 只控制下载哪些 ISO（列表），download.cn_host 只在 zone=cn 时换一个固定加速域名（kubekey.pek3b.qingstor.com），都换不成用户自建的 GitHub 代理/镜像（如 ghproxy.xxx/github.com/yourname/kubekey）。导致内网或被墙环境无法从自有源拉 ISO。

修复方式（2 处）：

• 10-download.yaml：download 段新增 iso_host 字段，默认空（保持官方行为）。
• iso.yaml：URL 模板改为：设了 iso_host 就完全用它（含 https:// 前缀，忽略 zone/cn_host）；没设则走官方原逻辑（zone=cn 时 qingstor 兜底）。

用法：在 config 里填完整的 ISO 源 URL 前缀，ISO 文件名会直接拼在它后面（中间补一个 /）：

spec:
  download:
    iso_host: https://mirrors.example.com/kubekey/iso/

拼出 https://mirrors.example.com/kubekey/iso/centos-8-rpms-amd64.iso。

支持两种 ISO 存放布局（补丁 9 修正，见下）：

• 平铺目录（ISO 直接放在目录下，最常见）：iso_host: https://mirrors.example.com/kubekey/iso/ → .../iso/centos-8-rpms-amd64.iso
• GitHub Release 镜像（自己补全 release 路径）：iso_host: https://ghproxy.example.com/github.com/yourname/kubekey/releases/download/iso-latest → .../iso-latest/centos-8-rpms-amd64.iso

设计要点：iso_host 是完整 URL 前缀（含协议），不是 owner/repo 路径。这样设了就完全接管 ISO URL，不再与 cn_host/zone=cn 叠加（否则会拼出 https://kubekey.pek3b.qingstor.com/ghproxy.xxx/... 双重路径 404）。不设则行为与官方完全一致，老 config 无需改动。

影响范围极窄：只改 ISO 下载 URL。普通 binary（etcd/kubelet 等）、镜像、Helm chart 各走独立模板，不受影响。

官方 bug：openEuler（ID=openEuler，20.03 / 22.03 / 24.03 三大 LTS 系列，每系列 SP1–SP4）在 kubekey 中完全不被识别，add-node 时 openEuler 节点会失败。比 HCE 2.0 多一层问题，共三个叠加：

1. OS 白名单不含 openEuler：01-cluster_require.yaml 的 supported_os_distributions 只有 ubuntu/centos/kylin/hce/rocky，precheck 直接拒绝 openEuler 节点。
2. OS 分类无 openEuler 特判：openEuler 的 /etc/os-release 没有 ID_LIKE 字段（和 HCE 一样），install_package.yaml 的 current_host_type 分支都不命中 → 结果为空 → yum 仓库初始化和 socat/conntrack/ipset/ebtables/chrony/ipvsadm 等系统依赖整段被跳过，join 后节点异常。
3. ISO 文件名带 SP 但取不到（openEuler 独有，HCE 没这问题）：openEuler 一个主版本对应多个 SP 的 ISO（如 openeuler-22.03-sp1/sp2/sp3/sp4-rpms-*.iso，共 11 个），但 VERSION_ID 只携带主版本号（22.03），区分 SP 的信息只在 VERSION（22.03 (LTS-SP3)）。原 system_string 的 else 分支会让 4 个 SP 坍缩成同一个 openeuler-22.03，4 个 ISO 一个都选不中。

修复方式（3 处）：

• 01-cluster_require.yaml：白名单加 openEuler 和 '"openEuler"'（注意大写 E）。
• install_package.yaml：加 ID == openEuler → centos 特判分支（与 kylin/hce 同样处理）。
• repository/tasks/main.yaml：仿 kylin 的 sp_version 特判，新增 oe_sp（从 VERSION 提取 SP1–SP4 拼成小写后缀 -sp1..-sp4）和 system_string 的 openEuler 分支（openeuler-<VERSION_ID><oe_sp>），产出 openeuler-22.03-sp3 等精确匹配 11 个预构建 ISO。

已验证：用仓库实际的 sprig FuncMap + KK unquote 渲染，全部 11 个版本（bare 和 quoted 两种 os-release 形式）都正确产出匹配的 ISO 名。

⚠️ 只影响 kk 二进制。重新编译带此补丁的 kk 后，新增 openEuler 节点即可正常 add-node；已部署的集群不受影响。ISO 依赖包（openeuler-*-rpms-*.iso）已构建并发布到 iso-latest Release（见 commit 89dbc235）。

补丁 7 的设计缺陷：补丁 7 让 iso_host 可配置，但实现时仍硬编码追加了 GitHub Release 路径 /releases/download/iso-latest/。这导致 iso_host 只在"GitHub Release 镜像"场景下可用（iso_host = scheme://host/owner/repo）。当把 iso_host 指向一个普通 HTTP 目录（ISO 文件直接平铺在目录下，最常见的自建源方式）时，URL 会多出一段不存在的 releases/download/iso-latest/ 路径，导致 404。

修复方式：去掉硬编码的 release 路径段。iso_host 设了之后，ISO 文件名直接拼接在它后面（中间补一个 /），真正实现补丁 7 文档承诺的"完整 URL 前缀"语义。支持两种布局：

• 平铺目录：iso_host: https://mirrors.example.com/kubekey/iso/ → .../iso/centos-8-rpms-amd64.iso
• GitHub Release 镜像：用户自己在 iso_host 里写全 release 路径 .../releases/download/iso-latest

默认行为不变（iso_host 为空时仍走官方 zone=cn/cn_host 逻辑）。已用 sprig FuncMap 验证四种场景（平铺目录 / GitHub 镜像 / 官方 cn / 官方直连）URL 拼接全部正确。

⚠️ 如果之前用补丁 7 的旧语义（iso_host 不含 release 路径、靠代码补全）配过 config，升级到补丁 9 后需要在 iso_host 里自己补全 release 路径（GitHub 镜像场景），或改成平铺目录形式。详见 PATCH-MAINTENANCE.md 补丁 9。

现象：当 image_registry 组配置了多个节点（Harbor HA 部署，配了 ha_vip）时，kk create cluster 推送镜像（ImageRegistry | Push images package to image registry）报错：

tls: failed to verify certificate: x509: certificate is valid for
dockerhub.kubekey.local, kk-master01, kk-master02, kk-master03, localhost, not kk-harbor02

根因（两个叠加 bug，都源于 .groups.image_registry 在 image-registry 角色渲染阶段不可靠——实测会解析为空）：

1. harbor.yml 的 hostname 用了条件 .groups.image_registry | len | lt 1。该变量解析为空时条件误判为 true，导致 hostname 被渲染成节点自身主机名（如 kk-harbor02），而不是 registry 域名（dockerhub.kubekey.local）。于是 Harbor 把 token 服务地址通告成 https://kk-harbor02/service/token，而 image_registry.crt 的 SAN 里只有 registry 域名和 IP，没有各节点主机名 → 客户端去 kk-harbor02 拿 token 时 TLS 证书校验失败。
2. keepalived 的 when（install 路径 2 处 + uninstall 路径 1 处）也用了 .groups.image_registry | len | lt 1。这里它碰巧为 true（空组的 0 lt 1），所以 keepalived 之前是意外启用的；若改成直观的 gt 1，0 gt 1 反而为 false，keepalived 会被跳过，VIP 起不来，harbor 健康检查（走 VIP）超时，集群部署卡死。uninstall 路径那处是 install 的对称 bug——靠同样的意外才执行卸载，漏改会导致卸载时留下 VIP 残留和 /opt/keepalived。

修复方式（4 个文件）：

• harbor.yml 的 hostname 条件改为 .image_registry.auth.registry | empty：配了 registry 域名就用它（单节点/多节点统一正确），没配才回退 inventory_hostname。不再依赖不可靠的 groups.image_registry。
• keepalived 三处 when（image-registry/meta/main.yaml、harbor/tasks/install.yaml、uninstall/image-registry/meta/main.yaml）统一改为只判断 .image_registry.ha_vip | empty | not（配了 ha_vip 就是 HA，就该启用/卸载 keepalived），彻底去掉对 groups.image_registry 的依赖，并保证 install/uninstall 对称。

已在真实 2 节点 Harbor HA 集群端到端验证：keepalived 正常启动、VIP 飘起、push 镜像成功、token realm 为 https://dockerhub.kubekey.local/service/token，完整集群（kubeadm init + 3 master + 1 worker）failed: 0 部署成功。

⚠️ 只影响 kk 二进制（四个 yaml 都是 //go:embed 编译进二进制的 role 模板）。重新编译带此补丁的 kk 后，新装的 HA 镜像仓库即正常。已部署的旧集群需手动把两台 Harbor 的 harbor.yml 里 hostname 改成 registry 域名并重新 prepare + 重启 Harbor（详见 PATCH-MAINTENANCE.md 补丁 10）。

⚠️ 编译注意：在 Windows 上编译 kk 时，务必确保 .gitattributes 生效（本仓库已加，强制 builtin/** 等用 LF）。否则 core.autocrlf=true 会把模板文件转成 CRLF，go embed 把 \r 烤进二进制，渲染出的配置（如 harbor.yml 的 data_volume）末尾带 \r，导致路径错误（目录被建成 data\r）。

现象：当 etcd.deployment_type: internal（etcd 作为 stacked static Pod 部署，交给 kubeadm 拉起）时，生成的 etcd 静态 Pod 永远拉不到镜像，etcd 起不来，kubeadm init 卡在 wait-control-plane 4 分钟后报 context deadline exceeded：

[WARNING ImagePull]: failed to pull image dockerhub.kubekey.local/etcd:v3.5.24: ...
unexpected status from HEAD request to https://dockerhub.kubekey.local/v2/etcd/manifests/v3.5.24: 400 Bad Request

根因（kubeadm 模板的两处叠加 bug）：

1. imageRepository 丢了 repository 路径。两个 kubeadm 模板（kubeadm-init.v1beta3 / kubeadm-init.v1beta4）的 etcd.local 块都只渲染了 {{ .etcd.image.registry }}（registry 主机名，如 dockerhub.kubekey.local），完全没引用 .etcd.image.repository。kubeadm 的 imageRepository 语义是「镜像前缀（项目路径）」，它会在后面自动追加组件名 /etcd，于是最终引用变成 dockerhub.kubekey.local/etcd:<tag>。私有 Harbor 里 etcd 镜像在项目 kubernetes/etcd 下，根路径 etcd 不存在 → registry 返回 400。所以无论用户在 config 里把 etcd.image.repository 改成什么，都不生效——模板根本没读这个字段。对比同文件其它组件是正确的：dns 行渲染 registry/repository，全局 imageRepository 本身含路径。
2. 默认值 kubesphere/etcd 与上游镜像源 hub.kubesphere.com.cn/kubernetes/etcd（也就是镜像实际被推送到 Harbor 的项目 kubernetes/etcd）不匹配。即使修好模板，默认值仍会解析到不存在的 kubesphere/etcd 路径。

修复方式（3 处）：

• kubeadm-init.v1beta3 / kubeadm-init.v1beta4：渲染

  - imageRepository: {{ .etcd.image.registry }}
  + imageRepository: {{ .etcd.image.registry }}/{{ dir .etcd.image.repository }}

  sprig 的 dir 去掉末尾镜像名，得到项目前缀（kubernetes/etcd → kubernetes）；kubeadm 再追加 /etcd → 最终 dockerhub.kubekey.local/kubernetes/etcd:<tag>（与 Harbor 实际路径一致，不再重复）。
• 04-etcd.yaml：默认 repository: kubesphere/etcd → kubernetes/etcd，与上游镜像源及 Harbor 项目布局一致。

已在真实 3 master + 1 worker 集群端到端验证：etcd static Pod 正确拉取 dockerhub.kubekey.local/kubernetes/etcd:v3.5.24，3 节点 etcd 全部 started，failed: 0 部署成功。

⚠️ 只影响 kk 二进制（三个 yaml 都是 //go:embed 编译进二进制的 kubeadm/defaults 模板）。重新编译带此补丁的 kk，新装的 internal（静态 Pod etcd）集群即正常。external（二进制 + systemd etcd，默认）模式不经过 kubeadm 的 etcd.local，不受影响。已部署的旧集群若用 internal 模式，重新用补丁版 kk delete cluster --all + create cluster 即可。

直接从本仓库的 Releases 下载，命名形如 kubekey-vX.Y.Z-portfix-<os>-<arch>.tar.gz（含 6 个平台：linux/windows/darwin × amd64/arm64）。

当前最新版：

方式一：GitHub Actions（推荐）

进入 Actions → Sync Patch → Run workflow → 输入官方版本号（如 v4.0.6）→ 运行。约 11 分钟后自动产出 v4.0.6-portfix Release（补丁 + 6 平台二进制）。

方式二：命令行触发

gh workflow run sync-patch.yml -R lpx0312/kubekey --ref port-fix -f version=v4.0.6 -f push=true

方式三：本地脚本（需 Go 环境，网络受限时用代理 SYNC_PROXY=...）

git checkout port-fix
./scripts/sync-patch.sh v4.0.6

以上三种方式都是幂等的：同一版本可重复运行，总是覆盖为最新结果。

发现官方代码还有 bug 需要修复时，按 ADD-PATCH-TUTORIAL.md 的 9 步流程操作即可。核心要点：

1. 在 port-fix 分支改代码并提交一个 fix(...) commit
2. 基于 patch/base 重建干净的补丁链（所有补丁串成一条直线，不能夹 docs/ci 等无关 commit），更新 patch/port-fix tag
3. 用 git format-patch 生成 patches/000N-*.patch 归档，同步更新 README / PATCH-MAINTENANCE / sync-patch.sh
4. 推送 port-fix 分支 + patch/port-fix tag（--force），然后触发 sync-patch.yml 生成新 Release

⚠️ 教程里有 5 个踩坑点详解（template trim 吃换行、--cleanup-tag 毁掉正确 tag、patch 链带垃圾 commit、网络问题、旧集群迁移），动手前务必先读一遍。其中"重建干净补丁链"和"验证发布 tag 的 commit 链底部是官方基线"两步是关键，做错会导致发布的 tag 指向错误。

需要让 kubekey 支持一个新的 OS（如统信 UOS、麒麟、openEuler 等）作为 worker 节点时，按 NEW-OS-ADAPTATION-GUIDE.md 的 完整 SOP 操作。涵盖：判断适配工作量、准备 Docker 镜像、编写 dockerfile 生成 ISO、改 kubekey 源码（白名单 / OS 分类 / ISO 名特判）、打补丁归档的全流程，并附带历史案例对照表（HCE / openEuler / kylin）和 Checklist。

离线安装 K8s 时，kk 需要从 GitHub Release 下载各发行版的系统依赖包 ISO（含 chrony、conntrack、socat 等）。为避免依赖官方 kubesphere/kubekey 的 iso-latest Release 消失，本仓库自带改造后的 GenRepositoryISO workflow，可在本 fork 内独立构建并发布全部 ISO 依赖包。

产物：Releases · iso-latest，共 37 个文件（12 个发行版 × amd64/arm64 + sha256 + harbor 离线包），与官方一一对应。

方式一：GitHub Actions（推荐）

进入 Actions → GenRepositoryISO → Run workflow → 选择 port-fix 分支 → 运行。约 10 分钟后产物覆盖到 iso-latest Release。

方式二：命令行触发

gh workflow run gen-repository-iso.yaml -R lpx0312/kubekey --ref port-fix

方式三：打 tag 自动触发

git tag -f iso-latest port-fix
git push origin iso-latest -f

确定性说明：改造后的 workflow 删除了上游的 update-tag 自动移 tag 逻辑，构建直接使用你触发时所选 ref（分支/tag）指向的 commit，产物版本完全由触发者决定，不会偷偷跟随 main。

风险与隔离：Kylin 系列依赖第三方镜像 hxsoong/kylin，若其不可用只会导致 4 个 kylin job 失败（fail-fast: false 已隔离），其余 8 个发行版照常出包。自定义包列表可编辑 hack/gen-repository-iso/packages.yaml。

git checkout port-fix   # 或 git checkout vX.Y.Z-portfix
LDFLAGS=$(bash hack/version.sh)
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 \
  go build -trimpath -tags "builtin" -ldflags "$LDFLAGS" \
  -o _output/bin/kk cmd/kk/kubekey.go

必须带 -tags "builtin"，否则 artifact 子命令不会被编译进去。

更多维护细节见 PATCH-MAINTENANCE.md。

English | 中文

👋 Welcome to KubeKey!

KubeKey is an open-source lightweight task flow execution tool. It provides a flexible and fast way to install Kubernetes.

KubeKey has passed the CNCF Kubernetes Conformance Certification

1. Expanded from Kubernetes lifecycle management tool to task execution tool (flow design refers to Ansible)
2. Supports multiple ways to manage task templates: git, local, etc.
3. Supports multiple node connection methods, including: local, ssh, kubernetes, prometheus.
4. Supports cloud-native automated batch task management
5. Advanced features: UI page (not yet open)

Get the corresponding binary files from the Release page.

curl -sfL https://get-kk.kubesphere.io | sh -

./kk create cluster

UI only supported after v4.0.0

./kk web --schema-path web-installer/schema --ui-path web-installer/dist

• Install Kubernetes
  • Component Versions
  • Online Installation
  • Offline Installation
  • Add Cluster Nodes
  • Delete Cluster Nodes
• Configuration Reference
• Playbooks
  • Create Kubernetes Cluster
  • Delete Kubernetes Cluster
  • Add Nodes
  • Delete Nodes
  • Renew Certificates
  • Export Offline Artifact
  • Pre-installation Check
  • Initialize OS
• Image Registry Installation
• Dependency Packages
• Task Execution Framework
  • Project
  • Playbook
  • Role
  • Task
  • Template Syntax
  • Variables