高度な Azure Kubernetes Service (AKS) マイクロサービスアーキテクチャ

Azure Application Gateway

Azure Container Registry

Azure Kubernetes Service (AKS)

Azure Virtual Network

この参照アーキテクチャでは、Azure Kubernetes Service (AKS) でマイクロサービスを実行するときに考慮すべきいくつかの構成について説明します。この記事では、マイクロサービスベースのアプリケーション全体で、ネットワークポリシーの構成、ポッドの自動スケーリング、および分散トレースについて説明します。

このアーキテクチャは、AKS インフラストラクチャの開始点として Microsoft が推奨する AKS ベースラインアーキテクチャに基づいています。 AKS ベースラインでは、Microsoft Entra ワークロード ID、イングレスとエグレスの制限、リソース制限、その他のセキュリティで保護された AKS インフラストラクチャ構成などのインフラストラクチャ機能について説明します。これらの機能については、この記事では説明しません。マイクロサービスのコンテンツに進む前に、AKS ベースラインアーキテクチャを理解することをお勧めします。

GitHub ロゴこのアーキテクチャのリファレンス実装は、GitHub で入手できます。

アーキテクチャ

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

AKS でのより基本的なマイクロサービスの例から始める場合は、 AKS のマイクロサービスアーキテクチャを参照してください。

Workflow

この要求フローでは、パブリッシャー/サブスクライバー、競合コンシューマー、およびゲートウェイルーティングのクラウド設計パターンが実装されます。次のワークフローは、上記のダイアグラムに対応しています。

ドローンによる集荷をスケジュールするための HTTPS 要求が送信されます。要求は Azure Application Gateway を介してインジェスト Web アプリケーションに渡されます。これは、AKS のクラスター内マイクロサービスとして実行されます。
インジェスト Web アプリケーションによってメッセージが生成され、Azure Service Bus メッセージキューに送信されます。
バックエンドシステムはドローンを割り当て、ユーザーに通知します。ワークフローマイクロサービスは、次のタスクを実行します。
- Service Bus メッセージキューからメッセージ情報を使用します
- HTTPS 要求を配信マイクロサービスに送信し、Azure Cache for Redis 外部データストレージにデータを渡します
- ドローンスケジューラマイクロサービスに HTTPS 要求を送信する
- MongoDB 外部データストレージにデータを渡す HTTPS 要求をパッケージマイクロサービスに送信します
このアーキテクチャでは、HTTPS GET 要求を使用して配信状態を返します。この要求は、Application Gateway を介して配信マイクロサービスに渡されます。
配信マイクロサービスでは、Azure Cache for Redis からデータを読み取ります。

コンポーネント

AKS では、マネージド Kubernetes クラスターが提供されます。 AKS を使用すると、Azure によって Kubernetes API サーバーが管理されます。クラスターオペレーターは、Kubernetes ノードまたはノードプールにアクセスして管理できます。

このアーキテクチャでは、次の AKS インフラストラクチャ機能が使用されます。
Azure Virtual Network は、仮想マシン (VM) とアプリケーションを実行するための分離された高度にセキュリティで保護された環境を提供します。この参照アーキテクチャでは、ピアリングされたハブスポーク仮想ネットワークトポロジを使用します。ハブ仮想ネットワークは、Azure Firewall サブネットと Azure Bastion サブネットをホストします。スポーク仮想ネットワークには、AKS システムとユーザーノードプールのサブネットと Application Gateway サブネットが含まれています。
Azure Private Link は 、Microsoft バックボーンネットワーク経由で Azure Container Registry と Azure Key Vault にアクセスするために、特定のプライベート IP アドレスを割り当てます。 Container Registry や Key Vault などのサービスとしてのプラットフォームソリューションには、AKS システムとユーザーノードプールのサブネットからプライベートエンドポイントを介してアクセスします。
Web アプリケーションファイアウォール (WAF) を使用する Application Gateway は、Web アプリケーションへの Web トラフィックの負荷分散を行います。このアーキテクチャでは、Application Gateway は、インジェストマイクロサービスをパブリックエンドポイントとして公開します。
Azure Firewall は、クラウドネイティブでインテリジェントなネットワークファイアウォールセキュリティサービスであり、Azure クラウドワークロードに対する脅威保護を提供します。このファイアウォールでは、承認されたサービスと完全修飾ドメイン名 (FQDN) のみをエグレストラフィックとして許可します。このアーキテクチャでは、Azure Firewall は、マイクロサービスから仮想ネットワーク外のリソースへの送信通信を制御します。

