Azure Kubernetes Service (AKS) クラスターのベースライン アーキテクチャ

Azure Application Gateway
Azure Container Registry
Azure Firewall
Azure Kubernetes Service (AKS)
Azure ロールベースのアクセス制御

このリファレンス アーキテクチャは、Azure に Azure Kubernetes Service (AKS) クラスターをデプロイするための推奨されるベースライン インフラストラクチャ アーキテクチャを提供します。 これは、Microsoft の設計原則を使用し、Azure Well-Architected フレームワークアーキテクチャのベスト プラクティスに基づいており、この汎用インフラストラクチャをデプロイすることで、ネットワーク、セキュリティ、ID などの学際的または複数の異なるチームをガイドします。

このアーキテクチャは、ワークロードに焦点を当てるのではなく、AKS クラスター自体に集中します。 ここでの情報は、ほとんどの AKS クラスターで推奨される最小ベースラインです。 これは、可観測性を提供する Azure サービスと統合され、マルチリージョンの成長をサポートし、クラスター内トラフィックをセキュリティで保護するネットワーク トポロジです。

ターゲット アーキテクチャはビジネス要件の影響を受けるため、アプリケーション コンテキストによって異なる場合があります。 これは、実稼働前および実稼働段階の開始点と見なす必要があります。

このアーキテクチャの実装は、GitHub: Azure Kubernetes Service (AKS) のベースライン リファレンス実装で利用できます。 これを代替の始点として使用し、ニーズに応じて構成することができます。

Note

このリファレンス アーキテクチャには、Kubernetes とその概念に関する知識が必要です。 復習が必要な場合は、リソースの「AKS の詳細」セクションをご覧ください。

ネットワーク トポロジ

このアーキテクチャでは、ハブスポーク ネットワーク トポロジを使用します。 ハブとスポークは、ピアリング経由で接続された個別の仮想ネットワークにデプロイされます。 このトポロジには次のような利点があります。

  • 分離された管理。 ガバナンスを適用し、最小限の特権の原則を順守する方法を有効にします。 また、職務の分離によって、Azure ランディング ゾーンの概念もサポートしています。

  • Azure リソースをパブリック インターネットに直接公開することを最小限に抑えます。

  • 多くの場合、組織はリージョンのハブスポーク トポロジを使用しています。 将来的にハブスポーク ネットワーク トポロジを拡張したり、ワークロードの分離を提供したりできます。

  • すべての Web アプリケーションに、HTTP トラフィック フローの管理に役立つ Web アプリケーション ファイアウォール (WAF) サービスが必要です。

  • 複数のサブスクリプションにまたがるワークロードの場合は、当然の選択です。

  • これにより、アーキテクチャが拡張可能になります。 新しい機能やワークロードに対応するために、ネットワーク トポロジを再設計するのではなく、新しいスポークを追加することができます。

  • ファイアウォールや DNS など、特定のリソースをネットワーク間で共有できます。

  • Azure エンタープライズ規模のランディング ゾーンと連携します。

ハブスポーク ネットワーク トポロジを示すアーキテクチャ図。

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

詳細については、「Azure のハブスポーク ネットワーク トポロジ」を参照してください。

AKS ベースライン リファレンス アーキテクチャ上の Windows コンテナーに含まれるネットワーク設計の変更を確認するには、関連記事を参照してください。

ハブ

ハブ仮想ネットワークは、接続性と監視の中心点です。 ハブには常に、中央の IT チームによって定義されたグローバル ファイアウォール ポリシーを備えた Azure Firewall が含まれており、組織全体のファイアウォール ポリシー、Azure Bastion、VPN 接続用のゲートウェイ サブネット、ネットワーク監視のための Azure Monitor が適用されます。

そのネットワーク内に 3 つのサブネットがデプロイされます。

Azure Firewall をホストするサブネット

Azure Firewall は、サービスとしてのファイアウォールです。 そのファイアウォールのインスタンスでは、送信ネットワーク トラフィックがセキュリティで保護されます。 このセキュリティ レイヤーがないと、このトラフィックが悪意のあるサードパーティ サービスと通信することで、会社の機密データが抜き取られる可能性があります。 Azure Firewall Manager を使用すると、複数のAzure Firewall インスタンスを一元的にデプロイして構成し、この "ハブ仮想ネットワーク ネットワーク" アーキテクチャの種類の Azure Firewall ポリシーを管理できます。

ゲートウェイをホストするサブネット

このサブネットは、VPN または ExpressRoute ゲートウェイのプレースホルダーです。 ゲートウェイでは、オンプレミスのネットワーク内のルーターと仮想ネットワークの間の接続が提供されます。

Azure Bastion をホストするサブネット

このサブネットは Azure Bastion のプレースホルダーです。 Bastion を使用すると、インターネットにリソースを公開することなく、Azure リソースに安全にアクセスできます。 このサブネットは、管理と運用のみに使用されます。

スポーク

スポーク仮想ネットワークには、AKS クラスターとその他の関連リソースが含まれます。 スポークには 4 つのサブネットがあります。

Azure Application Gateway をホストするサブネット

Azure Application Gateway は、第 7 層で動作する Web トラフィック ロード バランサーです。 リファレンス実装では、Web アプリケーション ファイアウォール (WAF) を有効にする Application Gateway v2 SKU を使用します。 WAF によって、ボットを含む一般的な Web トラフィック攻撃から着信トラフィックが保護されます。 インスタンスには、ユーザー要求を受信するパブリック フロントエンド IP 構成が使用されています。 仕様として、Application Gateway には、専用のサブネットが必要です。

イングレス リソースをホストするサブネット

トラフィックのルーティングと分散を行うために、Traefik は Kubernetes イングレス リソースを満たすイングレス コントローラーです。 このサブネットには、Azure 内部ロード バランサーが存在します。 詳しくは、「Azure Kubernetes Service (AKS) で内部ロード バランサーを使用する」をご覧ください。

クラスター ノードをホストするサブネット

AKS には、2 つの異なるノード グループ (またはノード プール) が保持されています。 "システム ノード プール" では、コア クラスター サービスを実行するポッドをホストします。 "ユーザー ノード プール" では、ワークロードとイングレス コントローラーが実行され、ワークロードへのインバウンド通信が有効になります。

Azure Container RegistryAzure Key Vault 用に Azure Private Link 接続が作成されるため、スポーク仮想ネットワーク内のプライベート エンドポイントを使用してこれらのサービスにアクセスできます。 プライベート エンドポイントは専用サブネットを必要としないため、ハブ仮想ネットワークに配置することもできます。 ベースライン実装では、スポーク仮想ネットワーク内の専用サブネットにデプロイされます。 このアプローチにより、ピアリングされたネットワーク接続を通過するトラフィックを減らし、同一仮想ネットワーク内のクラスターに属するリソースが保持されます。また、ネットワーク セキュリティ グループを使用して、各サブネットに詳細なセキュリティ規則を適用することができます。

詳細については、「Private Link 配置オプション」を参照してください。

IP アドレスの計画

AKS クラスターのネットワーク トポロジを示す図。

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

仮想ネットワークのアドレス空間は、すべてのサブネットを保持するのに十分な大きさにする必要があります。 トラフィックを受信するすべてのエンティティを考慮します。 これらのエンティティの IP アドレスは、サブネットのアドレス空間から割り当てられます。 次の点を考慮します。

  • アップグレード

    AKS では、基になる仮想マシンをセキュリティ機能やその他のシステム修正プログラムに関して確実に最新の状態にするために、ノードが定期的に更新されます。 アップグレード処理中、ポッドを一時的にホストするノードが AKS によって作成され、その一方でアップグレード ノードが切断およびドレインされます。 その一時ノードには、クラスター サブネットから IP アドレスが割り当てられます。

    ポッドには、戦略に応じて追加のアドレスが必要になることがあります。 ローリング アップデートの場合は、実際のポッドが更新中である間にワークロードを実行する一時ポッドのアドレスが必要になります。 置き換えの戦略を使用すると、ポッドが削除され、新しいものが作成されます。 そのため、古いポッドに関連付けられたアドレスが再利用されます。

  • スケーラビリティ

    すべてのシステム ノードおよびユーザー ノードのノード数と、それらの最大スケーラビリティの制限について検討します。 400% のスケールアウトが必要な場合を考えてみましょう。 スケールアウトされたすべてのノード用に、4 倍の数のアドレスが必要になります。

    このアーキテクチャでは、各ポッドに直接接続できます。 そのため、各ポッドに個別のアドレスが必要です。 ポッドのスケーラビリティはアドレスの計算に影響します。 その決定は、増やすポッドの数によって異なります。

  • Azure Private Link アドレス

    Private Link 経由で他の Azure サービスとの通信に必要なアドレスを考慮に入れます。 このアーキテクチャでは、Azure Container Registry と Key Vault へのリンクに 2 つのアドレスを割り当てています。

  • Azure で使用するために特定のアドレスが予約されています。 それらを割り当てることはできません。

上記の一覧は完全ではありません。 ご自身の設計に、使用可能な IP アドレスの数に影響する他のリソースが含まれている場合は、それらのアドレスを考慮に入れます。

このアーキテクチャは、単一のワークロード用に設計されています。 複数のワークロードの場合は、ユーザー ノード プールを相互に、およびシステム ノード プールから分離することができます。 このオプションを選択すると、サイズの小さいサブネットが増えます。 また、イングレス リソースはより複雑になることがあり、その結果、追加の IP アドレスを必要とする複数のイングレス コントローラーが必要になる場合があります。

このアーキテクチャのすべての考慮事項については、「AKS ベースライン ネットワーク トポロジ」を参照してください。

AKS クラスターの IP の計画に関する詳細については、「クラスターの IP アドレス指定を計画する」を参照してください。

AKS ベースライン リファレンス アーキテクチャ上の Windows コンテナーに含まれる IP アドレスの計画に関する考慮事項を確認するには、関連記事を参照してください。

アドオンとプレビュー機能

Kubernetes と AKS は絶えず進化し続ける製品であり、オンプレミス環境向けのソフトウェアよりもリリース サイクルが速くなっています。 このベースライン アーキテクチャは、選択した AKS プレビュー機能と AKS アドオンに依存します。 この 2 つの違いは次のとおりです。

  • AKS チームは、プレビュー機能を "出荷して引き続き改善する" と説明しています。 その背景にある理由は、プレビュー機能の多くは、一般リリース (GA) フェーズに移行する前の数か月間しかその状態にとどまらないためです。
  • AKS アドオンと拡張機能には、サポートされている追加の機能が用意されています。 これらのインストール、構成、ライフサイクルは AKS によって管理されます。

