この文書は自動機械翻訳技術を使用して翻訳されています。正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。相違がある場合は、元の英語版英語が優先され、正式なテキストとなります。

カメとCAPIのためのGitOpsベストプラクティス

このセクションでは、カメとCluster 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リソースを活用する: Fleet内のhttps://documentation.suse.com/cloudnative/continuous-delivery/v0.12/en/gitrepo-content.html#_nested_gitrepo_crs[ネストされた] `GitRepo`リソースを活用して、リポジトリの内容を効率的に構成してください。このアプローチにより、`ClusterClass`定義、必要なアドオン/アプリケーション、およびクラスター設定を組み合わせながら、モジュール式のプロビジョニングが可能になり、関心の分離を維持できます。
利用可能な場合はGitOps統合ツールを使用する: GitOpsセットアップを構成する際には、利用可能なツールとその提供する機能を考慮してください。その一例がhttps://rancher.github.io/cluster-api-addon-provider-fleet/00_intro.html[CAAPF]であり、これは`CAPI`クラスター上でFleet GitOpsのインストールを自動化し、便利な自動化を提供します。
環境特有のカスタマイズのためにKustomizeオーバーレイを適用する: `overlays/`を使用して、異なる環境のためのKustomizeオーバーレイを保存します。これにより、スケーリング調整、ネットワーク変更、またはコンポーネントのアップグレードなどの構成変更を、ベースマニフェストを変更することなく動的に適用できます。
比較パッチを利用する: Fleetは、バンドルに適切なhttps://documentation.suse.com/cloudnative/continuous-delivery/v0.12/en/troubleshooting.html#_suse_rancher_prime_continuous_delivery_deployment_stuck_in_modified_state[`diff`検出]のルールが含まれている場合、リソースの違いを選択的に無視することを可能にします。これにより、バンドルが変更された状態で停止することを防ぎます。

フォルダー分離戦略

よく構成されたリポジトリは、管理を簡素化し、明確さを向上させます。以下のフォルダー分離戦略が推奨されます：

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

テンプレートの設定

特定の`CAPIProvider`バンドルまたは外部`GitRepo`コンポーネントのために、`fleet.yaml`で`dependsOn`を指定します。これにより、テンプレートが正しい順序でデプロイメントされ、コンポーネントコントローラーが欠落しているか、`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

このセットアップには、特定のラベルに基づいてアドオンをプロビジョニングする責任を持つ2つの`GitRepo`リソースが必要です - 一つは`cni: calico`用、もう一つは`ccm: aws`用です。

以下は、Calico CNIをデプロイするための`GitRepo`リソースの例です：

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チャート値のテンプレート化

アドオン設定は、一致するクラスター定義と特定のクラスター状態に基づいて`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"}