外部ストレージとその他のコンポーネント

Key Vault は 、Azure サービスのセキュリティキー、シークレット値、証明書を格納および管理します。このアーキテクチャでは、Azure Key Vault には Azure Cosmos DB と Azure Cache for Redis の資格情報が格納されます。
Container Registry には、AKS クラスターで実行できるプライベートコンテナーイメージが格納されます。 AKS は、Microsoft Entra マネージド ID を使用して Container Registry で認証します。 Docker Hub などの他のコンテナーレジストリも使用できます。このアーキテクチャでは、Container Registry によってマイクロサービス用のコンテナーイメージが格納されます。
Azure Cosmos DB は、フルマネージドの NoSQL、リレーショナル、ベクターデータベースです。マイクロサービスは通常ステートレスであり、その状態は外部データストアに書き込まれます。 Azure Cosmos DB には、MongoDB、PostgreSQL、Cassandra 用のオープンソース API があります。このアーキテクチャでは、Azure Cosmos DB と Azure Cosmos DB for MongoDB は、各マイクロサービスのデータストアとして機能します。
Service Bus は、サービスとしての信頼性の高いクラウドメッセージングとシンプルなハイブリッド統合を提供します。 Service Bus では、マイクロサービスアプリケーションで一般的な非同期メッセージングパターンがサポートされています。このアーキテクチャでは、Service Bus はインジェストマイクロサービスとワークフローマイクロサービスの間の非同期キューレイヤーとして機能します。
Azure Cache for Redis は、トラフィックの多い負荷に対する速度とパフォーマンスを向上させるために、アプリケーションアーキテクチャにキャッシュレイヤーを追加します。このアーキテクチャでは、配信マイクロサービスは、状態ストアとサイドキャッシュとして Azure Cache for Redis を使用します。
Azure Monitor では、アプリケーションテレメトリや Azure プラットフォームおよびサービスのメトリックなど、メトリックとログが収集されて格納されます。このアーキテクチャでは、このデータを使用して、アプリケーションの監視、アラートとダッシュボードの設定、エラーの根本原因分析の実行を行うことができます。

その他の操作でシステムコンポーネントがサポートされる

Helm は Kubernetes のパッケージマネージャーであり、Kubernetes オブジェクトを 1 つのユニットにバンドルし、発行、デプロイ、バージョン管理、更新を行うことができます。このアーキテクチャでは、Helm コマンドを使用してマイクロサービスをパッケージ化し、AKS クラスターにデプロイします。
Key Vault シークレットストア CSI ドライバープロバイダー シークレットストア CSI ドライバーの Key Vault プロバイダーを使用すると、 CSI ボリュームを介して、シークレットストアとしてキーコンテナーを AKS クラスターと統合できます。このアーキテクチャでは、キーコンテナーシークレットがマイクロサービスコンテナーのボリュームとしてマウントされるため、マイクロサービスは Azure Cosmos DB、Azure Cache for Redis、Service Bus の資格情報を取得できます。
Flux は、 AKS で GitOps を有効にする Kubernetes 向けのオープンで拡張可能な継続的デリバリーソリューションです。

選択肢

