CD-云原生应用交付和管理平台-KubeVela

前言

从云计算到云原生，很多企业都想把自己开发的软件改造成微服务架构，部署到K8s集群中运行，充分利用上K8s的优势；

提到上K8s，首先运维和开发人员都需要

  • 会写各种Yaml、Heml Charts部署应用
  • 了解K8s的生态，知道使用生态中的哪些工具可以实现哪些功能！
  • 会配置云原生应用运行依赖的运维策略（例如：CI/CD、对外访问策略、部署、动态扩缩容、监控、可观测等.....）

导致上K8s的过程非常复杂；

不能让人人都成为K8s专家，那就再封装K8s，让应用上K8s的过程简单起来！

上K8s的最终目标是：把1个云原生应用部署到K8s、稳定运行、管理起来；

这就需要1个云原生应用交付和管理的平台（KubeVela），帮我们抽象上K8s面临的复杂操作；

KubeVela围绕着云原生应用交付和管理场景展开，背后的应用交付模型是 Open Application Model，简称OAM；

OAM是1个云原生应用定义+交付模型，允许开发者和运维人员通过标准的声明式方式定义和管理应用，而无需关心底层基础设施的复杂性。

它提供了1种面向应用的抽象，强调以应用为中心，而非底层资源（如Pod、Service 等）。

一、为什么要上K8s？

Kubernets封装了Iaas层，是1个标准化的能力接入层；

声明式API对象

CustomResourece：自定义底层基础设施的抽象

Node是对宿主机的抽象

Service是对负载均衡、网关、IPtables访问规则的抽象

Deployment是对Pod的抽象

Pod是对容器的抽象

控制器层

各种控制器（Controller）：控制器通过控制循环驱动底层基础设施，不断接近抽象层声明API中定义终态； 

标准化能力接入层

虽然K8s已经封装了底层基础设施的复杂性，变成了一种标准化的能力接入层，但对于业务研发和业务运维来说还是比较复杂；

所以需要构建1个面向最终用户的应用管理平台，减少业务接入K8s的复杂程度；

二、K8s应用管理平台

K8s应用管理平台是对标准化能力接入层（K8s）的再次封装；

使最终用户业务研发和业务运维可以更加方便、快捷的将业务迁移至K8s集群；

三、OAM规范

K8s的生态比较复杂：

  • Argo可以做CI/CD
  • Opentelementry做可观测性
  • KEDA（Kubernetes Event-Driven Autoscaling）可以做自动扩缩容
  • ...........

当K8s部署这些插件之后，将这么多的插件关联到应用，非常复杂；

可以按照OAM标准，以应用为中心设计应用管理平台；

1.OAM相关概念

1个应用至少包含1个组件

1个组件可以关联0-多个运维特征，多个关联运维特征后的组件构成1个应用；

1.应用(Application)：

1个完整的软件应用，由多个组件组成。

2.组件(Component)

组件（Component）: 组件定义1个应用包含的待交付制品（二进制、Docker 镜像、Helm Chart...）或云服务。

1个应用部署计划部署的是1个微服务的单元，里面主要包含1个核心的用于频繁迭代的服务，以及一组服务所依赖的中间件集合（包含数据库、缓存、云服务等），一个应用中包含的组件数量应该控制在约 15 个以内。

2.1 组件的组成

组件通常由以下几部分组成：

2.1.1.Workload类型

组件的核心是1个工作负载类型(Workload Type)描述了组件的运行形式。例如：

  • 容器（Kubernetes 的 Deployment 或 StatefulSet）。
  • 虚拟机
  • 函数（如 FaaS 平台上的 Lambda 或 OpenFaaS）。
  • 数据库
  • 中间件
2.1.2.属性

组件包含一些运行时配置的属性，典型内容包括：

  • 镜像：运行的容器镜像或其他代码包。
  • 环境变量：运行环境配置。
  • 参数化：支持通过变量注入动态配置。
2.1.3.组件间依赖关系

组件之间的依赖关系可以被显式定义。例如，一个服务依赖另一个服务或一个数据库。

2.1.4.组件特征绑定

组件通常绑定1个或多个运维特征（Traits），定义运行时的行为，例如暴露服务、扩缩容策略、监控等。

3.运维特征(Trait)

是对组件运行时的附加操作，比如对组件的流量暴露、自动扩缩容、健康检查等。

组件和运维特征是灵活绑定关系，这种绑定关系可通过CRD声明描述；

3.1. Trait类型

3.1.1.网络特征
  • Ingress/Service：定义服务的暴露方式，比如通过域名、负载均衡、端口映射等。
  • 流量控制：支持灰度发布、蓝绿部署或流量镜像。
  • 防火墙规则：限制服务的访问源和目标。
3.1.2.扩展性特征
  • 自动扩缩容：根据 CPU、内存、流量等指标调整实例数量。
  • 定时扩缩容：基于时间表扩展或缩减资源。
  • 实例副本控制：管理运行实例的副本数及负载分布。
