13、应用配置管理与抽象模式解析-优快云博客

本文链接：https://blog.youkuaiyun.com/tensor9flow/article/details/152551561

应用配置管理与抽象模式解析

在当今的应用开发与部署中，高效的配置管理以及灵活的抽象模式至关重要。本文将深入探讨几种关键的配置管理方法、开放应用模型（OAM）及其实现，还有配置变更频率的影响，最后介绍一些常用的配置管理工具。

1. 配置管理方法

在配置管理方面，有两种重要的方法：Patch/overlay 和 Composition。
- Patch/overlay ：该方法以基础配置作为纯数据点，使用补丁文件覆盖所需的变量以实现定制。可以替换现有配置旋钮的值，或者向整体基础添加新配置。还能在基于模板的抽象工具（如 Helm）中作为渲染后步骤使用。这种方法避免了泄漏问题，因为定制所需的额外参数化可以作为渲染后补丁进行管理。自从 Kustomize 工具出现后，它变得非常流行，并且这些工具无需人工干预，可作为部署管道中的一个步骤实现自动化。
- Composition ：这是一种通过组合依赖项来构建更高级别 API 和多个子 API 的技术，供不同角色使用。Crossplane 本身就是一个组合工具。组合模式中有拉取（Pull）和推送（Push）两种子模式。在拉取模型中，直接引用依赖项，例如 Crossplane 世界中的嵌套 XR；在推送模型中，通过运行时绑定间接跨 API 引用依赖项，适合分离关注点和构建可扩展的抽象，如使用标签在两个独立 XR 之间进行资源引用就是推送组合的一个例子。Composition 和 Patch/overlay 可以协同工作以实现定制，例如在 Crossplane 中，可以使用补丁生成特定环境（生产/暂存）的组合。

2. 开放应用模型（OAM）

OAM 是由微软和阿里巴巴开发的开源标准，旨在指导创建用于应用部署的更高级别抽象 API，即使用组合模式创建应用配置管理模型。该标准主要解决以下三个问题：
- 开发者专注度 ：让开发者直接进行 Kubernetes 配置管理来部署应用，会使他们花费时间处理基础设施细节，而无法专注于应用本身。因此，OAM 试图让开发者专注于应用开发。
- 供应商依赖 ：应用配置通常依赖于底层基础设施，将应用配置与底层基础设施完全解耦可以实现工作负载的可移植性。Kubernetes 在一定程度上实现了这一点，但在跨领域问题和商用现货（COTS）依赖方面还需要更多工作。
- 可扩展性 ：大规模的配置管理可能会遇到很多问题，特别是在平衡重用和定制时。OAM 提出了一种用于大规模重用和定制的模型。

OAM 通过基于角色的分层配置管理和相应的抽象组合来解决这些问题，并定义了三个角色来管理不同的应用部署问题。

3. OAM 的实现 - KubeVela

OAM 社区开发了 KubeVela 项目来实现该规范。它是 CNCF 沙盒项目，也是一个像 Crossplane 一样的组合工具。KubeVela 仅专注于组合定制化应用配置，而 Crossplane 则可以组合定制化应用和 COTS 基础设施/外部依赖项。两者可以通过以下两种不同模式相互补充：
- KubeVela 组合 Crossplane ：可以使用 KubeVela 组合定制化应用部署抽象，并依赖 Crossplane 作为 COTS 外部依赖项提供者。此模式要求 Crossplane 控制平面存在于应用工作负载集群中。
- Crossplane 组合 KubeVela ：可以使用 Crossplane 为定制化应用和 COTS 基础设施/外部依赖项组合抽象。对于定制化应用，它可以通过 Crossplane Provider for Kubernetes 使用 KubeVela。这种模式可以使用集中式或分布式的 Crossplane 控制平面。

以下是这两种模式的简单流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(KubeVela):::process -->|组合| B(Crossplane):::process
    C(Crossplane):::process -->|组合| D(KubeVela):::process

4. 专业化和可扩展抽象

