ZKE：把 Kubernetes 多集群控制台做成 macOS 风格的 Web Desktop
ZKE （ Z Kubernetes Engine ）是一款面向私有网络与混合云环境的开源 Kubernetes 多集群管理平台。每个集群中的 Agent 通过 QUIC/mTLS 主动连接 Server ；浏览器端 Console 采用 macOS 风格的桌面式交互，将资源管理、终端、权限与审计组织在同一个工作空间中。
项目地址：[github.com/togettoyou/zke](http://github.com/togettoyou/zke)
在线体验：[https://fbcupchhlacp.sealosbja.site/](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 。
连接过程可以概括为四步：
1. Server 创建一次性 Enrollment Token ；
2. Agent 在目标集群中完成注册并取得绑定身份的客户端证书；
3. Agent 使用 QUIC/mTLS 主动建立长期连接；
4. 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 主动连接，让每次操作明确目标，再把复杂能力装进一个更自然的桌面工作空间。
---
原文链接：[点击查看](https://www.v2ex.com/t/1233876)
项目地址：[github.com/togettoyou/zke](http://github.com/togettoyou/zke)
在线体验：[https://fbcupchhlacp.sealosbja.site/](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 。
连接过程可以概括为四步：
1. Server 创建一次性 Enrollment Token ；
2. Agent 在目标集群中完成注册并取得绑定身份的客户端证书；
3. Agent 使用 QUIC/mTLS 主动建立长期连接；
4. 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 主动连接，让每次操作明确目标，再把复杂能力装进一个更自然的桌面工作空间。
---
原文链接：[点击查看](https://www.v2ex.com/t/1233876)
评论
暂无评论。