本文档采用自动化机器翻译技术翻译。尽管我们力求提供准确的译文，但不对翻译内容的完整性、准确性或可靠性作出任何保证。若出现任何内容不一致情况，请以原始英文版本为准，且原始英文版本为权威文本。

GitOps最佳实践：海龟与CAPI

本节提供了与海龟和集群API（CAPI）实施GitOps的最佳实践，重点是将https://documentation.suse.com/cloudnative/continuous-delivery/v0.12/en/index.html[持续交付]与*集群API附加提供者Fleet*(CAAPF)结合使用，以实现代理的自动化配置和集成到`CAPI`生态系统中。

这些建议是可转移的，即使在使用不同的GitOps解决方案时也可以应用。

常见建议

分离CAPI集群和ClusterClass配置: 保持CAPI集群配置（clusters/）与CAPI ClusterClass`定义（`templates/）的独立性。这种分离允许从共享模板中部署多个集群，同时降低意外基础设施更改的风险。
隔离附加组件配置: 将应用程序清单存储在`applications/中，确保它们独立于`Clusters`和`ClusterClasses。这使得可以根据用户需求或匹配选择器进行选择性或分组部署，防止干扰集群基础设施。请注意，Helm图表依赖项在进行附加组件部署之前需要https://documentation.suse.com/cloudnative/continuous-delivery/v0.12/en/gitrepo-content.html#_fleet_yaml[刷新]。
利用嵌套GitRepo资源: 利用https://documentation.suse.com/cloudnative/continuous-delivery/v0.12/en/gitrepo-content.html#_nested_gitrepo_crs[嵌套] `GitRepo`资源在Fleet中高效地组织储存库内容。这种方法允许模块化部署，结合`ClusterClass`定义、所需的附加组件/应用程序和集群配置，同时保持关注点的分离。
在可用时使用GitOps集成工具: 在配置GitOps设置时，请考虑可用的工具和它提供的功能。一个例子是https://rancher.github.io/cluster-api-addon-provider-fleet/00_intro.html[CAAPF]，它自动化了在`CAPI`集群上安装Fleet GitOps并提供便捷的自动化。
应用Kustomize覆盖以进行环境特定的自定义: 使用`overlays/`存储不同环境的Kustomize覆盖。这确保了配置更改，例如扩展调整、网络修改或组件升级，可以动态应用，而无需更改基础清单。
利用比较补丁: 如果包中包含适当的规则以检测https://documentation.suse.com/cloudnative/continuous-delivery/v0.12/en/troubleshooting.html#_suse_rancher_prime_continuous_delivery_deployment_stuck_in_modified_state[`diff`的差异]，Fleet允许选择性忽略资源差异。这将防止包处于修改状态。

文件夹分离策略

结构良好的储存库简化了管理并提高了清晰度。推荐以下文件夹分离策略：

repo-root/
│── fleet/
│   ├── providers/         # CAPIProvider files to use with templates
│   │   ├── core/          # Core provider configuration
│   │   ├── infra-docker/  # Docker provider configuration
│   │   ├── infra-aws/     # AWS provider configuration
│   ├── clusters/          # Cluster-specific configurations
│   │   ├── prod/          # Production clusters
│   │   ├── staging/       # Staging clusters
│   │   ├── dev/           # Development clusters
│   ├── addons/            # Application-specific manifests focused on cluster bootstrapping, like CNI, CCM, CPI configurations.
│   │   ├── cni/           # Group applications based on purpose. Provide fleet.yaml per each sub-directory to maintain bundle separation.
│   │   ├── ccm/
│   ├── templates/         # CAPI ClusterClass templates for cluster provisioning
│   ├── fleet.yaml         # Fleet bundle configuration
│── overlays/              # Kustomize overlays for different environments
│   ├── prod/.             # Kustomize overlays for production environments
│   ├── staging/.          # Kustomize overlays for staging environments
│   ├── dev/.              # Kustomize overlays for development environments