このベースライン アーキテクチャには、すべてのプレビュー機能またはアドオンが含まれるわけではなく、汎用クラスターに重要な価値を追加するものだけが含まれます。 これらの機能がプレビュー段階を終了すると、このベースライン アーキテクチャが適宜変更されます。 セキュリティ、管理の容易性、またはその他の要件を強化する運用前クラスターで評価する必要があるプレビュー機能や AKS アドオンがいくつかあります。 サード パーティ製のアドオンを使用する場合は、それらをインストールして維持する必要があります。これには、利用可能なバージョンの追跡や、クラスターの Kubernetes バージョンのアップグレード後の更新プログラムのインストールなどが含まれます。

コンテナー イメージのリファレンス

ワークロードに加えて、クラスターには、イングレス コントローラーなどの他のイメージがいくつか含まれる場合があります。 これらのイメージの一部が、パブリック レジストリに存在することがあります。 これらをクラスターにプルする場合は、次の点を考慮してください。

  • クラスターは、イメージをプルするように認証されます。

  • パブリック イメージを使用している場合は、SLO と合致するコンテナー レジストリへのインポートを検討してください。 そうしないと、イメージが、予期しない可用性の問題の影響を受ける可能性があります。 必要なときにイメージを使用できないと、これらの問題によって、操作に関する問題が発生する場合があります。 ここでは、パブリック レジストリではなくコンテナー レジストリを使用する利点をいくつか紹介します。

    • イメージへの未承認のアクセスをブロックできます。
    • 公開された依存関係がありません。
    • イメージ プル ログにアクセスして、アクティビティを監視し、接続の問題をトリアージできます。
    • 統合されたコンテナー スキャンとイメージの準拠を利用します。

    Azure Container Registry (ACR) オプションが用意されています。

  • 承認済みレジストリからイメージをプルします。 この制限は、Azure Policy によって適用できます。 この参照実装では、クラスターは、アーキテクチャの一部としてデプロイされている ACR からのみイメージをプルします。

ベース クラスターのコンピューティングの構成

AKS では、各ノード プールは 1 つの仮想マシン スケール セットにマップされます。 ノードは各ノード プール内の VM です。 コストを最小限に抑えるには、より小さい VM サイズをシステム ノード プールに使用することを検討してください。 このリファレンス実装では、3 つの DS2_v2 ノードを持つシステム ノード プールをデプロイします。 そのサイズは、システム ポッドの予想される負荷を満たすのに十分です。 OS ディスクは 512 GB です。

ユーザー ノード プールについて、次にいくつかの考慮事項を示します。

  • ノード上に設定したポッドの最大数をパックするには、より大きいノード サイズを選択します。 それにより、すべてのノードで実行される監視やログ記録などのサービスのフットプリントを最小限に抑えることができます。

  • 少なくとも 2 つのノードをデプロイします。 こうすることで、ワークロードは 2 つのレプリカを持つ高可用性パターンを持つことになります。 AKS を使用すると、クラスターを再作成することなく、ノード数を変更できます。

  • ワークロードの実際のノード サイズは、設計チームによって決定された要件によって異なります。 ビジネス要件に基づいて、運用ワークロード向けに DS4_v2 を選択しました。 コストを削減するために、サイズを推奨最小値である DS3_v2 に落とすこともできます。

  • クラスターの容量を計画するときは、ワークロードが各ノードの最大 80% を消費できるものと想定します。残りの 20% は AKS サービス用に予約されています。

  • 容量計画に基づいて、ノードあたりの最大ポッド数を設定します。 容量のベースラインを確立しようとしている場合、最初は値を 30 に設定します。 ワークロードの要件、ノード サイズ、IP の制約に基づいてこの値を調整します。

クラスターの Microsoft Entra ID を統合する

クラスターとの間のアクセスをセキュリティで保護することが重要です。 セキュリティに関する選択を行うときは、クラスターの観点から考えてください。

  • "インサイドアウト アクセス"。 ネットワーク インフラストラクチャ、Azure Container Registry、Azure Key Vault などの Azure コンポーネントへの AKS アクセス。 クラスターがアクセスを許可されているリソースのみを承認します。
  • "アウトサイドイン アクセス"。 Kubernetes クラスターへの ID アクセスを提供します。 Kubernetes API サーバーおよび Azure Resource Manager へのアクセスが許可されている外部エンティティのみを承認します。

Azure への AKS アクセス

Microsoft Entra ID を使用して Azure への AKS アクセスを管理する方法は 2 つあります。1 つは "サービス プリンシパル" を使用する方法、もう 1 つは "Azure リソース用マネージド ID" を使用する方法です。

2 つの方法のうち、マネージド ID をお勧めします。 サービス プリンシパルを使用すると、シークレットの管理とローテーションを、手動またはプログラムによって行う必要があります。 マネージド ID を使用すると、Microsoft Entra ID によって認証が管理または実行され、シークレットのローテーションがタイムリーに処理されます。

Microsoft Entra ID 経由でクラスターと外部の Azure リソースとのやり取りができるように、マネージド ID を有効にすることをお勧めします。 この設定は、クラスターの作成時にのみ有効にすることができます。 Microsoft Entra ID をすぐに使用しない場合でも、後で組み込むことができます。

既定では、"クラスター ID" と "Kubelet ID" の 2 つのプライマリ ID がクラスターによって使用されます。 "クラスター ID" は、イングレス ロード バランサー、AKS マネージド パブリック IP などを含むクラスター リソースを管理するために、AKS コントロール プレーン コンポーネントによって使用されます。"kubelet ID" は、Azure Container Registry (ACR) での認証に使用されます。 一部のアドオンでは、マネージド ID を使用した認証もサポートされています。

インサイドアウトのケースの例として、クラスターがコンテナー レジストリからイメージをプルする必要がある場合のマネージド ID の使用について検討してみましょう。 この操作を行うには、クラスターでレジストリの資格情報を取得する必要があります。 1 つの方法として、その情報を Kubernetes シークレット オブジェクトの形式で格納し、imagePullSecrets を使用してシークレットを取得します。 セキュリティの複雑さにより、このアプローチは推奨されません。 シークレットについての事前の知識だけでなく、DevOps パイプラインを通じてそのシークレットを開示することも必要です。 もう 1 つの理由は、シークレットのローテーションを管理する際の運用上のオーバーヘッドです。 代わりに、クラスターの kubelet マネージド ID への acrPull アクセスをレジストリに許可します。 このアプローチによって、それらの懸念に対処します。

このアーキテクチャでは、クラスターから Microsoft Entra ID によって保護された Azure リソースにアクセスし、マネージド ID をサポートする操作を実行します。 クラスターで実行しようとする操作に応じて、Azure ロールベースのアクセス制御 (Azure RBAC) とアクセス許可をクラスターのマネージド ID に割り当てます。 クラスターはそれ自体が Microsoft Entra ID に対して認証され、割り当てられているロールに基づいて、アクセスが許可または拒否されます。 ここでは、このリファレンス実装から、Azure の組み込みロールがクラスターに割り当てられている例をいくつか紹介します。

  • ネットワーク共同作成者。 スポーク仮想ネットワークを制御する機能。 このロールの割り当てにより、AKS クラスター システムによって割り当てられた ID が、内部イングレス コントローラー サービスの専用サブネットで機能できるようになります。
  • 監視メトリック パブリッシャー。 メトリックを Azure Monitor に送信する機能。
  • AcrPull。 指定された Azure コンテナー レジストリからイメージをプルする機能。

クラスターへのアクセス

また Microsoft Entra の統合により、アウトサイドイン アクセスのセキュリティも簡素化されます。 たとえば、ユーザーが kubectl を使用したいとします。 最初のステップとして、az aks get-credentials コマンドを実行してクラスターの資格情報を取得します。 Microsoft Entra ID で、クラスターの資格情報を取得することが許可されている Azure のロールと照合してユーザーの ID が認証されます。 詳細については、「利用可能なクラスター ロールのアクセス許可」を参照してください。

AKS を使用すると、Microsoft Entra ID を使用して 2 つの方法で Kubernetes にアクセスできます。 1 つ目は、Microsoft Entra ID を、ネイティブの Kubernetes RBAC システムと統合された ID プロバイダーとして使用する方法です。 もう 1 つは、ネイティブの Azure RBAC を使用して、クラスター アクセスを制御する方法です。 これらの両方について、下で説明します。

Kubernetes RBAC を Microsoft Entra ID に関連付ける

Kubernetes では、次のようにロールベースのアクセス制御 (RBAC) がサポートされます。

  • アクセス許可のセット。 クラスター全体のアクセス許可のために、Role または ClusterRole オブジェクトによって定義されます。

  • アクションを実行することが許可されているユーザーとグループを割り当てるバインド。 RoleBinding または CluserRoleBinding オブジェクトによって定義されます。

Kubernetes には、クラスター管理者、編集、表示など、いくつかの組み込みロールがあります。 それらのロールを Microsoft Entra のユーザーとグループにバインドし、エンタープライズ ディレクトリを使用してアクセスを管理します。 詳細については、Microsoft Entra 統合での Kubernetes RBAC の使用に関するページを参照してください。

クラスターと名前空間のアクセスに使用される Microsoft Entra グループが、Microsoft Entra アクセス レビューに含まれていることを確認してください。

Kubernetes 認可に Azure RBAC を使用する

統合 Microsoft Entra 認証による認可に Kubernetes ネイティブ RBAC (ClusterRoleBindings および RoleBindings) を使用する代わりに、Azure RBAC と Azure ロールの割り当てを使用してクラスターに承認チェックを適用することをお勧めします。 これらのロール割り当ては、サブスクリプションのスコープまたはリソース グループのスコープで追加することもできるため、スコープ内のすべてのクラスターは、Kubernetes クラスター上のオブジェクトにアクセスする権限を持つユーザーに関して、一貫したロール割り当てのセットを継承します。

詳細については、「Kubernetes 認可のための Azure RBAC」を参照してください。

ローカル アカウント

AKS では、ネイティブの Kubernetes ユーザー認証がサポートされています。 この方法を使用したクラスターへのユーザー アクセスは推奨されていません。 これは証明書ベースであり、プライマリ ID プロバイダーの外部で実行されるため、一元化されたユーザーのアクセス制御とガバナンスが困難になります。 クラスターへのアクセスは常に Microsoft Entra ID を使用して管理し、ローカル アカウントへのアクセスを明示的に無効にするようにクラスターを構成します。

このリファレンス実装では、クラスターがデプロイされるときに、ローカル クラスター アカウント経由のアクセスが明示的に無効になります。

ワークロードの Microsoft Entra ID を統合する

