Azure Stack HCI または Windows Server で AKS ハイブリッドを使用してアプリをデプロイして運用する

Azure Kubernetes Service (AKS)
Azure Stack HCI
Azure Arc
GitHub
Azure Pipelines

この記事では、Azure Kubernetes Service ハイブリッドのデプロイ オプション (AKS ハイブリッド) で、コンテナー化されたアプリ用のアプリ デプロイ パイプラインを構築するための推奨事項について説明します。 アプリは、Azure Stack HCI または Windows Server で実行できます。 このガイダンスは、具体的には Azure Arc と GitOps を使用するデプロイを対象としています。

アーキテクチャ

Azure Stack HCI または Windows Server で実行されている AKS ハイブリッド クラスターのアーキテクチャを示す図。

このアーキテクチャの Visio ファイルをダウンロードします。

ワークフロー

このアーキテクチャは、Azure Stack HCI または Windows Server で実行されている AKS ハイブリッド クラスターで、コンテナー化されたアプリケーションをデプロイする実装を示しています。 コードとしてのインフラストラクチャ (IaC) の管理には、GitOps が使用されています。

  1. オペレーターが、AKS ハイブリッド クラスターをホスト可能な Azure Stack HCI または Windows Server ハードウェア上に、オンプレミス インフラストラクチャを設定します。
  2. オンプレミスで、管理者が Azure Stack HCI または Windows Server のインフラストラクチャに AKS ハイブリッド クラスターをデプロイし、Azure Arc を使用して AKS ハイブリッド クラスターを Azure に接続します。GitOps を有効にするために、管理者は Flux 拡張機能とその構成も AKS ハイブリッド クラスターにデプロイします。
  3. GitOps 構成によって IaC が容易になります。 これらの GitOps 構成は AKS ハイブリッド クラスターの目的の状態を表し、ローカル管理から提供される情報を使用します。 “ローカル管理” とは、Azure Stack HCI または Windows Server にデプロイされた AKS ハイブリッド クラスターから提供される管理ツール、インターフェイス、プラクティスを指します。
  4. 管理者が GitOps 構成を Git リポジトリにプッシュします。 Helm または Kustomize のリポジトリを使用することもできます。 AKS ハイブリッド クラスターの Flux コンポーネントによってリポジトリの変更が監視され、必要に応じて更新が検出、適用されます。
  5. リポジトリ内の構成に変更が加えられると、AKS ハイブリッド クラスター内の Flux 拡張機能が GitOps フローから通知を受け取ります。 Helm チャートまたは Kustomize を使用して、必要な構成のデプロイが自動的にトリガーされます。
  6. 構成またはコードの新規作成あるいは更新という形式で行われたアプリケーションの変更が、指定されたリポジトリにプッシュされます。これには、対応するコンテナー イメージの更新も含まれます。 これらのコンテナー イメージの更新は、プライベート またはパブリックのコンテナー レジストリにプッシュされます。
  7. AKS ハイブリッド クラスターの Flux オペレーターによってリポジトリ内の変更が検出され、クラスターへのデプロイが開始されます。
  8. 変更がクラスターにローリング形式で実装されます。これによりダウンタイムが最小限に抑えられ、クラスターの目的の状態が維持されます。

コンポーネント

  • Azure Stack HCI は、仮想化されたワークロードをオンプレミスで実行するために使用できるハイパーコンバージド インフラストラクチャ (HCI) ソリューションです。 ソフトウェア定義のコンピューティング、ストレージ、ネットワーク テクノロジの組み合わせが使用されます。 Windows Server の上に構築され、ハイブリッド クラウド エクスペリエンスを提供するために Azure サービスと統合されます。
  • AKS on Azure Stack HCI は、開発者と管理者が AKS を使用して、Azure Stack HCI でコンテナー化されたアプリをデプロイおよび管理できるようにします。
  • Azure Arc は、オンプレミス、マルチクラウド、エッジ環境でサーバー、Kubernetes クラスター、アプリケーションを管理するために使用できるハイブリッド クラウド管理ソリューションです。 Azure Policy、Microsoft Defender for Cloud、Azure Monitor などの Azure 管理サービスを使用してさまざまな環境でリソースを管理できるため、統合された管理エクスペリエンスを実現できます。
  • Git、Helm、Bitbucket のリポジトリ (パブリックおよびプライベート) は、Azure DevOps や GitHub のリポジトリを含む GitOps 構成をホストできます。
  • Azure Container Registry と Docker Hub を含むコンテナー レジストリ (パブリックおよびプライベート) は、コンテナー イメージをホストします。
  • Azure Pipelines は、リポジトリとレジストリの更新を自動化する継続的インテグレーション (CI) および継続的デリバリー (CD) サービスです。
  • Flux は、Azure Arc 対応の Kubernetes クラスターで使用できるオープンソースの GitOps デプロイ ツールです。 Azure Arc 接続を使用して、指定した Git、Helm、または Kustomize のリポジトリの変更を追跡し、変更をローカル クラスターに適用するクラスター コンポーネントを実装できます。 Flux オペレーターによって既存のクラスター構成が定期的に (またはトリガーに基づいて) レビューされ、Git リポジトリに存在するものと一致しているか確認されます。 差異が検出された場合は、修正するために Flux によって必要な構成が適用されます。構成のずれが生じている場合は、必要な構成が再適用されます。

