# RendaCloudLab **Repository Path**: RendaZhang/renda-cloud-lab ## Basic Information - **Project Name**: RendaCloudLab - **Description**: Renda Cloud Lab:专注于云计算技术研究与开发的开源团队,提供高效、灵活的云服务解决方案,支持多场景应用。 - **Primary Language**: Shell - **License**: MIT - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 1 - **Forks**: 0 - **Created**: 2025-06-24 - **Last Updated**: 2025-09-07 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README ## 目录 (Table of Contents) - [Renda Cloud Lab](#renda-cloud-lab) - [简介](#%E7%AE%80%E4%BB%8B) - [核心模块说明](#%E6%A0%B8%E5%BF%83%E6%A8%A1%E5%9D%97%E8%AF%B4%E6%98%8E) - [目录结构](#%E7%9B%AE%E5%BD%95%E7%BB%93%E6%9E%84) - [项目结构与职责分层原则](#%E9%A1%B9%E7%9B%AE%E7%BB%93%E6%9E%84%E4%B8%8E%E8%81%8C%E8%B4%A3%E5%88%86%E5%B1%82%E5%8E%9F%E5%88%99) - [Terraform 仅负责 Infra 层(集群基础设施)](#terraform-%E4%BB%85%E8%B4%9F%E8%B4%A3-infra-%E5%B1%82%E9%9B%86%E7%BE%A4%E5%9F%BA%E7%A1%80%E8%AE%BE%E6%96%BD) - [Helm 脚本负责部署层](#helm-%E8%84%9A%E6%9C%AC%E8%B4%9F%E8%B4%A3%E9%83%A8%E7%BD%B2%E5%B1%82) - [实践总结](#%E5%AE%9E%E8%B7%B5%E6%80%BB%E7%BB%93) - [安装部署指南](#%E5%AE%89%E8%A3%85%E9%83%A8%E7%BD%B2%E6%8C%87%E5%8D%97) - [前置条件](#%E5%89%8D%E7%BD%AE%E6%9D%A1%E4%BB%B6) - [基础设施部署](#%E5%9F%BA%E7%A1%80%E8%AE%BE%E6%96%BD%E9%83%A8%E7%BD%B2) - [环境重建和销毁](#%E7%8E%AF%E5%A2%83%E9%87%8D%E5%BB%BA%E5%92%8C%E9%94%80%E6%AF%81) - [附录](#%E9%99%84%E5%BD%95) - [常见问题 (FAQ)](#%E5%B8%B8%E8%A7%81%E9%97%AE%E9%A2%98-faq) - [🤝 贡献指南](#-%E8%B4%A1%E7%8C%AE%E6%8C%87%E5%8D%97) - [🔐 License](#-license) - [📬 联系方式](#-%E8%81%94%E7%B3%BB%E6%96%B9%E5%BC%8F) # Renda Cloud Lab - **最后更新**: September 07, 2025, 01:00 (UTC+08:00) - **作者**: 张人大(Renda Zhang) > *专注于云计算技术研究与开发的开源实验室,提供高效、灵活的云服务解决方案,支持多场景应用。*

