花折 - KubeDoor 正式开源：基于 AI 推荐+专家经验的 K8S 负载感知调度与容量管控系统

🌈概述

🌼花折 - KubeDoor 是一个使用 Python + Vue 开发，基于 K8S 准入控制机制的微服务资源管控平台。专注微服务每日高峰时段的资源视角，实现了微服务的资源分析统计与强管控，确保微服务资源的资源申请率和真实使用率一致。📀项目仓库： https://github.com/CassInfra/KubeDoor

💠架构图

💎功能描述

📊采集 K8S 微服务每日业务高峰时段 P95 的 CPU 内存消耗，以及需求、限制值与 Pod 数。基于采集的数据实现了一个 Grafana 看板并集成到了 WEB UI 。

🎨基于日维度采集每日高峰时段 P95 的资源数据,可以很好的观察各微服务长期的资源变化情况，即使查看 1 年的数据也很流畅。
🏅高峰时段全局资源统计与各资源 TOP10
🔎命名空间级别高峰时段 P95 资源使用量与资源消耗占整体资源的比例
🧿微服务级别高峰期整体资源与使用率分析
📈微服务与Pod 级别的资源曲线图(需求值,限制值,使用值)

🎡每日从采集的数据中，获取最近 10 天各微服务的资源信息，获取资源消耗最大日的 P95 资源，作为微服务的需求值写入数据库。

✨基于准入控制机制实现 K8S 微服务资源的真实使用率和资源申请需求值保持一致，具有非常重要的意义。
🌊K8S 调度器通过真实的资源需求值就能够更精确地将 Pod 调度到合适的节点上，避免资源碎片，实现节点的资源均衡。
♻K8S 自动扩缩容也依赖资源需求值来判断，真实的需求值可以更精准的触发扩缩容操作。
🛡K8S 的保障服务质量（ QoS 机制）与需求值结合，真实需求值的 Pod 会被优先保留，保证关键服务的正常运行。

🌐实现了一个 K8S 管控与展示的 WEB UI 。

⚙️对微服务的最新、每日高峰期的P95 资源展示，以及对Pod 数、资源限制值的维护管理。
⏱️支持即时、定时、周期性任务执行微服务的扩缩容和重启操作。
🔒基于 NGINX basic认证，支持 LDAP ，支持所有操作审计日志与通知。
📊在前端页面集成 Grafana 看板,更优雅的展示与分析采集的微服务数据。

🚧当微服务更新部署时，基于 K8S 准入控制机制对资源进行管控 [默认不开启] ：

🧮控制每个微服务的 Pod 数、需求值、限制值必须与数据库一致，以确保微服务的真实使用率和资源申请需求值相等，从而实现微服务的统一管控与 Pod 的负载感知调度均衡能力。
🚫对未管控的微服务，会部署失败并通知，必须在 WEB UI 新增微服务后才能部署。（作为新增微服务的唯一管控入口，杜绝未经允许的新服务部署。）
🌟通过本项目基于K8S 准入机制的扩展思路，大家可以自行简单定制需求，即可对 K8S 实现各种高灵活性与扩展性附加能力，诸如统一或者个性化的拦截、管理、策略、标记微服务等功能。

<center>K8S 准入控制逻辑</center>

如果觉得项目不错，麻烦动动小手点个⭐️Star⭐️ 如果你还有其他想法或者需求，欢迎在 issue 中交流

📀项目仓库： https://github.com/CassInfra/KubeDoor

🎯2025 KubeDoor RoadMap

📅KubeDoor 项目进度 https://github.com/orgs/CassInfra/projects/1
🥇多 K8S 支持：在统一的 WebUI 对多 K8S 做管控和资源分析展示。
🥈英文版发布
🥉集成 K8S 实时监控能力，实现一键部署，整合 K8S 实时资源看板，接入 K8S 异常 AI 分析能力。
🏅微服务 AI 评分：根据资源使用情况，发现资源浪费的问题，结合 AI 缩容，降本增效，做 AI 综合评分。
🏅微服务 AI 缩容：基于微服务高峰期的资源信息，对接 AI 分析与专家经验，计算微服务 Pod 数是否合理，生成缩容指令与统计。
🏅根据 K8S 节点资源使用率做节点管控与调度分析
🚩采集更多的微服务资源信息: QPS/JVM/GC
🚩针对微服务 Pod 做精细化操作：隔离、删除、dump 、jstack 、jfr 、jvm

🚀部署说明

0. 需要已有 Prometheus 监控 K8S

