naveen-vijay94/stargazer

# stargazer **一个基于 EKS 的生产级 GitOps 平台，配备 AI 事件响应代理，能够进行诊断、提出建议，并在获得人工批准后进行修复。** 🚧 **状态：早期开发中。** 本仓库正以公开方式逐步构建——会有脚手架代码、开发中的功能以及真实的提交记录。可以通过 [Issues](../../issues) 和 [Milestones](../../milestones) 关注进展。 ## 这是什么 在同一个架构上按顺序构建的两件事： **阶段 1 — 平台。** 使用 Terraform 从零开始配置的完整 EKS 环境：通过 ArgoCD 实现基于拉取的 GitOps，使用 OPA Gatekeeper 进行策略强制执行，默认拒绝的网络策略，全链路可观测性（Prometheus / Grafana / Loki），以及通过 Argo Rollouts 实现带有自动回滚的金丝雀部署。在 [kind](https://kind.sigs.k8s.io/) 上进行本地开发；在真实的 EKS 上进行验证。 **阶段 2 — 代理。** 一个接入 Alertmanager 的 AI SRE 代理（通过 AWS Bedrock 使用 Claude）。当警报触发时，它会使用只读的 MCP 工具（PromQL、Loki 查询、Kubernetes API）进行调查，以 GitHub issue 的形式发布结构化的诊断结果，从允许列表的 runbook 库中提取补救措施并以 pull request 的形式提出建议，且仅在获得人工批准后执行。其准确性是针对一套脚本化混沌场景进行衡量的——评估表将直接放在本 README 中。 ## 工作负载 该平台运行着一个特意设计为可破坏的演示系统——一个 Pokémon 队伍分析服务： - **`teambuilder-api`** (Go) — 接受队伍进行分析的 REST API；通过 gRPC 进行同步路径处理，通过 Redis 队列进行异步处理 - **`analyzer-worker`** (Go) — 计算属性克制覆盖率；提供 gRPC 服务，消费队列 - **`loadgen`** (Python) — 持续的真实流量：正弦波基准、随机激增、自然错误混合 每个服务都内置了**故障注入接口**（错误率、延迟、内存泄漏、崩溃循环、静默死锁——可在运行时切换）。工作负载本身不是重点；它是供平台进行修复的故障实验室。 ## 架构 ``` GitHub (source of truth) ├─ terraform/ ──▶ provisions VPC, EKS, IAM/IRSA, ECR ├─ apps/ ──▶ ArgoCD (pull-based) ──▶ workloads on EKS/kind └─ agent/ ──▶ the Phase 2 brain Incident path: Prometheus alert ─▶ Alertmanager ─▶ agent ─▶ MCP tools (kubectl / PromQL / Loki) ─▶ diagnosis (GitHub issue) ─▶ runbook proposal (PR) ─▶ human approval ─▶ gated execution ``` 完整的架构细节和设计原理以架构决策记录的形式存放在 [`docs/`](docs/) 中——从为什么选择 ArgoCD 而不是 Flux，为什么优先在 kind 上进行本地开发，以及为什么代理只建议而不直接行动开始。 ## 技术栈 Terraform · EKS (spot) · kind · ArgoCD · Argo Rollouts · OPA Gatekeeper · Prometheus · Grafana · Loki · Go · Python · gRPC (buf) · Redis · AWS Bedrock 上的 Claude · GitHub Actions ## 路线图 完全在本仓库中进行跟踪：[Milestones](../../milestones) 对应构建阶段，每个任务都是一个标记为 `deep-work` 或 `shallow-work` 的 issue。阶段 1（平台）将首先交付并独立运行；阶段 2（代理）将在此之上构建。 ## 许可证 [MIT](LICENSE)

标签：AI运维, ECS, EKS, GitOps, Python工具, Terraform, 搜索引擎查询, 日志审计, 混沌工程, 自定义请求头, 逆向工具