--- ## 简介 **Renda Cloud Lab** 实践了一套“每日自动销毁 -> 次日重建”的基础设施生命周期策略,以最大化节约 AWS 费用。云资源按需高效利用是本项目的重要考量。 **Renda Cloud Lab** 项目涵盖 **AWS 云服务、EKS、可观测性、SRE** 等前沿主题。 通过该实验室,开发者可以实践基础设施即代码、容器编排、持续交付、混沌工程等技术场景。 更多需求与功能状态请参见 [功能需求与规划](docs/REQUIREMENTS.md)。 --- ## 核心模块说明 本项目围绕云原生领域的多个核心模块展开,包括但不限于: - **IaC (Infrastructure as Code)** — 使用 `Terraform` 管理 AWS 基础设施。 - **容器 & 编排** — 基于 `Docker` 容器、`Kubernetes` (托管于 EKS) 进行应用部署。 - **可观测性 & SRE** — 集成 metrics-server、ADOT Collector(remote_write 至 AMP)与 Grafana,支持可选安装 Chaos Mesh 实践混沌工程。 - **成本 & 安全护栏** — 利用 Spot 实例与 IRSA 控制成本与权限,并提供 S3 前缀生命周期清理等基础护栏。 - **自动扩缩容 (Cluster Autoscaler)** — 通过脚本式 `Helm` 安装 `cluster-autoscaler`,实现节点数量根据负载弹性伸缩 - **负载均衡控制器 (AWS Load Balancer Controller)** — Terraform 仅预置 IRSA,ServiceAccount 由 `scripts/lifecycle/post-recreate.sh` 刷新 kubeconfig 并等待集群就绪后创建并注解,Helm 安装后即可管理 ALB Ingress 上述模块相互协作,构成了一个完整的云原生实验环境。 --- ## 目录结构 ```text ├─ deploy/ # 应用与系统的部署配置(Helm values、K8s manifests) │ ├─ helm-values/ # 常用 Helm Chart 的 values 文件 │ └─ k8s/ # 原生 Kubernetes YAML(按领域划分) ├─ diagrams/ # 架构图表与 Terraform graph 可视化 ├─ docs/ # 设计、流程与操作指南 ├─ infra/ # IaC 模块与环境定义 │ └─ aws/ # Terraform 配置(backend / providers / vars 等) ├─ scripts/ # 基础设施启停与自动化脚本 │ ├─ lifecycle/ # 环境重建与销毁相关脚本 │ └─ logs/ # 执行日志输出目录(已在 .gitignore 中排除) ├─ task-api/ # 示例微服务(Task API 服务)源码 └─ README.md ``` | 目录 | 说明 | | ------------------- | -------------------------------------------------------------------- | | **deploy/** | Kubernetes 部署相关配置(Helm values、原生 YAML) | | **infra/aws/** | Terraform 模块(VPC、子网、NAT、EKS 等)和环境配置,远端状态保存在 S3/DynamoDB(默认 Region=`us-east-1`) | | **docs/** | 生命周期与流程说明文档,例如 `docs/lifecycle.md` 等 | | **scripts/** | 脚本:如 `preflight.sh`(预检检查)等 | | **diagrams/** | 系统架构和流量拓扑图,帮助理解基础设施与应用关系 | | **task-api/** | 示例微服务 Task API 的源码与 Docker 构建配置 | --- ## 项目结构与职责分层原则 > Infra vs Deploy 本项目遵循云原生基础设施管理的标准分层设计,**明确将集群资源的创建与 Kubernetes 服务的部署进行解耦**,以提升可维护性、调试效率与后期扩展能力。 ### Terraform 仅负责 Infra 层(集群基础设施) Terraform 所管理的内容包括但不限于: - VPC、子网、NAT 网关、路由表等网络资源; - EKS 集群与托管 Node Group; - IAM 角色与 IRSA; - 安全组规则、服务配额与相关依赖。 Terraform 目标:**纯声明式 Infra、幂等、稳定、易重建、适合每日重建测试环境使用。** ### Helm 脚本负责部署层 所有 Kubernetes 层的应用部署,均由脚本 + Helm 完成,确保部署顺序清晰、调试灵活,避免 Terraform 状态污染。 - Helm Chart 管理 Kubernetes 原生控制器; - 每次重建后刷新 kubeconfig 并统一部署所有控制器; - 每个微服务都可以拥有独立 Chart 和 `values.yaml`。 ### 实践总结 > Terraform 管控资源边界;Helm 与脚本部署工作负载。 > 两者职责清晰,互不耦合,是现代云原生团队通用的 Infra / App Layer 分离模式。 --- ## 安装部署指南 以下指南将帮助你在自己的 AWS 账户中部署本实验环境,包括基础设施和示例应用的部署步骤。 ### 前置条件 完整步骤参见 📄 [前置条件操作指南](https://github.com/RendaZhang/renda-cloud-lab/blob/master/docs/PREREQUISITES_GUIDE.md#%E5%89%8D%E7%BD%AE%E6%9D%A1%E4%BB%B6%E6%93%8D%E4%BD%9C%E6%8C%87%E5%8D%97)。 ### 基础设施部署 **克隆仓库**:下载代码库到本地环境。 ```bash git clone https://github.com/RendaZhang/renda-cloud-lab.git cd renda-cloud-lab ``` 后续操作参考文档内容:📄 [运维手册](https://github.com/RendaZhang/renda-cloud-lab/blob/master/docs/RUNBOOK.md) ### 环境重建和销毁 具体请参考文档内容:📄 [环境重建与销毁指南](https://github.com/RendaZhang/renda-cloud-lab/blob/master/docs/ENV_REBUILD_TEARDOWN_GUIDE.md#%E7%8E%AF%E5%A2%83%E9%87%8D%E5%BB%BA%E4%B8%8E%E9%94%80%E6%AF%81%E6%8C%87%E5%8D%97) --- ## 附录 - 📄 [功能需求与规划](docs/REQUIREMENTS.md#云原生实验室功能需求与规划) - 📄 [运维手册](https://github.com/RendaZhang/renda-cloud-lab/blob/master/docs/RUNBOOK.md#%E8%BF%90%E7%BB%B4%E6%89%8B%E5%86%8C) - 📄 [环境重建与销毁指南](https://github.com/RendaZhang/renda-cloud-lab/blob/master/docs/ENV_REBUILD_TEARDOWN_GUIDE.md#%E7%8E%AF%E5%A2%83%E9%87%8D%E5%BB%BA%E4%B8%8E%E9%94%80%E6%AF%81%E6%8C%87%E5%8D%97) - 📄 [集群故障排查指南](https://github.com/RendaZhang/renda-cloud-lab/blob/master/docs/TROUBLESHOOTING.md#%E9%9B%86%E7%BE%A4%E6%95%85%E9%9A%9C%E6%8E%92%E6%9F%A5%E6%8C%87%E5%8D%97) - 📄 [AGENTS 智能体操作指南](https://github.com/RendaZhang/renda-cloud-lab/blob/master/docs/AGENTS.md#guidance-for-ai-agents) - 📄 [eksctl 遗留指引](https://github.com/RendaZhang/renda-cloud-lab/blob/master/docs/LEGACY_EKSCTL.md#eksctl-%E6%8C%87%E5%BC%95) - 📄 [前置条件操作指南](https://github.com/RendaZhang/renda-cloud-lab/blob/master/docs/PREREQUISITES_GUIDE.md#%E5%89%8D%E7%BD%AE%E6%9D%A1%E4%BB%B6%E6%93%8D%E4%BD%9C%E6%8C%87%E5%8D%97) --- ## 常见问题 (FAQ) **如何检查本地工具和 AWS 配额是否满足实验要求?** - 运行 `make preflight`,脚本会自动检查本地 CLI 工具版本、AWS SSO 登录状态,以及关键配额(如 ENI / vCPU / Spot 使用情况),并生成报告帮助你评估当前环境是否符合要求。 **如何将本项目部署到我的 AWS 账户?需要修改哪些配置?** - 首先请确保满足文档中提到的所有前置条件,然后在 `infra/aws/terraform.tfvars` 中修改必要的变量以匹配你的环境。 - 例如,将 `profile` 更新为你的 AWS CLI 配置文件名,提供你自有的 S3 Bucket 和 DynamoDB 表用于 Terraform 后端存储。 - 若使用自定义域名,还需要在 Terraform 配置中将默认的 `lab.rendazhang.com` 改为你的域名并提供对应的 Hosted Zone。 - 完成配置后,按照 **安装部署指南** 中的步骤执行 Terraform 和相关脚本即可。 - 部署过程中请确保 AWS 凭证有效且有足够权限创建所需资源。 **每天自动销毁和重建集群环境是如何实现的?可以自定义这个调度吗?** - 本项目通过 Makefile 脚本和 Terraform 模块实现资源的按日启停:早晨执行 `make start-all` 创建 NAT 网关以及 EKS 集群,夜晚执行 `make stop-all` 完全销毁这些资源,仅保留 VPC 等基础设施状态。 - 你可以利用 CI/CD 平台的定时任务实现全自动调度,例如使用 GitHub Actions 的 `cron` 定时触发 `make start-all/stop-all`,或通过 AWS CodePipeline 配合 EventBridge 定时事件触发。 - 同样地,你也可以根据需要调整策略:例如,仅在工作日执行自动启停,周末保持关闭,甚至完全停用自动销毁(但需承担额外费用)。 - 调度的灵活性完全取决于你的实验需求。 **如果我希望集群长时间连续运行,是否可以不销毁资源?** - 可以。 - 上述自动销毁策略主要用于节约成本,你可以选择不执行每日的 `make stop-all`,使集群和相关资源持续运行。 - 不过请注意,长时间运行将产生持续费用(特别是 EKS 控制平面和 NAT 网关等固定成本)。 - 建议在持续运行时仍采用其他成本控制措施,例如缩减不必要的节点、监控预算消耗等。 - 你也可以改为按需启停的方式,例如只在需要时手动运行脚本创建/删除集群。 - 总之,本项目提供的脚本和策略是可选的,用户可根据实际需求调整资源生命周期管理方式。 **如果需要使用自定义域名,该如何配置?** - 本项目默认不再创建 Route 53 Hosted Zone 或 DNS 记录。 - 如需使用自定义域名,可在 Route 53 或其他 DNS 服务中创建对应的 Hosted Zone。 - 当 ALB Controller 为 Ingress 创建 ALB 后,通过 `kubectl get ingress` 或 AWS 控制台获取 ALB 的 DNS 名称,并在 Hosted Zone 中创建一条指向该 DNS 的 A 记录(Alias)。 - 由于 ALB 每次重建都会生成新的 DNS 名称,需要在重建后更新该记录,或使用 ExternalDNS 等自动化方案。 - 若不配置自定义域名,可直接使用 ALB 自动分配的域名访问服务。 --- ## 🤝 贡献指南 - Fork & clone this repo. - 进入虚拟环境: ```bash # 如果还没安装虚拟环境,执行命令:python -m venv venv source venv/bin/activate ``` - 安装依赖并启用 **pre-commit**: ```bash pip install pre-commit pre-commit install ``` - 在每次提交前,钩子会自动运行。 - README 和 docs 下的文档会自动更新 Doctoc 目录(若本地未安装则跳过)。 - 你也可以手动触发: ```bash pre-commit run --all-files ``` > ✅ 所有提交必须通过 pre-commit 检查;CI 会阻止不符合规范的 PR。 --- ## 🔐 License 本项目以 **MIT License** 发布,你可以自由使用与修改。请在分发时保留原始许可证声明。 --- ## 📬 联系方式 - 联系人:张人大(Renda Zhang) - 📧 邮箱:[952402967@qq.com](mailto:952402967@qq.com) > ⏰ **Maintainer**:@Renda — 如果本项目对你有帮助,请不要忘了点亮 ⭐️ Star 支持我们!