AKS および Azure Arc 対応 Kubernetes 用の GitOps (Flux v2) を使用したアプリケーションデプロイ

[アーティクル]
03/27/2024

Azure では、Azure Kubernetes Service (AKS) および Azure Arc 対応 Kubernetes クラスターと連携する GitOps を使用した自動アプリケーションデプロイ機能を提供しています。アプリケーションを Kubernetes クラスターにデプロイするために GitOps を採用することで得られる主な利点は次のとおりです。

クラスターで実行されているアプリケーションの状態に対する継続的な可視性。
アプリケーション開発チームとインフラストラクチャチーム間の懸念事項の分離。アプリケーションチームには、Kubernetes デプロイの経験が必要ありません。プラットフォームエンジニアリングチームは通常、アプリケーションチーム向けのセルフサービスモデルを作成し、より高い信頼性でデプロイを実行できるようにします。
クラッシュした場合やスケールアウトした場合に、同じ目的の状態でクラスターを再作成する機能。

GitOps では、Git リポジトリ内のファイルで、Kubernetes クラスターの必要な状態を宣言します。 Git リポジトリには、次のファイルが含まれる場合があります。

Kubernetes リソース (名前空間、シークレット、デプロイなど) を記述する YAML 形式のマニフェスト
アプリケーションをデプロイするための Helm チャート
環境固有の変更について記述する Kustomize ファイル

これらのファイルは Git リポジトリに格納されるため、バージョン管理され、バージョン間の変更を簡単に追跡できます。 Kubernetes コントローラーはクラスターで実行され、Git リポジトリで宣言されている必要な状態でクラスターの状態を継続的に調整します。これらのオペレーターは、Git リポジトリからファイルを取得し、必要な状態をクラスターに適用します。また、オペレーターは、クラスターが必要な状態を維持していることを継続的に保証します。

Azure Arc 対応 Kubernetes または Azure Kubernetes Service の GitOps は、一般的なオープンソースツールセットである Flux を使用します。 Flux は、一般的なファイルソース (Git および Helm リポジトリ、バケット、Azure Blob Storage) とテンプレートの種類 (YAML、Helm、および Kustomize) をサポートします。また、Flux はマルチテナントとデプロイの依存関係の管理などの機能もサポートしています。

Flux はクラスターに直接デプロイされ、各クラスターのコントロールプレーンは論理的に分離されます。これにより、数百と数千のクラスターに適切にスケーリングできます。 Flux により、純粋なプルベースの GitOps アプリケーションのデプロイが可能になります。ソースリポジトリまたはその他のクラスターによるクラスターへのアクセスは必要ありません。

Flux クラスターの拡張機能

GitOps は、Azure Arc 対応 Kubernetes クラスターまたは AKS クラスターで、Microsoft.KubernetesConfiguration/extensions/microsoft.fluxクラスター拡張機能リソースとして有効になっています。 1 つ以上の fluxConfigurations を作成するには、事前に microsoft.flux 拡張機能をクラスターにインストールする必要があります。クラスターで最初の Microsoft.KubernetesConfiguration/fluxConfigurations を作成すると、拡張機能が自動的にインストールされます。また、ポータル、Azure CLI (az k8s-extension create --extensionType=microsoft.flux)、ARM テンプレート、または REST API を使用して、拡張機能を手動でインストールできます。

コントローラー

既定では、microsoft.flux 拡張機能によって Flux コントローラー (Source、Kustomize、Helm、Notification) と、FluxConfig カスタムリソース定義 (CRD)、fluxconfig-agent、fluxconfig-controller がインストールされます。また、必要に応じて、Docker イメージの更新と取得に関する機能を提供する、Flux image-automation および image-reflector コントローラーをインストールすることもできます。