クラスター全体で Azure システム割り当てマネージド ID を使用する場合と同様に、マネージド ID をポッド レベルで割り当てることができます。 ワークロード ID を使用すると、ホストされているワークロードから Microsoft Entra ID を通じてリソースにアクセスできます。 たとえば、ワークロードで Azure Storage にファイルを保存するとします。 これらのファイルにアクセスする必要がある場合、ポッドは Azure マネージド ID としてリソースに対して自身を認証します。

このリファレンス実装では、ポッドのマネージド ID は、AKS 上の Microsoft Entra ワークロード ID を通じて提供されます。 これは Kubernetes のネイティブ機能と統合され、外部 ID プロバイダーとフェデレーションされます。 Microsoft Entra ワークロード ID のフェデレーションの詳細については、次の概要を参照してください。

イングレス リソースのデプロイ

Kubernetes イングレス リソースにより、クラスターへの着信トラフィックのルーティングと分散が行われます。 イングレス リソースには、次の 2 つの部分があります。

  • 内部ロード バランサー。 AKS によって管理されます。 このロード バランサーでは、プライベートな静的 IP アドレスを使用してイングレス コントローラーが公開されます。 それは受信フローを受信する単一のコンタクト ポイントとして機能します。

    このアーキテクチャでは、Azure Load Balancer を使用します。 それはクラスターの外側の、イングレス リソース専用サブネット内に配置されます。 Azure Application Gateway からのトラフィックを受信し、その通信は TLS 経由で行われます。 受信トラフィックの TLS 暗号化の詳細については、「イングレス トラフィック フロー」を参照してください。

  • イングレス コントローラー。 ここでは Traefik を選択しました。 それはクラスター内のユーザー ノード プールで実行されます。 内部ロード バランサーからのトラフィックを受信し、TLS を終了して、HTTP 経由でワークロード ポッドに転送します。

イングレス コントローラーは、クラスターの重要なコンポーネントです。 このコンポーネントを構成するときは、これらの点を考慮してください。

  • 設計に関する決定事項の一部として、イングレス コントローラーが動作できる範囲を選択します。 たとえば、コントローラーと特定のワークロードを実行するポッドとのやり取りのみを許可することができます。

  • 負荷を分散し、ノードがダウンした場合のビジネス継続性を確保するために、同じノードにレプリカを配置することは避けてください。 この目的には podAntiAffinity を使用します。

  • nodeSelectors を使用することによって、ポッドがユーザー ノード プールでのみスケジューリングされるように制限します。 この設定により、ワークロードとシステムのポッドが分離されます。

  • 特定のエンティティからイングレス コントローラーにトラフィックを送信できるようにするポートとプロトコルを開きます。 このアーキテクチャでは、Traefik が受信するのは Azure Application Gateway からのトラフィックだけです。

  • イングレス コントローラーからポッドの正常性を示す信号が送信される必要があります。 指定した間隔でポッドの正常性を監視する readinessProbelivenessProbe の設定を構成します。

  • イングレス コントローラーについて、特定のリソースへのアクセスと、特定のアクションを実行する機能を制限することを検討してください。 その制限は、Kubernetes RBAC アクセス許可を使用して実装できます。 たとえば、このアーキテクチャでは、Kubernetes の ClusterRole オブジェクトのルールを使用して、Traefik にサービスとエンドポイントを監視、取得、一覧表示するためのアクセス許可が付与されています。

Note

適切なイングレス コントローラーの選択は、ワークロードの要件、オペレーターのスキル セット、テクノロジ オプションのサポートの可否によって決まります。 最も重要なのは、想定された SLO を満たすことができるかどうかという点です。

Traefik は、Kubernetes クラスター向けに広く使用されているオープンソース オプションであり、このアーキテクチャでは "説明" のために、これが選択されています。 これは、サードパーティ製品と Azure サービスの統合を示しています。 たとえば、この実装は、Traefik を Microsoft Entra ワークロード ID および Azure Key Vault と統合する方法を示しています。

もう 1 つの選択肢は、Azure Application Gateway イングレス コントローラーで、AKS と適切に統合されます。 これには、イングレス コントローラーとしての機能とは別に、他の利点もあります。 たとえば、Application Gateway はクラスターの仮想ネットワーク エントリ ポイントとして機能します。 これは、クラスターに入ってくるトラフィックを監視できます。 WAF が必要なアプリケーションでは、WAF と統合されているため、Application Gateway が適しています。 さらに、TLS を終了する機会も提供されます。

AKS ベースライン リファレンス アーキテクチャ上の Windows コンテナーで使用されるイングレス設計を確認するには、関連記事を参照してください。

ルーター設定

イングレス コントローラーによって、ルートを使用してトラフィックの送信先が決定されます。 ルートによって、トラフィックを受信する送信元ポートと、宛先ポートとプロトコルに関する情報が指定されます。

このアーキテクチャからの例をこちらに示します。

Traefik では、Kubernetes プロバイダーを使用してルートが構成されます。 annotationstlsentrypoints は、ルートが HTTPS 経由で提供されることを示します。 middlewares では、Azure Application Gateway サブネットからのトラフィックのみが許可されることを指定します。 クライアントで受け入れられる場合は、gzip エンコードが応答に使用されます。 Traefik で TLS 終端が行われるため、バックエンド サービスとの通信は HTTP 経由で行われます。

apiVersion:networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port: 
              number: 80

ネットワーク フローのセキュリティ保護

このコンテキストでは、ネットワーク フローは次のように分類できます。

  • イングレス トラフィック。 クライアントからクラスターで実行されているワークロードまで。

  • エグレス トラフィック。 クラスター内のポッドまたはノードから外部サービスまで。

  • ポッド間トラフィック。 ポッド間の通信。 このトラフィックには、イングレス コントローラーとワークロードとの間の通信が含まれます。 また、ワークロードがクラスターにデプロイされた複数のアプリケーションで構成されている場合、それらのアプリケーション間の通信はこのカテゴリに分類されます。

  • 管理トラフィック。 クライアントと Kubernetes API サーバーとの間で送受信されるトラフィック。

クラスター トラフィック フローを示す図。

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

このアーキテクチャには、すべての種類のトラフィックをセキュリティで保護するための複数のセキュリティ層があります。

イングレス トラフィック フロー

このアーキテクチャでは、クライアントからの TLS で暗号化された要求のみが受け入れられます。 TLS v1.2 は、許可される最小バージョンであり、制限された暗号セットを使用しています。 厳密な Server Name Indication (SNI) が有効になっています。 エンドツーエンド TLS は、次の図に示すように、2 つの異なる TLS 証明書を使用して Application Gateway によって設定されます。

TLS 終端を示す図。

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

  1. クライアントからドメイン名 bicycle.contoso.com に HTTPS 要求が送信されます。 その名前は、DNS A レコードを介して Azure Application Gateway のパブリック IP アドレスに関連付けられます。 このトラフィックは、クライアント ブラウザーとゲートウェイとの間のトラフィックを検査または変更できないようにするために暗号化されます。

  2. Application Gateway では、統合された Web アプリケーション ファイアウォール (WAF) があり、bicycle.contoso.com の TLS ハンドシェイクをネゴシエートして、セキュリティで保護された暗号のみを許可します。 Application Gateway は、WAF 検査規則を処理し、構成されたバックエンドにトラフィックを転送するルーティング規則を実行するために必要なため、TLS の終端ポイントです。 TLS 証明書は Azure Key Vault に格納されます。 Application Gateway に統合されたユーザー割り当てのマネージド ID を使用してアクセスされます。 その機能の詳細については、「Key Vault 証明書を使用した TLS 終端」を参照してください。

  3. トラフィックは、Application Gateway からバックエンドに移動すると、内部ロード バランサーに転送されるときに、別の TLS 証明書 (*.aks-ingress.contoso.com のワイルドカード) を使用して再度暗号化されます。 この再暗号化により、安全でないトラフィックがクラスター サブネットに流れることがなくなります。

  4. イングレス コントローラーでは、ロード バランサーを介して暗号化されたトラフィックを受信します。 コントローラーは、*.aks-ingress.contoso.com のもう 1 つの TLS 終端ポイントであり、HTTP 経由でワークロード ポッドにトラフィックを転送します。 証明書は Azure Key Vault に格納され、コンテナー ストレージ インターフェイス (CSI) ドライバーを使用してクラスターにマウントされます。 詳細については、「シークレット管理の追加」を参照してください。

エンドツーエンドの TLS トラフィックすべてを、ワークロード ポッドに至るすべてのホップに実装できます。 ポッド間トラフィックをセキュリティで保護することを決定する際には、パフォーマンス、待ち時間、運用上の影響を必ず測定してください。 ほとんどのシングルテナント クラスターは、適切なコントロール プレーン RBAC と成熟したソフトウェア開発ライフサイクル プラクティスを使用して、イングレス コントローラーまでを TLS で暗号化し、Web アプリケーションファイアウォール (WAF) で保護するだけで十分です。 これにより、ワークロード管理のオーバーヘッドとネットワーク パフォーマンスへの影響が最小限に抑えられます。 ワークロードとコンプライアンスの要件によって、TLS 終端を行う場所が決まります。

エグレス トラフィック フロー

このアーキテクチャでは、クラスターからのすべてのエグレス トラフィックは、NAT GatewayHTTP プロキシなどの他のオプションではなく、Azure Firewall または独自の同様のネットワーク仮想アプライアンスを介して通信することをお勧めします。 ゼロトラスト制御とトラフィックを検査する機能については、クラスターからのすべてのエグレス トラフィックが Azure Firewall 経由で移動します。 この選択は、ユーザー定義ルート (UDR) を使用して実装できます。 ルートの次のホップは、Azure Firewall のプライベート IP アドレスです。 ここで、エグレス トラフィックをブロックするか許可するかが、Azure Firewall によって決定されます。 この決定は、Azure Firewall または組み込みの脅威インテリジェンス規則に定義された特定の規則に基づいて決定されます。

Azure Firewall を使用する代わりに、AKS の HTTP プロキシ機能を利用することができます。 クラスターから送信されるすべてのトラフィックは、最初に HTTP プロキシの IP アドレスに設定されます。これは、トラフィックを転送するかドロップするかを決定します。

どちらの方法でも、AKS に必要なエグレス ネットワーク規則を確認してください。

注意

UDR を使用した Azure Firewall 経由イグレス トラフィックおよびエグレスのパブリック ポイントとして、パブリック ロード バランサーを利用する場合、ルーティングが非対称になる可能性があります。 このアーキテクチャによって使用されるのは、Application Gateway の背後にある専用イングレス サブネットの "内部" ロード バランサーです。 この設計を選択すると、セキュリティが強化されるだけでなく、非対称ルーティングの問題も解消されます。 別の方法として、Application Gateway の前または後に Azure Firewall を介してイングレス トラフィックをルーティングすることもできますが、この方法はほとんどの状況で不要であるか、推奨されません。 非対称ルーティングの詳細については、Azure Firewall と Azure Standard Load Balancer の統合に関するページをご覧ください。