シナリオの詳細

コンテナーを大規模に実行するには、スケジュール、デプロイ、ネットワーク、スケーリング、稼働状況の監視、コンテナー管理を自動化するオーケストレーターが必要です。 Kubernetes は、コンテナー化された新しいデプロイでよく使用されるオーケストレーターです。 Kubernetes のクラスターと環境の数が増えるにつれて、それらを個別に管理するのが難しくなることがあります。 Azure Arc 対応の Kubernetes、GitOps、Azure Monitor、Azure Policy などの Azure Arc 対応サービスを使用すると、管理上の負担が軽減され、この問題を解決できます。

考慮事項

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

Well-Architected Framework は、クラウドベース ソリューションの利点を評価し最適化するための指針を提供します。 オンプレミスの AKS デプロイと Azure テクノロジの固有の統合を考慮に入れると、GitOps の設計と実装にフレームワークの推奨事項を適用するのが適しています。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。

  • Kubernetes の高可用性機能を使用して、GitOps ベースのソリューションで高い信頼性を確保します。
  • Flux v2 を使用して、複数の場所またはクラスターにまたがるデプロイでアプリケーションの可用性をさらに向上させます。
  • 自動デプロイを使用して、人的エラーの可能性を減らします。
  • CI/CD パイプラインをアーキテクチャに統合して、自動テストの有効性を高めます。
  • すべてのコード変更を追跡して、問題をすばやく特定して解決できるようにします。 これらの運用上の変更を追跡するには、GitHub または Azure DevOps の組み込み機能を使用します。 これらのツールを使用してポリシーと自動化を実装すると、確実に変更を追跡し、適切な承認プロセスに従い、簡単に変更を管理できるようになります。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

  • アーキテクチャのセキュリティ上の利点を理解します。 Flux v2、Kustomize、GitOps、DevOps の各パイプラインを使用すると、運用上の変更が自動化によって適用されます。 ブランチ保護、pull request のレビュー、変更不可能な履歴などのメカニズムを利用すると、これらの運用プラクティスを実装するコードを制御して監査できます。 IaC アプローチでは、インフラストラクチャにアクセスするためのアクセス許可を管理する必要がなく、最小特権の原則がサポートされています。 Flux では名前空間ベースの構成のスコーピングがサポートされているため、マルチテナントのシナリオが容易になります。

  • 暗号化について理解します。 データのセキュリティを確保するために、クラスター構成サービスでは Flux 構成のリソース データを Azure Cosmos DB データベースに格納し、保存時に暗号化します。

  • プライベート エンドポイントの使用を検討します。 GitOps では、Azure Arc 関連サービスに接続するための Azure Private Link がサポートされています。

Azure ポリシーと Azure Arc を使用する

Azure Arc を使用すると、リソース管理の範囲を Azure を超えて拡張できます。 範囲を拡張すると、さまざまな利点が物理サーバーと仮想サーバーに適用されます。 AKS のコンテキストでは、次のような利点があります。

  • ガバナンス。 Azure Arc では、Kubernetes 用の Azure Policy と、対応するポリシーのコンプライアンスに関する一元的なレポートを使用して、AKS クラスターとそのポッドに影響を与えるランタイム ガバナンスを適用できます。 この機能を使って、たとえば、Kubernetes クラスターを対象とするイングレス トラフィックに HTTPS の使用を強制したり、指定した特定のポートのみがコンテナーによってリッスンされるようにしたりすることができます。
  • 操作の改善。 Azure Arc では、GitOps を使用した自動クラスター構成のサポートが強化されています。

Azure Policy では、組み込みの “GitOps を Kubernetes クラスターにデプロイする” ポリシー定義を使用できるため、GitOps の一元管理が容易になります。 このポリシーを割り当てると、Azure Resource Manager リソースが割り当ての範囲内にある場合は、選択した GitOps ベースの構成が指定の Azure Arc 対応 Kubernetes クラスターに自動的に適用されます。

