国内用户如果访问异常，可以访问Gitee同步站：https://gitee.com/starsl/KubeDoor
🌼花折 - KubeDoor 是一个使用Python + Vue开发，基于K8S准入控制机制的微服务资源管控平台，以及支持多K8S集群统一远程存储、监控、告警、通知、展示的一站式K8S监控平台，并且专注微服务每日高峰时段的资源视角，实现了微服务的资源分析统计与强管控，确保微服务资源的资源申请率和真实使用率一致。
- 🌊支持多K8S集群统一远程存储、监控、告警、通知、展示的一站式K8S监控方案。
- 📀Helm一键部署完成监控、采集、展示、告警、通知（多K8S集群监控从未如此简单✨）。
- 🚀基于VictoriaMetrics全套方案实现多K8S统一监控，统一告警规则管理，实现免配置完整指标采集。
- 🎨WEBUI集成了K8S节点监控看板与K8S资源监控看板，均支持在单一看板中查看各个K8S集群的资源情况。
- 📐集成了大量K8S资源与K8S节点的告警规则，并支持统一维护管理，支持对接企微，钉钉，飞书异常告警通知。
- 🐛修复了采集高峰期指标经常失败，获取不到值的BUG。
- 🎨基于日维度采集每日高峰时段P95的资源数据,可以很好的观察各微服务长期的资源变化情况，即使查看1年的数据也很流畅。
- 🏅高峰时段全局资源统计与各资源TOP10
- 🔎命名空间级别高峰时段P95资源使用量与资源消耗占整体资源的比例
- 🧿微服务级别高峰期整体资源与使用率分析
- 📈微服务与Pod级别的资源曲线图(需求值,限制值,使用值)
- ✨基于准入控制机制实现K8S微服务资源的真实使用率和资源申请需求值保持一致，具有非常重要的意义。
- 🌊K8S调度器通过真实的资源需求值就能够更精确地将Pod调度到合适的节点上，避免资源碎片，实现节点的资源均衡。
- ♻K8S自动扩缩容也依赖资源需求值来判断，真实的需求值可以更精准的触发扩缩容操作。
- 🛡K8S的保障服务质量（QoS机制）与需求值结合，真实需求值的Pod会被优先保留，保证关键服务的正常运行。
- ⚙️对微服务的最新、每日高峰期的P95资源展示，以及对Pod数、资源限制值的维护管理。
- ⏱️支持即时、定时、周期性任务执行微服务的扩缩容和重启操作。
- 🔒基于NGINX basic认证，支持LDAP，支持所有操作审计日志与通知。
- 📊在前端页面集成Grafana看板,更优雅的展示与分析采集的微服务数据。
- 🧮控制每个微服务的Pod数、需求值、限制值必须与数据库一致，以确保微服务的真实使用率和资源申请需求值相等，从而实现微服务的统一管控与Pod的负载感知调度均衡能力。
- 🚫对未管控的微服务，会部署失败并通知，必须在WEB UI新增微服务后才能部署。（作为新增微服务的唯一管控入口，杜绝未经允许的新服务部署。）
- 🌟通过本项目基于K8S准入机制的扩展思路，大家可以自行简单定制需求，即可对K8S实现各种高灵活性与扩展性附加能力，诸如统一或者个性化的拦截、管理、策略、标记微服务等功能。
- 📅KubeDoor 项目进度
- 🥇多K8S支持：在统一的WebUI对多K8S做管控和资源分析展示。
- 🥈英文版发布
- 🥉集成K8S实时监控能力，实现一键部署，整合K8S实时资源看板，接入K8S异常AI分析能力。
- 🏅微服务AI评分：根据资源使用情况，发现资源浪费的问题，结合AI缩容，降本增效，做AI综合评分。
- 🏅微服务AI缩容：基于微服务高峰期的资源信息，对接AI分析与专家经验，计算微服务Pod数是否合理，生成缩容指令与统计。
- 🏅根据K8S节点资源使用率做节点管控与调度分析
- 🚩采集更多的微服务资源信息: QPS/JVM/GC
- 🚩针对微服务Pod做精细化操作：隔离、删除、dump、jstack、jfr、jvm
需要有cadvisor和kube-state-metrics这2个JOB，才能采集到K8S的以下指标
container_cpu_usage_seconds_totalcontainer_memory_working_set_bytescontainer_spec_cpu_quotakube_pod_container_infokube_pod_container_resource_limitskube_pod_container_resource_requests
用于K8S Mutating Webhook的强制https认证
# 镜像已替换为国内镜像
kubectl apply -f https://StarsL.cn/kubedoor/00.cert-manager_v1.16.2_cn.yaml
用于存储采集的指标数据与微服务的资源信息
# 默认使用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.sqlwget https://StarsL.cn/kubedoor/kubedoor-0.3.0.tgz
tar -zxvf kubedoor-0.3.0.tgz
# 编辑values.yaml文件，请仔细阅读注释，根据描述修改配置内容。
vim kubedoor/values.yaml
# 使用helm安装（注意在kubedoor目录外执行。）
helm install kubedoor ./kubedoor
# 安装完成后，所有资源都会部署在kubedoor命名空间。-
使用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：
-
后端技术栈
-
前端技术栈
-
特别鸣谢
- CassTime：KubeDoor的诞生离不开🦄开思的支持。