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

多集群管理

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

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

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

ZKE 给出的原则很直接：

全局观察，按集群执行。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ZKE 接下来会做什么

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

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

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