ZKE：把 Kubernetes 多集群控制台做成 macOS 风格的 Web Desktop

ZKE （ Z Kubernetes Engine ）是一款面向私有网络与混合云环境的开源 Kubernetes 多集群管理平台。每个集群中的 Agent 通过 QUIC/mTLS 主动连接 Server ；浏览器端 Console 采用 macOS 风格的桌面式交互，将资源管理、终端、权限与审计组织在同一个工作空间中。

项目地址：github.com/togettoyou/zke

在线体验：https://fbcupchhlacp.sealosbja.site/

体验账号：view
体验密码：LECQkqcp2tQ5Yh8

@main/2026/08/12/1786504166758-f0dcf656-bbd1-42cb-bebe-0998a17eacb1.png" alt="" />

多集群管理

在多集群场景中，仅把资源展示出来还不够，还要处理网络与作用域两层问题。

第一层是网络。位于中心侧的管理平台未必能够主动访问私有网络、边缘机房或独立安全域中的 Kubernetes API Server 。根据网络边界和安全策略，团队可能需要维护专线、VPN 、反向代理或额外的跳板入口。

第二层是作用域。运维人员从一个集群切换到另一个集群时，界面看起来可能没有明显变化，但操作目标已经变了。查询可以汇总，写操作却必须精确落到某个 Cluster 、Namespace 和资源对象。权限、确认和审计如果没有携带相同的作用域，多集群入口反而会放大误操作风险。

ZKE 给出的原则很直接：

全局观察，按集群执行。

用户可以从全局入口查看有权访问的资源，但集群资源查询和操作都会定域到明确的目标集群。全局视图不等于全局操作权限。

第一眼亮点：把控制台做成桌面

ZKE 最直观的区别不是表格多了几列，而是 Console 采用了一套运行在浏览器中的桌面式交互界面。

集群接入管理、组织与资源、访问与审计、容器服务和终端都以独立应用存在。用户可以从桌面或 Dock 打开应用，在窗口之间切换、最小化、最大化，并保存自己的桌面布局和工作作用域。

这种设计并不只是视觉模仿。多集群运维很少是一条从上到下的单页面流程。排查一个异常工作负载时，操作者可能同时需要资源详情、事件、Pod 日志和终端。多窗口让这些上下文保留在同一个工作空间中，最小化终端窗口也不会被当成关闭会话。

@main/2026/08/12/1786504361342-ed674f3c-3ab3-4bcb-90df-23fcc7873fc6.png" alt="" />

QUIC + Agent ，面向私有网络的主动连接模型

ZKE 的核心连接模型是 Server + Agent 。每个接入集群内部署一个 ZKE Agent ，由 Agent 主动连接 ZKE Server ，而不是要求 Server 主动访问每个 Kubernetes API Server 。

连接过程可以概括为四步：

1. Server 创建一次性 Enrollment Token ；
2. Agent 在目标集群中完成注册并取得绑定身份的客户端证书；
3. Agent 使用 QUIC/mTLS 主动建立长期连接；
4. Server 将经过认证和授权的 Kubernetes 资源请求与集群操作，通过对应 Agent 定域到目标集群执行。

@main/2026/08/12/1786504417036-f880e6bc-826b-44c2-a2cc-37c8e9a43a57.png" alt="" />

不只好看，多项日常运维主链路已经打通

ZKE 的容器服务已经覆盖多类高频 Kubernetes 操作。除了 Node 、Namespace 、Pod 、Deployment 、StatefulSet 、DaemonSet 、Job 和 CronJob ，还包括 Service 、Ingress 、ConfigMap 、存储、HPA 、策略资源与 Kubernetes RBAC 资源。

对不在类型化页面中的资源，ZKE 提供基于 Kubernetes Discovery 的资源对象浏览器，支持 CRD 、自定义资源以及 YAML 查看与编辑。Secret 、Event 和 Kubernetes 授权资源不通过这个通用入口开放，而是使用专用能力或保持拒绝。多文档清单的应用与删除也位于独立入口。

@main/2026/08/12/1786504669505-088c0353-36e8-48e2-8cad-983a3b884f3a.png" alt="" />

排障方面，工作负载诊断会把关联对象和 Kubernetes Event 组织在一起，帮助减少操作者在多个页面之间手工拼接故障上下文的工作。

@main/2026/08/12/1786504478845-859ad6aa-026d-411b-a37e-e56c1773e97b.png" alt="" />

Pod 日志支持有界快照和实时 Follow ，终端通过一次性票据、权限重验和独立 QUIC Stream 建立会话。

@main/2026/08/12/1786504527305-b2af53a5-5c85-45d1-bc56-5fd769a5d985.png" alt="" />

对于只在 Pod 内监听的 HTTP 服务，ZKE 还能创建受限的临时访问入口。

@main/2026/08/12/1786504570653-9f5ae9fc-931f-4b2a-b732-c14e649bcd29.png" alt="" />

敏感操作不能只靠一句“确定吗”

更新工作负载、删除资源、进入容器、打开临时访问地址和修改授权关系，都属于需要明确控制的敏感操作。

ZKE 没有把安全边界只放在前端按钮上。权限由 Server 根据 Global 、Tenant 、Project 和目标 Cluster 进行校验，前端的隐藏或禁用只用于能力提示，不能替代服务端授权。

根据操作类型，ZKE 的 Kubernetes 写入链路会组合使用以下保护：

• 目标定域： 展示 Cluster 、Namespace 、资源名称和资源身份；
• DryRun： 先由目标 Kubernetes API Server 完成预检，不直接持久化；
• 差异确认： 在提交前展示 Kubernetes DryRun 后的最终对象差异；
• 并发保护： 使用 UID 与 resourceVersion 拒绝覆盖同名重建或已经变化的对象；
• 幂等保护： 网络结果不确定时，抑制同一幂等键对应的重复执行；
• 审计留痕： 记录发起者、目标作用域、操作类型、结果和时间，不记录 Token 、Secret 正文等敏感内容。

@main/2026/08/12/1786504712185-0f39a99d-3784-4920-80a8-25d4a948b041.png" alt="" />

角色和权限绑定同样受到作用域限制与提权防护。一个人能管理角色，不代表他可以把自己没有的权限写进角色或绑定给其他账号。

@main/2026/08/12/1786504762152-07384e1d-bee4-4d0a-a488-b49c0309b005.png" alt="" />

ZKE 接下来会做什么

ZKE 当前已经完成平台基础、集群接入与容器服务的主要链路。后续规划集中在两个方向：

• 多集群可观测性，计划整合指标、日志、事件、告警和资源对比；
• AI 运维与排障助手（ Copilot ），计划结合资源状态、事件、日志和指标辅助分析问题，并继续遵守原有权限、确认和审计边界。

如果你正在管理私有网络、混合云或边缘环境中的多个 Kubernetes 集群，可以体验一下 ZKE 的思路：让 Agent 主动连接，让每次操作明确目标，再把复杂能力装进一个更自然的桌面工作空间。