Flux ソースコントローラー: source.toolkit.fluxcd.io カスタムリソースを監視します。 Git リポジトリ、Helm リポジトリ、バケットおよび Azure Blob Storage 間の同期を処理します。プライベート Git、Helm リポジトリ、Azure BLOB ストレージアカウントのソースを使用した認可を処理します。 Tar アーカイブファイルを使用して、ソースへの最新の変更を示します。
Flux Kustomize コントローラー: kustomization.toolkit.fluxcd.io カスタムリソースを監視します。ソースからクラスターに Kustomize ファイルまたは未加工の YAML ファイルを適用します。
Flux Helm コントローラー: helm.toolkit.fluxcd.io カスタムリソースを監視します。 Source コントローラーによって示される Helm リポジトリソースから、関連するグラフを取得します。 HelmChart カスタムリソースを作成し、特定のバージョン、名前、および顧客定義の値を使用して HelmRelease をクラスターに適用します。
Flux Notification コントローラー: notification.toolkit.fluxcd.io カスタムリソースを監視します。すべての Flux コントローラーから通知を受信します。ユーザー定義の Webhook エンドポイントに通知をプッシュします。
Flux カスタムリソース定義:
- kustomizations.kustomize.toolkit.fluxcd.io
- imagepolicies.image.toolkit.fluxcd.io
- imagerepositories.image.toolkit.fluxcd.io
- imageupdateautomations.image.toolkit.fluxcd.io
- alerts.notification.toolkit.fluxcd.io
- providers.notification.toolkit.fluxcd.io
- receivers.notification.toolkit.fluxcd.io
- buckets.source.toolkit.fluxcd.io
- gitrepositories.source.toolkit.fluxcd.io
- helmcharts.source.toolkit.fluxcd.io
- helmrepositories.source.toolkit.fluxcd.io
- helmreleases.helm.toolkit.fluxcd.io
- fluxconfigs.clusterconfig.azure.com
FluxConfig CRD: FluxConfig Kubernetes オブジェクトを定義する fluxconfigs.clusterconfig.azure.com カスタムリソースのカスタムリソース定義。
fluxconfig-agent: Azure の新規または更新された fluxConfigurations リソースを監視し、クラスターで関連する Flux 構成を開始する役割を担います。また、各 fluxConfigurations リソースについて、クラスター内の Flux の状態の変更を Azure に戻す役割も担います。
fluxconfig-controller: fluxconfigs.clusterconfig.azure.com カスタムリソースを監視し、クラスター内の GitOps 構造の新規または更新された構成によって変更に対応します。

Note

microsoft.flux 拡張機能は flux-system 名前空間にインストールされ、クラスター全体に反映されます。名前空間スコープでこの拡張機能をインストールすることはできません。

Flux 構成

Git リポジトリ、バケットソースまたは Azure BLOB ストレージからクラスターの GitOps 管理を有効にするには、Flux 構成リソース (Microsoft.KubernetesConfiguration/fluxConfigurations) を作成します。 fluxConfigurations リソースを作成するときに、ターゲットの Git リポジトリなどのパラメーターに指定した値は、そのクラスターで GitOps プロセスを有効にする Kubernetes オブジェクトを作成および構成するために使用されます。データのセキュリティを確保するため、fluxConfigurations リソースデータは、Cluster Configuration サービスによって、保存時に暗号化された状態で Azure Cosmos DB データベースに格納されます。

microsoft.flux 拡張機能と共にインストールされる fluxconfig-agent および fluxconfig-controller エージェントは、GitOps 構成プロセスを管理します。

fluxconfig-agent は以下のタスクを担当します。

新規または更新された fluxConfigurations リソースについて、Kubernetes 構成データプレーンサービスをポーリングします。
構成情報を使用して、クラスター内の FluxConfig カスタムリソースを作成または更新します。
FluxConfig カスタムリソースを監視し、関連する Azure fluxConfiguration リソースに状態の変更を戻します。

fluxconfig-controller は以下のタスクを担当します。

管理対象の fluxConfigurations で作成された Flux カスタムリソースへのステータス更新を監視します。
fluxConfigurations の有効期間にわたって存在する秘密キーと公開キーのペアを作成します。このキーは、URL が SSH ベースの場合、および構成の作成時にユーザーが独自の秘密キーを指定していない場合に、認証に使用されます。
ユーザー指定の秘密キー/http 基本認証/既知のホスト/認証なしのデータに基づいて、カスタム認証シークレットを作成します。
ロールベースのアクセス制御 (サービスアカウントのプロビジョニング、ロールバインドの作成/割り当て、ロールの作成/割り当て) を設定します。
FluxConfig カスタムリソースの情報から、GitRepository または Bucket カスタムリソース、および Kustomization カスタムリソースを作成します。