アプリケーションルーティングアドオンを使用する代わりに、 Application Gateway for Containers や Istio ゲートウェイアドオンなどの代替手段を使用できます。 AKS のイングレスオプションの比較については、「 AKS のイングレス」を参照してください。 Application Gateway for Containers は Application Gateway イングレスコントローラーの進化であり、トラフィックの分割や重み付けラウンドロビン負荷分散などの追加機能を提供します。

Flux v2 の代わりに GitOps ツールとして ArgoCD を使用できます。 Flux v2 と ArgoCD はどちらもクラスター拡張機能として使用できます。

Azure Cosmos DB と Azure Cache for Redis の資格情報をキーコンテナーに格納する代わりに、パスワードなしの認証メカニズムの方が安全であるため、マネージド ID を使用して認証することをお勧めします。詳細については、「マネージド ID を使用して Azure VM から Azure Cosmos DB に接続し、 Microsoft Entra ID を使用して Service Bus リソースにアクセスしてマネージド ID を認証する」を参照してください。 Azure Cache for Redis では、マネージド ID を使用した認証もサポートされています。

シナリオの詳細

前の図に示した Fabrikam ドローン配送配送アプリの例は、この記事で説明するアーキテクチャコンポーネントとプラクティスを実装しています。この例では、架空の会社である Fabrikam, Inc. が複数のドローンを管理しています。企業がサービスに登録すると、ユーザーは、ドローンで商品を集荷して配送するように依頼できます。顧客が集荷をスケジュールすると、バックエンドシステムはドローンを割り当て、推定配送時間をユーザーに通知します。配送の進行中、顧客はドローンの場所を追跡し、継続的に更新された推定到着時間を確認できます。

推奨事項

次の推奨事項は、ほとんどのシナリオに適用できます。これらの推奨事項には、オーバーライドする特定の要件がない限り、従ってください。

アプリケーションルーティングアドオンを使用したマネージド NGINX イングレス

API ゲートウェイルーティングは、一般的なマイクロサービスの設計パターンです。 API ゲートウェイは、クライアントからマイクロサービスに要求をルーティングするリバースプロキシとして機能します。 Kubernetes イングレス リソースと イングレスコントローラー は、次のアクションを実行して、ほとんどの API ゲートウェイ機能を処理します。

クライアント要求を適切なバックエンドサービスにルーティングして、クライアントに単一のエンドポイントを提供し、クライアントをサービスから切り離すのに役立ちます
クライアントとバックエンドの間のチャットを減らすために、複数の要求を 1 つの要求に集約する
Secure Sockets Layer (SSL) の終了、認証、IP アドレス制限、バックエンドサービスからのクライアントレート制限や調整などの機能のオフロード

イングレスコントローラーは、AKS クラスターへのトラフィックインジェストを簡素化し、安全性とパフォーマンスを向上させ、リソースを節約します。このアーキテクチャでは、イングレス制御用のアプリケーションルーティングアドオンと共にマネージド NGINX イングレスを使用します。

内部 (プライベート) IP アドレスと内部ロードバランサーでイングレスコントローラーを使用し、マイクロサービスのホスト名解決のために Azure プライベートドメインネームシステムゾーンに統合することをお勧めします。 Application Gateway のバックエンドプールアドレスとして、イングレスコントローラーのプライベート IP アドレスまたはホスト名を構成します。 Application Gateway は、パブリックエンドポイントでトラフィックを受信し、WAF 検査を実行し、トラフィックをイングレスプライベート IP アドレスにルーティングします。

トラフィックがエンドツーエンドで暗号化されるように、カスタムドメイン名と SSL 証明書を使用してイングレスコントローラーを構成する必要があります。 Application Gateway は、HTTPS リスナーでトラフィックを受信します。 WAF 検査の後、Application Gateway はイングレスコントローラーの HTTPS エンドポイントにトラフィックをルーティングします。 AKS クラスター内のマイクロサービス間通信も SSL を使用してセキュリティで保護されるように、すべてのマイクロサービスをカスタムドメイン名と SSL 証明書で構成する必要があります。