ゼロトラスト制御の例外は、クラスターと他の Azure リソースとの通信が必要な場合です。 たとえば、クラスターでは、コンテナー レジストリから更新されたイメージをプルするか、Azure Key Vault からシークレットをプルする必要があります。 推奨されるアプローチは、Azure Private Link を使用することです。 利点は、クラスターとサービスの間のトラフィックがインターネットを経由するのではなく、特定のサブネットがサービスに直接到達することです。 欠点として、Private Link では、パブリック エンドポイント経由でターゲット サービスを使用するのではなく、追加の構成が必要です。 また、すべての Azure サービスまたは SKU で Private Link がサポートされているわけではありません。 そのような場合は、サブネット上の仮想ネットワーク サービス エンドポイントがサービスにアクセスできるようにすることを検討してください。

Private Link またはサービス エンドポイントがオプションでない場合は、パブリック エンドポイントを介して他のサービスにアクセスしたり、Azure Firewall 規則とターゲット サービスに組み込まれたファイアウォールを使用してアクセスを制御したりすることができます。 このトラフィックはファイアウォールの静的 IP アドレスを通過するため、そのアドレスをサービスの IP 許可リストに追加することができます。 欠点の 1 つは、Azure Firewall には、特定のサブネットからのトラフィックのみが許可されるようにするための追加の規則が必要なことです。 Azure Firewall でエグレス トラフィック用に複数の IP アドレスを計画している場合は、これらのアドレスを考慮に入れてください。そうしないと、ポート枯渇になる可能性があります。 複数の IP アドレス計画の詳細については、送信トラフィックの制限と制御に関するセクションを参照してください。

AKS ベースライン リファレンス アーキテクチャ上の Windows コンテナーで使用される、エグレスに関する Windows 特有の考慮事項を確認するには、関連記事を参照してください。

ポッド間トラフィック

既定では、ポッドではクラスター内の他のポッドからのトラフィックを受け入れることができます。 Kubernetes NetworkPolicy は、ポッド間のネットワーク トラフィックを制限するために使用されます。 ポリシーは慎重に適用してください。そうしないと、重要なネットワーク フローがブロックされる状況が発生する可能性があります。 イングレス コントローラーとワークロードとの間のトラフィックなど、特定の通信パス "のみ" を必要に応じて許可します。 詳細については、「ネットワーク ポリシー」を参照してください。

ネットワーク ポリシーは後で追加することができないため、クラスターをプロビジョニングするときに有効にします。 NetworkPolicy を実装するテクノロジには、いくつかの選択肢があります。 Azure ネットワーク ポリシーをお勧めします。それには Azure Container Networking Interface (CNI) が必要です。以下の注を参照してください。 その他のオプションとしては、よく知られているオープンソース オプションである Calico ネットワーク ポリシーがあります。 クラスター全体のネットワーク ポリシーを管理する必要がある場合は、Calico を検討してください。 Calico は、標準の Azure サポートの対象にはなりません。

詳細については、Azure ネットワーク ポリシーと Calico ポリシー、およびそれらの機能の相違点に関するページを参照してください。

注意

AKS では、kubernet、Azure Container Network Interface (CNI)、Azure CNI オーバーレイというネットワーク モデルがサポートされています。 CNI モデルはより高度なモデルであり、Azure ネットワーク ポリシーを有効にするには CNI ベースのモデルが必要です。 非オーバーレイの CNI モデルでは、すべてのポッドがサブネットのアドレス空間から IP アドレスを取得します。 それらの IP アドレスを使用して、同じネットワーク内のリソース (またはピアリングされたリソース) からポッドに直接アクセスできます。 そのトラフィックをルーティングするために NAT は必要ありません。 どちらの CNI モデルも非常に高性能であり、ポッド間のパフォーマンスは仮想ネットワーク内の仮想マシンと同等です。 また、Azure CNI では Azure ネットワーク ポリシーを使用できるため、強化されたセキュリティ制御が提供されます。 Azure CNI オーバーレイは、ノードのノードプール サブネットからのみ IP アドレスを割り当て、ポッド IP に高度に最適化されたオーバーレイ レイヤーを使用する、IP アドレスの制約付きデプロイに使用することをお勧めします。 CNI ベースのネットワーク モデルをお勧めします。

モデルについては、使用する CNI ネットワーク モデルの選択および kubenet と Azure CNI のネットワーク モデルの比較に関する記事を参照してください。

管理トラフィック

クラスター実行の一環として、Kubernetes API サーバーは、クラスターに対する管理操作を実行するリソースからのトラフィック (リソースを作成またはクラスターをスケーリングする要求など) を受信します。 そのようなリソースの例としては、DevOps パイプラインのビルド エージェント プール、Bastion サブネット、ノード プール自体があります。 すべての IP アドレスからこの管理トラフィックを受け入れるのではなく、AKS の許可された IP 範囲の機能を使用して、許可された IP 範囲から API サーバーへのトラフィックのみを許可します。

詳細については、API サーバーの許可された IP 範囲の定義に関するページを参照してください。

複雑さという代償を払って制御レイヤーを追加すると、プライベート AKS クラスターをプロビジョニングできます。 プライベート クラスターを使用すると、API サーバーとノード プール間のネットワーク トラフィックがプライベート ネットワークのみに留まり、インターネットに公開されないようにすることができます。 詳細については、AKS プライベート クラスターに関するページを参照してください。

シークレット管理の追加

Azure Key Vault などの管理されたキー ストアにシークレットを格納します。 その利点は、マネージド ストアでシークレットのローテーションが処理されること、強力な暗号化が提供されること、アクセス監査ログが提供されること、デプロイ パイプラインからコア シークレットが切り離されることです。 このアーキテクチャでは、Azure Key Vault ファイアウォールが有効化され、シークレットと証明書にアクセスする必要がある Azure 内のリソースへのプライベート リンク接続で構成されます。

Azure Key Vault は、他の Azure サービスと適切に統合されています。 それらのサービスの組み込み機能を使用して、シークレットにアクセスします。 Azure Application Gateway からイングレス フローの TLS 証明書へのアクセスがどのように行われるかを示す例については、「イングレス トラフィック フロー」セクションを参照してください。

Key Vault の Azure RBAC アクセス許可モデルを使用すると、ワークロード ID を Key Vault Secrets User または Key Vault Reader のいずれかのロールの割り当てに割り当てて、シークレットにアクセスできます。 詳細については、RBAC を使用した Azure Key Vault へのアクセスに関するページを参照してください。

クラスター シークレットへのアクセス

ポッドから特定のストアにあるシークレットにアクセスできるようにするには、ワークロード ID を使用する必要があります。 取得プロセスを容易にするには、シークレット ストア CSI ドライバーを使用します。 ポッドにシークレットが必要な場合、ドライバーによって、指定されたストアへの接続、ボリューム上のシークレットの取得、クラスター内でのそのボリュームのマウントが行われます。 その後、ボリューム ファイル システムからポッドにシークレットを取得できます。

CSI ドライバーには、さまざまなマネージド ストアをサポートするプロバイダーが多数存在します。 この実装では、Azure Key Vault から TLS 証明書を取得し、イングレス コントローラーを実行しているポッドにそれを読み込むために、アドオンを使用する Azure Key Vault とシークレット ストア CSI ドライバーを選択しました。 これはポッドの作成時に行われ、ボリュームには公開キーと秘密キーの両方が格納されます。

ワークロード ストレージ

このアーキテクチャで使用しているワークロードはステートレスです。 状態を格納する必要がある場合は、クラスターの外部で永続化することをお勧めします。 ワークロードの状態に関するガイダンスは、この記事の範囲外です。

ストレージ オプションの詳細については、「Azure Kubernetes Service (AKS) でのアプリケーションのストレージ オプション」を参照してください。

ポリシー管理

AKS クラスターを管理する効果的な方法は、ポリシーを使用してガバナンスを適用することです。 Kubernetes は、OPA Gatekeeper を介してポリシーを実装します。 AKS の場合、ポリシーは、Azure Policy を介して提供されます。 各ポリシーは、そのスコープ内のすべてのクラスターに適用されます。 Azure Policy の適用は、最終的に、クラスター内の OPA Gatekeeper によって処理され、すべてのポリシー チェックはログされます。 ポリシーの変更はすぐにはクラスターに反映されません。多少の遅延が発生することが予想されます。

AKS クラスターを管理するために、Azure Policy では 2 つの異なるシナリオが提供されています。

  • 組織の基準を評価して、リソース グループまたはサブスクリプションでの AKS クラスターのデプロイを防止または制限します。 たとえば、名前付け規則に従って、タグを指定するなどです。
  • Kubernetes の Azure Policy を使用して AKS クラスターをセキュリティで保護します。

ポリシーを設定する場合、ワークロードの要件に基づいて適用します。 次の点を考慮します。

  • ポリシーのコレクション (イニシアティブと呼ばれる) を設定するか、個々のポリシーを選択するか? Azure Policy には、基本と制限の 2 つの組み込みイニシアティブが用意されています。 各イニシアティブは、AKS クラスターに適用可能な組み込みポリシーのコレクションです。 組織の要件に従って、イニシアティブを選択し、"かつ" クラスターおよびクラスターとやり取りするリソース (ACR、Application Gateway、Key Vault など) に関する追加のポリシーを選択することをお勧めします。

  • アクションを監査するか、拒否するか? 監査モードでは、アクションは許可されますが、非準拠のフラグが設定されます。 非準拠の状態を定期的にチェックし、必要なアクションを実行するプロセスを用意します。 拒否モードでは、アクションはポリシーに違反しているため、ブロックされます。 このモードは制限が厳しすぎてワークロードが機能しない可能性があるため、選択する場合は注意が必要です。

  • ワークロードに、仕様上準拠する必要のない領域があるか: Azure Policy には、ポリシーの適用から除外される Kubernetes 名前空間を指定する機能があります。 これらのインスタンスを認識できるように、監査モードでもポリシーの適用をお勧めします。

  • 組み込みのポリシーの対象ではない要件があるか: カスタム OPA Gatekeeper ポリシーを適用するカスタムの Azure Policy 定義を作成できます。 カスタム ポリシーをクラスターに直接適用しないでください。 カスタム ポリシーの作成の詳細については、「カスタム ポリシー定義を作成して割り当てる」を参照してください。

  • 組織全体の要件はあるか: ある場合は、それらのポリシーを管理グループ レベルで追加します。 組織に汎用的なポリシーがある場合でも、クラスターでは独自のワークロード固有のポリシーを割り当てる必要もあります。

  • Azure のポリシーは、特定のスコープに割り当てられます。 必ず、"運用前" 環境に対しても "運用" ポリシーが検証されるようにしてください。 そうしなければ、運用環境にデプロイするときに、運用前環境では考慮されていなかった予期しない追加の制限が発生する可能性があります。