提供者配置

CAPI提供者定义了部署集群所需的基础设施组件。一个简单的设置可能如下所示：

repo-root/
│── fleet/
│   ├── providers/
│   │   ├── core/
│   │   |   ├── core.yaml  # Core `CAPIProvider` definition
│   │   |   ├── fleet.yaml # Fleet.yaml definition for the provider setup

其中内核提供者包含：

apiVersion: turtles-capi.cattle.io/v1alpha1
kind: CAPIProvider
metadata:
  name: cluster-api
spec:
  type: core

模板配置

在`dependsOn`中指定`fleet.yaml`以用于特定的`CAPIProvider`包或外部`GitRepo`组件。这确保模板按正确顺序推出，并防止组件控制器缺失或未准备好接受`ClusterClass`定义的问题。

namespace: capa-clusters
dependsOn:
  - name: core      # Ensure core bundle is installed first
  - name: infra-aws # Wait for AWS provider installation

集群配置

使用标签动态匹配集群与所需的附加组件，仅允许部署必要的工作负载。

示例标签用法：

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: aws-cluster
  labels:
    cni: calico
    ccm: aws
    env: dev

建议将集群定义与模板分开，因为这样的集群包移除将允许CAPI控制器按正确顺序处理删除。同时移除`Clusters`和`ClusterClasses`可能会产生意想不到的结果。

附加组件配置

附加组件配置对于简化集群部署至关重要，确保它们在没有人工干预或第三方工具的情况下达到`Ready`状态。

集群附加组件应定义精确的选择规则，以匹配适当标记的集群。

下面的示例展示了一个需要安装`Calico` CNI和`AWS` 云控制器管理器（CCM）的集群：

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: aws-cluster
  labels:
    cni: calico
    ccm: aws

此设置需要两个`GitRepo`资源，每个资源负责根据特定标签部署附加组件——一个用于`cni: calico`，另一个用于`ccm: aws`。

这是一个用于部署`GitRepo` CNI的`Calico`资源示例：

apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
  name: calico
spec:
  branch: main
  paths:
  - /fleet/applications/calico
  repo: https://github.com/rancher-sandbox/cluster-api-addon-provider-fleet.git
  targets:
  - clusterSelector:
      matchLabels:
        cni: calico
        env: dev

这确保`Calico` CNI仅在标记为`cni: calico`和`env: dev`的集群上部署，从而实现选择性环境部署。

Helm Chart 值模板化

附加组件配置需要根据匹配的集群定义和特定集群状态动态调整`Calico`工作负载。这可以通过一个类似于以下结构的`fleet.yaml`设置来实现：

repo-root/
│── fleet/
│   ├── applications/
│   │   ├── calico/
│   │   │   ├── fleet.yaml # Fleet configuration for the Calico setup

fleet.yaml`文件定义了模板化规则和`comparePatches，以确保平稳的发布，与集群配置无关。要了解更多关于这里使用的`CAAPF`模板化的信息，请参考官方https://rancher.github.io/cluster-api-addon-provider-fleet/04_reference/02_templating-strategy.html[文档]。

helm:
  releaseName: projectcalico
  repo: https://docs.tigera.io/calico/charts
  chart: tigera-operator
  templateValues:
    installation: |-
      cni:
        type: Calico
        ipam:
          type: HostLocal
      calicoNetwork:
        bgp: Disabled
        mtu: 1350
        ipPools:
          ${- range $cidr := .ClusterValues.Cluster.spec.clusterNetwork.pods.cidrBlocks }
          - cidr: "${ $cidr }"
            encapsulation: None
            natOutgoing: Enabled
            nodeSelector: all()${- end}

diff:
  comparePatches:
  - apiVersion: operator.tigera.io/v1
    kind: Installation
    name: default
    operations:
    - {"op":"remove", "path":"/spec/kubernetesProvider"}