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

Application Gateway
Container Registry
ファイアウォール
Kubernetes Service
Azure ロールベースのアクセス制御

このリファレンス アーキテクチャでは、Azure Kubernetes Service (AKS) クラスターをデプロイするベースライン インフラストラクチャを構築します。 この記事には、組織のビジネス要件に基づいたクラスターのネットワーク、セキュリティ、ID、管理、監視に関する推奨事項が記載されています。

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

注意

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

ネットワーク トポロジ

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

  • 分離された管理。 これにより、ガバナンスを適用し、影響範囲を制御することができます。 また、職務の分離によって、ランディング ゾーンの概念もサポートします。

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

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

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

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

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

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

Hub-spoke network topology

ハブ

ハブ仮想ネットワークは、接続性と監視の中心点です。 そのネットワーク内に 3 つのサブネットがデプロイされます。

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

Azure Firewall は、サービスとしてのファイアウォールです。 そのファイアウォールのインスタンスでは、送信ネットワーク トラフィックがセキュリティで保護されます。 このセキュリティ レイヤーがないと、フローと悪意のあるサードパーティ サービスが通信することで、会社の機密データが抜き取られる可能性があります。

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

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

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

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

スポーク

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

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

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

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

トラフィックのルーティングと分散を行うために、Traefik は Kubernetes イングレス リソースを満たすイングレス コントローラーです。 このサブネットには、Azure 内部ロード バランサーが存在します。

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

AKS には、2 つの異なるノード グループ (またはノード プール) が保持されています。 "システム ノード プール" では、コア クラスター サービスを実行するポッドをホストします。 "ユーザー ノード プール" では、ワークロードへの受信方向の通信を容易にするために、Contoso のワークロードとイングレス コントローラーを実行します。 ワークロードは、単純な ASP.NET アプリケーションです。

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

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

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

IP アドレスの計画

Network topology of the AKS cluster

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

  • アップグレード

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

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

  • スケーラビリティ

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

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

  • Azure Private Link アドレス

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

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

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

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

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

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

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

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

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

  • パブリック イメージを使用している場合は、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 の制約に基づいてこの値を調整します。

クラスターのための Azure Active Directory の統合

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

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

Azure への AKS アクセス

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

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

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

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

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

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

クラスターへのアクセス

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

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

Kubernetes RBAC を Azure Active Directory に関連付ける

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

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

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

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

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

Kubernetes 認可に Azure RBAC を使用する

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

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

ローカル アカウント

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

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

ワークロードのための Azure Active Directory の統合

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

このリファレンス実装では、マネージド ポッド ID は Azure AD pod identity によって容易になります。

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

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 を Azure AD ポッド マネージド ID および Azure Key Vault と統合する方法を示しています。

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

ルーター設定

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

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

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: /
        backend:
          service:
            name: aspnetapp-service
            port: 
              name: http

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

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

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

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

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

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

Cluster traffic flow

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

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

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

TLS termination

  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 終端を行う場所が決まります。

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

ゼロトラスト制御とトラフィックを検査する機能については、クラスターからのすべてのエグレス トラフィックが Azure Firewall 経由で移動します。 この選択は、ユーザー定義ルート (UDR) を使用して実装できます。 ルートの次のホップは、Azure Firewall のプライベート IP アドレスです。 ここで、エグレス トラフィックをブロックするか許可するかが、Azure Firewall によって決定されます。 この決定は、Azure Firewall または組み込みの脅威インテリジェンス規則に定義された特定の規則に基づいて決定されます。

注意

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

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

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

ポッド間トラフィック

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

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

詳細については、「Azure と Calico のポリシーとその機能の相違点」を参照してください。

注意

AKS では、kubernet と Azure Container Network Interface (CNI) というネットワーク モデルがサポートされています。 2 つのモデルのうち CNI の方が高度であり、これは、Azure ネットワーク ポリシーを有効にするために必要です。 このモデルでは、すべてのポッドがサブネットのアドレス空間から IP アドレスを取得します。 それらの IP アドレスを使用して、同じネットワーク内のリソース (またはピアリングされたリソース) からポッドに直接アクセスできます。 そのトラフィックをルーティングするために NAT は必要ありません。 したがって、追加のネットワーク オーバーレイがないため、CNI はパフォーマンスに優れています。 また、Azure ネットワーク ポリシーを使用できるようになるため、セキュリティ制御も強化されます。 一般に、CNI をお勧めします。 CNI では、チームとそれらが制御するリソースによってきめ細かい制御が提供されます。 また、CNI では kubernet よりもスケーリングされたポッドが可能になります。 慎重に検討して選択してください。そうしないと、クラスターの再デプロイが必要になります。 モデルの詳細については、「ネットワーク モデルを比較する」を参照してください。

管理トラフィック

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

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

シークレット管理の追加

Azure Key Vault などの管理されたキー ストアにシークレットを格納します。 その利点は、マネージド ストアでシークレットのローテーションが処理されること、強力な暗号化が提供されること、アクセス監査ログが提供されること、デプロイ パイプラインからコア シークレットが切り離されることです。

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

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