マルチテナントワークロードまたは開発環境とテスト環境をサポートする単一のクラスターでは、より多くのイングレスコントローラーが必要になる場合があります。アプリケーションルーティングアドオンは、同じ AKS クラスター内の複数のイングレスコントローラーや、注釈を使用してイングレスリソースを構成するなど、高度な構成とカスタマイズをサポートしています。

ゼロトラストネットワークポリシー

ネットワークポリシーでは、AKS ポッドが相互に通信する方法、および他のネットワークエンドポイントと通信する方法が指定されます。既定では、すべてのイングレスおよびエグレストラフィックがポッドとの間で許可されます。マイクロサービスが互いに、また他のエンドポイントと通信する方法を設計する場合は、サービス、デバイス、アプリケーション、またはデータリポジトリへのアクセスに明示的な構成が必要な ゼロトラスト原則に従ってください。

ゼロトラストポリシーを実装する方法の 1 つは、ターゲット名前空間内のすべてのポッドへのすべてのイングレスおよびエグレストラフィックを拒否するネットワークポリシーを作成することです。次の例は、名前空間にあるすべてのポッドに適用されるすべてのポリシーをbackend-devする方法を示しています。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend-dev
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

制限付きポリシーが適用されたら、マイクロサービス内の各ポッドとの間で送受信されるトラフィックを許可する特定のネットワークルールの定義を開始します。次の例では、ネットワークポリシーは、backend-devに一致するラベルを持つapp.kubernetes.io/component: backend名前空間内の任意のポッドに適用されます。ポリシーは、 app.kubernetes.io/part-of: dronedeliveryに一致するラベルを持つポッドから送信されない限り、トラフィックを拒否します。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app.kubernetes.io/part-of: dronedelivery
    ports:
    - port: 80
      protocol: TCP

Kubernetes ネットワークポリシーの詳細と、既定のポリシーの例については、 Kubernetes ドキュメントのネットワークポリシーを参照してください。

Azure には、ネットワークポリシーを適用するための 3 つのネットワークポリシーエンジンが用意されています。

Cilium を使用する Azure CNI を使用する AKS クラスターの Cilium
Azure ネットワークポリシーマネージャー
オープンソースのネットワークとネットワークセキュリティソリューションである Calico

ネットワークポリシーエンジンとして Cilium を使用することをお勧めします。

リソースクォータ

管理者は、リソースクォータを使用して、開発チームまたはプロジェクト全体のリソースを予約および制限します。名前空間にリソースクォータを設定し、それらを使用して次のリソースに制限を設定できます。

CPU やメモリ、GPU などのコンピューティングリソース
ストレージリソース (特定のストレージクラスのボリューム数またはディスク領域の量を含む)
作成できるシークレット、サービス、ジョブの最大数など、オブジェクトの数

リソース要求または制限の累積合計が割り当てられたクォータを超えた後、それ以上のデプロイは成功しません。

リソースクォータを使用すると、名前空間に割り当てられた一連のポッドの合計が名前空間のリソースクォータを超えないようにすることができます。フロントエンドでバックエンドサービスのすべてのリソースを使用することはできません。また、バックエンドがフロントエンドサービスのすべてのリソースを使用することはできません。

リソースクォータを定義するときは、名前空間内で作成されるすべてのポッドのポッド仕様で、制限または要求を指定する必要があります。これらの値が指定されていない場合、デプロイが拒否されます。

次の例は、リソースクォータの要求と制限を設定するポッドの仕様を示しています。

requests:
  cpu: 100m
  memory: 350Mi
limits:
  cpu: 200m
  memory: 500Mi

リソースクォータの詳細については、以下を参照してください。

自動スケール

Kubernetes では、デプロイに割り当てられたポッドの数を増やしたり、クラスター内のノードを増やして使用可能なコンピューティングリソースの合計を増やしたりするための 自動スケーリング がサポートされています。自動スケールは、自己修正型の自律的フィードバックシステムです。ポッドとノードは手動でスケーリングできますが、自動スケーリングにより、高負荷時にサービスがリソース制限に達する可能性が最小限に抑えられます。自動スケーリング戦略では、ポッドとノードの両方を考慮する必要があります。

