2026/9/8 15:37:39
FEATURED · 精选文章 
Kubernetes Kubemark 实战指南使用 pre-existing Provider 在已有 Master 上搭建 Hollow-Node 大规模测试集群【免费下载链接】kubernetesProduction-Grade Container Scheduling and Management项目地址: https://gitcode.com/GitHub_Trending/kuber/kubernetesKubemark 是 Kubernetes 仓库内置的空心节点测试框架用于在有限资源下模拟大规模集群成百上千个节点对 API Server、etcd 等控制面的压力。本篇以 Kubemark pre-existing Provider 指南 为核心完整讲清 pre-existing 模式下的拓扑结构、前置条件、配置写法与启停流程并结合 start-kubemark.sh、pre-existing/util.sh 等脚本源码说明每一步背后实际发生了什么帮助读者在自己的集群上复用 Kubemark 工具链而不必新建任何云基础设施。1. 先理解一个运行中的 Kubemark 环境长什么样根据 pre-existing Provider 指南每一个运行中的 Kubemark 环境都由四部分构成一个真实运行的 Kubernetes 集群host cluster由本地 kubeconfig 指向一台独立 VM上面运行着Kubemark Master即一组 Kubernetes 控制面组件API Server、etcd、controller-manager 等若干 hollow-node空心节点以 Pod 形式运行在第 1 步的真实集群里但对 Kubemark Master 而言它们看起来就是 Node网络指向关系这些 hollow-node 被配置为与第 2 步的 Kubemark Master 通信。概念对应关系Kubemark Master运行在 VM 中的一组 Kubernetes 控制面组件Kubernetes Clusterhost cluster一个拥有 master 和 nodes 的真实集群hollow-node Pod 跑在这里但对 Kubemark Master 表现为节点。hollow-node 本身是仓库中的独立可执行程序入口见 cmd/kubemark/hollow-node.go其核心命令由 cmd/kubemark/app 包中的NewHollowNodeCommand提供。它模拟 kubelet 向控制面注册节点、上报状态、领取 Pod 等行为但不会真正拉起容器从而以极低的真实资源开销伪装出大规模节点。2. pre-existing Provider 的定位不建基础设施只用现成 MasterKubemark 的测试脚本采用provider插件机制start-kubemark.sh 按CLOUD_PROVIDER变量动态加载两个文件source ${KUBE_ROOT}/test/kubemark/skeleton/util.sh source ${KUBE_ROOT}/test/kubemark/cloud-provider-config.sh source ${KUBE_ROOT}/test/kubemark/${CLOUD_PROVIDER}/util.sh source ${KUBE_ROOT}/cluster/kubemark/${CLOUD_PROVIDER}/config-default.sh因此CLOUD_PROVIDERpre-existing时实际生效的是 test/kubemark/pre-existing/util.sh 和 cluster/kubemark/pre-existing/config-default.sh。pre-existing provider 的目标引自 README开发者负责创建第 1 步的 host cluster 和第 2 步的 Kubemark Master VMKubemark 脚本不创建任何基础设施也不会像其他 provider 那样启动一个 kubemark master。第 2 步 VM$MASTER_IP指向上已就绪的资源直接充当 Kubemark Master。这是一个面向高级用户的使用场景要求使用者已经掌握如何搭建一个 Kubemark Master。从源码结构可以印证不建任何东西这一点pre-existing provider 的 util.sh 只额外定义了execute-cmd-on-pre-existing-master-with-retries一个函数并没有覆写 skeleton/util.sh 中的create-kubemark-master和delete-kubemark-master。这两个骨架函数的实现只是打印Creating cluster.../Deleting cluster...——也就是说当 start/stop 脚本调用它们时对 pre-existing 来说基本是空操作。这正是指南中所说的脚本不会创建基础设施或启动 kubemark master的代码依据。对比之下GCE provider 的默认配置 cluster/kubemark/gce/config-default.sh 默认NUM_NODES${KUBEMARK_NUM_NODES:-10}还会处理 Cluster Autoscaler 的启停分支而 pre-existing 的 config-default.sh 刻意保持极简默认NUM_NODES${NUM_NODES:-1}把拓扑完全交给用户自己掌控。3. 前置条件与检查清单按 README 的 Requirements 一节使用 pre-existing provider 需要满足存在一个可通过$MASTER_IP访问的 Kubemark Master运行 Kubemark 脚本的宿主机必须能 SSH 登录到该 Master 所在机器该机器上的用户必须是kubernetes。要求清单原文完整保留将MASTER_IP设置为 Kubemark Master 的 IP 地址执行 Kubemark 脚本的宿主机必须能够ssh kubernetes$MASTER_IP。这两条要求并非文档空话而是脚本的硬性依赖。test/kubemark/pre-existing/util.sh 中的实现如下# Leave the skeleton definition of execute-cmd-on-master-with-retries # so only the pre-existing provider functions will target this. function execute-cmd-on-pre-existing-master-with-retries() { IP_WITHOUT_PORT$(echo ${MASTER_IP} | cut -f 1 -d :) || ${MASTER_IP} RETRIES${2:-1} run-cmd-with-retries ssh kubernetes${IP_WITHOUT_PORT} ${1} }三点值得注意固定 SSH 用户为kubernetes这就是用户必须是 kubernetes要求的来源剥离端口MASTER_IP允许写成IP:端口形式如192.168.121.29:6443但 SSH 前会用cut -f 1 -d :去掉端口说明 API 端口与 SSH 端口可以分离重试机制底层run-cmd-with-retries定义在 test/kubemark/common/util.sh默认重试 3 次失败间隔随尝试次数递增sleep $((attempt * 5))并对 already exists 这类资源残留错误有专门的失败/容忍判定。MASTER_IP支持非默认端口的写法在 cluster/kubemark/pre-existing/config-default.sh 的注释里也有明确示例# Pre-existing provider expects a MASTER_IP. # If you need to specify a port thats not the default (443), add it to MASTER_IP. # # Example: Connect to the Master on the secure port 6443 # MASTER_IP192.168.122.5:6443 # MASTER_IP${MASTER_IP:-}4. 配置示例cloud-provider-config.sh 逐变量解析README 给出的官方示例配置放在 test/kubemark/cloud-provider-config.sh 中CLOUD_PROVIDERpre-existing KUBEMARK_IMAGE_MAKE_TARGETpush CONTAINER_REGISTRYdocker.io PROJECTrthallisey MASTER_IP192.168.121.29:6443逐变量说明变量示例值作用CLOUD_PROVIDERpre-existing选择 pre-existing provider决定脚本加载哪套 util.sh 与 config-default.sh。cloud-provider-config.sh 中默认值是gce用 pre-existing 必须显式覆盖KUBEMARK_IMAGE_MAKE_TARGETpush构建并推送 hollow-node 镜像时使用的 make 目标。该文件默认值是gcloudpush面向 GCRpre-existing 场景通常推送到自建/公开 registry因此示例改为pushCONTAINER_REGISTRYdocker.io镜像仓库前缀。默认值gcr.io见 cloud-provider-config.sh#L18PROJECTrthallisey与 registry 组合成镜像路径$CONTAINER_REGISTRY/$PROJECT/kubemark见 config-default.sh#L27-L31 注释MASTER_IP192.168.121.29:6443Kubemark Master 地址端口非 443 时显式带上pre-existing 版 config-default.sh 中全部可用变量及默认值MASTER_IP${MASTER_IP:-} # Kubemark Master 地址必需可为 IP:端口 CONTAINER_REGISTRY${CONTAINER_REGISTRY:-} # 镜像仓库 PROJECT${PROJECT:-} # 仓库下的项目/命名空间 NUM_NODES${NUM_NODES:-1} # hollow-node 数量默认仅 1 KUBELET_TEST_LOG_LEVEL${KUBELET_TEST_LOG_LEVEL:-} KUBEPROXY_TEST_LOG_LEVEL${KUBEPROXY_TEST_LOG_LEVEL:-} MASTER_NAME${MASTER_NAME:-}对比 GCE provider 还多了ENABLE_KUBEMARK_CLUSTER_AUTOSCALER、KUBEMARK_AUTOSCALER_MAX_NODES、ENABLE_KUBEMARK_KUBE_DNS等开关pre-existing 版则全部省略——是否启用 Cluster Autoscaler、kube-dns 等 addon由开发者自行在 Master 侧解决这与其高级用法、基础设施自理的定位一致。5. 启动流程start-kubemark.sh 在 pre-existing 模式下做什么执行./test/kubemark/start-kubemark.sh后即便 Master 是用户自备的脚本仍会完成在 host cluster 中部署 hollow-node的全部工作。按 start-kubemark.sh 的主流程L239-L251detect-project /dev/null create-kubemark-master # pre-existing 下为 skeleton 空操作 # ... 选择 HOLLOWNODE_KUBECONFIGinternal 或 local kubeconfig MASTER_IP$(grep server ${HOLLOWNODE_KUBECONFIG} | awk -F / {print $3}) start-hollow-nodes resize-node-objects5.1 构建并推送 hollow-node 镜像start-hollow-nodesL213-L219第一步是create-and-upload-hollow-node-imageL48-L71调用 provider 的authenticate-docker完成镜像仓库认证pre-existing 未覆写走 skeleton 实现生成 6 位随机KUBEMARK_IMAGE_TAG避免多次运行互相覆盖查找平台对应的kubemark编译产物找不到即报错退出拷贝到 cluster/images/kubemark 目录以REGISTRY${KUBEMARK_IMAGE_REGISTRY} IMAGE_TAG${KUBEMARK_IMAGE_TAG}执行make ${KUBEMARK_IMAGE_MAKE_TARGET}构建并推送镜像——这就是配置中KUBEMARK_IMAGE_MAKE_TARGETpush的落点。5.2 在 host cluster 中创建 hollow-node 相关资源create-kube-hollow-node-resourcesL80-L170通过cluster/kubectl.sh作用于本地 kubeconfig 指向的 host cluster依次创建kubemark 命名空间kubectl create -f resources/kubemark-ns.jsonnode-configmap配置 hollow kubelet、proxy、npd 的 ConfigMapkubeconfig Secret把指向 Kubemark Master 的 kubeconfig 以kubelet.kubeconfig、kubeproxy.kubeconfig、npd.kubeconfig等多个键注入kubeconfigSecret——hollow-node Pod 正是凭这份 kubeconfig 与 Master而非 host cluster 自己的控制面通信从而在 Master 眼中表现为节点addon Podheapster监控、可选的 Cluster Autoscaler 与 kube-dns由ENABLE_KUBEMARK_*开关控制见 L115-L133hollow-node 复制控制器由hollow-node_template.yaml经sed模板替换生成关键替换项包括{{numreplicas}}→NUM_REPLICAS默认取NUM_NODES{{master_ip}}→MASTER_IP即 hollow-node 要连接的控制面地址kubelet/proxy/npd 的 millicpu 与内存Ki如KUBEMARK_HOLLOW_KUBELET_MILLICPU:-40、KUBEMARK_HOLLOW_PROXY_MEM_PER_NODE_KB:-50且节点数超过 1000 时 proxy CPU 自动从 20m 提到 50mL141-L147{{hollow_kubelet_params}}/{{hollow_proxy_params}}→ 来自HOLLOW_KUBELET_TEST_ARGS/HOLLOW_PROXY_TEST_ARGS的测试参数pre-existing 版 config 中默认继承KUBELET_TEST_LOG_LEVEL/KUBEPROXY_TEST_LOG_LEVEL之外的空值可按需注入--v等日志级别。5.3 等待节点就绪与节点对象增肥wait-for-hollow-nodes-to-run-or-timeoutL173-L208用 Kubemark kubeconfig 每秒轮询kubectl get node统计 Ready 数量直至达到NUM_REPLICAS超时上限 30 分钟超时后打印 node describe、hollow-node Pod 的 Running/非 Running 统计并提示可能是 API Server 不可用resize-node-objectsL225-L236若设置了KUBEMARK_NODE_OBJECT_SIZE_BYTES会给每个 Node 对象附加一个随机大 label使其对象体积接近真实节点让 API Server 存储压力更贴近现实源码注释中说明这是过渡手段未来计划由 ClusterLoader 的镜像预加载替代。流程结束时会输出Master IP: ${MASTER_IP} Kubeconfig for kubemark master is written in ${LOCAL_KUBECONFIG}其中LOCAL_KUBECONFIG为test/kubemark/resources/kubeconfig.kubemark是后续运行 e2e 测试时访问 Kubemark 集群的入口。6. 停止流程stop-kubemark.sh 只清理集群内资源不动你的 Masterstop-kubemark.sh 的清理逻辑detect-project /dev/null ${KUBECTL} delete --timeout5m -f ${RESOURCE_DIRECTORY}/addons --namespacekubemark /dev/null || true ${KUBECTL} delete --timeout5m -f ${RESOURCE_DIRECTORY}/hollow-node.yaml --namespacekubemark /dev/null || true ${KUBECTL} delete --timeout5m -f ${RESOURCE_DIRECTORY}/kubemark-ns.json /dev/null || true rm -rf ${RESOURCE_DIRECTORY}/addons \ ${RESOURCE_DIRECTORY}/kubeconfig.kubemark \ ${RESOURCE_DIRECTORY}/hollow-node.yaml /dev/null || true delete-kubemark-master与启动流程对称删除 host cluster 中的 kubemark 命名空间、addon 与 hollow-node 控制器并清理本地生成的 manifest/kubeconfig 文件末尾的delete-kubemark-master对 pre-existing 同样是 skeleton 空操作——自备的 Master VM 不会被动过由开发者自行销毁。这与 README 中脚本不会创建/管理基础设施的承诺一致。7. 在 Kubemark 上跑 e2e 测试集群就绪后run-e2e-tests.sh 负责把测试指向 Kubemark 控制面export KUBERNETES_PROVIDERkubemark export KUBE_MASTER_URLhttps://${KUBE_MASTER_IP} export KUBECONFIG${ABSOLUTE_ROOT}/test/kubemark/resources/kubeconfig.kubemark export E2E_MIN_STARTUP_PODS0 ... ${KUBE_ROOT}/hack/ginkgo-e2e.sh --e2e-verify-service-accountfalse --dump-logs-on-failurefalse ${ARGS[]}要点通过 cluster/kubemark/util.sh 间接复用 provider 配置它再次 sourcecluster/kubemark/${CLOUD_PROVIDER}/config-default.sh因此 pre-existing 下MASTER_NAME等变量同样生效KUBECONFIG被强制指向 start 阶段生成的test/kubemark/resources/kubeconfig.kubemark即测试对象是 Kubemark Master 而非 host cluster参数中的[/]ginkgo 测试过滤语法会被转义后透传给 hack/ginkgo-e2e.sh。8. 落地检查清单Self-check按 README 要求清单 结合源码pre-existing 模式下动手前逐项确认Master 可达性Kubemark Master 已部署且 API 可在$MASTER_IP可带端口如:6443访问——对应 config-default.sh 的注释与示例SSH 链路执行脚本的宿主机可ssh kubernetes$MASTER_IP——这是 pre-existing/util.sh 中execute-cmd-on-pre-existing-master-with-retries的硬依赖用户名必须为kubernetes镜像可推送CONTAINER_REGISTRY/$PROJECT有写权限KUBEMARK_IMAGE_MAKE_TARGET如push与仓库类型匹配且 host cluster 能拉取该镜像hollow-node Pod 跑在 host cluster 里本地 kubeconfigcluster/kubectl.sh使用的本地 kubeconfig 指向 host cluster且账号具备创建 kubemark 命名空间、Secret、ConfigMap 与 ReplicaSet 的权限规模参数NUM_NODES决定 hollow-node 副本数pre-existing 默认 1hollow-node Pod 的资源配额KUBEMARK_HOLLOW_*系列变量需与 host cluster 实际容量匹配测试入口e2e 阶段使用test/kubemark/resources/kubeconfig.kubemark访问 Kubemark Master。9. 小结pre-existing provider 是 Kubemark 工具链中最薄的一层它不替你创建 Master、不管理 VM 生命周期只负责把 hollow-node 这套 Pod 正确部署到 host cluster 并指向你自备的 MasterREADME。换来的是对控制面拓扑、镜像来源、节点规模的完全自定义能力适合需要在异构环境自建机房、其他云、既有实验环境中复用 test/kubemark 脚本与 e2e 框架的高级用户。核心入口文件只有四个配置 test/kubemark/cloud-provider-config.sh、默认值 cluster/kubemark/pre-existing/config-default.sh、SSH 工具 test/kubemark/pre-existing/util.sh、启停脚本 start-kubemark.sh / stop-kubemark.sh围绕它们即可完整掌握该 provider 的全部行为边界。【免费下载链接】kubernetesProduction-Grade Container Scheduling and Management项目地址: https://gitcode.com/GitHub_Trending/kuber/kubernetes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kubernetes Kubemark 实战指南：使用 pre-existing Provider 在已有 Master 上搭建 Hollow-Node 大规模测试集群
Kubernetes Kubemark 实战指南使用 pre-existing Provider 在已有 Master 上搭建 Hollow-Node 大规模测试集群【免费下载链接】kubernetesProduction-Grade Container Scheduling and Management项目地址: https://gitcode.com/GitHub_Trending/kuber/kubernetesKubemark 是 Kubernetes 仓库内置的空心节点测试框架用于在有限资源下模拟大规模集群成百上千个节点对 API Server、etcd 等控制面的压力。本篇以 Kubemark pre-existing Provider 指南 为核心完整讲清 pre-existing 模式下的拓扑结构、前置条件、配置写法与启停流程并结合 start-kubemark.sh、pre-existing/util.sh 等脚本源码说明每一步背后实际发生了什么帮助读者在自己的集群上复用 Kubemark 工具链而不必新建任何云基础设施。1. 先理解一个运行中的 Kubemark 环境长什么样根据 pre-existing Provider 指南每一个运行中的 Kubemark 环境都由四部分构成一个真实运行的 Kubernetes 集群host cluster由本地 kubeconfig 指向一台独立 VM上面运行着Kubemark Master即一组 Kubernetes 控制面组件API Server、etcd、controller-manager 等若干 hollow-node空心节点以 Pod 形式运行在第 1 步的真实集群里但对 Kubemark Master 而言它们看起来就是 Node网络指向关系这些 hollow-node 被配置为与第 2 步的 Kubemark Master 通信。概念对应关系Kubemark Master运行在 VM 中的一组 Kubernetes 控制面组件Kubernetes Clusterhost cluster一个拥有 master 和 nodes 的真实集群hollow-node Pod 跑在这里但对 Kubemark Master 表现为节点。hollow-node 本身是仓库中的独立可执行程序入口见 cmd/kubemark/hollow-node.go其核心命令由 cmd/kubemark/app 包中的NewHollowNodeCommand提供。它模拟 kubelet 向控制面注册节点、上报状态、领取 Pod 等行为但不会真正拉起容器从而以极低的真实资源开销伪装出大规模节点。2. pre-existing Provider 的定位不建基础设施只用现成 MasterKubemark 的测试脚本采用provider插件机制start-kubemark.sh 按CLOUD_PROVIDER变量动态加载两个文件source ${KUBE_ROOT}/test/kubemark/skeleton/util.sh source ${KUBE_ROOT}/test/kubemark/cloud-provider-config.sh source ${KUBE_ROOT}/test/kubemark/${CLOUD_PROVIDER}/util.sh source ${KUBE_ROOT}/cluster/kubemark/${CLOUD_PROVIDER}/config-default.sh因此CLOUD_PROVIDERpre-existing时实际生效的是 test/kubemark/pre-existing/util.sh 和 cluster/kubemark/pre-existing/config-default.sh。pre-existing provider 的目标引自 README开发者负责创建第 1 步的 host cluster 和第 2 步的 Kubemark Master VMKubemark 脚本不创建任何基础设施也不会像其他 provider 那样启动一个 kubemark master。第 2 步 VM$MASTER_IP指向上已就绪的资源直接充当 Kubemark Master。这是一个面向高级用户的使用场景要求使用者已经掌握如何搭建一个 Kubemark Master。从源码结构可以印证不建任何东西这一点pre-existing provider 的 util.sh 只额外定义了execute-cmd-on-pre-existing-master-with-retries一个函数并没有覆写 skeleton/util.sh 中的create-kubemark-master和delete-kubemark-master。这两个骨架函数的实现只是打印Creating cluster.../Deleting cluster...——也就是说当 start/stop 脚本调用它们时对 pre-existing 来说基本是空操作。这正是指南中所说的脚本不会创建基础设施或启动 kubemark master的代码依据。对比之下GCE provider 的默认配置 cluster/kubemark/gce/config-default.sh 默认NUM_NODES${KUBEMARK_NUM_NODES:-10}还会处理 Cluster Autoscaler 的启停分支而 pre-existing 的 config-default.sh 刻意保持极简默认NUM_NODES${NUM_NODES:-1}把拓扑完全交给用户自己掌控。3. 前置条件与检查清单按 README 的 Requirements 一节使用 pre-existing provider 需要满足存在一个可通过$MASTER_IP访问的 Kubemark Master运行 Kubemark 脚本的宿主机必须能 SSH 登录到该 Master 所在机器该机器上的用户必须是kubernetes。要求清单原文完整保留将MASTER_IP设置为 Kubemark Master 的 IP 地址执行 Kubemark 脚本的宿主机必须能够ssh kubernetes$MASTER_IP。这两条要求并非文档空话而是脚本的硬性依赖。test/kubemark/pre-existing/util.sh 中的实现如下# Leave the skeleton definition of execute-cmd-on-master-with-retries # so only the pre-existing provider functions will target this. function execute-cmd-on-pre-existing-master-with-retries() { IP_WITHOUT_PORT$(echo ${MASTER_IP} | cut -f 1 -d :) || ${MASTER_IP} RETRIES${2:-1} run-cmd-with-retries ssh kubernetes${IP_WITHOUT_PORT} ${1} }三点值得注意固定 SSH 用户为kubernetes这就是用户必须是 kubernetes要求的来源剥离端口MASTER_IP允许写成IP:端口形式如192.168.121.29:6443但 SSH 前会用cut -f 1 -d :去掉端口说明 API 端口与 SSH 端口可以分离重试机制底层run-cmd-with-retries定义在 test/kubemark/common/util.sh默认重试 3 次失败间隔随尝试次数递增sleep $((attempt * 5))并对 already exists 这类资源残留错误有专门的失败/容忍判定。MASTER_IP支持非默认端口的写法在 cluster/kubemark/pre-existing/config-default.sh 的注释里也有明确示例# Pre-existing provider expects a MASTER_IP. # If you need to specify a port thats not the default (443), add it to MASTER_IP. # # Example: Connect to the Master on the secure port 6443 # MASTER_IP192.168.122.5:6443 # MASTER_IP${MASTER_IP:-}4. 配置示例cloud-provider-config.sh 逐变量解析README 给出的官方示例配置放在 test/kubemark/cloud-provider-config.sh 中CLOUD_PROVIDERpre-existing KUBEMARK_IMAGE_MAKE_TARGETpush CONTAINER_REGISTRYdocker.io PROJECTrthallisey MASTER_IP192.168.121.29:6443逐变量说明变量示例值作用CLOUD_PROVIDERpre-existing选择 pre-existing provider决定脚本加载哪套 util.sh 与 config-default.sh。cloud-provider-config.sh 中默认值是gce用 pre-existing 必须显式覆盖KUBEMARK_IMAGE_MAKE_TARGETpush构建并推送 hollow-node 镜像时使用的 make 目标。该文件默认值是gcloudpush面向 GCRpre-existing 场景通常推送到自建/公开 registry因此示例改为pushCONTAINER_REGISTRYdocker.io镜像仓库前缀。默认值gcr.io见 cloud-provider-config.sh#L18PROJECTrthallisey与 registry 组合成镜像路径$CONTAINER_REGISTRY/$PROJECT/kubemark见 config-default.sh#L27-L31 注释MASTER_IP192.168.121.29:6443Kubemark Master 地址端口非 443 时显式带上pre-existing 版 config-default.sh 中全部可用变量及默认值MASTER_IP${MASTER_IP:-} # Kubemark Master 地址必需可为 IP:端口 CONTAINER_REGISTRY${CONTAINER_REGISTRY:-} # 镜像仓库 PROJECT${PROJECT:-} # 仓库下的项目/命名空间 NUM_NODES${NUM_NODES:-1} # hollow-node 数量默认仅 1 KUBELET_TEST_LOG_LEVEL${KUBELET_TEST_LOG_LEVEL:-} KUBEPROXY_TEST_LOG_LEVEL${KUBEPROXY_TEST_LOG_LEVEL:-} MASTER_NAME${MASTER_NAME:-}对比 GCE provider 还多了ENABLE_KUBEMARK_CLUSTER_AUTOSCALER、KUBEMARK_AUTOSCALER_MAX_NODES、ENABLE_KUBEMARK_KUBE_DNS等开关pre-existing 版则全部省略——是否启用 Cluster Autoscaler、kube-dns 等 addon由开发者自行在 Master 侧解决这与其高级用法、基础设施自理的定位一致。5. 启动流程start-kubemark.sh 在 pre-existing 模式下做什么执行./test/kubemark/start-kubemark.sh后即便 Master 是用户自备的脚本仍会完成在 host cluster 中部署 hollow-node的全部工作。按 start-kubemark.sh 的主流程L239-L251detect-project /dev/null create-kubemark-master # pre-existing 下为 skeleton 空操作 # ... 选择 HOLLOWNODE_KUBECONFIGinternal 或 local kubeconfig MASTER_IP$(grep server ${HOLLOWNODE_KUBECONFIG} | awk -F / {print $3}) start-hollow-nodes resize-node-objects5.1 构建并推送 hollow-node 镜像start-hollow-nodesL213-L219第一步是create-and-upload-hollow-node-imageL48-L71调用 provider 的authenticate-docker完成镜像仓库认证pre-existing 未覆写走 skeleton 实现生成 6 位随机KUBEMARK_IMAGE_TAG避免多次运行互相覆盖查找平台对应的kubemark编译产物找不到即报错退出拷贝到 cluster/images/kubemark 目录以REGISTRY${KUBEMARK_IMAGE_REGISTRY} IMAGE_TAG${KUBEMARK_IMAGE_TAG}执行make ${KUBEMARK_IMAGE_MAKE_TARGET}构建并推送镜像——这就是配置中KUBEMARK_IMAGE_MAKE_TARGETpush的落点。5.2 在 host cluster 中创建 hollow-node 相关资源create-kube-hollow-node-resourcesL80-L170通过cluster/kubectl.sh作用于本地 kubeconfig 指向的 host cluster依次创建kubemark 命名空间kubectl create -f resources/kubemark-ns.jsonnode-configmap配置 hollow kubelet、proxy、npd 的 ConfigMapkubeconfig Secret把指向 Kubemark Master 的 kubeconfig 以kubelet.kubeconfig、kubeproxy.kubeconfig、npd.kubeconfig等多个键注入kubeconfigSecret——hollow-node Pod 正是凭这份 kubeconfig 与 Master而非 host cluster 自己的控制面通信从而在 Master 眼中表现为节点addon Podheapster监控、可选的 Cluster Autoscaler 与 kube-dns由ENABLE_KUBEMARK_*开关控制见 L115-L133hollow-node 复制控制器由hollow-node_template.yaml经sed模板替换生成关键替换项包括{{numreplicas}}→NUM_REPLICAS默认取NUM_NODES{{master_ip}}→MASTER_IP即 hollow-node 要连接的控制面地址kubelet/proxy/npd 的 millicpu 与内存Ki如KUBEMARK_HOLLOW_KUBELET_MILLICPU:-40、KUBEMARK_HOLLOW_PROXY_MEM_PER_NODE_KB:-50且节点数超过 1000 时 proxy CPU 自动从 20m 提到 50mL141-L147{{hollow_kubelet_params}}/{{hollow_proxy_params}}→ 来自HOLLOW_KUBELET_TEST_ARGS/HOLLOW_PROXY_TEST_ARGS的测试参数pre-existing 版 config 中默认继承KUBELET_TEST_LOG_LEVEL/KUBEPROXY_TEST_LOG_LEVEL之外的空值可按需注入--v等日志级别。5.3 等待节点就绪与节点对象增肥wait-for-hollow-nodes-to-run-or-timeoutL173-L208用 Kubemark kubeconfig 每秒轮询kubectl get node统计 Ready 数量直至达到NUM_REPLICAS超时上限 30 分钟超时后打印 node describe、hollow-node Pod 的 Running/非 Running 统计并提示可能是 API Server 不可用resize-node-objectsL225-L236若设置了KUBEMARK_NODE_OBJECT_SIZE_BYTES会给每个 Node 对象附加一个随机大 label使其对象体积接近真实节点让 API Server 存储压力更贴近现实源码注释中说明这是过渡手段未来计划由 ClusterLoader 的镜像预加载替代。流程结束时会输出Master IP: ${MASTER_IP} Kubeconfig for kubemark master is written in ${LOCAL_KUBECONFIG}其中LOCAL_KUBECONFIG为test/kubemark/resources/kubeconfig.kubemark是后续运行 e2e 测试时访问 Kubemark 集群的入口。6. 停止流程stop-kubemark.sh 只清理集群内资源不动你的 Masterstop-kubemark.sh 的清理逻辑detect-project /dev/null ${KUBECTL} delete --timeout5m -f ${RESOURCE_DIRECTORY}/addons --namespacekubemark /dev/null || true ${KUBECTL} delete --timeout5m -f ${RESOURCE_DIRECTORY}/hollow-node.yaml --namespacekubemark /dev/null || true ${KUBECTL} delete --timeout5m -f ${RESOURCE_DIRECTORY}/kubemark-ns.json /dev/null || true rm -rf ${RESOURCE_DIRECTORY}/addons \ ${RESOURCE_DIRECTORY}/kubeconfig.kubemark \ ${RESOURCE_DIRECTORY}/hollow-node.yaml /dev/null || true delete-kubemark-master与启动流程对称删除 host cluster 中的 kubemark 命名空间、addon 与 hollow-node 控制器并清理本地生成的 manifest/kubeconfig 文件末尾的delete-kubemark-master对 pre-existing 同样是 skeleton 空操作——自备的 Master VM 不会被动过由开发者自行销毁。这与 README 中脚本不会创建/管理基础设施的承诺一致。7. 在 Kubemark 上跑 e2e 测试集群就绪后run-e2e-tests.sh 负责把测试指向 Kubemark 控制面export KUBERNETES_PROVIDERkubemark export KUBE_MASTER_URLhttps://${KUBE_MASTER_IP} export KUBECONFIG${ABSOLUTE_ROOT}/test/kubemark/resources/kubeconfig.kubemark export E2E_MIN_STARTUP_PODS0 ... ${KUBE_ROOT}/hack/ginkgo-e2e.sh --e2e-verify-service-accountfalse --dump-logs-on-failurefalse ${ARGS[]}要点通过 cluster/kubemark/util.sh 间接复用 provider 配置它再次 sourcecluster/kubemark/${CLOUD_PROVIDER}/config-default.sh因此 pre-existing 下MASTER_NAME等变量同样生效KUBECONFIG被强制指向 start 阶段生成的test/kubemark/resources/kubeconfig.kubemark即测试对象是 Kubemark Master 而非 host cluster参数中的[/]ginkgo 测试过滤语法会被转义后透传给 hack/ginkgo-e2e.sh。8. 落地检查清单Self-check按 README 要求清单 结合源码pre-existing 模式下动手前逐项确认Master 可达性Kubemark Master 已部署且 API 可在$MASTER_IP可带端口如:6443访问——对应 config-default.sh 的注释与示例SSH 链路执行脚本的宿主机可ssh kubernetes$MASTER_IP——这是 pre-existing/util.sh 中execute-cmd-on-pre-existing-master-with-retries的硬依赖用户名必须为kubernetes镜像可推送CONTAINER_REGISTRY/$PROJECT有写权限KUBEMARK_IMAGE_MAKE_TARGET如push与仓库类型匹配且 host cluster 能拉取该镜像hollow-node Pod 跑在 host cluster 里本地 kubeconfigcluster/kubectl.sh使用的本地 kubeconfig 指向 host cluster且账号具备创建 kubemark 命名空间、Secret、ConfigMap 与 ReplicaSet 的权限规模参数NUM_NODES决定 hollow-node 副本数pre-existing 默认 1hollow-node Pod 的资源配额KUBEMARK_HOLLOW_*系列变量需与 host cluster 实际容量匹配测试入口e2e 阶段使用test/kubemark/resources/kubeconfig.kubemark访问 Kubemark Master。9. 小结pre-existing provider 是 Kubemark 工具链中最薄的一层它不替你创建 Master、不管理 VM 生命周期只负责把 hollow-node 这套 Pod 正确部署到 host cluster 并指向你自备的 MasterREADME。换来的是对控制面拓扑、镜像来源、节点规模的完全自定义能力适合需要在异构环境自建机房、其他云、既有实验环境中复用 test/kubemark 脚本与 e2e 框架的高级用户。核心入口文件只有四个配置 test/kubemark/cloud-provider-config.sh、默认值 cluster/kubemark/pre-existing/config-default.sh、SSH 工具 test/kubemark/pre-existing/util.sh、启停脚本 start-kubemark.sh / stop-kubemark.sh围绕它们即可完整掌握该 provider 的全部行为边界。【免费下载链接】kubernetesProduction-Grade Container Scheduling and Management项目地址: https://gitcode.com/GitHub_Trending/kuber/kubernetes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