Azure の各 fluxConfigurations リソースは、Kubernetes クラスターで、1 つの Flux GitRepository または Bucket カスタムリソース、および 1 つ以上の Kustomization カスタムリソースに関連付けられます。 fluxConfigurations リソースを作成するとき、ソース (Git リポジトリ、バケットまたは Azure Blob Storage) の URL と、各 Kustomization のソースの同期ターゲットを指定します。 Kustomization カスタムリソース間の依存関係を構成して、デプロイシーケンスを制御できます。また、異なるアプリケーションおよびアプリチームのために、同じクラスターで名前空間で範囲指定された複数の fluxConfigurations リソースを作成することもできます。

Note

fluxconfig-agent は、Azure の新規または更新された fluxConfiguration リソースを監視します。エージェントは、fluxConfiguration の必要な状態をクラスターに適用するために、Azure への接続を必要とします。エージェントが Azure に接続できない場合、クラスター内の変更はエージェントが接続できるようになるまで待機します。クラスターが 48 時間以上 Azure から切断された場合、クラスターへの要求はタイムアウトになり、変更を Azure に再適用する必要があります。

秘密キー、トークン/パスワードなどの機密性の高い顧客入力が、48 時間以上 Kubernetes 構成サービスに保存されることはありません。 Azure でこれらの値のいずれかを更新する場合は、クラスターが 48 時間以内に Azure に接続していることを確認してください。

Azure portal で Flux の構成状態とコンプライアンスを監視したり、ダッシュボードを使用して状態、コンプライアンス、リソース使用量、調整アクティビティを監視したりできます。詳細については、「GitOps (Flux v2) の状態とアクティビティを監視する」を参照してください。

バージョンのサポート

Flux v2 拡張機能 (microsoft.flux) の最新バージョンと、前の 2 つのバージョン (N-2) がサポートされています。一般的に、拡張機能の最新バージョンを使用することをお勧めします。 microsoft.flux バージョン 1.7.0 以降では、ARM64 ベースのクラスターがサポートされています。

Note

Flux v1 を使用している場合、できるだけ早く Flux v2 に移行することをお勧めします。

2024 年 1 月 1 日より前に作成された Flux v1 ベースのクラスター構成リソースのサポートは、2025 年 5 月 24 日に終了します。 2024 年 1 月 1 日から、新しい Flux v1 ベースのクラスター構成リソースを作成することはできません。

プライベートリンクを使用する GitOps

Azure Arc 対応 Kubernetes クラスターにプライベートリンクのサポートを追加した場合、microsoft.flux 拡張機能は Azure に戻る通信ですぐに機能します。 Git リポジトリ、Helm リポジトリ、または Kubernetes マニフェストをデプロイするために必要なその他のエンドポイントへの接続の場合は、これらのエンドポイントをファイアウォールの内側にプロビジョニングするか、ファイアウォールにリストして Flux Source コントローラーが正常にアクセスできるようにする必要があります。

データの保存場所

Azure GitOps サービス (Azure Kubernetes Configuration Management) は、顧客データを格納/処理します。既定では、顧客データはペアになっているリージョンにレプリケートされます。シンガポール、東アジア、ブラジル南部のリージョンでは、すべての顧客データがリージョン内で格納および処理されます。

Flux 構成を大規模に適用する

Azure Resource Manager によって構成が管理されるので、サブスクリプションまたはリソースグループの範囲内で、Azure Kubernetes Service と Azure Arc 対応 Kubernetes のリソース全体で Azure Policy を使用して同じ構成の作成を自動化できます。この大規模な適用によって、クラスターグループ全体に特定の構成が一貫して適用されます。

詳細については、「Flux v2 構成と Azure Policy を使用して、アプリケーションを一貫して大規模にデプロイする」を参照してください。

パラメーター

Azure で Flux v2 によってサポートされているすべてのパラメータについては、az k8s-configuration ドキュメントを参照してください。現在、Azure の実装では、Flux がサポートしているすべてのパラメーターがサポートされているわけではありません。

使用可能なパラメーターとその使用方法については、「GitOps (Flux v2) でサポートされているパラメーター」を参照してください。

マルチテナント

Flux v2 では、バージョン 0.26 以降でマルチテナントがサポートされています。この機能は、Azure の Flux v2 に統合されています。

Note

マルチテナント機能を実現するには、マニフェストに HelmRelease、Kustomization、ImagePolicy、他のオブジェクト用の名前空間をまたがる sourceRef があるかどうか、または 1.20.6 より前の Kubernetes バージョンを使用するかどうかを把握している必要があります。準備するには:

