何时需要关注平台架构
- 集群上线时缺少平台标准
- 应用团队与平台团队归属不清
- RBAC、网络策略与供应链存在安全缺口
- 升级痛苦且配置持续漂移
- 可观测性无法支撑事件响应
我们如何在此平台上工作
- AKS、EKS 与 GKE 目标架构
- 平台工程与内部开发者平台设计
- 面向集群与应用的 GitOps 与 CI/CD
- 网络策略、Ingress 与服务网格决策
- 兼容 Prometheus/Grafana 的可观测性
- 从虚拟机或 PaaS 迁移至容器
架构全景
概念架构
示意决策边界的概念架构，不代表任何客户环境。: 身份与策略; 专用连接; 业务工作负载受控交付
平台基础
01身份与策略
02专用连接
03业务工作负载
示意决策边界的概念架构，不代表任何客户环境。
根据现有环境选择托管服务
AKS、EKS 与 GKE 共享 Kubernetes API，但在身份集成、网络默认项、附加组件与升级体验上各有不同。应基于主云环境、身份模型、团队技能与周边服务选择，而非孤立的功能清单。
平台工程质量通常比托管服务的细微差异更重要。集群设计完成后，平台运营页面的方式即为我们持续参与的模式。
我们不做假定
并非每个现代化项目都需要 Kubernetes。部分工作负载更适合 PaaS、无服务器或管理良好的虚拟机。架构应跟随工作负载，而非潮流。
日常服务台与终端用户 IT 不属于 Kubernetes 平台运营范畴，相关需求由 Podium Catchers 承担。
技术决策背景
- Kubernetes
- AKS
- EKS
- GKE
- Helm
- GitOps
- Terraform
- Istio / 服务网格模式
工作旨在实现的目标
- 可支撑的运营化集群与平台模式
- 更清晰的开发者自助服务边界
- 通过 GitOps 减少配置漂移
- 提升安全与升级就绪度
平台选择即运营选择
实施前我们约定工作负载验收标准、访问归属、变更实践与容灾责任。提供商服务不能替代应用测试、成本问责与运营团队。
常见问题
常见问题
AKS、EKS 与 GKE 有何区别？
三者均为 Azure、AWS 与 Google Cloud 上的托管 Kubernetes 服务。概念相通，但在身份集成、网络默认项、附加组件、升级工具与周边云服务上各有差异。
#是否每个现代化项目都需要 Kubernetes？
否。当需要可移植的容器编排与平台杠杆时，Kubernetes 才有价值。部分工作负载更适合 PaaS、无服务器或管理良好的虚拟机。架构应跟随工作负载特征，而非时尚。
#上线后由谁运维集群？
我们可运营所设计的平台，涵盖登陆区与集群运营，而非托管 IT。
#服务网格决策应放在哪里？
在本页作为架构选择，并在已发布的 API 网关与服务网格文章中展开。网格不能替代登陆区。
#