コスト最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させることです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

  • GitOps に用意されている自動化を使用して、管理とメンテナンスのオーバーヘッドを最小限に抑えます。 シンプルな運用モデルによって保守の労力が少なく済み、運用コストが削減されます。

  • AKS ハイブリッドを使用します。 AKS ハイブリッドには、コンピューティング リソースの自動スケーリングの組み込みサポートが用意されており、コンテナ化に固有のワークロード密度も向上しています。 自動スケーリングを使用すると、物理インフラストラクチャの適切なサイズを設定し、データセンター統合イニシアチブを迅速に実施できます。これにより、コストを削減できます。

オペレーショナル エクセレンス

オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスの重要な要素の概要」を参照してください。

  • GitOps リポジトリを使用して、すべての AKS アプリケーションとクラスター インフラストラクチャ データを格納する、信頼できる唯一の情報源を提供します。 これらのリポジトリは、クラスターに変更を適用する唯一のコンポーネントとして機能します。

  • GitOps とインフラストラクチャの DevOps アプローチとの統合を活用して、新しいソフトウェア リリースの配信に必要な時間を短縮します。 また、Azure Resource Manager と Azure Arc を使用して、クラウドベースおよびオンプレミスのコンテナー化されたワークロード用に一貫した運用モデルを構築することをお勧めします。 さまざまなレベルで GitOps 構成を制御するには、Azure Policy を Flux オペレーター機能と組み合わせて使用します。 これにより、エンタープライズ レベル、個々の AKS クラスターのレベル、さらにはクラスター内の特定の名前空間のレベルで制御を確立できます。

  • 1 つまたは複数のクラスターを範囲とする GitOps 構成を作成して、イングレス コントローラー、サービス メッシュ、セキュリティ製品、監視ソリューションなど、コンテナー化されたインフラストラクチャのコンポーネント向けのベースラインを実装します。 これにより、クラスターでベースライン インフラストラクチャの要件を確実に満たすことができます。

  • 名前空間レベルの GitOps 構成を作成すると、ワークロードのリソースをより細かいレベル (ポッド、サービス、イングレス ルートなど) で制御できるため、ワークロードをアプリケーション標準に確実に準拠させることができます。 これらのガイドラインに従うことで、AKS ハイブリッド アプリケーションのデプロイと管理を、効率的、効果的、コスト効率に優れた状態に保つことができます。

GitOps を使用する

GitOps は、AKS クラスターの管理に最適です。 Kubernetes は宣言型モデルに基づいています。 クラスターの状態とそのコンポーネントはコードに記述されています。 GitOps によってそのコードが Git リポジトリに格納され、それを使ってターゲット環境の目的の状態が定義されます。

コードの変更は、バージョン コントロール、監査、オプションのレビューと承認の対象となります。 レビューと承認を使用すると、AKS インフラストラクチャとコンテナー化されたワークロードの更新を自動的にトリガーできます。 GitOps ではプル モデルが使用されます。このモデルでは、特殊な一連のクラスター コンポーネントよってリポジトリの状態がポーリングされます。 変更が検出されると、AKS でホストされる GitOps コンポーネントによって新しい構成が取得され、適用されます。

GitOps では、直接的なクラスター管理の必要性が最小限となるため、運用モデルが簡素化され、セキュリティも強化されます。 GitOps では、最小特権の原則がサポートされています。 たとえば、GitOps では kubectl を使用してクラスターを手動で変更する必要がないため、必要な特権が少なくなります。 GitOps では、提案されたポリシー変更に関する早期のフィードバックも提供されます。 早期のフィードバックは、バグに関連するリスクとコストの低減に役立つため、開発者にとって特に重要です。

GitOps を使用すると、組織全体のクラスター構成の標準化を簡素化して、コンプライアンスとガバナンスの要件を満たすことができます。 ネットワーク ポリシー、ロール バインディング、ポッド セキュリティ ポリシーなど、すべてのクラスターとそのコンポーネントに適用するベースライン構成を定義できます。 その構成をすべての Azure Arc 対応クラスターに実装するには、リソース グループまたはサブスクリプションを対象とするAzure Policyを使用できます。 これらのポリシーは、既存のリソースと、ポリシーの割り当て後に作成されたリソースに自動的に適用されます。

GitOps により、クラスターが 1 つ以上の Git リポジトリにリンクされます。 各リポジトリを使用して、クラスター構成のさまざまな側面を記述できます。 結果として得られる宣言型モデルにより、マニフェスト ファイルを介した Kubernetes リソース (名前空間やデプロイなど) のプロビジョニングと管理の自動化が容易になります。 Helm チャートを使用することもできます。これを Flux v2 と Kustomize と組み合わせることで、コンテナー化されたアプリケーションや、環境固有の変更が記述された Kustomize ファイルの自動デプロイが容易になります。