随着在 Kubernetes 中部署的应用数量增加，需要管理的配置可能会呈指数级增长。专业化和可扩展抽象对于解决这些问题至关重要。
- 专业化抽象 ：这是一种构建基本抽象并重用基础抽象以创建处理定制需求的专业化抽象的技术，类似于面向对象编程中的继承模式，也是核心 Kubernetes 中常见的模式。例如，Pod 资源类型是基础，Deployment、DemonSet 和 Job 是使用 Pod 作为基础的专业化抽象。平台团队可以构建的专业化抽象包括：
- 策略抽象层 ：组织可能针对每个云资源有不同的策略，如安全、架构和合规性等方面。可以在 Crossplane 提供者之上为每个资源创建一个 XR 的抽象层，作为创建配方的坚实基础。
- 数据库配方 ：不同的产品团队有不同的数据库需求，如地理分布式数据库、单区域可用性区域容错数据库或符合 PCI - DSS 标准的数据库。可以创建一个基础数据库 XR，并在其上创建专业化 XR 以满足每个需求。
- 工作负载配方 ：不同的工作负载（如 Web 应用程序、RESTful API、定时作业和数据转换）有不同的依赖需求。可以创建一个包含所有常见跨领域问题的主要工作负载，并在其上开发专业化抽象。可以使用 Crossplane、KubeVela 或两者的组合来实现。
- 可扩展抽象 ：该技术构建部分抽象，允许其他团队完全实现它，类似于面向对象编程中的多态模式，也是核心 Kubernetes 中常见的模式。例如，Ingress 是核心 Kubernetes 中的一个例子，每个托管 Kubernetes 提供者都会为 Ingress 提供自己的实现。可扩展抽象适用于平台团队和应用程序操作员，其使用示例包括：
- 共享资源 ：以 VPC 为例，有时需要为不同场景创建和使用多个资源变体。可以为这些资源制定标准的标签名称/值策略，其他 XR 配方可以通过适当的标签引用选择一个 VPC，这是一种多态行为，通过依赖注入提供可扩展性。
- 嵌套 XR ：平台团队可以创建一个识别出缺少依赖项的 XR 配方，缺少的依赖项可以单独实现，然后通过嵌套 XR 模式将两部分组合起来。当每个产品团队对缺少的依赖项的需求不同时，可以选择这种模式，例如一个应用配方不指定数据库选择，应用操作员可以根据特定产品团队的需求完成该配方。

5. 配置变更频率的影响

从变更频率的角度看待配置旋钮，有助于在 OAM 定义的角色之间对其进行分类，同时也涉及到所有权的讨论。可以将配置变更频率分为以下三类：
|变更频率|描述|所有权|管理方式|
| ---- | ---- | ---- | ---- |
|非常频繁|通常，应用 KRM 配置参数（如图像标签、发布版本、环境变量、秘密引用和应用配置）变化非常频繁。这些配置以应用为中心，主要由应用开发者拥有。|应用开发者|如果使用基于模板或 DSL 的抽象，可将其作为变量暴露；如果使用普通配置 YAML，开发者可以拥有一个版本控制的补丁/覆盖文件；使用组合时，应以高级 API 向开发者暴露这些配置。|
|较少频繁|应用上下文相关信息（命名空间、标签、引用等）、资源约束（内存、卷等）和发布相关旋钮（副本计数和推出方法）等配置变化较少。这些配置主要因环境而异，或在有新的操作要求时发生变化。|应用操作员|无论使用基于模板、DSL、普通 YAML 还是组合，最好使用补丁机制来管理这些较少频繁变化的配置值，并在管道中根据目标环境选择补丁文件。|
|很少变化|很少定制的配置是核心应用的基本结构，应由平台开发者拥有。基本结构是核心抽象，可减少应用操作员和开发者的认知负担，并总结配方中的策略要求。|平台开发者|通常使用覆盖、专业化和可扩展抽象来实现不同产品团队和工作负载所需的核心配置的多个变体。|

对于 XRM 合规的 COTS 外部基础设施依赖项，大多数情况下变化不频繁。例如，外部基础设施的区域扩展、自动扩展设置、安全配置调整、升级和迁移等操作在初始设置后会以较低的频率发生。这些基础设施抽象的构建应由平台团队负责。不过，应用操作员可以进行一些 XR 组合练习，以创建新的专业化配方，即使用嵌套 XR 模式创建特定工作负载的抽象。此外，XRM 还可以通过 Helm 和 SQL 等提供者管理外部应用，这些配置可能会频繁变化，例如每次应用发布都可能更改数据库的 SQL 模式，因此应用操作员可以扩展现有配方以满足产品团队的需求。

6. 常用配置管理工具

接下来介绍几种常用的应用配置管理工具，包括 Helm、Kustomize 和 KubeVela。
- Helm ：Helm 是 Kubernetes 生态系统中流行的配置管理工具，于 2015 年出现，经过多年发展，已成为 CNCF 毕业项目，具有成熟性、生产就绪性和价值。其三个关键概念如下：
- Charts ：是 Helm 中应用的基本单位，是包含应用及其所有依赖项的捆绑包。
- Repository ：捆绑的图表需要一致的存储方式以可靠分发，存储库满足了这一需求。开源应用可以使用公共存储库，专有应用可以使用私有存储库。从 Helm v3.8.0 开始，任何符合 Open Container Initiative（OCI）的存储库都支持 Helm，这意味着大多数容器注册表也支持 Helm 包。
- Release ：是在集群中运行的图表实例。首次安装图表时会创建一个新的发布版本，任何更新都会增加发布版本号。该构造支持发布管理功能，如推出、回滚和蓝绿部署。

使用 Helm 需要设置客户端命令行界面（CLI），在 macOS 操作系统中，可以使用 brew 安装 CLI，在 Windows 中可以使用 choco 安装，具体命令如下：