3.1.3.监控与日志特征
  • 日志采集：将组件的日志发送到指定的存储（如 Elasticsearch 或 S3）。
  • 监控指标：暴露 Prometheus 格式的监控指标。
  • 健康检查：定义组件的存活探针（Liveness Probe）和就绪探针（Readiness Probe）。
3.1.4.安全特征
  • 访问控制：限制 API 或服务的访问权限（如 RBAC）。
  • TLS/SSL 配置：为流量加密或定义证书管理。
  • 安全上下文：指定容器运行的安全策略（如非 root 运行）。
3.1.5.数据管理特征
  • 存储挂载：挂载持久卷或配置临时存储。
  • 数据备份与恢复：定义数据的定期备份或灾难恢复策略。
  • 状态管理：持久化应用状态，防止数据丢失。
3.1.6.性能调优特征
  • 资源限制：设置 CPU、内存的上下限。
  • 优先级配置：定义 Pod 的 QoS 或调度优先级。
  • 负载均衡策略：优化流量分发方式。

3.2. 运维特征的作用

  • 解耦：将组件的业务逻辑和运维策略分离，使二者独立管理。
  • 复用：1个运维特征可以被多个组件复用，避免重复定义。
  • 扩展：可根据需求自定义特征，满足不同场景的运维需求。

通过OAM 中的运维特征，可以更灵活地定义应用在云原生环境中的运行模式，并让开发和运维团队协同工作，提升系统的可扩展性和运维效率。

4.应用策略（Policy）

应用策略负责定义指定应用交付过程中的策略，比如多集群部署的差异化配置、资源放置策略、安全组策略、防火墙规则、SLO 目标等。

运维特征专注于应用运行时的稳定性和可扩展性，而应用策略则侧重于如何在开发和部署阶段管理应用的版本和发布方式。

4.1.策略分类

5.工作流步骤（Workflow Step）

工作流由多个步骤组成，允许用户自定义应用在某个环境的交付过程。

5.1.内置工作流列表

典型的工作流步骤包括人工审核、数据传递、多集群发布、通知等。

四、K8s如何支持OAM规范?

如果要在 Kubernetes上使用OAM，推荐使用KubeVela或Crossplane这样的开源项目；

KubeVela和Crossplane相当于OAM的CRD的解释器，实现了符合OAM规范的Controller和Operator，并提供了更多功能来简化应用的管理和调度。

1.KubeVela

KubeVela 围绕着云原生应用交付和管理场景展开，背后的应用交付模型是 Open Application Model，简称 OAM 。

2.应用交付计划

KubeVela的核心是将应用部署所需的所有组件和各项运维动作，描述为一个统一的、与基础设施无关的“部署计划”，进而实现在混合环境中标准化和高效率的应用交付。这使得最终用户无需关注底层细节，就可以使用丰富的扩展能力，并基于统一的概念自助式操作。

每1个应用部署计划都由四个部分组成，分别是组件、运维能力、部署策略和工作流。其格式如下：

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: <name>
spec:
  components:
    - name: <component name>
      type: <component type>
      properties:
        <parameter values>
      traits:
        - type: <trait type>
          properties:
            <traits parameter values>
    - name: <component name>
      type: <component type>
      properties:
        <parameter values>
  policies:
  - name: <policy name>
    type: <policy type>
    properties:
      <policy parameter values>
  workflow:
    - name: <step name>
      type: <step type>
      properties:
        <step parameter values>

3.Day 2 Operations概念

Day 2 Operations是IT运维领域中的1个术语，指的是系统、应用程序或服务在部署和上线后所涉及的持续运维操作。

  • Day 0（规划和设计阶段）
  • Day 1（部署和交付阶段）
  • Day 2 关注系统运行时的优化、维护和管理，以确保系统的稳定性、可靠性和高效性。

运维特征和部署策略的区别：部署策略关注是Day 1，运维特征关注的是Day 2；

1.Day 2 Operations 的核心任务

Day 2 Operations 的任务涵盖了广泛的运维工作，其核心目标是确保系统的正常运行和不断优化。以下是典型的 Day 2 工作内容：

1.1 监控和可观测性

  • 系统监控：监控 CPU、内存、磁盘、网络等资源使用情况。
  • 应用性能监控 (APM)：跟踪应用的关键性能指标（KPIs），如响应时间、吞吐量和错误率。
  • 日志管理：收集和分析日志以诊断问题。
  • 分布式追踪：通过工具如 OpenTelemetry，追踪微服务调用链。

1.2 伸缩性与高可用

  • 弹性伸缩：根据负载自动扩展或缩减服务实例的数量。
  • 容灾与备份：设计和实施备份策略，确保数据和服务在灾难发生时可以快速恢复。
  • 高可用性管理：确保系统具备冗余设计，避免单点故障。

1.3 持续更新

  • 补丁和升级：对操作系统、应用程序和依赖库进行版本升级和安全补丁应用。
  • 滚动更新和蓝绿部署：通过渐进式发布减少对生产环境的影响。

1.4 安全管理

  • 身份和访问管理 (IAM)：限制和管理系统用户和服务的权限。
  • 安全事件响应：检测和应对安全漏洞或攻击。
  • 合规性监控：确保系统符合行业和法规要求。