Kubernetes バージョン 1.20.6 以上にアップグレードします。
Kubernetes のマニフェストで、すべての sourceRef が GitOps 構成と同じ名前空間内のオブジェクトを示していることを確認します。
- マニフェストを更新するために時間が必要な場合は、マルチテナントをオプトアウトできます。ただし、その場合も Kubernetes のバージョンをアップグレードする必要はあります。

マルチテナント用にマニフェストを更新する

クラスターのスコープを指定して fluxConfiguration を cluster-config 名前空間の Kubernetes クラスターの 1 つにデプロイするとします。 https://github.com/fluxcd/flux2-kustomize-helm-example リポジトリを同期するようにソースを構成します。これは、Flux v2 チュートリアルで GitOps を使用してアプリケーションをデプロイする場合に使用されるのと同じサンプル Git リポジトリです。

Flux は、リポジトリを同期した後、マニフェスト (YAML ファイル) で説明されているリソースをデプロイします。マニフェストの 2 つで HelmRelease および HelmRepository オブジェクトを記述しています。

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: nginx
  namespace: nginx
spec:
  releaseName: nginx-ingress-controller
  chart:
    spec:
      chart: nginx-ingress-controller
      sourceRef:
        kind: HelmRepository
        name: bitnami
        namespace: flux-system
      version: "5.6.14"
  interval: 1h0m0s
  install:
    remediation:
      retries: 3
  # Default values
  # https://github.com/bitnami/charts/blob/master/bitnami/nginx-ingress-controller/values.yaml
  values:
    service:
      type: NodePort

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
  name: bitnami
  namespace: flux-system
spec:
  interval: 30m
  url: https://charts.bitnami.com/bitnami

既定では、Flux 拡張機能は、cluster-config 名前空間にのみデプロイされている flux-applier サービスアカウントを借用することにより、fluxConfigurations をデプロイします。上記のマニフェストを使用すると、マルチテナントが有効になっている場合に、HelmRelease はブロックされます。これは、 HelmRelease は nginx 名前空間内にあるものの、flux-system 名前空間内の HelmRepository を参照しているためです。また、Flux helm-controller は、nginx 名前空間に flux-applier サービスアカウントがないため、HelmRelease を適用できません。

マルチテナントを使用するには、すべての Flux オブジェクトを fluxConfigurations と同じ名前空間にデプロイするのが正しい方法です。このアプローチでは、名前空間間の参照の問題を回避でき、Flux コントローラーはオブジェクトを適用するための権限を取得できるようになります。そのため、cluster-config 名前空間で作成された GitOps 構成の場合、上記のマニフェストは次のように変更されます。

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: nginx
  namespace: cluster-config 
spec:
  releaseName: nginx-ingress-controller
  targetNamespace: nginx
  chart:
    spec:
      chart: nginx-ingress-controller
      sourceRef:
        kind: HelmRepository
        name: bitnami
        namespace: cluster-config
      version: "5.6.14"
  interval: 1h0m0s
  install:
    remediation:
      retries: 3
  # Default values
  # https://github.com/bitnami/charts/blob/master/bitnami/nginx-ingress-controller/values.yaml
  values:
    service:
      type: NodePort

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
  name: bitnami
  namespace: cluster-config
spec:
  interval: 30m
  url: https://charts.bitnami.com/bitnami

マルチテナントのオプトアウト

microsoft.flux 拡張機能をインストールすると、マルチテナントが既定で有効になります。マルチテナントを無効にする必要がある場合は、次のコマンド例に示すように、--configuration-settings multiTenancy.enforce=false を指定してクラスター内の microsoft.flux 拡張機能を作成または更新することでオプトアウトできます。

az k8s-extension create --extension-type microsoft.flux --configuration-settings multiTenancy.enforce=false -c CLUSTER_NAME -g RESOURCE_GROUP -n flux -t <managedClusters or connectedClusters>

az k8s-extension update --configuration-settings multiTenancy.enforce=false -c CLUSTER_NAME -g RESOURCE_GROUP -n flux -t <managedClusters or connectedClusters>

Flux v1 から移行する

Flux v1 をまだ使用している場合、できるだけ早く Flux v2 に移行することをお勧めします。