クラスターの自動スケール

クラスターオートスケーラー (CA) は、ノードの数をスケーリングします。リソースの制約のためにポッドをスケジュールできない場合は、クラスターオートスケーラーによってさらに多くのノードがプロビジョニングされます。 AKS クラスターとワークロードの稼働を維持する最小数のノードと、トラフィックの負荷が多い場合の最大数のノードを定義します。 CA は、保留中のポッドまたは空のノードを数秒ごとにチェックし、AKS クラスターを適切にスケーリングします。

次の例は、Bicep テンプレートからの CA 構成を示しています。

autoScalerProfile: {
  'scan-interval': '10s'
  'scale-down-delay-after-add': '10m'
  'scale-down-delay-after-delete': '20s'
  'scale-down-delay-after-failure': '3m'
  'scale-down-unneeded-time': '10m'
  'scale-down-unready-time': '20m'
  'scale-down-utilization-threshold': '0.5'
  'max-graceful-termination-sec': '600'
  'balance-similar-node-groups': 'false'
  expander: 'random'
  'skip-nodes-with-local-storage': 'true'
  'skip-nodes-with-system-pods': 'true'
  'max-empty-bulk-delete': '10'
  'max-total-unready-percentage': '45'
  'ok-total-unready-count': '3'
}

Bicep テンプレートの次の行は、クラスターオートスケーラーの最小ノードと最大ノードの例を設定します。

minCount: 2
maxCount: 5

水平ポッドの自動スケーリング

ポッドの水平オートスケーラー (HPA) は、観察された CPU、メモリ、またはカスタムメトリックに基づいてポッドをスケーリングします。ポッドの水平スケーリングを構成するには、ターゲットメトリックと、Kubernetes デプロイポッド仕様でレプリカの最小数と最大数を指定します。サービスをロードテストして、これらの数値を特定します。

CA と HPA が連携するため、AKS クラスターで両方の自動スケーラーオプションを有効にします。 HPA によりアプリケーションがスケーリングされ、CA によりインフラストラクチャがスケーリングされます。

次の例では、HPA のリソースメトリックを設定します。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: delivery-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: delivery
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

HPA は、ポッドの実行中に消費された実際のリソースまたはその他のメトリックを確認します。 CA は、まだスケジュールされていないポッドのノードをプロビジョニングします。その結果、CA はポッド仕様で指定されているように、要求されたリソースを確認します。ロードテストを使用して、これらの値を微調整します。

詳細については、「 AKS でのアプリケーションのスケーリングオプション」を参照してください。

ポッドの垂直自動スケーリング

Vertical Pod Autoscaler (VPA) は、ワークロードの使用パターンに合わせてポッドの CPU 要求とメモリ要求を自動的に調整します。 VPA が構成されると、過去の使用状況に基づいて、各ワークロードのコンテナーに対するリソース要求と制限が自動的に設定されます。 VPA を使用すると、他のポッドで CPU とメモリを使用できるようになり、AKS クラスターの効果的な使用率を確保するのに役立ちます。

このアーキテクチャでは、VPA は、過去の使用量に基づいて、マイクロサービスの CPU 要求とメモリ要求と制限を増やします。たとえば、ワークフローマイクロサービスが他のマイクロサービスと比較して CPU を消費する場合、VPA はこの使用状況を監視し、ワークフローマイクロサービスの CPU 制限を増やすことができます。

Kubernetes イベントドリブン自動スケーリング

Kubernetes Event Driven Autoscaler (KEDA) アドオンを使用すると、イベントドリブン自動スケーリングを使用してマイクロサービスをスケーリングし、持続可能でコスト効率の高い方法で需要を満たすことができます。たとえば、SERVICE Bus キュー内のメッセージの数が特定のしきい値を超えた場合、KEDA はマイクロサービスをスケールアップできます。

