Azure Kubernetes Service (AKS)
GitHub
GitOps は、ソフトウェア システムを運用および管理する際の一連の原則です。 この記事では、GitOps の原則を使って Azure Kubernetes Services (AKS) クラスターを運用および管理する手法について説明します。
Flux、Argo CD、OPA Gatekeeper、Kubernetes、Git のロゴは、それぞれの会社の商標です。 これらのマークを使用することが、保証を意味するものではありません。
アーキテクチャ
AKS で使用できる GitOps オペレーターは Flux と Argo CD の 2 つです。 これらは Cloud Native Computing Foundation (CNCF) のグラデュエート プロジェクトであり、広く使われています。 次のシナリオは、これらの使用方法を示しています。
シナリオ 1: GitOps と Flux、AKS との併用
このアーキテクチャの Visio ファイルをダウンロードします。
シナリオ 1 のデータ フロー
Flux は、AKS とネイティブに統合される クラスター拡張機能 です。 クラスター拡張機能は、AKS クラスターにソリューションをインストールして管理するためのプラットフォームを提供します。 AKS の拡張機能として Flux を有効にするには、Azure portal、Azure CLI、またはコードとしてのインフラストラクチャ (IaC) スクリプト (Terraform、Bicep スクリプトなど) を使用できます。 また、Azure Policy を使って、AKS クラスターに Flux v2 構成を大規模に適用することもできます。 詳細については、 Flux v2 構成と Azure Policy を使用した大規模なアプリケーションの一貫したデプロイに関するページを参照してください。
Flux を使うと、Kubernetes マニフェスト、Helm グラフ、Kustomization ファイルを AKS にデプロイできます。 Flux はポーリングベースのプロセスなので、クラスターのエンドポイントをビルド エージェントに公開することなく、構成の変更の検出、プル、調整を行うことができます。
このシナリオの場合、Kubernetes 管理者は、シークレットや ConfigMaps などの Kubernetes 構成オブジェクトを変更し、その変更を GitHub リポジトリに直接コミットできます。
次のデータ フローは、前の図に対応しています。
開発者が構成変更を GitHub リポジトリにコミットします。
Flux は、Git リポジトリの構成ドリフトを検出し、構成の変更をプルします。
Flux により、Kubernetes クラスターの状態が調整されます。
シナリオ 1 の代替方法
Flux は、Azure DevOps、GitLab、Bitbucket などの他の Git リポジトリと共に使用できます。
Flux Bucket API は、Git リポジトリの代わりに、Amazon S3 や Google Cloud Storage バケットなどのストレージ ソリューションからオブジェクトの成果物を生成するソースを定義します。 また、S3 互換の API を持つソリューションを使うこともできます。 MinIO と Alibaba Cloud Object Storage Service (OSS) の 2 つの例が挙げられますが、他にも解決策があります。
また、成果物を生成するソースとして Azure Blob Storage コンテナーに対して Flux を構成することもできます。 詳細については、「AKS および Azure Arc 対応 Kubernetes を使用した GitOps Flux v2 構成」を参照してください。
Flux v2 では、個別のチームが単一の共有 Kubernetes クラスターにワークロードをデプロイできるようにすることで、マルチテナントをサポートしています。 それぞれ異なるテナントを表す複数の Git リポジトリをクラスターに同期できます。 チーム間のワークロードの分離を確保するために、各チームは、Kubernetes ロールベースのアクセス制御 (RBAC) ポリシーによってアクセスが制限される AKS クラスター内に独自の名前空間または名前空間を持つことができます。
Flux では、1 つのクラスターを使用して、同じクラスターまたは他のクラスターでアプリを管理できます。 Flux オペレーターが含まれたハブ AKS クラスターは、複数のスポーク AKS クラスターへのアプリとインフラストラクチャ ワークロードの GitOps 継続的デリバリーを管理します。
シナリオ 2: GitOps と Flux、GitHub、AKS を併用して CI/CD を実装する
このアーキテクチャの Visio ファイルをダウンロードします。
シナリオ 2 のデータ フロー
このシナリオは、一般的な Web アプリケーションに対応するプルベースの DevOps パイプラインです。 このパイプラインでは、ビルドに GitHub Actions を使います。 デプロイには、アプリをプルして同期する GitOps オペレーターとして Flux を使います。
次のデータ フローは、前の図に対応しています。
アプリ コードは、Visual Studio Code などの統合開発環境 (IDE) を使用して開発されます。
アプリ コードが GitHub リポジトリにコミットされます。
GitHub Actions でアプリ コードからコンテナー イメージがビルドされ、コンテナー イメージが Azure Container Registry にプッシュされます。
GitHub Actions は、Container Registry のコンテナー イメージのバージョン番号に基づいて、現在のイメージ バージョンで Kubernetes マニフェスト配置ファイルを更新します。
Flux オペレーターにより、Git リポジトリ内の構成のドリフトが検出され、構成の変更がプルされます。
Flux は、アプリを AKS クラスターにデプロイするためにマニフェスト ファイルを使います。
シナリオ 3: Argo CD、GitHub リポジトリ、AKS を使用した GitOps
このアーキテクチャの Visio ファイルをダウンロードします。
シナリオ 3 のデータ フロー
AKS でクラスター拡張機能として Argo CD を有効にすることができます。 このシナリオの場合、Kubernetes 管理者は、シークレットや ConfigMaps などの Kubernetes 構成オブジェクトを変更し、その変更を GitHub リポジトリに直接コミットできます。
次のデータ フローは、前の図に対応しています。
Kubernetes 管理者は、YAML ファイルで構成の変更を行い、その変更を GitHub リポジトリにコミットします。
Argo CD は Git リポジトリから変更をプルします。
Argo CD は AKS クラスターに合わせて構成の変更を調整します。
Argo CD で、目的のターゲット状態を AKS クラスターに自動的に同期する必要はありません。 これは、実行中のアプリケーションを継続的に監視する Kubernetes コントローラーとして実装されています。 これは、AKS クラスターの現在のライブ状態と、Git リポジトリで指定されている目的のターゲット状態を比較します。 Argo CD は、相違点を報告して視覚化し、ライブ状態を目的のターゲット状態に自動的または手動で同期するツールを提供します。
Argo CD にはブラウザーベースのユーザー インターフェイスがあります。 これを使って、アプリケーションの構成を追加し、クラスターに対する同期状態を観察し、クラスターに対する同期を開始することができます。 Argo CD コマンド ラインを使用して、これらのタスクを実行することもできます。 ユーザー インターフェイスとコマンド ライン インターフェイスの両方に、構成の変更履歴を表示し、以前のバージョンにロールバックする機能があります。
既定では、Argo CD ユーザー インターフェイスと API サーバーは公開されません。 それらにアクセスするには、内部 IP アドレスを持つイングレス コントローラーを作成することをお勧めします。 または、 内部ロード バランサーを使用 してそれらを公開することもできます。
シナリオ 3 の代替方法
Azure DevOps などの Git と互換性のあるリポジトリであれば、構成ソース リポジトリとして利用できます。
シナリオ 4: Argo CD、GitHub Actions、AKS で GitOps を使用して CI/CD を実装する
このアーキテクチャの Visio ファイルをダウンロードします。
シナリオ 4 のデータ フロー
このシナリオは、一般的な Web アプリケーションに対応するプルベースの DevOps パイプラインです。 このパイプラインでは、ビルドに GitHub Actions を使います。 デプロイの場合、GitOps オペレーターとして Argo CD を使ってアプリのプルと同期を行います。
次のデータ フローは、前の図に対応しています。
このアプリ コードは、Visual Studio Code などの IDE を使って開発しています。
アプリ コードが GitHub リポジトリにコミットされます。
GitHub Actions は、アプリ コードからコンテナー イメージをビルドし、コンテナー イメージを Container Registry にプッシュします。
GitHub Actions は、Container Registry のコンテナー イメージのバージョン番号に基づいて、現在のイメージ バージョンで Kubernetes マニフェスト配置ファイルを更新します。
Argo CD は Git リポジトリからプルします。
Argo CD は、アプリを AKS クラスターにデプロイします。
シナリオ 4 の代替方法
Azure DevOps などの Git と互換性のあるリポジトリであれば、構成ソース リポジトリとして利用できます。
シナリオの詳細
GitOps は、ソフトウェア システムを運用および管理する際の一連の原則です。
システムの信頼できる唯一の情報源としてソース管理が使われています。
バージョン管理、コラボレーション、コンプライアンス、継続的インテグレーション、継続的デプロイ (CI/CD) などの開発プラクティスをインフラストラクチャの自動化に適用します。
これはあらゆるソフトウェア システムに適用できます。
GitOps は、Kubernetes のクラスター管理とアプリケーション配信によく使われます。
GitOps の原則に従って、GitOps マネージド システムの望ましい状態は次の条件を満たす必要があります。
宣言的： GitOps が管理するシステムでは、目的の状態が宣言によって表現されている必要があります。 通常、この宣言は Git リポジトリに格納されます。
バージョン管理と変更不可: 必要な状態は、不変性とバージョン管理を強制し、完全なバージョン履歴を保持する方法で格納されます。
自動取得: ソフトウェアエージェントは、ソースから目的の状態宣言を自動的に取得します。
継続的に調整: ソフトウェア エージェントは、実際のシステム状態を継続的に観察し、目的の状態の適用を試みます。
GitOps では、 IaC はコードを使用して、仮想マシン (VM)、ネットワーク、ファイアウォールなどのインフラストラクチャ コンポーネントの望ましい状態を宣言します。 このコードはバージョン コントロールされ、監査できます。
Kubernetes では、マニフェストを使用して、クラスターの状態からアプリケーションのデプロイまで、すべてを宣言によって記述します。 GitOps for Kubernetes では、クラスター インフラストラクチャの必要な状態が、バージョン コントロールに配置されます。 クラスター内のコンポーネント (通常は 演算子と呼ばれます) は、宣言型の状態を継続的に同期します。 この方法で、クラスターに影響するコード変更を確認し、監査できます。 最小限の特権 (PoLP) の原則をサポートすることで、セキュリティが強化されます。
GitOps エージェントは、コード リポジトリに格納されている目的の状態を使って、システムの状態を継続的に調整します。 一部の GitOps エージェントでは、Kubernetes オブジェクトの手動作成など、クラスターの外部で実行される操作を元に戻すことができます。 たとえば、 アドミッション コントローラーは 、作成、更新、および削除の操作中にオブジェクトにポリシーを適用します。 これらを使うと、ソース リポジトリ内のデプロイ コードが変更された場合にのみ、デプロイを変更できます。
ポリシーの管理と適用のツールを GitOps と組み合わせて、ポリシーを適用し、提案されたポリシーの変更に対してフィードバックを提供することができます。 個々のチームの通知を構成して、現在の GitOps の状態に関する通知を維持することができます。 たとえば、デプロイの成功と調整の失敗の通知を送信できます。
信頼できる唯一の情報源としての GitOps
GitOps は、クラスターの状態の一貫性と標準化を提供し、セキュリティの強化に役立ちます。 また、GitOps を使って、複数のクラスター間で一貫した状態を確保することもできます。 たとえば、GitOps は、プライマリ クラスターとディザスター リカバリー (DR) クラスター間、またはクラスターのファーム全体で同じ構成を適用できます。
クラスターの状態を変更するための唯一の方法として GitOps を適用するには、クラスターへの直接アクセスを制限します。 この構成を設定するには、Azure ロールベースのアクセス制御 (Azure RBAC)、アドミッション コントローラー、またはその他のツールを使用します。
GitOps を使って初期構成をブートストラップする
AKS クラスターのデプロイがベースライン構成の一部として必要な場合があります。 たとえば、アプリケーション ワークロードをデプロイする前に、共有サービスまたはシステム レベルの構成をデプロイする必要がある場合があります。 これらの共有サービスでは、次のアドオンとツールを構成できます。
Microsoft Entra Workload ID や Azure Key Vault Provider for Secrets Store CSI Driver などの AKS アドオン
Prisma Cloud Defender などのパートナー ツール
Kubernetes イベント ドリブン自動スケール (KEDA)、ExternalDNS、Cert-manager などのオープンソース ツール
Flux は、AKS クラスターを作成するときに適用される拡張機能として有効にすることができます。 Flux は、ベースライン構成をクラスターにブートストラップすることができます。 AKS クラスターのベースライン アーキテクチャでは、ブートストラップに GitOps を使用することをお勧めします。 Flux 拡張機能を使用する場合は、デプロイ後すぐにクラスターをブートストラップできます。
その他の GitOps ツールとアドオン
説明されているシナリオを他の GitOps ツールに拡張できます。 Jenkins X も、Azure に統合する手順が用意されている GitOps ツールです。 Flagger などのプログレッシブ デリバリー ツールを使うと、GitOps を介してデプロイされる運用ワークロードを段階的に移行することができます。
考えられるユース ケース
このソリューションは、アプリケーションと IaC をデプロイし、すべての変更の監査証跡を維持したい組織にとってメリットがあります。
GitOps を使用すると、開発者向けのコンテナー管理が簡素化され、生産性が向上します。 開発者は、Git のような使い慣れたツールを引き続き使って更新プログラムと新機能を管理できます。
考慮事項
これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「 Well-Architected Framework」を参照してください。
[信頼性]
信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。
クラスターが使用できなくなった場合は、新しいクラスターの作成の一部として GitOps を使用する必要があります。 Kubernetes の構成とアプリケーション ロジックに関する信頼できる唯一の情報源として、Git リポジトリが使われます。 クラスター構成とアプリケーションのデプロイをスケール ユニットとして作成して適用し、 デプロイ スタンプ パターンを確立できます。
セキュリティ
セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。 詳細については、「セキュリティの設計レビュー チェックリスト」を参照してください。
GitOps アプローチでは、個々の開発者または管理者が Kubernetes クラスターに直接アクセスして変更や更新を適用することはありません。 代わりに、ユーザーは変更を Git リポジトリにプッシュし、Flux や Argo CD などの GitOps オペレーターが変更を読み取り、クラスターに適用します。 このアプローチは、Kubernetes API への書き込みアクセス許可を DevOps チームに付与しないことによって、最小の特権のセキュリティのベスト プラクティスに従います。 診断またはトラブルシューティングのシナリオでは、クラスターのアクセス許可を特定の時間に限定して付与することができます。
リポジトリのアクセス許可を構成するだけでなく、AKS クラスターと同期する Git リポジトリに次のセキュリティ対策を実装することを検討してください。
ブランチ保護: Kubernetes クラスターの状態を表すブランチを保護して、変更が直接プッシュされないようにします。 pull requests (PR) を使用して変更を行い、少なくとも 1 人の他のユーザーにすべての PR をレビューさせます。 また、PR を使用して自動チェックを行います。
PR レビュー: 複数の目による確認を適用するために、PR は最低 1 人のレビュアーを必要とします。 また、GitHub コード所有者機能を使用して、リポジトリ内の特定のファイルのレビューに責任を持つ個人またはチームを定義することもできます。
変更不可能な履歴: 新しいコミットを既存の変更に加えてのみ許可します。 監査目的では、変更不可能な履歴が特に重要です。
追加のセキュリティ対策: GitHub ユーザーに 2 要素認証のアクティブ化を要求します。 変更を防ぐために署名されたコミットのみを許可します。
コストの最適化
コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。
AKS Free レベルでは、無料のクラスター管理が提供されます。 コストは、AKS がノードのホストに使うコンピューティング、ストレージ、ネットワークの各リソースに限定されます。 AKSの無料プランにはサービス レベル アグリーメント (SLA) は含まれていません。本番環境でのワークロードには推奨されません。
GitHub には無料のサービスが用意されていますが、コード所有者や必要なレビュー担当者などの高度なセキュリティ関連機能を使用するには、チーム プランが必要です。 詳細については、 GitHub の価格を参照してください。
Azure DevOps には、一部のシナリオで使用できる無料レベルが用意されています。
コストの見積もりには、Azure 料金計算ツールをご利用ください。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスのデザイン レビュー チェック一覧」を参照してください。
GitOps を使用すると DevOps の生産性が向上します。 最も便利な機能の 1 つは、Git 操作を実行して予期しない動作をする変更をすばやくロールバックできることです。 コミット グラフには引き続きすべてのコミットが含まれているため、振り返り分析に役立ちます。
GitOps チームは、多くの場合、同じアプリケーションの複数の環境を管理します。 アプリケーションの複数の段階を異なる Kubernetes クラスターまたは名前空間にデプロイするのが一般的です。 信頼できる単一の情報源である Git リポジトリは、現在クラスターにデプロイされているアプリケーションのバージョンを示しています。
シナリオをデプロイする
5 つのシナリオのデプロイの詳細については、次のリソースを参照してください。
シナリオ 1: Flux v2 で GitOps を使用してアプリケーションを AKS にデプロイする方法については、「 チュートリアル: Flux v2 で GitOps を使用してアプリケーションをデプロイする」を参照してください。 Flux 拡張機能を使って AKS クラスター デプロイをブートストラップする方法の例については、AKS ベースラインの参照実装のページを参照してください。
シナリオ 2: AKS で Flux v2 で GitOps を使用してアプリケーションをデプロイし、CI/CD を実装する方法については、「 チュートリアル: GitOps を使用して CI/CD を実装する (Flux v2)」を参照してください。
シナリオ 3 と 4: Argo CD と AKS を使用してサンプル ワークロードをデプロイする方法の詳細なガイダンスについては、 AKS ベースライン自動化のプルベースの CI/CD シナリオを参照してください。
共同作成者
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
プリンシパル作成者:
- フランシス・シミー・ナザレ |プリンシパル・クラウド・ソリューション・アーキテクト
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。
次の手順
- Flux v2 で GitOps を使用してアプリケーションをデプロイする
- Argo CD で GitOps を使用してアプリケーションをデプロイする
- GitOps を使用して CI/CD を実装する (Flux v2)
- Argo CD のドキュメント
- Flux CD のドキュメント
- GitOps と Jenkins X
- Azure RBAC とは