需要有cadvisor和kube-state-metrics这 2 个 JOB ，才能采集到 K8S 的以下指标

container_cpu_usage_seconds_total
container_memory_working_set_bytes
container_spec_cpu_quota
kube_pod_container_info
kube_pod_container_resource_limits
kube_pod_container_resource_requests

1. 部署 Cert-manager

用于 K8S Mutating Webhook 的强制 https 认证

kubectl apply -f https://StarsL.cn/kubedoor/00.cert-manager_v1.16.2_cn.yaml

2. 部署 ClickHouse 并初始化

用于存储采集的指标数据与微服务的资源信息

# 默认使用 docker compose 运行，部署在/opt/clickhouse 目录下。
curl -s https://StarsL.cn/kubedoor/install-clickhouse.sh|sudo bash
# 启动 ClickHouse （启动后会自动初始化表结构）
cd /opt/clickhouse && docker compose up -d

如果已有 ClickHouse ，请逐条执行以下 SQL ，完成初始化表结构

https://StarsL.cn/kubedoor/kubedoor-init.sql

3. 部署 KubeDoor

wget https://StarsL.cn/kubedoor/kubedoor.tgz
tar -zxvf kubedoor.tgz
# 编辑 values.yaml 文件，请仔细阅读注释，根据描述修改配置内容。
vim kubedoor/values.yaml
# 使用 helm 安装（注意在 kubedoor 目录外执行。）
helm install kubedoor ./kubedoor
# 安装完成后，所有资源都会部署在 kubedoor 命名空间。

4. 访问 WebUI 并初始化数据

使用 K8S 节点 IP + kubedoor-web 的 NodePort 访问，默认账号密码都是 kubedoor
点击配置中心，输入需要采集的历史数据时长，点击采集并更新，即可采集历史数据并更新高峰时段数据到管控表。

默认会从 Prometheus 采集 10 天数据(建议采集 1 个月)，并将 10 天内最大资源消耗日的数据写入到管控表，如果耗时较长，请等待采集完成或缩短采集时长。重复执行采集并更新不会导致重复写入数据，请放心使用，每次采集后都会自动将 10 天内最大资源消耗日的数据写入到管控表。
点击管控状态的开关，显示管控已启用，表示已开启。

⛔注意事项

部署完成后，默认不会开启管控机制，你可以按上述操作通过 WebUI 来开关管控能力。特殊情况下，你也可以使用kubectl来开关管控功能：
```
# 开启管控
kubectl apply -f https://StarsL.cn/kubedoor/99.kubedoor-Mutating.yaml

# 关闭管控
kubectl delete mutatingwebhookconfigurations kubedoor-webhook-configuration
```
开启管控机制后，目前只会拦截deployment 的创建，更新，扩缩容操作；管控pod 数，需求值，限制值。不会控制其它操作和属性。
开启管控机制后，通过任何方式对 Deployment 执行扩缩容或者更新操作都会受到管控。
开启管控机制后，扩缩容或者重启 Deployment 时，Pod 数优先取指定 Pod字段，若该字段为-1 ，则取当日 Pod字段。

🌰管控例子

你通过 Kubectl 对一个 Deployment 执行了扩容 10 个 Pod 后，会触发拦截机制，到数据库中去查询该微服务的 Pod ，然后使用该值来进行实际的扩缩容。（正确的做法应该是在 KubeDoor-Web 来执行扩缩容操作。）
你通过某发布系统修改了 Deployment 的镜像版本，执行发布操作，会触发拦截机制，到数据库中去查询该微服务的 Pod 数，需求值，限制值，然后使用这些值值以及新的镜像来进行实际的更新操作。

🚩管控原则

你对 deployment 的操作不会触发 deployment 重启的，也没有修改 Pod 数的： 触发管控拦截后，只会按照你的操作来更新 deployment （不会重启 Deployment ）
你对 deployment 的操作不会触发 deployment 重启的，并且修改 Pod 数的： 触发管控拦截后，Pod 数会根据数据库的值以及你修改的其它信息来更新 Deployment 。（不会重启 Deployment ）
你对 deployment 的操作会触发 deployment 重启的： 触发管控拦截后，会到数据库中去查询该微服务的 Pod 数，需求值，限制值，然后使用这些值以及你修改的其它信息来更新 Deployment 。（会重启 Deployment ）

🥰鸣谢

感谢如下优秀的项目，没有这些项目，不可能会有KubeDoor：

后端技术栈
- Flask
- Grafana
- Nginx
前端技术栈
特别鸣谢
- CassTime：KubeDoor的诞生离不开🦄开思的支持。