Fabrikam ドローン配信の例では、KEDA は Service Bus キューの深さに応じて、およびインジェストマイクロサービスの出力に基づいてワークフローマイクロサービスをスケールアウトします。 Azure サービスの KEDA スケーラーの一覧については、 AKS での KEDA との統合に関するページを参照してください。

正常性プローブ

Kubernetes は、サービスのラベルセレクターに一致するポッドへのトラフィックを負荷分散します。正常に起動され、正常な状態にあるポッドのみがトラフィックを受信します。コンテナーがクラッシュした場合、Kubernetes はポッドを削除し、置き換えをスケジュールします。

Kubernetes は、ポッドが公開できる 3 種類の正常性プローブを定義します。

準備プローブは、ポッドが要求を受け入れる準備ができているかどうかを Kubernetes に通知します。
liveness プローブは、ポッドを削除して新しいインスタンスを開始するかどうかを Kubernetes に通知します。
スタートアッププローブは、ポッドが起動されているかどうかを Kubernetes に通知します。

liveness probe は、まだ実行中だが、異常があるためリサイクルする必要があるポッドを処理します。たとえば、HTTP 要求を処理しているコンテナーがハングした場合、コンテナーはクラッシュしませんが、要求の処理を停止します。 HTTP ライブネスプローブは応答を停止し、ポッドを再起動するように Kubernetes に警告します。

ポッドが正常に起動されたにもかかわらず、そのポッドがトラフィックを受信する準備ができていない場合があります。たとえば、コンテナーで実行されているアプリケーションが初期化タスクを実行している可能性があります。 readiness probe は、ポッドがトラフィックを受信する準備ができているかどうかを示します。

マイクロサービスは、正常性プローブを容易にするコード内のエンドポイントを公開する必要があります。遅延とタイムアウトは、実行するチェック専用に調整されます。 HPA 式はポッドの準備フェーズに依存するため、正常性プローブが存在し、正確である必要があります。

監視

マイクロサービスアプリケーションでは、異常の検出、問題の診断、サービス間の依存関係の迅速な理解のために、アプリケーションパフォーマンス管理 (APM) の監視が不可欠です。 Azure Monitor の機能である Application Insights は、.NET Core、Node.js、Java、およびその他の多くのアプリケーション言語で記述されたライブアプリケーションの APM 監視を提供します。

Azure には、マイクロサービスワークロードを監視するためのさまざまなメカニズムが用意されています。

メトリック収集のための Managed Prometheus。 Prometheus を使用して、インフラストラクチャとワークロードのパフォーマンスを監視およびアラートします。
Prometheus とコンテナー分析情報用の Azure Monitor マネージドサービスは連携して、Kubernetes 環境を完全に監視します。
クラスターとマイクロサービスの視覚化のためのマネージド Grafana。

Kubernetes でサービステレメトリをコンテキスト化するには、Azure Monitor テレメトリを AKS と統合して、コントローラー、ノード、コンテナー、コンテナー、およびノードログからメトリックを収集します。コードを変更することなく、Application Insights と AKS を統合できます。

考慮事項

これらの考慮事項では、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。詳細については、「 Well-Architected Framework」を参照してください。

セキュリティ

セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。詳細については、「セキュリティ設計レビューチェックリスト」を参照してください。

セキュリティを計画するときは、次の点を考慮してください。

