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

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

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

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 アプリケーションのデプロイが可能になります。ソースリポジトリまたはその他のクラスターによるクラスターへのアクセスは必要ありません。

Important

Azure Kubernetes Service (AKS)、AKS Edge Essentials、または Azure Arc on Azure Local で有効になっている AKS での Flux デプロイには料金はかかりません。 Azure Arc 対応 Kubernetes 経由で接続されている他の Kubernetes ディストリビューションの場合、サブスクリプションの最初の 6 つの vCPU での Flux デプロイには料金はかかりません。その後、クラスターあたりの vCPU の数に基づいて料金が適用されます。詳細については、 Azure Arc の価格に関するページを参照してください。

Flux クラスターの拡張機能

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

コントローラー

既定では、 microsoft.flux 拡張機能によって Flux コントローラー (ソース、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 Storage アカウントのソースを使用した認可を処理します。 Tar アーカイブファイルを通じて、ソースに対する最新の変更を示します。
Flux Kustomize コントローラー: kustomization.toolkit.fluxcd.io カスタムリソースを監視します。ソースからクラスターに Kustomize ファイルまたは未加工の YAML ファイルを適用します。
Flux Helm コントローラー: helm.toolkit.fluxcd.io カスタムリソースを監視します。 Source コントローラーによって示される Helm リポジトリソースから、関連するグラフを取得します。 HelmChart カスタムリソースを作成し、特定のバージョン、名前、顧客定義の値を使用して、HelmRelease をクラスターに適用します。
Flux 通知コントローラー: 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: fluxconfigs.clusterconfig.azure.com Kubernetes オブジェクトを定義する FluxConfig カスタムリソースのカスタムリソース定義。
fluxconfig-agent: Azure で新規または更新された fluxConfigurations リソースがないかどうかを監視する役割と、クラスター内にある関連する Flux 構成を開始する役割を担います。また、各 fluxConfigurations リソースについて、クラスター内の Flux の状態の変更を Azure にプッシュして戻す役割も担います。
fluxconfig-controller: fluxconfigs.clusterconfig.azure.com カスタムリソースを監視し、クラスター内の GitOps 構造の新規または更新された構成を使用して変更に対応します。

注

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

Flux 構成

アーキテクチャ図を高解像度でダウンロードするには、 Jumpstart Gem にアクセスしてください。

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

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

fluxconfig-agent は、次のタスクを担当します。

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

fluxconfig-controller は、次のタスクを担当します。

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

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

注

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 ベースのクラスターがサポートされています。

プライベートリンクを使用する 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 に統合されています。

注

マルチテナント機能の場合、マニフェストに HelmRelease、Kustomization、ImagePolicy、またはその他のオブジェクトのクロス名前空間 sourceRef が含まれているかどうか、または 1.20.6 未満の Kubernetes バージョンを使用しているかどうかを確認する必要があります。準備するには、次を実行します。

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

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

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

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

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

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

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

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>

次のステップ

このチュートリアルでは、 AKS または Azure Arc 対応 Kubernetes クラスターで GitOps を有効にする方法について説明します。
GitOps を使用した CI/CD ワークフローについて説明します。

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-10-08