このリファレンス実装では、AKS クラスターの作成時に Azure Policy が有効になり、監査モードで制限付きイニシアティブを割り当てて、コンプライアンス違反を視覚化します。

この実装では、組み込みのイニシアティブに含まれていない追加のポリシーも設定します。 これらのポリシーは、拒否モードで設定されます。 たとえば、イメージが、デプロイされた ACR からのみプルされるようにするポリシーを設定します。 独自のカスタム イニシアティブの作成を検討してください。 また、ワークロードに適用可能なポリシーを 1 つの割り当てに結合してください。

クラスター内から Azure Policy がどのように機能しているかを監視するには、gatekeeper-system 名前空間内のすべてのポッドのポッド ログと、kube-system 名前空間内の azure-policy および azure-policy-webhook ポッドのログにアクセスします。

AKS ベースライン リファレンス アーキテクチャ上の Windows コンテナーに含まれる、Azure Policy に関する Windows 特有の考慮事項を確認するには、関連記事を参照してください。

ノードとポッドのスケーラビリティ

Kubernetes では、ポッドの水平自動スケーリング (HPA) を使用して既存のノードにポッドを追加することで、要求の増加に応じてスケールアウトできます。 追加のポッドをそれ以上スケジュールできなくなった場合は、AKS クラスター自動スケーリングによってノードの数を増やす必要があります。 完全なスケーリング ソリューションには、クラスター内のポッド レプリカとノード数の両方をスケーリングする方法が必要です。

自動スケーリングまたは手動スケーリングという 2 つの方法があります。

手動つまりプログラムによる方法では、CPU 使用率またはカスタム メトリックについての監視とアラート設定を行う必要があります。 ポッド スケーリングの場合、アプリケーションのオペレーターで Kubernetes API を使用して ReplicaSet を調整することで、ポッド レプリカの数を増減できます。 クラスターのスケーリングでは、1 つの方法として、Kubernetes スケジューラが失敗したときに通知を受け取ることができます。 もう 1 つの方法は、時間の経過と共に保留中のポッドを監視することです。 ノード数は Azure CLI またはポータルを使用して調整できます。

自動スケーリングが推奨される方法です。それは、オートスケーラーにそれらの手動メカニズムの一部が組み込まれているためです。

一般的な方法として、最小数のポッドとノードを使用を使用したパフォーマンス テストから始めます。 それらの値を使用して、ベースライン予測を確立します。 次に、パフォーマンス メトリックと手動スケーリングの組み合わせを使用して、ボトルネックを特定し、スケーリングに対するアプリケーションの反応を把握します。 最後に、このデータを使用して自動スケーリングのパラメーターを設定します。 AKS を使用したパフォーマンス チューニング シナリオの詳細については、「パフォーマンス チューニングのシナリオ: 分散ビジネス トランザクション」を参照してください。

ポッドの水平オートスケーラー

ポッドの水平オートスケーラー (HPA) は、ポッドの数をスケーリングする Kubernetes リソースです。

HPA リソースで、レプリカの最小数と最大数を設定することをお勧めします。 それらの値によって自動スケーリングの範囲を制約します。

HPA は、CPU 使用率、メモリ使用量、カスタム メトリックに基づいてスケーリングできます。 既定では、CPU 使用率のみが提供されます。 HorizontalPodAutoscaler 定義によって、それらのメトリックのターゲット値を指定します。 たとえば、仕様によってターゲットの CPU 使用率が設定されます。 ポッドが実行されている間、HPA コントローラーによって、Kubernetes Metrics API を使用して各ポッドの CPU 使用率が確認されます。 この値をターゲットの使用率と比較して比率が計算されます。 次に、この比率を使用して、ポッドが多く割り当てられているか、少なく割り当てられているかどうかが判断されます。 ノードに新しいポッドを割り当てたり、ノードからポッドを削除したりするには、Kubernetes スケジューラが使用されます。

スケーリング操作が完了する前に HPA のチェックが行われる競合状態が発生する可能性があります。 その結果、比率計算は正しくない可能性があります。 詳細については、「スケーリング イベントのクールダウン」を参照してください。

イベントドリブンのワークロードの場合、一般的なオープンソース オプションは KEDA です。 ワークロードが CPU またはメモリバインドではなく、メッセージ キューなどのイベント ソースによって左右される場合は、KEDA を検討してください。 KEDA では、多くのイベント ソース (またはスケーラー) がサポートされています。 Azure Monitor を含む、サポートされている KEDA スケーラーの一覧はこちらにあります。Azure Monitor は、Azure Monitor のメトリックに基づいて KEDA ワークロードをスケーリングする便利な方法です。

クラスター オートスケーラー

クラスター オートスケーラーは、ノード プール内のノードの数をスケーリングする AKS アドオン コンポーネントです。 クラスターのプロビジョニング時に追加する必要があります。 ユーザー ノード プールごとに個別のクラスター オートスケーラーが必要です。

クラスター オートスケーラーは、Kubernetes スケジューラによってトリガーされます。 リソースの制約が原因で Kubernetes スケジューラによるポッドのスケジューリングが失敗すると、オートスケーラーによってノード プールに新しいノードが自動的にプロビジョニングされます。 逆に、クラスター オートスケーラーによって、未使用のノード容量が確認されます。 ノードが想定した容量で実行されていない場合は、ポッドが別のノードに移動され、未使用のノードが削除されます。

オートスケーラーを有効にする場合は、ノードの最大数と最小数を設定します。 推奨値は、ワークロードのパフォーマンス予測、クラスターに希望する拡張量、コストの影響によって異なります。 最小数は、そのノード プール用に予約されている容量です。 このリファレンス実装では、ワークロードの種類が単純なため、最小値を 2 に設定しています。

システム ノード プールの場合、推奨される最小値は 3 です。

AKS ベースライン リファレンス アーキテクチャ上の Windows コンテナーに含まれるスケーリングに関する考慮事項を確認するには、関連記事を参照してください。

ビジネス継続性に関する決定事項

ビジネス継続性を維持するために、インフラストラクチャとアプリケーションのサービス レベル アグリーメントを定義します。 月間アップタイムの計算の詳細については、「Azure Kubernetes Service (AKS) の SLA」を参照してください。

クラスター ノード

ワークロードの最小レベルの可用性を達成するために、ノード プール内に複数のノードが必要です。 ノードがダウンした場合、同じクラスター内にあるノード プール内の別のノードでアプリケーションの実行を続行できます。 信頼性を確保するために、システム ノード プールに 3 つのノードをお勧めします。 ユーザー ノード プールの場合、2 つ以上のノードから開始します。 高可用性が必要な場合は、さらに多くのノードをプロビジョニングします。