# Helm install macOS
brew install Helm
# Helm install Windows
choco install kubernetes-helm

更多安装选项可访问 https://helm.sh/docs/intro/install/。使用 Helm 可以分为处理现有图表和开发新图表两部分，下面先介绍处理现有图表的操作：
- 存储库管理 ：

# Add a repo (Add bitnami repo to your local repo list)
helm repo add bitnami https://charts.bitnami.com/bitnami
# For private repository, use additional authentication flags
# To view the list of possible authentication flags
helm repo add --help
# Update the charts in all the added repo's
helm repo update
# Update the charts in a specific repo.
helm repo update bitnami
# Search for charts with the given name within the added repo
helm search repo wordpress
# Search charts in ArtifactHub, a famous open-source repo  
helm search hub wordpress
#List all the repositories added
helm repo list

- **发布管理**：

# Install a chart
# Format
helm install <release-name> <chart-name>
# Example
helm install redis bitnami/redis
# Each chart will support a list of variables to be set
# Variables can be hierarchical. For example, the 'enabled' flag 
is under the 'auth' hierarchy in the bitnami/redis chart.
helm install redis bitnami/redis --set auth.enabled=false
# Install with a value set in the values file
helm install redis bitnami/redis -f values.yaml
# If the same variable is present in both the command line set 
and value file, the command line set takes precedence. 
helm install redis bitnami/redis -f values.yaml --set auth.enabled=false
# Update a release
# Format
helm upgrade <release-name> <chart-name>

综上所述，通过合理运用这些配置管理方法、抽象模式以及工具，能够提高应用开发和部署的效率，降低管理成本，实现更灵活、可扩展的应用配置管理。后续还会有更多关于这些工具的实践示例，帮助大家更好地掌握和应用这些技术。

应用配置管理与抽象模式解析（续）

7. 使用 Kustomize 定制配置

Kustomize 是另一个强大的 Kubernetes 配置管理工具，它允许用户通过补丁和覆盖的方式定制 Kubernetes 配置。与 Helm 不同，Kustomize 不使用模板，而是直接处理 YAML 文件，因此更适合那些希望保持配置文件简洁和易于理解的场景。

使用 Kustomize 定制配置的基本步骤如下：
1. 创建基础配置文件 ：首先，创建一个包含基本配置的 YAML 文件，例如 deployment.yaml 和 service.yaml 。
2. 创建 Kustomization 文件 ：在基础配置文件所在的目录下，创建一个名为 kustomization.yaml 的文件，用于指定需要定制的内容。例如：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml
patchesStrategicMerge:
  - patch.yaml

创建补丁文件 ：创建一个补丁文件，例如 patch.yaml ，用于覆盖或修改基础配置中的特定部分。例如：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3

应用定制配置 ：使用 kustomize build 命令生成定制后的配置文件，然后使用 kubectl apply 命令将其应用到 Kubernetes 集群中。

kustomize build . | kubectl apply -f -

以下是一个使用 Kustomize 定制配置的流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(基础配置文件):::process --> B(Kustomization 文件):::process
    B --> C(补丁文件):::process
    B --> D(kustomize build):::process
    D --> E(kubectl apply):::process
    E --> F(Kubernetes 集群):::process

8. 使用 KubeVela 部署应用工作负载

KubeVela 是 OAM 的具体实现，它专注于组合定制化应用配置，为开发者和运维人员提供了一种简单而强大的方式来部署和管理应用工作负载。

使用 KubeVela 部署应用工作负载的基本步骤如下：
1. 安装 KubeVela ：首先，需要在 Kubernetes 集群中安装 KubeVela。可以使用 Helm 或官方提供的安装脚本进行安装。
2. 定义应用组件 ：创建一个 YAML 文件，定义应用的组件和特性。例如：

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: my-app
spec:
  components:
    - name: my-web-service
      type: webservice
      properties:
        image: nginx:latest
        port: 80
      traits:
        - type: ingress
          properties:
            domain: example.com
            http:
              "/": 80

部署应用 ：使用 vela up 命令将应用部署到 Kubernetes 集群中。

vela up -f app.yaml

监控和管理应用 ：使用 vela status 命令查看应用的状态，使用 vela delete 命令删除应用。

以下是一个使用 KubeVela 部署应用工作负载的列表说明：
|步骤|操作|命令示例|
| ---- | ---- | ---- |
|安装 KubeVela|使用 Helm 或官方脚本安装| helm install kubevela kubevela/vela-core -n vela-system |
|定义应用组件|创建 YAML 文件定义组件和特性| vim app.yaml |
|部署应用|使用 vela up 命令部署| vela up -f app.yaml |
|监控应用|使用 vela status 命令查看状态| vela status my-app |
|删除应用|使用 vela delete 命令删除| vela delete my-app |