AKS クラスターでデプロイセーフガードを使用します。デプロイセーフガードは、Azure Policy コントロールを使用して AKS クラスターに Kubernetes のベストプラクティスを適用します。
セキュリティスキャンをマイクロサービスのビルドおよびデプロイパイプラインに統合します。 Microsoft Defender for Cloud DevOps セキュリティを使用して DevOps 環境を管理します。継続的インテグレーションおよび継続的デプロイ (CI/CD) パイプラインの一部として、エージェントレスコードスキャンを使用し、静的コード分析ツールを実行して、ビルドおよびデプロイプロセスの一部としてマイクロサービスコードの脆弱性を特定して対処できるようにします。
AKS ポッドは、Microsoft Entra ID に格納されている ワークロード ID を 使用して自身を認証します。ワークロード ID はクライアントシークレットを必要としないため、使用する必要があります。
マネージド ID を使用すると、アプリケーションは実行時に Azure Resource Manager OAuth 2.0 トークンをすばやく取得できます。パスワードや接続文字列は必要ありません。 AKS では、ワークロード ID を使用して個々のポッドに ID を割り当てることができます。
マイクロサービスアプリケーションの各サービスには、最小特権の RBAC 割り当てを支援するための一意のワークロード ID を割り当てる必要があります。 ID は、それを必要とするサービスにのみ割り当てる必要があります。
アプリケーションコンポーネントで Kubernetes API アクセスが必要な場合、API アクセスが適切にスコープ設定されたサービスアカウントを使用するようにアプリケーションポッドが構成されていることを確認します。詳細については、「 Kubernetes サービスアカウントの管理」を参照してください。
すべての Azure サービスで、データプレーン認証に Microsoft Entra ID の使用がサポートされているわけではありません。これらのサービス、Microsoft 以外のサービス、または API キーの資格情報またはアプリケーションシークレットを格納するには、Key Vault を使用します。 Key Vault は、一元管理、アクセス制御、保存時の暗号化、すべてのキーとシークレットの監査を提供します。
AKS では、1 つ以上のシークレットを Key Vault からボリュームとしてマウントできます。ポッドはその後、これらの Key Vault シークレットを通常のボリュームと同様に読み取ることができます。詳細については、「 AKS クラスター内のシークレットストア CSI ドライバーに Key Vault プロバイダーを使用する」を参照してください。マイクロサービスごとに個別のキーコンテナーを保持することをお勧めします。参照実装では、マイクロサービスごとに個別のキーコンテナーが使用されます。
マイクロサービスがクラスターの外部にある外部 URL などのリソースと通信する必要がある場合は、Azure Firewall 経由でアクセスを制御します。マイクロサービスが送信呼び出しを行う必要がない場合は、ネットワーク分離クラスターを使用します。
Microsoft Defender for Containers を有効にして、セキュリティ体制管理、マイクロサービスの脆弱性評価、実行時の脅威保護、およびその他のセキュリティ機能を提供します。

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。詳細については、「コストの最適化設計レビューチェックリスト」を参照してください。

Well-Architected フレームワークの [コストの最適化] セクションでは、コストに関する考慮事項について説明します。
具体的なシナリオのコストを見積もるには、Azure 料金計算ツールを使用します。
Free レベルでは、AKS には Kubernetes クラスターのデプロイ、管理、および操作に関連するコストはありません。料金は、クラスターが使用する VM インスタンス、ストレージ、およびネットワークリソースに対してのみ行います。クラスターの自動スケールでは、空または未使用のノードを削除することで、クラスターのコストを大幅に削減できます。
開発ワークロードには AKS の Free レベルを使用し、運用環境のワークロードには Standard レベルと Premium レベルを使用することを検討してください。
Kubernetes 固有のコンストラクトによる詳細なクラスターインフラストラクチャコストの割り当てに対して、 AKS コスト分析を有効にすることを検討してください。

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

オペレーショナルエクセレンスは、アプリケーションをデプロイし、運用環境で実行し続ける運用プロセスを対象としています。詳細については、「オペレーショナルエクセレンス設計レビューチェックリスト」を参照してください。

管理容易性を計画するときは、次の点を考慮してください。