Flux v1 を使用していたのと同じクラスターで Flux v2 を使用するように移行するには、まず、クラスターからすべての Flux v1 sourceControlConfigurations を削除する必要があります。 Flux v2 のアーキテクチャは基本的に異なるため、クラスター内に Flux v1 sourceControlConfigurations リソースがある場合、microsoft.flux クラスター拡張機能はインストールされません。 Flux v1 構成を削除し、Flux v2 構成をデプロイするプロセスには、30 分以上はかかりません。

Flux v1 sourceControlConfigurations を削除しても、クラスターで実行されているアプリケーションは停止されません。ただし、Flux v1 構成が削除され、Flux v2 拡張機能がまだ完全にデプロイされていない期間中は:

Git リポジトリに格納されているアプリケーションマニフェストに新しい変更がある場合、これらの変更は移行中にプルされず、クラスターにデプロイされたアプリケーションのバージョンは古くなります。
クラスターの状態に意図しない変更があり、ソース Git リポジトリで指定された目的の状態から逸脱している場合、クラスターは自己修復できません。

運用環境を移行する前に、開発環境で移行シナリオをテストすることをお勧めします。

Flux v1 構成の表示と削除

次の Azure CLI コマンドを使用し、クラスター内の既存の sourceControlConfigurations を検索して削除します。

az k8s-configuration list --cluster-name <cluster name> --cluster-type <connectedClusters or managedClusters> --resource-group <resource group name>
az k8s-configuration delete --name <configuration name> --cluster-name <cluster name> --cluster-type <connectedClusters or managedClusters> --resource-group <resource group name>

Azure portal でクラスターの既存の GitOps 構成を検索および削除することもできます。これを行うには、構成が作成されたクラスターに移動し、左側のウィンドウで [GitOps] を選択します。構成を選択し、[削除] を選択します。

Flux v2 構成のデプロイ

Azure portal または Azure CLI を使用して、クラスターに Flux v2 構成を適用します。

Flux v1 の廃止に関する情報

Flux v1 のオープンソースプロジェクトがアーカイブされ、機能開発が無期限に停止されました。

Flux v2 は、アップグレードされた Flux のオープンソースプロジェクトとして開始されました。これは、新しいアーキテクチャが採用されており、より多くの GitOps のユースケースをサポートしています。 Microsoft は 2022 年 5 月、Flux v2 を使用した拡張機能のバージョンを開始しました。それ以降、Flux v1 の使用に対するサポートは 2025 年 5 月に終了する予定であるため、3 年以内に Flux v2 に移行することをお勧めします。

Flux v2 の GitOps 拡張機能で導入された主な新機能:

Flux v1 は、すべての操作を行うモノリシックなオペレーターです。 Flux v2 では、機能が特殊なコントローラー (ソースコントローラー、Kustomize コントローラー、Helm コントローラー、および通知コントローラー) に分離されています。
複数のソースリポジトリとの同期をサポートします。
独自のアクセス許可セットを使用して各ソースリポジトリの適用などのマルチテナントをサポートします。
正常性チェック、イベント、アラートを通じて運用上の分析情報を提供します。
Git ブランチ、コミットとタグの固定、および SemVer タグ範囲のフォローをサポートします。
GitRepository リソースごとの資格情報の構成: SSH 秘密キー、HTTP/S ユーザー名/パスワード/トークン、OpenPGP 公開キー。

次のステップ

チュートリアルを使用して、AKS または Azure Arc 対応 Kubernetes クラスターで GitOps を有効にする方法をご確認ください。
GitOps を使用した CI/CD ワークフローをご確認ください。

AKS および Azure Arc 対応 Kubernetes 用の GitOps (Flux v2) を使用したアプリケーション デプロイ

Flux クラスターの拡張機能

コントローラー

Flux 構成

バージョンのサポート

プライベート リンクを使用する GitOps

データの保存場所

Flux 構成を大規模に適用する

パラメーター

マルチテナント

マルチテナント用にマニフェストを更新する

マルチテナントのオプトアウト

Flux v1 から移行する

Flux v1 構成の表示と削除

Flux v2 構成のデプロイ

Flux v1 の廃止に関する情報

次のステップ

その他のリソース

AKS および Azure Arc 対応 Kubernetes 用の GitOps (Flux v2) を使用したアプリケーションデプロイ

プライベートリンクを使用する GitOps