アプリケーションをユーザー ノード プールと呼ばれる別のノード プールに配置して、システム サービスから分離します。 このように、Kubernetes サービスは専用ノードで実行され、ワークロードと競合しません。 タグ、ラベル、テイントを使用して、ワークロードをスケジュールするノード プールを特定し、システム ノード プールが CriticalAddonsOnly [taint] (/azure/aks/use-system-pools#system-and-user-node-pools) でテイントされていることを確認することをお勧めします。

信頼性を確保するには、クラスターの定期的な保守 (タイムリーな更新など) が不可欠です。 また、probe によってポッドの正常性を監視することをお勧めします。

ポッドの可用性

ポッド リソースを確保する。 デプロイにポッド リソースの要件を指定することを強くお勧めします。 そうすることで、スケジューラでポッドを適切にスケジューリングできます。 ポッドをスケジューリングできない場合、信頼性は大幅に低下します。

ポッド中断バジェットを設定する。 この設定により、更新またはアップグレード イベント時にダウンさせることができる、デプロイ内のレプリカの数が決まります。 詳細については、ポッド中断バジェットに関するページを参照してください。

ハードウェア障害などの中断に対処するために、デプロイに複数のレプリカを構成します。 更新やアップグレードなどの計画されたイベントに備えて、予想されるアプリケーション負荷を処理するために必要な数のポッド レプリカを、中断バジェットによって確保できます。

ワークロードの名前空間にリソース クォータを設定する。 名前空間のリソース クォータによって、デプロイにポッドの要求と制限が適切に設定されます。 詳細については、「リソース クォータを適用する」を参照してください。

注意

リソース クォータをクラスター レベルで設定すると、適切な要求と制限のないサードパーティのワークロードをデプロイするときに、問題が発生する可能性があります。

ポッドの要求と制限を設定する。 これらの制限を設定することにより、Kubernetes で CPU やメモリ リソースを効率的にポッドに割り当て、ノードのコンテナー密度を上げることができます。 制限により、ハードウェアの使用率が向上するため、コストを削減しながら信頼性を高めることもできます。

制限を見積もるために、テストを行い、ベースラインを確立します。 要求と制限に等しい値を使用して開始します。 その後、それらの値を徐々に調整しながら、クラスターを不安定にする可能性があるしきい値を確定します。

それらの制限を配置マニフェスト内に指定できます。 詳細については、ポッドの要求と制限の設定に関するページを参照してください。

可用性ゾーンと複数リージョンのサポート

SLA でより高いアップタイムが要求される場合は、可用性ゾーンを使用して停止から保護します。 リージョンで可用性ゾーンがサポートされている場合は、それを使用できます。 これにより、コントロール プレーン コンポーネントとノード プール内のノードの両方をゾーン間で分散させることができます。 1 つのゾーン全体が使用できない場合でも、リージョン内にある別のゾーンのノードを引き続き使用できます。 各ノード プールは、ノード インスタンスとスケーラビリティを管理する個別の仮想マシン スケール セットにマップされます。 スケール セットの操作と構成は AKS サービスによって管理されます。 複数ゾーンを有効にする場合の考慮事項のいくつかを次に示します。

  • インフラストラクチャ全体。 可用性ゾーンをサポートしているリージョンを選択します。 詳細については、「制限事項とリージョンの可用性」を参照してください。 アップタイム SLA を購入する場合は、そのオプションをサポートするリージョンを選択します。 可用性ゾーンを使用する場合、アップタイム SLA がより適切です。

  • クラスター。 可用性ゾーンは、ノード プールの作成時にのみ設定でき、後で変更することはできません。 予想される分散が可能になるように、ノード サイズがすべてのゾーンでサポートされている必要があります。 基になる仮想マシン スケール セットによって、複数ゾーンで同じハードウェア構成が実現します。

    マルチゾーンのサポートは、ノード プールだけでなく、コントロール プレーンにも適用されます。 AKS コントロール プレーンは、ノード プールと同様に、要求されたすべてのゾーンに及びます。 お使いのクラスターでゾーン サポートを使用しない場合、コントロール プレーン コンポーネントが複数の可用性ゾーンにわたって広がるとは限りません。

  • 依存リソース。 ゾーンを完全に活用するには、すべてのサービス依存関係でもゾーンがサポートされている必要があります。 依存サービスでゾーンがサポートされていない場合、ゾーンの障害によってそのサービスが失敗する可能性があります。

たとえば、マネージド ディスクは、プロビジョニングされているゾーンで使用できます。 障害が発生した場合、ノードは別のゾーンに移される可能性がありますが、マネージド ディスクがノードと共にそのゾーンに移動することはありません。

わかりやすくするために、このアーキテクチャでは、可用性ゾーン 1、2、3 にまたがるノード プールを持つ 1 つのリージョンに AKS をデプロイしています。 Azure Firewall や Application Gateway など、インフラストラクチャのその他のリソースは、やはり複数ゾーンをサポートする同じリージョンにデプロイされます。 Azure Container Registry の geo レプリケーションが有効になります。

複数のリージョン

可用性ゾーンを有効にしても、リージョン全体がダウンした場合には十分ではありません。 可用性を高めるには、複数の AKS クラスターを異なるリージョンで実行します。

  • ペアになっているリージョンを使用します。 ペアのリージョンを使用してリージョンの障害から復旧するように構成された CI/CD パイプラインの使用を検討してください。 ペアのリージョンを使用する利点は、更新中の信頼性です。 Azure では、ペアのうち 1 つのリージョンのみが一度に更新されるようになっています。 Flux などの特定の DevOps ツールを使用すると、複数リージョンのデプロイを簡単に行うことができます。

  • Azure リソースで geo 冗長がサポートされている場合は、冗長サービスのセカンダリが維持される場所を指定します。 たとえば、Azure Container Registry の geo レプリケーションを有効にすると、選択した Azure リージョンにイメージが自動的にレプリケートされ、リージョンで障害が発生した場合でも、イメージへの継続的なアクセスが提供されます。

  • 要件に応じて、ゾーンまたはリージョン間でトラフィックを分散できるトラフィック ルーターを選択します。 このアーキテクチャでは、Web 以外のトラフィックをゾーン間で分散できるため、Azure Load Balancer をデプロイします。 リージョン間でトラフィックを分散する必要がある場合は、Azure Front Door を検討してください。 その他の考慮事項については、ロード バランサーの選択に関するページを参照してください。

注意

アクティブ/アクティブの高可用性構成内に複数のリージョンを含める目的で、この参照アーキテクチャを拡張しました。 その参照アーキテクチャについては、「マルチリージョン クラスターの AKS ベースライン」を参照してください。

GitHub logo マルチリージョン アーキテクチャの実装については、GitHub: マルチリージョン デプロイ用の Azure Kubernetes Service (AKS) に関するページを参照してください。 これを出発点として使用し、実際のニーズに合わせて構成することができます。

障害復旧

プライマリ リージョンで障害が発生した場合は、別のリージョンに新しいインスタンスをすばやく作成できる必要があります。 以下に、推奨事項をいくつか示します。

  • ペアになっているリージョンを使用します。

  • ステートフルでないワークロードは、効率的にレプリケートできます。 クラスター内に状態を格納する必要がある場合 (推奨されません)、ペアになっているリージョンで頻繁にデータをバックアップしてください。

  • サービス レベル目標 (SLO) を満たすために、DevOps パイプラインの一部として、別のリージョンへのレプリケーションなどの復旧戦略を統合します。

  • 各 Azure サービスをプロビジョニングするときに、ディザスター リカバリーをサポートする機能を選択します。 たとえば、このアーキテクチャでは、Azure Container Registry で geo レプリケーションが有効になっています。 リージョンがダウンした場合でも、レプリケートされたリージョンから引き続きイメージをプルできます。

クラスターバックアップ

多くのアーキテクチャでは、新しいクラスターをプロビジョニングし、それを動作状態に戻すには、GitOps ベースの [クラスター ブートストラップ}(#クラスターブートストラップ) と、その後にアプリケーションをデプロイすることで実現できます。 ただし、構成マップ、ジョブ、および何らかの理由でブートストラップ プロセス内でキャプチャできない可能性のあるシークレットなどの重要なリソース状態がある場合は、復旧戦略を検討してください。 一般的に、Kubernetes ではステートレス ワークロードの実行をお勧めしますが、アーキテクチャにディスクベースの状態が含まれている場合は、その内容の復旧戦略も検討する必要があります。

復旧戦略の一環としてクラスターのバックアップが必要な場合は、クラスター内のビジネス要件に合致するソリューションをインストールする必要があります。 このエージェントは、選んだ宛先にクラスター リソースの状態をプッシュし、Azure ディスクベースの永続ボリューム スナップショットを調整する役割を担います。

VMware の Velero は、直接インストールして管理できる一般的な Kubernetes バックアップ ソリューションの例です。 または、AKS バックアップ拡張機能 を使用して、マネージド Velero 実装の提供もできます。 AKS バックアップ拡張機能では、Kubernetes リソースと永続ボリューム両方のバックアップがサポートされており、スケジュールとバックアップ スコープは、Azure Backup のボールト構成として外部化されています。

参照実装にバックアップは実装されません。バックアップには、管理、監視、支払い、セキュリティ保護のために、追加の Azure リソース (Azure Storage アカウント、Azure Backup ボールトと構成、信頼されたアクセスなど) がアーキテクチャに必要となります。 実装される復旧ソリューションは、ステートレス ワークロードを実行する意図で GitOps を組み合わせたものとなります。

定義済みの目標復旧時点 (RPO) と目標復旧時間 (RTO) を含め、ビジネス目標を満たすソリューションを選んで検証します。 チーム Runbook にこの復旧プロセスを定義し、ビジネス クリティカルなすべてのワークロードに対してそれを実践します。

Kubernetes API サーバー SLA

AKS は無料のサービスとして使用できますが、そのレベルでは、金銭的な補償を伴う SLA は提供されません。 その SLA を得るには、Standard レベルを選ぶ必要があります。 すべての運用クラスターで Standard レベルの採用をお勧めします。 Free レベルのクラスターは運用前クラスター用に取っておきます。 Azure Availability Zones と組み合わせると、Kubernetes API サーバーの SLA は 99.95% に向上します。 ノード プールとその他のリソースは、それぞれ専用の SLA の対象になっています。

トレードオフ

複数のゾーンや、特に複数のリージョンにわたってアーキテクチャをデプロイする場合、コストと可用性のトレードオフがあります。 Azure Container Registry の geo レプリケーションなどの一部のレプリケーション機能を Premium SKU で利用できますが、コストが高くなります。 また、トラフィックが複数のゾーンやリージョンに移動したときに適用される帯域幅の料金も、コスト増加の原因になります。

さらに、ゾーン間またはリージョン間のノード通信における追加のネットワーク待ち時間が予想されます。 このアーキテクチャ上の決定がワークロードに与える影響を測定します。

シミュレーションと強制フェールオーバーをテストする

ノードの停止、ゾーン障害をシミュレートする特定のゾーン内の全 AKS リソースの停止、外部依存関係の障害の呼び出しなどで障害をシミュレートして強制フェールオーバーをテストすることによって、信頼性を確保します。 Azure Chaos Studio を利用して、Azure とクラスターのさまざまな種類の停止をシミュレートすることもできます。

詳細については、Azure Chaos Studio に関するページを参照してください。

メトリックの監視と収集

Azure Monitor Container insights は、リアルタイムでイベントを表示できるため、コンテナー ワークロードのパフォーマンスを監視するための推奨ツールです。 実行中のポッドからコンテナー ログをキャプチャし、集計して表示できます。 また、メトリック API からメモリと CPU 使用率に関する情報を収集して、実行中のリソースとワークロードの正常性を監視します。 これを使用して、ポッド スケールとしてパフォーマンスを監視することもできます。 これには、傾向を識別するために収集されたデータの監視、分析、視覚化に不可欠なテレメトリのコレクションと、重大な問題が予防的に通知されるアラートの構成が含まれます。

ポッドでホストされているほとんどのワークロードからは、Prometheus メトリックが出力されます。 Container insights は Prometheus と統合して、ノードと Kubernetes から収集したアプリケーションとワークロードのメトリックを表示できます。

組織で既に使用している場合は、Datadog、Grafana、New Relic など、Kubernetes と統合して利用できるサードパーティ ソリューションがいくつかあります。

AKS を使用すると、Azure でいくつかのコア Kubernetes サービスが管理され、AKS コントロール プレーン コンポーネントのログは リソース ログとして Azure に実装されます。 ほとんどのクラスターで常に以下のものを有効にすることをお勧めします。ログの密度が比較的低く、クラスターの問題のトラブルシューティングに役立ちます。

  • ClusterAutoscaler のログ記録 (スケーリング操作を監視するため)。 詳細については、「クラスター オートスケーラーのログと状態を取得する」を参照してください。
  • KubeControllerManager (Kubernetes と Azure コントロール プレーンの間のやり取りを監視するため)。
  • KubeAuditAdmin (クラスターを変更するアクティビティを監視するため)。 KubeAudit は変更のない (読み取り) 操作も含む KubeAuditAdmin のスーパーセットであるため、KubeAuditKubeAuditAdmin の両方を有効にする理由はありません。
  • Guard は、Microsoft Entra ID と Azure RBAC の監査をキャプチャします。

KubeSchedulerKubeAudit などの他のログ カテゴリをクラスターまたはワークロード ライフサイクルの開発の初期段階で有効にすると、非常に役立つ場合があります。クラスターの自動スケーリング、ポッドの配置とスケジュール設定、同様のデータが追加され、クラスターまたはワークロードの操作に関する問題のトラブルシューティングに役立つことがあります。 トラブルシューティングの必要性がなくなると、拡張されたトラブルシューティング ログを常時保存して Azure Monitor に取り込んで格納することが、不要なコストと見なされる場合があります。

Azure Monitor には、最初に使用する既存のログ クエリのセットが含まれていますが、それらを基盤として使用して独自のクエリを構築することもできます。 ライブラリが大きくなるにつれて、1 つ以上のクエリ パックを使用してログ クエリを保存および再利用できます。 クエリのカスタム ライブラリは、AKS クラスターの正常性とパフォーマンスに対する監視を強化し、サービス レベル目標 (SLO) をサポートするのに役立ちます。

AKS の監視のベスト プラクティスの詳細については、「Azure Monitor を使用して Azure Kubernetes Service (AKS) を監視する」を参照してください。

AKS ベースライン リファレンス アーキテクチャ上の Windows コンテナーに含まれる、監視に関する Windows 特有の考慮事項を確認するには、関連記事を参照してください。

自己復旧を有効にする

liveness と readiness の probe を設定することによって、ポッドの正常性を監視します。 応答しないポッドが検出された場合、Kubernetes によってポッドが再起動されます。 liveness probe では、ポッドが正常であるかどうかが判断されます。 応答がない場合、Kubernetes によってポッドが再起動されます。 readiness probe では、ポッドが要求またはトラフィックを受信する準備ができているかどうかが判断されます。

注意

AKS では、ノードの自動修復を使用して、組み込みのインフラストラクチャ ノードの自己復旧が提供されます。

AKS クラスターの更新

ビジネス要件と整合性のある更新戦略を定義することが最も重要です。 AKS クラスターの更新ブループリントを作成するには、AKS クラスターのバージョンまたはそのノードが更新される日時をどの程度予測できるかと、インストールされる特定のイメージまたはバイナリをどの程度制御することが望ましいかを理解することが基本です。 予測可能性は、更新周期とメンテナンス期間という 2 つの主要な AKS クラスター更新プロパティに関連付けられています。 制御とは、更新プログラムを手動でインストールするか、自動的にインストールするかを示します。 AKS クラスターに厳格なセキュリティ規則が適用されていない組織では、毎週または毎月の更新を検討できます。それ以外の組織では、セキュリティ ラベルの付いた修正プログラムが利用可能になったらすぐに (毎日) 更新する必要があります。 AKS クラスターを不変インフラストラクチャとして運用している組織では、クラスターの更新は行いません。 つまり、自動更新も手動更新も実施されません。 代わりに、必要な更新プログラムが利用可能になると、レプリカ スタンプがデプロイされ、新しいインフラストラクチャ インスタンスの準備ができたときにのみ以前のインスタンスがドレインされます。これにより、最も高いレベルの制御が提供されます。

AKS クラスターの更新ブループリントが決定したら、それを AKS ノードと AKS クラスター バージョンの利用可能な更新オプションに簡単にマップできます。

  • AKS ノード:

    1. なし/手動更新: 不変インフラストラクチャの場合、または手動更新を優先する場合に使用します。 これにより、AKS ノードの更新に対して、より高いレベルの予測可能性と制御を実現できます。
    2. 自動無人更新: AKS は、ネイティブの OS の更新を実行します。 ビジネスに適したメンテナンス期間を構成することで予測可能性を確保できます。 これは、ピーク時間と運用上最適な時間を基にすることができます。 AKS ノード内に具体的に何がインストールされるかを事前に知ることはできないため、制御のレベルは低くなります。
    3. ノード イメージの自動更新: 新しい仮想ハード ディスク (VHD) が利用可能になったら、AKS ノード イメージを自動的に更新することをお勧めします。 メンテナンス期間は、できるだけビジネス ニーズに合うように設計します。 セキュリティ ラベルの付いた VHD 更新プログラムについては、最も低い予測可能性に基づいて毎日のメンテナンス期間を構成することをお勧めします。 通常の VHD 更新プログラムは、毎週、2 週間ごと、または毎月のメンテナンス期間で構成できます。 セキュリティ ラベルの付いた VHD と通常の VHD のどちらが必要かと、スケジュールされたメンテナンス期間に応じて予測可能性は変動し、ビジネス要件にどの程度柔軟に合わせられるかも変わります。 理想は常にビジネス要件に合わせることですが、現実には、転換点を見つけることが組織に求められます。 新しい VHD に具体的にどのようなバイナリが含まれているかを事前に知ることはできないため、制御のレベルは低くなります。それでも、この種類の自動更新ではイメージが利用可能になる前に審査されるため、このオプションを推奨します。

    Note

    AKS ノードの自動更新を構成する方法の詳細については、「ノードの OS イメージを自動アップグレードする」を参照してください。

  • AKS クラスター バージョン:

    1. なし/手動更新: 不変インフラストラクチャの場合、または手動更新を優先する場合に使用します。 これにより、AKS クラスター バージョンの更新に対して、より高いレベルの予測可能性と制御を実現できます。 完全な制御が可能であり、運用環境への導入前に、下位の環境で新しい ASK クラスター バージョン (つまり 1.14.x から 1.15.x) をテストする機会が得られるため、このオプションにオプトインすることをお勧めします。
    2. 自動更新: 運用クラスターでは、下位の環境で適切にテストすることなく、自動的に修正プログラムを適用したり、利用可能な新しい ASK クラスター バージョン (つまり 1.16.x から 1.16.y) に更新したりすることは推奨されません。 Kubernetes のアップストリーム リリースと AKS クラスター バージョンの更新プログラムは定期的な周期で連動するように調整されていますが、運用環境の AKS クラスターでは防御的な戦略をとり、更新プロセスに対する予測可能性と制御を高めることをお勧めします。 一方、このオプションは、オペレーショナル エクセレンスの一貫として、潜在的な問題をできるだけ早期に検出するために事前テストの定期的な実行を可能にする、下位の環境向けの構成と考えてください。

サポートされている N-2 バージョンを使用して、Kubernetes バージョンを最新の状態に保ちます。 新しいバージョンが頻繁にリリースされるため、最新バージョンの Kubernetes にアップグレードすることが重要です。

詳細については、「最新版の Kubernetes に定期的に更新する」および「Azure Kubernetes Service (AKS) クラスターのアップグレード」を参照してください。

クラスターで発生したイベント (クラスターで新しい AKS バージョンが使用可能になることなど) の通知は、Azure Event Grid の AKS システム トピックを通じて実現できます。 リファレンス実装では、イベント ストリーム通知ソリューションから Microsoft.ContainerService.NewKubernetesVersionAvailable イベントをサブスクライブできるように、この Event Grid システム トピックがデプロイされます。

週次更新

AKS によって、OS とランタイムの最新の更新プログラムを含む新しいノード イメージが提供されます。 これらの新しいイメージは、自動的に適用されません。 イメージを更新する頻度は、ご自分で決定する必要があります。 ノード プールの基本イメージを毎週アップグレードするプロセスを用意することをお勧めします。 詳細については、「Azure Kubernetes Service (AKS) ノード イメージのアップグレード」および AKS リリース ノートを参照してください。

日次更新

イメージのアップグレード間に、AKS ノードにより、OS とランタイムのパッチが個別にダウンロードされインストールされます。 インストールするには、ノード VM の再起動が必要になる場合があります。 更新が保留中であるため、AKS によりノードが再起動されません。 再起動が必要な適用済みの更新についてノードを監視し、それらのノードの再起動を制御された方法で実行するプロセスを用意します。 オープンソース オプションは Kured (Kubernetes の再起動デーモン) です。

ノード イメージを最新の週次リリースと同期させることで、強化されたセキュリティ体制を維持しながら、これらの不定期の再起動要求を最小限に抑えることができます。 ノード イメージのアップグレードのみに依存することで、AKS の互換性と週次セキュリティ更新プログラムの適用が保証されます。 日次更新を適用すると、セキュリティの問題がより早く修正されますが、それらは AKS でテストされているとは限りません。 可能な場合は、主要な週次セキュリティ更新プログラムの適用戦略としてノード イメージのアップグレードを使用してください。

セキュリティの監視

アクティブな脅威と潜在的なセキュリティ リスクの両方について、コンテナー インフラストラクチャを監視します。

クラスターとワークロードの運用 (DevOps)

次にいくつかの考慮事項を示します。 詳細については、「オペレーショナル エクセレンス」のトピックを参照してください。

クラスター ブートストラップ

プロビジョニングが完了すると、クラスターは動作しますが、ワークロードをデプロイする前に必要な手順がまだ存在する可能性があります。 クラスターを準備するプロセスはブートストラップと呼ばれ、クラスター ノードへの前提条件イメージのデプロイ、名前空間の作成などのアクション、および使用事例や組織の要件を満たすその他のアクションで構成できます。

プロビジョニングされたクラスターと適切に構成されたクラスターの間のギャップを減らするには、クラスター オペレーターは、独自のブートストラップ プロセスの外観を考え、関連する資産を事前に準備する必要があります。 たとえば、アプリケーション ワークロードをデプロイする前に各ノードで Kured を実行することが重要な場合、クラスター オペレーターは、クラスターをプロビジョニングする前に、ターゲットの Kured イメージを含む ACR が既に存在することを確認する必要があります。

ブートストラップ プロセスは、次のいずれかの方法を使用して構成できます。

Note

これらの方法は、任意のクラスター トポロジで動作しますが、GitOps Flux v2 クラスター拡張機能は、統一性と大規模なガバナンスの容易さのために、フリートに推奨されます。 少数のクラスターのみを実行する場合、GitOps は過剰に複雑と見なされる可能性があります。代わりに、ブートストラップが実行されるのを確認するために、そのプロセスを 1 つ以上のデプロイ パイプラインに統合することを選択できます。 組織とチームの目標に最も合った方法を使用します。

AKS 用の GitOps Flux v2 クラスター拡張機能を使用する主な利点の 1 つは、プロビジョニングされたクラスターとブートストラップされたクラスターの間に実質的にギャップがない点です。 これにより、今後の強固な管理基盤を備えた環境が設定されます。また、実際の IaC 戦略に合わせて、そのブートストラップをリソース テンプレートとして含めることもサポートされます。

最後に、拡張機能 kubectlkubectlを使用する場合、 はブートストラップ プロセスの一部には必要ありません。また、 ベースのアクセスの使用は緊急のブレーク修正の状況用に予約できます。 Azure リソース定義のテンプレートと GitOps 拡張機能を使用したマニフェストのブートストラップの間で、 を使用することなく、すべての通常の構成アクティビティを実行できます kubectl

ワークロードの役割を分離する

チームごと、およびリソースの種類ごとにワークロードを分割して、各部分を個別に管理します。

基本コンポーネントを含む基本的なワークロードから開始し、それを基に構築します。 最初のタスクとして、ネットワークを構成します。 ハブとスポークの仮想ネットワークと、それらのネットワーク内のサブネットをプロビジョニングします。 たとえば、スポークにはシステムおよびユーザーのノード プール用の個別のサブネットと、イングレス リソースがあります。 Azure Firewall のサブネットはハブ内です。

また、別の部分で基本ワークロードを Microsoft Entra ID と統合することもできます。

コードとしてのインフラストラクチャ (IaC) を使用する

可能であれば、命令型のアプローチではなく、べき等の宣言型メソッドを選択します。 構成オプションを指定する一連のコマンドを記述するのではなく、リソースとそのプロパティを記述する宣言型の構文を使用します。 オプションの 1 つは、Azure Resource Manager (ARM) テンプレートです。 もう 1 つは Terraform です。

必ず管理ポリシーに従ってリソースをプロビジョニングしてください。 たとえば、適切な VM サイズを選択するときは、コストの制約、可用性ゾーンのオプションの範囲内で、アプリケーションの要件を満たすようにします。

一連のコマンドを記述する必要がある場合は、Azure CLI を使用します。 これらのコマンドは、さまざまな Azure サービスに対応しており、スクリプトを使用して自動化できます。 Azure CLI は、Windows と Linux でサポートされています。 別のクロスプラットフォーム オプションは Azure PowerShell です。 実際の選択は、優先スキルセットによって異なります。

スクリプトとテンプレート ファイルをソース管理システムに格納し、バージョン管理します。

ワークロードの CI/CD

ワークフローとデプロイのパイプラインには、アプリケーションを継続的に構築してデプロイする機能が必要です。 更新プログラムは、安全かつ迅速に展開され、問題が発生した場合はロールバックされる必要があります。

デプロイ戦略には、信頼性が高い自動化された継続的デリバリー (CD) パイプラインを含める必要があります。 ワークロード コンテナー イメージに対する変更は、クラスターに自動的にデプロイされる必要があります。

このアーキテクチャでは、ワークフローとデプロイを管理するために GitHub Actions を選択しました。 その他の一般的なオプションとして、Azure DevOps ServicesJenkins があります。

クラスターの CI/CD

ワークロードの CI/CD を示す図。

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

Kubectl のような命令型のアプローチを使用するのではなく、クラスターとリポジトリの変更を自動的に同期するツールを使用します。 運用環境にデプロイする前に、新しいバージョンのリリースやそのバージョンの検証などのワークフローを管理するには、GitOps フローを検討してください。

CI/CD フローの重要な部分は、新しくプロビジョニングされたクラスターのブートストラップです。 GitOps アプローチは、この最後に役立ちます。これにより、オペレーターは、ブートストラップ プロセスを IaC 戦略の一部として宣言によって定義し、クラスターに自動的に反映される構成を確認できます。

GitOps を使用する場合は、クラスターにエージェントをデプロイして、プライベート Git リポジトリに格納されている構成とクラスターの状態が確実に連携するようにします。 そのようなエージェントの 1 つが flux です。flux はクラスター内の 1 つ以上のオペレーターを使用して、Kubernetes の内部でデプロイをトリガーします。 Flux により、次のタスクが実行されます。

  • 構成されているすべてのリポジトリを監視する。
  • 新しい構成の変更を検出する。
  • デプロイをトリガーする。
  • それらの変更に基づいて、必要な実行中の構成を更新する。

また、それらの変更のデプロイ方法を制御するポリシーを設定することもできます。

GitOps と flux を使用してクラスター構成を自動化する方法を表す例をこちらに示します。

GitOps フローを示す図。

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

  1. 開発者は、git リポジトリに格納されている構成の YAML ファイルなどのソース コードに変更をコミットします。 次に変更が git サーバーにプッシュされます。

  2. Flux は、ワークロードと共にポッドで実行されます。 開発者が要求した変更のみが Flux によって適用されるようにするため、Flux から git リポジトリへのアクセスは読み取り専用です。

  3. Flux により、構成の変更が認識され、それらの変更が kubectl コマンドを使用して適用されます。

  4. 開発者が kubectl を使用して Kubernetes API に直接アクセスすることはできません。

  5. 使用している Git サーバーに分岐ポリシーを用意します。 そうすることで、複数の開発者が pull request を通じて変更を承認してから、運用環境に適用することができます。

GitOps と Flux は手動で構成できますが、AKS には Flux v2 クラスター拡張機能を備えた GitOps をお勧めします。

ワークロードとクラスターのデプロイ戦略

"任意の" 変更 (アーキテクチャのコンポーネント、ワークロード、クラスター構成) を少なくとも 1 つの運用前 AKS クラスターにデプロイします。 そうすることで、運用環境にデプロイする前に、変更によって問題が解消されるかどうかをシミュレートすることができます。

次に移る前に各ステージでテストや検証を実行することで、高度に制御された方法で更新プログラムを運用環境にプッシュし、予期しないデプロイの問題による中断を最小限に抑えることができます。 このデプロイは、同じ GitHub Actions パイプラインまたは Flux オペレーターを使用して、運用環境と同様のパターンに従っている必要があります。

ブルーグリーン デプロイ、A/B テスト、カナリア リリースなどの高度なデプロイ手法では、追加のプロセスが必要になります。追加のツールが必要になる可能性もあります。 Flagger は、高度なデプロイ シナリオを解決するのに役立つ、広く普及しているオープンソースのソリューションです。

コスト管理

まず、コスト最適化の設計チェックリストと、AKS 用 Well Architected Framework で概説されている推奨事項のリストを確認します。 Azure 料金計算ツールを使用して、アーキテクチャで使用するサービスのコストを見積もります。 その他のベスト プラクティスについては、Microsoft Azure Well-Architected Framework に関するページのコストの最適化に関するセクションに説明されています。

Kubernetes 固有のコンストラクトによる詳細なクラスター インフラストラクチャ コストの割り当てに対して、AKS コスト分析を有効にすることを検討してください。

AKS ベースライン リファレンス アーキテクチャ上の Windows コンテナーに含まれる、Windows ベースのワークロードに特有のコスト管理に関する考慮事項を確認するには、関連記事を参照してください。

プロビジョニング

  • Kubernetes クラスターのデプロイ、管理、操作では、AKS に関連するコストはありません。 コストに影響を与えるのは、クラスターによって消費される仮想マシン インスタンス、ストレージ、ログ データ、ネットワーク リソースです。 システム ノード プールには、より安価な VM を選択することを検討してください。 DS2_v2 SKU は、システム ノード プールの一般的な VM の種類です。

  • Dev/Test 環境と運用環境に同じ構成を使用しないでください。 運用環境のワークロードには、高可用性のための追加の要件があり、一般的にはより高価です。 この構成は、Dev/Test 環境では必要ありません。

  • 運用環境のワークロードについては、アップタイム SLA を追加します。 ただし、Dev/Test または試験的なワークロード向けに設計されたクラスターは、可用性を保証する必要がないため、節約になります。 たとえば、SLO で十分です。 また、ワークロードでサポートされている場合は、スポット VM を実行する専用のスポット ノード プールを使用することを検討してください。

    AKS ワークロード アーキテクチャの一部として Azure SQL Database または Azure App Service を含む非運用環境のワークロードの場合、サービスの割引を受けるには、Azure Dev/Test サブスクリプションの利用資格があるかどうかを確認します。

  • スケーリングのニーズを満たすために大き過ぎるクラスターを使用して始めるのはなく、最小ノード数でクラスターをプロビジョニングし、クラスター オートスケーラーで監視してサイズを決定できるようにします。

  • ポッドの要求と制限を設定して、Kubernetes によって高い密度でノード リソースを割り当てられるようにし、ハードウェアが容量の上限まで使用されるようにします。

  • クラスターで診断を有効にすると、コストが増加する可能性があります。

  • ワークロードが長期間にわたって存在すると予想される場合は、1 年間または 3 年間の予約仮想マシン インスタンスで契約し、ノード コストを削減することができます。 詳細については、「予約 VM」を参照してください。

  • ノード プールを作成するときにタグを使用します。 タグは、発生したコストを追跡するカスタム レポートを作成する場合に役立ちます。 タグによって、経費の合計を追跡し、特定のリソースまたはチームにコストをマップする機能が提供されます。 また、チーム間でクラスターを共有する場合は、コンシューマーごとにチャージバック レポートを作成して、共有クラウド サービスの従量制課金コストを特定します。 詳細については、「テイント、ラベル、またはタグをノード プールに指定する」を参照してください。

  • リージョンの可用性ゾーン間でのデータ転送は無料ではありません。 ワークロードが複数リージョンである場合、または可用性ゾーン間で転送される場合は、追加の帯域幅コストが予想されます。 詳細については、「課金ゾーンとリージョンをまたぐトラフィック」を参照してください。

  • 組織によって特定されたコスト制約内に収まるように、予算を作成します。 1 つの方法は、Azure Cost Management を使用して予算を作成することです。 また、アラートを作成して、特定のしきい値を超えたときに通知を受け取ることもできます。 詳細については、「テンプレートを使用して予算を作成する」を参照してください。

モニター

クラスター全体のコストを監視するために、コンピューティング コストに加えて、ストレージ、帯域幅、ファイアウォール、ログに関するコスト情報も収集します。 Azure には、コストを監視および分析するためのさまざまなダッシュボードが用意されています。

理想的には、リアルタイムで、または少なくとも定期的な周期でコストを監視し、コストの計算が既に終わっている月末になる前にアクションを実行します。 また、時間の経過に伴う月ごとの傾向を監視して、予算内に収まるようにします。

データに基づく意思決定を行うには、最もコストがかかるリソース (詳細レベル) を特定します。 また、各リソースの使用量を計算するために使用されるメーターについてもよく理解しておいてください。 メトリックを分析することで、プラットフォームがインスタンスに対して過剰なサイズであるかどうかを判断できます。 Azure Monitor メトリックに使用量メーターが表示されます。

最適化

Azure Advisor によって提供されるレコメンデーションに基づいて対応します。 その他の最適化方法もあります。

  • ノード プール内の使用率が低いノードを検出して削除するには、クラスター オートスケーラーを有効にします。

  • ノード プール用には低めの SKU を選択します (ワークロードでサポートされている場合)。

  • アプリケーションでバースト スケーリングを必要としない場合は、パフォーマンス メトリックの経時変化を分析することで、クラスターのサイズを適切なサイズに変更することを検討してください。

  • ワークロードでサポートされている場合は、実行が想定されていないユーザー ノード プールを 0 ノードにスケーリングします。 さらに、クラスターで実行されるようスケジュールされているワークロードがない場合は、AKS の開始/停止機能を使用して、システム ノード プールと AKS コントロール プレーンを含むすべてのコンピューティングをシャットダウンすることを検討してください。

その他のコスト関連情報については、AKS の価格に関するページを参照してください。

次のステップ

AKS ベースライン アーキテクチャについて学習を続けます。

AKS の詳細情報

次の関連ガイドを参照してください。

次の関連するアーキテクチャを参照してください。