自動デプロイパイプラインを使用して、AKS クラスターインフラストラクチャを管理します。このアーキテクチャの参照実装では、パイプラインを構築するときに参照できる GitHub Actions ワークフローが提供されます。
ワークフローファイルでは、ワークロードではなくインフラストラクチャのみが、既存の仮想ネットワークと Microsoft Entra 構成にデプロイされます。インフラストラクチャとワークロードを個別にデプロイすると、個別のライフサイクルと運用上の問題に対処できます。
リージョンの障害が発生した場合は、ワークフローを別のリージョンにデプロイするメカニズムと考えてください。パラメーターと入力の変更を使用して新しいリージョンに新しいクラスターをデプロイできるように、パイプラインを構築します。

パフォーマンス効率

パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。詳細については、「パフォーマンス効率設計レビューチェックリスト」を参照してください。

スケーラビリティを計画するときは、次の点を考慮してください。

レプリカの数の自動スケールと命令型または宣言型の管理を組み合わせないでください。ユーザーと自動スケーラーの両方がレプリカの数を変更しようとすると、予期しない動作が発生する可能性があります。 HPA が有効になっている場合は、レプリカの数をデプロイする最小数に減らします。
ポッドの自動スケールの副作用は、アプリケーションのスケールインまたはスケールアウト時にポッドが頻繁に作成または削除される可能性があるということです。これらの影響を軽減するには、次のアクションを実行します。
- 準備プローブを使用して、新しいポッドがトラフィックを受け付ける準備ができたら Kubernetes に認識されるようにします。
- ポッド中断バジェットを使用して、サービスから一度に削除できるポッドの数を制限します。
マイクロサービスからの送信フローが多数ある場合は、送信元ネットワークアドレス変換ポートの枯渇を回避するために、ネットワークアドレス変換ゲートウェイの使用を検討してください。
マルチテナントまたはその他の高度なワークロードには、より小さなサブネットを必要とするノードプール分離要件がある場合があります。詳細については、「一意のサブネットを持つノードプールを追加する」を参照してください。ハブスポーク実装の基準は組織によって異なります。必ず組織のガイドラインに従ってください。
オーバーレイネットワークで CNI を使用して、ネットワークアドレス空間を節約することを検討してください。

次の方法で共有

高度な Azure Kubernetes Service (AKS) マイクロサービスアーキテクチャ

アーキテクチャ

Workflow

コンポーネント

外部ストレージとその他のコンポーネント

その他の操作でシステムコンポーネントがサポートされる

選択肢

シナリオの詳細

推奨事項

アプリケーションルーティングアドオンを使用したマネージド NGINX イングレス

ゼロトラストネットワークポリシー

リソースクォータ

自動スケール

クラスターの自動スケール

水平ポッドの自動スケーリング

ポッドの垂直自動スケーリング

Kubernetes イベントドリブン自動スケーリング

正常性プローブ

監視

考慮事項

セキュリティ

コストの最適化

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

パフォーマンス効率

次のステップ

次の方法で共有

高度な Azure Kubernetes Service (AKS) マイクロサービス アーキテクチャ

アーキテクチャ

Workflow

コンポーネント

外部ストレージとその他のコンポーネント

その他の操作でシステム コンポーネントがサポートされる

選択肢

シナリオの詳細

推奨事項

アプリケーション ルーティング アドオンを使用したマネージド NGINX イングレス

ゼロ トラスト ネットワーク ポリシー

リソース クォータ

自動スケール

クラスターの自動スケール

水平ポッドの自動スケーリング

ポッドの垂直自動スケーリング

Kubernetes イベント ドリブン自動スケーリング

正常性プローブ

監視

考慮事項

セキュリティ

コストの最適化

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

パフォーマンス効率

次のステップ

関連リソース

フィードバック

高度な Azure Kubernetes Service (AKS) マイクロサービスアーキテクチャ

その他の操作でシステムコンポーネントがサポートされる

アプリケーションルーティングアドオンを使用したマネージド NGINX イングレス

ゼロトラストネットワークポリシー

リソースクォータ

Kubernetes イベントドリブン自動スケーリング

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