1. 课程导论：GitOps 核心理念、资源配额校准的必要性、Envoy 网关在云原生中的角色
1.1 GitOps 核心理念：声明式交付与不可变状态
GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的云原生交付模式。其核心在于将基础设施与应用的期望状态全部声明式地存储在 Git 中，并通过自动化 Operator 持续将集群实际状态向 Git 中的期望状态对齐。
核心原则： 声明式配置、版本化存储、自动同步、自愈回滚。
GitOps 工作流的关键组件与职责如下表所示：
| 组件 | 职责 | 典型工具 |
|---|---|---|
| Git 仓库 | 存储所有 YAML 清单、Kustomize/Helm 模板、策略代码 | GitHub, GitLab, Bitbucket |
| GitOps Operator | 持续对比 Git 期望状态与集群实际状态，自动执行同步 | Argo CD, Flux CD |
| CI 流水线 | 构建镜像、运行测试、更新 Git 仓库中的部署清单 | GitHub Actions, GitLab CI |
| Kubernetes 集群 | 运行实际工作负载，接收 Operator 的同步指令 | K8s, OpenShift |
实践要点： GitOps 要求所有变更必须通过 Pull Request 发起，经 Code Review 后合入主干分支，Operator 自动检测并应用。这从根本上杜绝了“配置漂移”和“手工运维”问题。
1.2 资源配额校准的必要性：从“能跑”到“可控”
在 GitOps 交付场景中，资源配额（Resource Quota）与 LimitRange 是保障多团队、多环境稳定性的第一道防线。未经校准的配额配置会导致以下典型问题：
- 资源争抢： 某个 Namespace 的“野蛮”Pod 耗尽集群 CPU/内存，影响其他业务。
- 配额浪费： 过度预留资源导致集群整体利用率低于 30%。
- 交付阻塞： 新应用因配额不足无法调度，CI/CD 流水线卡在 Pending 状态。
- 成本失控： 云资源费用因未校准的 Request/Limit 比例而线性增长。
常见误区： 很多团队在 Git 仓库中只维护 Deployment 和 Service，却忽略了 ResourceQuota 和 LimitRange 的版本化。这导致 GitOps 交付的“期望状态”并不完整，集群实际配额与 Git 配置脱节。
资源配额校准的核心目标可归纳为以下四个维度：
| 维度 | 校准目标 | 关键指标 |
|---|---|---|
| 合理性 | Request 与 Limit 比例符合业务实际峰值 | Request/Limit 比值 ≤ 0.8 |
| 公平性 | 多 Namespace 按权重分配，避免“饿死” | Namespace 配额占比偏差 < 15% |
| 可预测性 | 配额变更必须经过 Git PR 审批 | 配额变更 100% 走 GitOps 流程 |
| 可观测性 | 实时监控配额使用率，提前预警 | 配额使用率 > 80% 触发告警 |
校准时机： 建议在每个 GitOps 交付周期（Sprint）结束时，结合监控数据对配额进行一次校准。校准结果以 PR 形式合入 Git 仓库，Operator 自动同步生效。
1.3 Envoy 网关在云原生中的角色：南北向流量统一入口
Envoy 网关（如 Envoy Gateway、Istio Ingress Gateway、Contour）在云原生架构中承担南北向流量的统一代理角色。它位于集群边缘，负责将外部请求路由到内部 Service，并执行 TLS 终止、限流、重试、熔断、观测等高级功能。
Envoy 网关与 GitOps 的结合点主要体现在以下方面：
- 配置即代码： Envoy 的 Listener、Route、Cluster 等配置全部以 CRD（如 HTTPRoute、Gateway）形式存储在 Git 中。
- 灰度发布： 通过 Envoy 的权重路由实现金丝雀发布，权重比例由 Git 中的 Route 配置控制。
- 参数调优： 连接池大小、超时时间、重试策略等参数在 Git 中版本化管理，支持快速回滚。