ポッドから特定のストアにあるシークレットにアクセスできるようにするには、ポッド マネージド 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 によって処理され、すべてのポリシー チェックはログされます。 ポリシーの変更は、クラスター内に即座に反映されません。 多少の遅れが予想されます。

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

  • ポリシーのコレクション (イニシアティブと呼ばれる) を設定するか、個々のポリシーを選択するか: 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 ポッドのログにアクセスします。

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

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 です。

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

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

クラスター ノード

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

アプリケーションを別のノード プールに配置してシステム サービスから分離します。 このように、Kubernetes サービスは専用ノードで実行され、ワークロードと競合しません。 ワークロードをスケジューリングするノード プールを識別するために、タグ、ラベル、テイントを使用することをお勧めします。

信頼性を確保するには、クラスターの定期的な保守 (タイムリーな更新など) が不可欠です。 また、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 レプリケーションが有効になっています。 リージョンがダウンした場合でも、レプリケートされたリージョンから引き続きイメージをプルできます。

Kubernetes API サーバーのアップタイム SLA

AKS は無料のサービスとして使用できますが、そのレベルでは、金銭的な補償を伴う SLA は提供されません。 そのような SLA を取得するには、購入内容にアップタイム SLA を追加することを選択する必要があります。 すべての運用クラスターでこのオプションを使用することをお勧めします。 このオプションを使用していないクラスターを運用前のクラスター用に用意します。 Azure Availability Zones と組み合わせると、Kubernetes API サーバーの SLA は 99.95% に向上します。 ノード プールとその他のリソースは、それぞれ専用の SLA の対象になっています。

トレードオフ

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

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

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

ノードの停止、ゾーン障害をシミュレートする特定のゾーン内の全 AKS リソースの停止、外部依存関係の停止などで障害をシミュレートして強制フェールオーバーをテストすることによって、信頼性を確保します。

メトリックの監視と収集

Azure Monitor Container insights 機能はイベントをリアルタイムで表示できるため、監視とログ記録に推奨されるツールです。 実行中のポッドからコンテナー ログをキャプチャし、集計して表示できます。 また、メトリック API からメモリと CPU 使用率に関する情報を収集して、実行中のリソースとワークロードの正常性を監視します。 これを使用して、ポッド スケールとしてパフォーマンスを監視することができます。 もう 1 つの利点は、Azure portal を使用してグラフやダッシュボードを簡単に構成できることです。 Automation Runbook、Azure Functions などをトリガーするアラートを作成する機能があります。

ポッドでホストされているほとんどのワークロードからは、Prometheus メトリックが出力されます。 Azure Monitor は、Prometheus のメトリックをスクレイピングして視覚化することができます。

Kubernetes に統合されたサードパーティのユーティリティがいくつかあります。 組織で既に使用している場合は、Grafana や Datadog などのログおよびメトリック プラットフォームを活用します。

Azure では、いくつかのコア Kubernetes サービスが AKS を使用して管理されます。 それらのサービスのログは、カスタマー サポートからの要求に従って有効にする必要があります。 ただし、次のログ ソースはクラスターに関する問題のトラブルシューティングに役立つので、有効にすることをお勧めします。

  • ClusterAutoscaler のログ記録 (スケーリング操作を監視するため)。 詳細については、「クラスター オートスケーラーのログと状態を取得する」を参照してください。
  • KubeControllerManager (ポッド スケジューラを監視するため)。
  • KubeAuditAdmin (クラスターを変更するアクティビティを監視するため)。

自己復旧を有効にする

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

注意

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 のサブネットはハブ内です。

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

コードとしてのインフラストラクチャ (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

Workload CI/CD

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

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

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

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

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

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

GitOps Flow

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

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

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

  4. 開発者が kubectl を使用して Kubernetes API に直接アクセスすることはできません。 使用している git サーバーに分岐ポリシーを用意します。 そうすることで、複数の開発者が変更を承認してから、運用環境に適用することができます。

GitOps と flux は手動で構成することができますが、 Flux v2 クラスター拡張機能を使用した GitOps では、このプロセスが簡単に行えるので、多くの追加の利点が提供されます。特に、プロビジョニングされたクラスターとブートストラップされたクラスターの間のギャップが大幅に減少します。 その統一性と大規模なメンテナンスの容易さにより、これは、フリートと呼ばれる多数のクラスターを担当するチームに推奨される方法です。

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

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

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

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

コスト管理

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

プロビジョニング

  • Kubernetes クラスターのデプロイ、管理、操作には、AKS に関連するコストはありません。 主なコスト要因は、クラスターによって使用される仮想マシン インスタンス、ストレージ、およびネットワーク リソースです。 システム ノード プールには、より安価な VM を選択することを検討してください。 推奨される SKU は DS2_v2 です。

  • 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 の価格に関するページを参照してください。

次の手順

Kubernetes について復習したい場合は、Microsoft Learn の学習パスで「Kubernetes の概要」と「Kubernetes でのアプリケーションの開発とデプロイ」を完了してください。