前言
原始人工部署的痛点
Kubectl直连Kubernetes集群API，命令行操作Deployment、Service等资源完成应用手动部署，会逐渐暴露出一些问题：
- 学习成本高：开发者需要学习理解大量Kubernetes资源对象Deployment、Service、Ingress、ConfigMap等概念。
- 配置漂移：不同人员可能通过不同方式部署运维，例如手写YAML进行apply操作、临时修改配置进行patch/edit操作，没有统一入口和规范，造成系统配置漂移。
- 缺乏权限和审计能力：直接使用Kubectl操作k8s集群，企业很难做到细粒度权限控制以及完整的操作审计。
- 部署运维过程不可追溯：配置修改和应用部署往往是即时操作，一旦出现问题，很难追溯是谁在什么时间修改了哪些配置。
传统DevOps的痛点：
- 流程碎片化：开发、测试、运维各自为政，靠CI/CD工具链硬串联。
- 复杂度外溢：运维团队要维护Gitlab、Jenkins、GitLabRunner、ArgoCD、HelmChart等多套工具。
- 不可控的体验：不同团队的自动化脚本和流程不统一，新人入职学习成本高。
- 缺乏稳定的审计与可追溯性：流水线日志、变更记录分散，难以形成统一的安全合规视图。
DevOps已死，更加注重用户体验的平台工程才是未来。
DevOps过度依赖工具链、强调个人能力、缺乏标准化平台化支撑，长期难以扩展。
平台工程（Platform Engineering）就是为企业开发团队提供标准化、可复用、可自助的内建能力平台（Internal Developer Platform）也称IDP ，IDP把DevOps的复杂性封装起来，让业务团队专注于业务逻辑而非工具维护、工具的使用。
平台工程核心价值：
- 一套平台解决开发运维问题：统一管理CI/CD、镜像仓库、环境配置、部署策略。
- 标准化接口：团队通过 API 或自助 UI 就能完成部署、发布、监控，而无需了解底层细节。
- 可追溯与审计：所有流水线、配置变更、资源使用都被平台统一记录。
- 扩展性强：平台能力模块化，可接入云厂商服务、SaaS、内部工具。
- 解放生产力：开发团队不必重复做DevOps工具维护，业务开发效率提升明显。
小结
DevOps强调流程和工具，而平台工程强调能力和自助服务。
未来企业的发展趋势是：把DevOps的复杂性封装进一个可自助使用的平台，让开发团队专注于业务创新，而不是代码开发完成后如何通过流水线发布。
运维管理平台通过对底层资源编排能力进行封装，提供应用部署、扩缩容、网络与存储管理、权限控制、审计、CI/CD等功能，从而实现运维流程的自动化和平台化；
一、持续部署（CD）模式
运维管理平台实现应用自动化部署主要有以下2种实现路径：
1.平台驱动部署
如果更注重用户体验和部署效率，可以采用类似VelaUX的部署方式。
平台将应用配置（OAM 模型）持久化到数据库中，在用户发起部署时，平台直接调用KubeVela完成应用发布。这种模式前后端交互简单、部署速度快，更适合平台化操作。
2.Git驱动部署
如果更关注部署过程的可追溯性、审计能力以及企业合规要求，则可以采用GitOps模式。
在这种模式下，代码仓库作为唯一的事实源（Single Source of Truth），所有应用配置和变更都通过Git提交完成，由GitOps控制器（例如 ArgoCD）持续同步到Kubernetes集群，从而实现可追溯、可审计、可审批的部署流程。
二、OAM应用交付模型
OAM全称OpenApplicationModel，封装了原生K8s原生资源描述的复杂度，以应用为中心，将应用抽象成组件（Component）+ 特性（Trait）+ 工作流（Scope/Workflow）
解耦开发人员关注的业务逻辑与运维人员关注的部署策略
使应用可以在不同平台上声明式交付而无需修改应用代码
三、GitOps应用交付工具
GitOps是一种以Git代码仓库为唯一可信源的基础设施和云原生应用的交付与运维模式，用于实现基础设施和云原生应用的的持续交付和自动化管理。
GitOps利用Kubernetes、Terraform等平台的声明式API特性与DevOps实践相结合，通过在Git仓库中统一定义系统的期望状态，由GitOps控制器（如ArgoCD/FluxCD）持续监听、同步并校准系统状态，确保实际运行环境始终与Git仓库中定义的状态保持一致。
GitOps并不依赖于具体工具（如 GitLab或ArgoCD/FluxCD），而在于部署流程是否满足以下原则：
- 以代码仓库作为唯一事实源
- 能够自动执行
- 并且能完整追踪操作与变更。
例如，将OAM应用信息存储在Gitea中，一旦PR合并触发ArgoWorkflows流水线执行，将OAM应用配置更新到KubeVela管控集群，这种交付方式同样符合GitOps风格。
| 工具 | 优势 | 适合 OAM 场景吗？ |
|---|---|---|
| Argo Workflows | 流水线 + 任务编排 → 一次性执行 Workflow | ❌ 不适合管理持续状态，需要额外逻辑做差异检测和修复 |
| Argo CD | 原生GitOps控制器 → 持续同步 Git → K8s，自动矫正差异 | ✅ 非常适合 OAM 应用管理，Git 仓库就是唯一事实源，集群状态始终与 Git 保持一致 |
通过GitOps这种部署方式，可以实现基础设施与云原生应用的：
-
自动化部署
-
可追溯变更
-
可审计流程
-
环境一致性
1.GitOps控制器FluxCD
FluxCD是一款云原生的GitOps工具，由CNCF（云原生计算基金会）孵化并毕业；
FluxCD的核心目标是实现Kubernetes集群配置/应用的声明式自动化管理；
FluxCD可以实现Kubernetes资源配置（如 Deployment、Service、KubeVela Application 等）托管在Git仓库（如 Gitee/GitHub），然后自动将Git仓库中的配置同步到Kubernetes集群，实现Git仓库作为唯一可信数据源的运维模式。
FluxCD持续部署流程
创建known_hosts文件
ssh-keyscan gitee.com > ./known_hosts
创建存储gitee秘钥的secret
kubectl create secret generic gitee-credentials \ > -n gitops \ > --from-file=identity=./flux-gitee \ > --from-file=identity.pub=./flux-gitee.pub \ > --from-file=known_hosts=./known_hosts secret/gitee-credentials created
创建gitrepository资源
FluxCD的源控制器（source-controller）将按照interval: 1m配置的周期，通过SSH协议访问Gitee的KubeVela配置仓库git@gitee.com/zhanggen6/ci-cd.git的master分支
借助gitee-credentials这个Secret完成 SSH身份认证与服务器指纹验证
拉取KubeVela配置仓库中存储的KubeVelaOAM应用配置
拉取后的配置会作为标准化的Kubernetes资源artifact存储在集群中，为后续同步部署流程提供统一的配置源
最终实现OAM配置从代码仓库到当前Kubernetes集群的定时同步与自动化部署。
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
name: gitee-oam-repo
namespace: gitops
spec:
interval: 1m
url: ssh://git@gitee.com/zhanggen6/ci-cd.git
ref:
branch: master
secretRef:
name: gitee-credentials
timeout: 60s
查看gitrepository资源
kubectl get gitrepository -n gitops NAME URL AGE READY STATUS gitee-oam-repo ssh://git@gitee.com/zhanggen6/ci-cd.git 7m54s True stored artifact for revision 'master@sha1:aaf17a618fcbfb2e13aeb22f2a3b85d53e8c61bb'
创建Kustomization资源
GitRepository只负责拉取配置到集群生成artifact，不会触发部署流程，FluxCD的Kustomization同步控制器会自动读取artifact并将配置部署到集群。
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: gitee-oam-deploy
namespace: gitops # 与 GitRepository 同命名空间
spec:
# 关联已成功拉取配置的 GitRepository
sourceRef:
kind: GitRepository
name: gitee-oam-repo
namespace: gitops
# 同步周期（与 GitRepository 一致，1分钟检查一次配置变更）
interval: 1m
# 关键：Git 仓库中 KubeVela OAM 配置所在的目录（必填！）
# 替换为你 Gitee 仓库中 my-app 配置文件的实际路径（根目录填 "./"）
path: "./"
# 自动清理：删除集群中不在 Git 仓库的资源，同时缺失的资源会自动重建
prune: true
# 等待部署完成，确保配置生效
wait: true
# 关键：指定部署到应用所在的 oam-test 命名空间
targetNamespace: oam-test
# 允许创建 KubeVela 自定义资源（Application/core.oam.dev）
timeout: 30s
查看Kustomization资源
kubectl get kustomization gitee-oam-deploy -n gitops
NAME AGE READY STATUS
gitee-oam-deploy 17m True Applied revision: master@sha1:aaf17a618fcbfb2e13aeb22f2a3b85d53e8c61bb
2.GitOps交付工具的局限性
在长期使用FluxCD或ArgoCD这类GitOps工具后，能深刻体会到其核心设计理念：持续保证Git仓库中声明的期望状态，与Kubernetes集群etcd中维护的实际状态严格一致。
所以在现阶段，这类GitOps控制器工具，无疑非常适合用于追求一次性部署后、长期稳定的基础设施层。
第一层：云基础设施（Terraform管）
- - EKS/ACK 集群
- - VPC、安全组、节点
第二层：K8s内部底座（GitOps工具FluxCd/ArgoCD管）
- - Prometheus、日志服务、DevOps工具、网关、Operator、Harbor等公共服务
- - 持续守护 + 自动纠偏
第三层：业务应用（Openkruise/ArgoRollout管）
- 业务应用
- -渐进式发布+持久守护+自动纠偏
四、渐进式发布工具
平台工程并不是某一个具体工具，而是一种通过构建内部开发平台（IDP），将Kubernetes与DevOps工具链能力进行统一封装，并以自助服务方式提供给开发者的工程体系。
有DevOps、可观测 = 不代表是平台工程。
面向开发者、做自助、做标准化、降低认知负担，才叫平台工程。
云原生时代，如果K8s是围绕Pod展开的，那DevOps就是围绕云原生应用自动部署到pod的容器里展开的。
1.应用即代码（Application As Code）
KubeVela基于OAM开放应用模型，屏蔽了Kubernetes底层复杂的资源、调度、运维细节。
KubeVela以应用为中心提供统一的声明式定义与管控能力，极大简化了云原生应用的交付与管理成本，让研发人员只需要关注应用本身，而非复杂的基础设施细节。
KubeVela内置GitOps控制器工具插件FluxCD，也可以实现GitOps持续部署流程。
在GitOps最佳实践中，应用代码仓库（App Code Repo）和 KubeVela配置仓库（KubeVela Config Repository）在Git仓库分开存储，可以让代码和部署配置解耦；
运维/SRE
运维/SRE直接维护KubeVela配置仓库。
FluxCD或者ArgoCD等GitOps控制器工具必须遵循单一配置源原则，禁止同时监听多个配置库，否则会出现配置源 + 控制器双重死循环，导致应用无限发布、版本横跳。
开发人员
CI/CD大致流程如下：
- CI工具（GitLab-CI/Jenkins/ArgoWorkflows）完成源代码集成和镜像构建，推送Docker镜像至镜像仓库（Harbor/JFrog Artifactory）
- KubeVela监听（watch）到镜像仓库中镜像版本变化，自动更新镜像到KubeVela配置仓库。
- KubeVela又监听（watch）到KubeVela配置仓库的内容变化， 自动从KubeVela配置仓库pull最新镜像同步更新到Kubernetes集群。
五、DevOps系统功能
交付模型=让应用依赖的K8s原生资源可以描述
交付工具= 让软件到位达到可以发布的状态
发布工具 = 发布软件给用户
DevOps系统=融合了OAM交付模型+交付工具+发布工具，以及自动化CI/CD流程。
GitOps不能直接作为应用发布平台，使用GitOps工具管理用户声明的应用期望状态实时同步到K8s集群，再使用进式交付工具管理应用发布过程与运行时状态的一致性，是一种不错的实践。
这是就是期望状态与实际状态分开管理。
GitLab/Gitee/Gitea (代码库保存用户DesiredState) │ ▼ ArgoCD/FluxCD (检查Git仓库期望状态&同步期望状态配置到K8S集群) │ ▼ Rollout/OpenKruise (执行期望状态声明的发布流程+修正实际状态=期望状态) │ ▼ Kubernetes (Pods/ReplicaSets)
DevOps的核心交付链路
CI阶段(ArgoWorkflows) 开发提交代码 CI构建镜像 推送镜像仓库 交付阶段（ArgoCD/FluxCd） 更新部署配置 CD系统同步 部署到Kubernetes 发布阶段（ArgoRollout/OpenKruiseRollout） 灰度/金丝雀发布 逐步切流到新版本 最终全部用户访问新版本
DevOps全流程
Plan（计划） │ 需求规划、任务管理 ▼ Code（编码） │ 开发业务功能，提交代码 ▼ Build（构建） │ 编译、打包、生成可运行产物（镜像、包） ▼ Test（测试） │ 单元测试、集成测试、自动化安全测试 ▼ Deploy（部署） │ 将应用部署到环境（开发/测试/生产） ▼ Release（发布） │ 灰度发布 / 金丝雀 / 逐步切流上线 ▼ Operate（运行 / 运维） │ 自动化运维、弹性扩缩容、自愈能力 ▼ Observe（监控 / 可观测） │ 指标采集、日志、链路追踪、告警 ▼ Feedback（反馈） │ 异常、指标、用户体验闭环反馈，改进流程
六、平台工程融合IaaS和PaaS层
当前，运维与开发协作普遍通过内部开发者平台（IDP）或运维管理平台实现。
开发人员通过IDP/运维管理平台：自助完成应用的发布，以及日志、监控数据的可视化查看；
运维人员利用IDP/运维管理平台：自动化管理IaaS层（计算、网络、存储）和PaaS层（中间件、监控等）资源，实现职责分离与高效协同。
1.平台工程功能描述
传统开发运维方式
传统开发运维过程，核心特点是以各类资源为中心，设备的安装、调试，应用的部署、运维基本靠人力完成，自动化程度低，缺乏统一的设备和应用管理能力。
为了保证正式环境的可靠性和安全性，开发和运维人员以正式环境为边界：
- 开发人员：负责编码到上线前准备
- 运维人员：负责正式环境的发布和更新
运维人员对正式环境的维护内容，依赖于开发人员的技术架构实现。
由于双方工作关联的紧密程度，在线上发布或故障排查阶段，双方协作对接成本较 高，且较为容易发生沟通上误差，导致线上发布步骤的遗漏或误操作，导致故障的发生。
除此之外，不管开发还是部署阶段，均存在大量的重复手工工作。
例如应用的手工构建、不同环境的人工部署、不同环境依赖的重复安装、环境的调试，类似工作导致开发人员较多时间耗费在了非核心业务编码上。
云原生开发运维方式
随着业务系统复杂度和规模的急剧增长，传统开发运维方式已无法规模化支撑当下业务发展速度。
企业关注转移到以应用为中心，包括应用的敏捷交付、弹性伸缩、监控 告警、灾备机制，如何将基础设施与PaaS平台融合？
为业务应用提供标准的运行、监控、治理平台，并将业务的通用能力下沉到平台侧，更好的帮助企业实现应用的自动化管理？
基于敏捷精益的理念，以容器化、微服务等代表性的云原生技术应运而生。
应用长在云上成为了IT企业发展的趋势，应用的构建、部署、监控、治理等内容下沉到了平台侧管理，然后再以可视化、自动化方式赋能给开发人员自助化管理，让研发人力资 源能够聚焦在价值密度更高的业务逻辑开发上，明显提高了研发效率和质量。
2.平台工程完成后运维职能划分
开发侧重自助操作，运维侧重自动管理，职责分明。
SRE工程师负责稳：负责让基础设施、K8s平台、中间件、业务应用长期稳定、高可用、少故障，保证应用跑得稳。
DevOps工程师负责快：两者一起既能提升业务研发效率，又能保证业务运行阶段的稳定，使业务价值最大化。
应用上线（CI/CD 流水线 & DevOps） │ ▼ 应用在 Kubernetes 上跑起来（DevOps 关注） │ ▼ SRE 全链路维稳 ├─ 应用可靠性：流量治理/SLO/ErrorBudget/灰度控制 ├─ Kubernetes平台：调度、网络插件、存储插件、集群健康 ├─ 中间件服务：数据库、缓存、消息队列 ├─ 基础设施层：节点、存储卷、网络、物理/虚拟硬件 ▼ 应用 + 平台 + 基础设施稳定可靠运行
3.平台工程完成目标
在平台工程实践中，平台工程的最终产物通常称为运维管理平台。
该运维管理平台面向开发和运维人员，覆盖了从软件编码到交付的完整路径，提供体系化、标准化、一站式云原生开发运维平台。
平台工程的本质，是构建一套融合IaaS与PaaS的内部平台：
-
IaaS层：封装计算（含K8s）、网络、存储等基础资源；
-
PaaS层：封装中间件、监控、应用等平台能力；
-
对外输出层：提供统一的工具链和自动化运维流程，降低开发人员使用复杂度和对运维的依赖程度。
终极目标：快速上线，线上稳定。
浙公网安备 33010602011771号