153 lines
6.3 KiB
Markdown
153 lines
6.3 KiB
Markdown
|
---
|
|||
|
|
tags: [wayne, preview, infra]
|
|||
|
|
create time: 2026-07-04 12:00
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# Wayne 多集群容器管理平台
|
|||
|
|
|
|||
|
|
## 概述
|
|||
|
|
|
|||
|
|
Wayne（由 360 开源）是一个基于 Web 的多集群 Kubernetes 容器管理平台，支持通过可视化的方式创建、管理 Deployment 和 Service。xininfra 平台将其作为核心的**服务发布入口**——开发同学无需直接操作 kubectl，通过 Wayne UI 或 API 即可完成服务部署。
|
|||
|
|
|
|||
|
|
> [!info] 背景
|
|||
|
|
> Wayne 已大规模服务于 360 搜索内部，稳定管理近千个业务、上万个容器，运行两年以上。命名源于 DC 漫画角色「Bruce Wayne」（蝙蝠侠）。
|
|||
|
|
|
|||
|
|
## 核心概念
|
|||
|
|
|
|||
|
|
### 架构概览
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
graph LR
|
|||
|
|
subgraph 前端
|
|||
|
|
UI["Web UI / Angular + Ace Editor"]
|
|||
|
|
end
|
|||
|
|
subgraph 后端
|
|||
|
|
API["API Server / Beego (Go)"]
|
|||
|
|
Worker["Worker / 异步任务"]
|
|||
|
|
DB[("MySQL - 持久化存储")]
|
|||
|
|
end
|
|||
|
|
subgraph 底层
|
|||
|
|
K8s1[K8s Cluster A]
|
|||
|
|
K8s2[K8s Cluster B]
|
|||
|
|
K8N[...]
|
|||
|
|
end
|
|||
|
|
UI --> API
|
|||
|
|
API <--> DB
|
|||
|
|
API -->|"Client-Go"| K8s1
|
|||
|
|
API -->|"Client-Go"| K8s2
|
|||
|
|
API -->|"消息队列"| Worker
|
|||
|
|
Worker -->|"Audit / Webhook"| K8s1
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
核心交互：
|
|||
|
|
- **前端**：Angular 框架 + Ace Editor 实现 YAML 模板编辑，提供表单式部署界面
|
|||
|
|
- **后端**：Beego（Go 框架）处理 HTTP API → Client-Go 操作 K8s API，数据持久化到 MySQL
|
|||
|
|
- **Worker**：基于消息队列的异步任务组件，负责审计日志、Webhook 通知等
|
|||
|
|
- **数据库**：存储项目/用户/部门权限关系、YAML 模板版本历史、发布记录与审计数据
|
|||
|
|
|
|||
|
|
### 核心模型
|
|||
|
|
|
|||
|
|
| 模型 | 说明 |
|
|||
|
|
|------|------|
|
|||
|
|
| **Project** | 项目级分组，相当于 Git Repo 的映射 |
|
|||
|
|
| **Cluster** | 注册的 K8s 集群连接信息（kubeconfig） |
|
|||
|
|
| **Namespace** | 集群内的逻辑隔离空间 |
|
|||
|
|
| **Environment** | 环境（dev / staging / prod），用于区分不同阶段的部署 |
|
|||
|
|
| **Deployment** | 应用层面的容器编排配置 |
|
|||
|
|
| **Service** | 网络层面的服务暴露配置 |
|
|||
|
|
|
|||
|
|
### Wayne 与 K8s 对象的对应关系
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
Wayne Deployment YAML ──→ K8s Deployment + ConfigMap + Ingress
|
|||
|
|
Wayne Service YAML ──→ K8s Service
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Wayne 对这两种资源的 YAML 做了**标准化封装**，内置了一套模板体系：
|
|||
|
|
|
|||
|
|
```yaml
|
|||
|
|
# Wayne 中的 Deployment 模板骨架
|
|||
|
|
apiVersion: apps/v1
|
|||
|
|
kind: Deployment
|
|||
|
|
metadata:
|
|||
|
|
name: {{ .Release.Name }}
|
|||
|
|
spec:
|
|||
|
|
replicas: {{ .Env.Replicas | default 2 }}
|
|||
|
|
template:
|
|||
|
|
spec:
|
|||
|
|
containers:
|
|||
|
|
- name: {{ .ContainerName }}
|
|||
|
|
image: {{ .Image.Repository }}:{{ .Image.Tag }}
|
|||
|
|
ports:
|
|||
|
|
- containerPort: {{ .Container.Ports }}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Wayne 核心能力
|
|||
|
|
|
|||
|
|
| 能力 | 说明 | 对你的意义 |
|
|||
|
|
|------|------|-----------|
|
|||
|
|
| **RBAC 权限管理** | 用户通过角色关联部门与项目，部门角色 vs 项目角色分离 | 多租户场景下按团队划分资源边界 |
|
|||
|
|
| **简化 K8s 对象创建** | 基础模式（表单+模板）+ 高级模式（直接编辑 JSON/YAML） | 降低业务接入成本，无需记忆 kubectl 命令 |
|
|||
|
|
| **多集群管理** | 统一入口管理多个 K8s 集群，可针对集群定制配置 | xininfra 跨机房、跨集群部署的基础 |
|
|||
|
|
| **完整审计模块** | 每次操作留痕，支持自定义 Webhook 回调 | 故障追溯、合规检查的关键支撑 |
|
|||
|
|
| **发布历史与回滚** | 保存所有版本发布记录，一键回滚或基于旧版更新 | 生产安全的底线保障 |
|
|||
|
|
| **Web Shell** | 基于严格权限校验的 Pod 远程终端 | 排查线上问题的快捷通道 |
|
|||
|
|
| **资源报表** | 各项目资源使用占比、上线频次等图表 | 容量规划与成本分摊依据 |
|
|||
|
|
| **站内通知系统** | 管理员推送集群公告、故障报告等 | 信息同步通道 |
|
|||
|
|
| **APIKey 开放接口** | 用户可自助申请 APIKey 管理自己的部门/项目，运维可获取全局 APIKey 进行批量操作 | CI/CD 自动化的基础凭证 |
|
|||
|
|
|
|||
|
|
### 认证登录模式
|
|||
|
|
|
|||
|
|
Wayne 支持三种认证方式，适应不同企业的集成需求：
|
|||
|
|
|
|||
|
|
| 模式 | 适用场景 |
|
|||
|
|
|------|---------|
|
|||
|
|
| **DB 内置** | 独立运行，不依赖外部认证服务 |
|
|||
|
|
| **LDAP** | 与企业组织架构打通，同步部门用户 |
|
|||
|
|
| **OAuth 2.0** | 对接已有 SSO / Identity Provider |
|
|||
|
|
|
|||
|
|
> [!warning] 实习环境
|
|||
|
|
> xininfra 目前使用 DB 模式 + LDAP 混合架构。开发同学通过 LDAP 账号登录 Wayne，但权限分配由 xininfra 侧统一管控。
|
|||
|
|
|
|||
|
|
### API 对接思路
|
|||
|
|
|
|||
|
|
Wayne 提供 RESTful API，适合 CI/CD 流水线自动化调用：
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
# 1. 登录获取 token
|
|||
|
|
curl -X POST http://wayne-host/api/user/token/ \
|
|||
|
|
-H "Content-Type: application/json" \
|
|||
|
|
-d '{"username": "admin", "password": "wayne"}'
|
|||
|
|
|
|||
|
|
# 2. 基于模板创建 Deployment（GitLab CI 场景）
|
|||
|
|
curl -X POST http://wayne-host/api/project/{project-id}/environment/{env-id}/deployment/template/ \
|
|||
|
|
-H "Authorization: Bearer {token}" \
|
|||
|
|
-H "Content-Type: application/json" \
|
|||
|
|
-d '{"templateName": "my-service", ...}'
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
> [!tip] GitLab CI 对接 Wayne 的设计方向
|
|||
|
|
> 实习目标是开发 GitLab CI 自动触发 Wayne API 创建 Deployment 和 Service，流程大致为：
|
|||
|
|
> `CI 编译 → 镜像推送到 Registry → CI 调 Wayne API 传入镜像 tag → Wayne 执行部署`
|
|||
|
|
|
|||
|
|
## 常见陷阱与最佳实践
|
|||
|
|
|
|||
|
|
### 1. 权限模型要提前规划
|
|||
|
|
|
|||
|
|
Wayne 的 Project → Environment → Namespace 三级结构容易与实际的 K8s 权限边界不对齐。**建议**：每个业务团队一个 Project，按环境划分 Environment，避免多人混用同一命名空间。
|
|||
|
|
|
|||
|
|
### 2. YAML 模板版本管理
|
|||
|
|
|
|||
|
|
Wayne 允许保存多个 Deployment Template 版本。生产环境的模板应该锁定版本并纳入代码仓库，避免「今天能跑明天不行」的问题。
|
|||
|
|
|
|||
|
|
### 3. APIKey 权限边界要明确
|
|||
|
|
|
|||
|
|
运维人员的全局 APIKey 拥有所有集群和资源的操作权限。**原则**：给 CI/CD 流水线分配最小必要范围的 APIKey，限制其可操作的 Project 和环境范围，避免凭证泄漏导致大面积影响。
|
|||
|
|
|
|||
|
|
## 延伸阅读
|
|||
|
|
|
|||
|
|
- [[technical/xinfra-preview/k8s-rke2-fundamentals]] — Wayne 上层的 K8s 对象知识基础
|
|||
|
|
- [[technical/xinfra-preview/cloud-dm-overview]] — Wayne 部署的服务通常依赖 CloudDM 管理的 MySQL
|
|||
|
|
- [[technical/xinfra-preview/cachecloud-overview]] — Wayne 部署的服务可能使用 CacheCloud 管理的 Redis
|
|||
|
|
- https://github.com/Qihoo360/wayne — Wayne GitHub 仓库
|