1.5 优化和成本管理

  • 资源优化：分析系统资源使用情况，优化服务性能和成本。
  • 成本控制：通过对云资源的使用监控，减少不必要的支出。

1.6 事件响应和问题管理

  • 告警处理：设置自动化告警机制，快速发现问题。
  • 根因分析 (RCA)：针对问题事件进行深度分析，找到根本原因并修复。
  • 灾难恢复演练：定期测试容灾机制。

2.Day 2 Operations 的重要性

在系统上线后，Day 2 Operations 决定了服务能否持续满足用户需求、稳定运行并快速响应变化。以下是其关键价值：

  1. 提升用户体验：通过持续优化和监控，确保应用程序以最佳性能运行。
  2. 降低故障风险：通过高可用性设计和快速事件响应机制减少宕机和故障。
  3. 确保安全性：及时应用安全补丁并检测漏洞，保护数据和服务。
  4. 控制成本：优化资源利用率，避免不必要的云资源浪费。

3.工具和平台支持 Day 2 Operations

以下是一些常用工具和平台，可以帮助实施 Day 2 Operations：

3.1 监控和可观测性

  • Prometheus + Grafana：用于系统监控和可视化。
  • Elastic Stack (ELK)：日志管理和分析。
  • Datadog / New Relic：全面的 APM 和基础设施监控。
  • Jaeger / OpenTelemetry：分布式追踪。

3.2 运维自动化

  • Terraform / Ansible：用于基础设施即代码（IaC）管理和自动化配置。
  • Kubernetes：通过 HPA（Horizontal Pod Autoscaler）实现应用自动伸缩。

3.3 持续交付与部署

  • ArgoCD / Flux：Kubernetes 原生的 GitOps 工具。
  • Jenkins / Tekton：持续集成与持续部署（CI/CD）工具。

3.4 容灾和备份

  • Velero：Kubernetes 的备份和恢复工具。
  • AWS Backup / Azure Backup：云平台的备份解决方案。

3.5 安全管理

  • HashiCorp Vault：用于密钥管理。
  • Falco：Kubernetes 容器安全监控。
  • Trivy：容器镜像漏洞扫描。

五、VelaUX

VelaUX全称KubeVela User Experience (UX) 平台是 KubeVela提供的1个非常方便的图形化界面，它大大简化了 Kubernetes应用管理和微服务部署，尤其是对于没有深厚YAML编写经验的用户来说，图形化界面可以显著降低使用难度。

它的核心优势就是能直观地管理应用、组件、流水线以及资源，尤其适合需要频繁更新和协调多个微服务的场景。你可以通过拖拽、点击的方式来创建应用、配置服务、定义工作流，而不需要手动编写繁琐的 YAML 文件。

  • 多集群 & 多环境支持: 实现跨集群资源的统一管理。
  • 管道管理: 简化 CI/CD 流程，提升开发效率。
  • 可观测性增强: 直观展示关键指标，优化运维体验。

多集群应用实践架构

1.安装VelaUX

helm repo add kubevela https://charts.kubevela.net/addons
helm repo update
helm install velaux kubevela/velaux --namespace vela-system

开通访问权限

kubectl port-forward svc/velaux -n vela-system 8080:80

在浏览器中访问 http://localhost:8080，就可以看到 VelaUX 的图形化界面。

六、CI系统对接KubeVela

在大型CI/CD系统架构中CI和CD通常是解耦分离的，例如：

  • CI流水线负责代码集成构建输出构建制品并上传到制品库（CI）
  • KubeVela负责应用交付和管理，KubeVela在应用配置中，直接引用构建制品，并指定环境变量、部署策略等参数，将应用多环境发布（如开发环境、测试环境、生产环境）。（CD）

CI系统(云效/ArgoWorkflows/JenKins/GitLabCI) 构建出制品上传到制品库之后， 调用kubevela的WebHook Triger，触发1个应用部署流程，实现CI/CD对接；

1.在VelaUX创建应用

配置好应用相关的运维特征，镜像地址先随便填CI之后会覆盖；

应用创建完成后查看应用的绑定的相关属性

2.获取TrigerWebhook地址

VelaUX内置了1个默认触发器，通常用来直接部署应用，而不需要额外绑定自定义工作流，这个默认触发器适用于应用场景简单、直接触发部署的需求。

如果新建触发器需要与工作流绑定，因为触发器的核心作用就是用来启动工作流或者执行某些操作。

如果没有绑定工作流或操作，触发器实际上是没有实际用途的。

从应用的Properties中获取当前应用的TrigerWebhook地址

3.CI系统调用TrigerWebhook

Workflow：CI系统(ArgoWorkflows)构建出Docker镜像制品，调用KubevelaUX的TrigerWebHook触发KubevelaUX中的Workflow执行；

app-instances：KubevelaUX中的Workflow执行完成后，在2个K8s集群中创建了2个应用实例，CD部署完成；

Service EndPoint：应用部署成功后就可以通过应用实例的Service Endpoint访问部署好的2个应用了；

 

 

参考

posted on 2024-09-23 21:18  Martin8866  阅读(18)  评论(0)  编辑  收藏  举报