平台工程融合GitOps

媒介

平台工程办理开发者体验题目，GitOps办理体系设置强同等性题目，两者正在融合为今世云原生交付体系。
通过Kubectl下令行直连Kubernetes集群API操纵Deployment、Service等资源完成应用手动摆设，会徐徐暴袒露一些题目：

• 学习资本高：开发者须要学习明白大量Kubernetes资源对象Deployment、Service、Ingress、ConfigMap等概念。
  
• 设置漂移：差别职员大概通过差别方式摆设运维，比方手写YAML举行apply操纵、暂时修改设置举行patch/edit操纵，没有同一入口和规范，造成体系设置漂移。
  
• 缺乏权限和审计本领：直接利用Kubectl操纵k8s集群，企业很难做到细粒度权限控制以及完备的操纵审计。
  
• 摆设运维过程不可追溯：设置修改和应用摆设通常是即时操纵，一旦出现题目，很难追溯是谁在什么时间修改了哪些设置。
  

运维管理平台通常构建在Kubernetes之上，为企业提供一整套尺度化的应用和根本办法管理本领。
运维管理平台通过对底层资源编排本领举行封装，提供应用摆设、扩缩容、网络与存储管理、权限控制、审计、CI/CD等功能，从而实现运维流程的主动化宁静台化；
一、CD一连摆设方式

运维管理平台实现应用主动化摆设告急有以下2种实现路径：
1.平台驱动摆设

如果更注意用户体验和摆设服从，可以接纳类似VelaUX的摆设方式。
平台将应用设置（OAM 模子）长期化到数据库中，在用户发起摆设时，平台直接调用KubeVela完成应用发布。这种模式前后端交互简朴、摆设速率快，更适当平台化操纵。
2.Git驱动摆设

如果更关注摆设过程的可追溯性、审计本领以及企业合规要求，则可以接纳GitOps模式。
在这种模式下，代码堆栈作为唯一的毕竟源（Single Source of Truth），全部应用设置和变动都通过Git提交完成，由GitOps控制器（比方 ArgoCD）一连同步到Kubernetes集群，从而实现可追溯、可审计、可审批的摆设流程。
二、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这种摆设方式，可以实现根本办法与云原生应用的：

• 主动化摆设
  
• 可追溯变动
  
• 可审计流程
  
• 环境同等性
  

三、平台工程融合GitOps

在今世平台工程体系中，平台UI充当同一门面，成为用户操纵体系的唯一入口，而Git堆栈依然负担体系状态唯一毕竟源（Source of Truth）的脚色。
GitOps与平台工程的融合，本质是用GitOps保障体系设置强同等性，用平台工程提拔用户体验，二者缺一不可；
1.KubeVela实现GitOps一连摆设流程

KubeVela基于OAM开放应用模子，屏蔽了Kubernetes底层复杂的资源、调理、运维细节。
KubeVela以应用为中心提供同一的声明式界说与管控本领，极大简化了云原生应用的交付与管理资本，让研发职员只须要关注应用本身，而非复杂的根本办法细节。
KubeVela内置GitOps控制器工具插件FluxCD，也可以实现GitOps一连摆设流程。
在GitOps最佳实践中，应用代码堆栈（App Code Repo）和 KubeVela设置堆栈（KubeVela Config Repository）在Git堆栈分开存储，可以让代码和摆设设置解耦；
运维/SRE

运维/SRE直接维护KubeVela设置堆栈。

开发职员

CI/CD大抵流程如下：

• CI工具（GitLab-CI/Jenkins/ArgoWorkflows）完成源代码集成和镜像构建，推送Docker镜像至镜像堆栈（Harbor/JFrog Artifactory）
  
• KubeVela监听（watch）到镜像堆栈中镜像版本变革，主动更新镜像到KubeVela设置堆栈。
  
• KubeVela又监听（watch）到KubeVela设置堆栈的内容变革， 主动从KubeVela设置堆栈pull最新镜像同步更新到Kubernetes集群。
  

2.平台工程融合GitOps

GitOps一连交付的默认用户入口是Git客户端，这要求用户把握Git的根本操纵。
但在现实场景中，运维平台的用户不但包罗开发和运维工程师，还会涉及产物司理等不认识Git客户端的脚色。
这时，内部开发者平台（IDP）就可以在GitOps之上封装关键抽象层，将GitOps的底层流程封装成直观易用的UI界面，让全部用户群体都能通过可视化操纵完成一连摆设。
GitOps并不是平台工程的替换方案，而是平台工程的交付引擎。平台工程融合GitOps后主动化交付流程大抵如下：

• 前端提交JSON格式的OAM设置；
  
• 后端生存JSON格式的OAM到关系型数据库方便前端回显；
  
• 后端根据JSON数据天生YAML文件并提交到KubeVela设置堆栈，如果前端发起更新OAM设置哀求，后端重新天生同名新内容的yaml文件覆盖原内容；
  
• YAML文件由代码堆栈同一存储和管理；
  
• ArgoCD监听YAML文件变动将最新KubeVela设置同步更新到K8s集群；
  
• KubeVela负责OAM设置渲染、Workflow实验与应用摆设，并输失变乱日志；
  
• 日志收罗服务同一网络管控集群的变乱与日志上传到ClickHouse数据库；
  
• 前端通过轮询后端接口，从ClickHouse获取并展示完备的应用摆设变乱和运行日志；
  

 
 
 
 
 
 
 
参考

免责声明：如果侵犯了您的权益，请联系站长及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金.