Flux を使用する

Flux は Kubernetes オペレーターとして実装されます。 一連のコントローラーと、対応する宣言型 API が使用されます。 コントローラーは、目的の機能を提供するために連動する一連のカスタム リソースを管理します。

GitOps は、Azure Arc 対応の Kubernetes クラスターで、Microsoft.KubernetesConfiguration/extensions/microsoft.flux クラスター拡張機能として有効になっています。 microsoft.flux クラスター拡張機能をインストールしたら、構成ソースの内容をクラスターに同期する 1 つ以上の fluxConfigurations リソースを作成し、クラスターを目的の状態に調整できます。

既定では、microsoft.flux 拡張機能によって Flux コントローラー (Source、Kustomize、Helm、Notification) と、FluxConfig カスタム リソース定義 (CRD)、fluxconfig-agentfluxconfig-controller がインストールされます。 これらのどのコントローラーをインストールするか選択することもできます。また、必要に応じて Flux の image-automationimage-reflector コントローラーをインストールできます。これらを使うと、Docker イメージの更新と取得が簡単になります。

fluxConfigurations リソースの作成時に、パラメーターに指定した値 (ターゲットの Git リポジトリなど) を使って、そのクラスターで GitOps 機能を有効にする Kubernetes オブジェクトが作成されて構成されます。

Flux v2 クラスター拡張機能をデプロイして構成すると、次のコンポーネントと機能が提供されます。

  • source-controller. Git リポジトリ、Helm リポジトリ、S3 バケットなどのクラウド ストレージ サービスといったカスタム構成のソースを監視し、これらのソースに対して同期と承認を行います。
  • kustomize-controller. Kubernetes マニフェストと生の YAML ファイルが含まれる、Kustomization CRD に基づくカスタム リソースを監視します。 マニフェストと YAML ファイルをクラスターに適用します。
  • helm-controller. チャートに基づいていて、source-controller によって表示される Helm リポジトリに格納されているカスタム リソースを 監視します。
  • notification-controller. Git リポジトリから発生した受信イベントと、送信イベント (Microsoft Teams や Slack を対象とする送信イベントなど) を管理します。
  • FluxConfig CRD. Flux 固有の Kubernetes オブジェクトを定義するカスタム リソースを表します。
  • fluxconfig-agent. 新しい Flux 構成リソースと更新された Flux 構成リソースを検出します。 クラスターで対応する構成更新を開始します。 状態の変更を Azure に伝達します。
  • fluxconfig-controller. fluxconfigs カスタム リソースを監視します。

Flux のバージョン 2 には、次の追加機能が用意されています。

カテゴリ 特徴量
インフラストラクチャとワークロードの管理 デプロイの依存関係の管理
Kubernetes のロールベースのアクセス制御 (RBAC) との統合
クラスターとそのワークロードの正常性評価
イメージのスキャンやパッチ適用など、Git に対するコンテナー イメージの自動更新
クラスター API プロバイダーとの相互運用性
セキュリティとガバナンス 外部システムへのアラート (Webhook 送信者経由)
Open Policy Agent Gatekeeper のサポートを含む、ポリシー主導型の検証
コンテナー イメージのスキャンとパッチ適用
外部システムへのアラート (Webhook 送信者経由)
他の GitOps フローとの統合 GitHub、GitLab、Bitbucket など、さまざまな Git プロバイダーとの統合
GitHub Actions を含むワークフロー プロバイダーとの相互運用性

詳細については、「AKS および Azure Arc 対応 Kubernetes を使用した GitOps Flux v2 構成」を参照してください。

パフォーマンス効率

パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。

クラスター ワークロードには、Kubernetes プラットフォームに固有のスケーラビリティと機敏性のメリットがもたらされます。 Flux v2 によってさらに機敏性が提供されるため、エンド ツー エンドのソフトウェア配信に必要な時間が短縮されます。

  • 特定のワークロードに合わせて、Kubernetes クラスターとインフラストラクチャの設定を最適化します。 アプリケーション開発者と協力して必要な設定を決定することをお勧めします。

  • Kubernetes の自動スケーリング機能を使用します。 詳細については、「AKS ハイブリッドでのクラスターの自動スケーリング」を参照してください。

  • キャッシュを追加してアプリケーションを最適化します。

  • パフォーマンス ベースラインを確立します。 アーキテクチャをベンチマークし、メトリックと監視ツールを使用して、パフォーマンスに影響を与える問題やボトルネックを特定します。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

  • Sarah Cooley |プリンシパル プログラム マネージャー
  • Mike Kostersitz | プリンシパル プログラム マネージャー リード

その他の共同作成者:

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