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

Azure Application Gateway

Azure Container Registry

Azure Kubernetes Service (AKS)

Azure Virtual Network

この参照アーキテクチャでは、Azure Kubernetes Services でマイクロサービスを実行するときに考慮すべきいくつかの構成について詳しく説明します。トピックには、ネットワークポリシーの構成、ポッドの自動スケール、マイクロサービスベースのアプリケーション全体での分散トレースなどが含まれています。

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

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

アーキテクチャ

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

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

ワークフロー

この要求フローでは、パブリッシャー/サブスクライバー、競合コンシューマー、およびゲートウェイルーティングのクラウド設計パターンが実装されます。メッセージングフローは次のように進みます。

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

Components

このアーキテクチャは、次の Azure コンポーネントを使用します。

Azure Kubernetes Service は、マネージド Kubernetes クラスターを提供する Azure オファリングです。 AKS を使用する場合、Kubernetes API サーバーは Azure によって管理されます。 Kubernetes ノードまたはノードプールにはアクセス可能で、これらはクラスターオペレーターによって管理できます。

このアーキテクチャで使用される AKS インフラストラクチャには、次のものが含まれています。

Azure Virtual Network は 、仮想マシン (VM) とアプリケーションを実行するための分離された安全性の高い環境です。この参照アーキテクチャでは、ピアリングされたハブスポーク仮想ネットワークトポロジを使用します。ハブ仮想ネットワークには、Azure ファイアウォールと Azure Bastion サブネットが保持されます。スポーク仮想ネットワークには、AKS システムおよびユーザーノードプールのサブネット、および Azure Application Gateway サブネットが保持されます。

Azure Private Link では、AKS システムおよびユーザーノードプールのサブネット内のプライベートエンドポイントから Azure Container Registry および Key Vault にアクセスするための特定のプライベート IP アドレスを割り当てます。

Web アプリケーションファイアウォール (WAF) を使用する Azure Application Gateway では、AKS クラスターへの HTTP(S) ルートを公開し、Web アプリケーションへの Web トラフィックを負荷分散します。このアーキテクチャでは、Azure Application Gateway イングレスコントローラー (AGIC) を Kubernetes イングレスコントローラーとして使用します。

Azure Bastion では、Secure Socket Layer (SSL) を使用して仮想ネットワーク内の VM へのセキュアリモートデスクトッププロトコル (RDP) および Secure Shell (SSH) アクセスが提供されるため、パブリック IP アドレスを使用して VM を公開する必要はありません。

Azure Firewall は、すべての Azure Virtual Network リソースを保護するネットワークセキュリティサービスです。このファイアウォールでは、承認されたサービスと完全修飾ドメイン名 (FQDN) のみをエグレストラフィックとして許可します。

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

Azure Key Vault では、AKS サービスのセキュリティキーを格納および管理します。

Azure Container Registry には、AKS クラスターで実行できるプライベートコンテナーイメージが格納されます。 AKS は、その Microsoft Entra マネージド ID を使用して Container Registry に対して認証します。 Docker Hub などの他のコンテナーレジストリも使用できます。

Azure Cosmos DB では、オープンソースの Azure Cosmos DB for MongoDB を使ってデータが格納されます。マイクロサービスは通常ステートレスであり、その状態は外部データストアに書き込まれます。 Azure Cosmos DB は、MongoDB および Cassandra 用のオープンソース API を使用する NoSQL データベースです。

Azure Service Bus では、信頼性の高いサービスとしてのクラウドメッセージングとシンプルなハイブリッド統合が実現されます。 Service Bus では、マイクロサービスアプリケーションで一般的な非同期メッセージングパターンがサポートされます。

Azure Cache for Redis ではアプリケーションアーキテクチャにキャッシュレイヤーを追加して、負荷が高いトラフィックの速度とパフォーマンスを向上させます。

Azure Monitor では、アプリケーションテレメトリや Azure プラットフォームおよびサービスのメトリックなど、メトリックとログが収集されて格納されます。このデータを使用して、アプリケーションを監視したり、アラートやダッシュボードを設定したり、障害の根本原因を分析したりできます。

その他のオペレーションサポートシステム (OSS) コンポーネント:

Helm は Kubernetes のパッケージマネージャーであり、Kubernetes オブジェクトを発行、デプロイ、バージョン管理、および更新が可能な 1 つの単位にバンドルします。

Azure Key Vault シークレットストア CSI プロバイダー では、Azure Key Vault に格納されているシークレットを取得し、シークレットストア CSI ドライバーインターフェイスを使用してそれらを Kubernetes ポッドにマウントします。

Flux は、GitOps Toolkit を利用した、Kubernetes 用のオープンで拡張可能な継続的デリバリーソリューションです。

シナリオの詳細

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

考えられるユースケース

このソリューションは、航空機、航空宇宙、航空の各業界に最適です。

Recommendations

高度な AKS マイクロサービスアーキテクチャをデプロイするときは、次の推奨事項を実装してください。

Application Gateway イングレスコントローラー (AGIC)

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

クライアント要求を適切なバックエンドサービスにルーティングすることで、クライアントに単一のエンドポイントを提供し、クライアントをサービスから切り離せるようにします。

クライアントとバックエンド間での頻繁な通信を減らすために、複数の要求を 1 つの要求に集約する。
SSL 終了、認証、IP 制限、クライアントのレート制限または調整などの機能をバックエンドサービスからオフロードする。

AKS クラスターの状態は Application Gateway 固有の構成に変換され、Azure Resource Manager 経由で適用されます。

外部のイングレスコントローラーによって AKS クラスターへのトラフィックインジェストが簡素化され、安全性とパフォーマンスが向上し、リソースが節約されます。このアーキテクチャでは、Azure Application Gateway イングレスコントローラー (AGIC) をイングレス制御用に使用します。 Application Gateway を使用してすべてのトラフィックを処理することで、追加のロードバランサーが不要になります。ポッドによって Application Gateway に対する直接接続が確立されるため、必要なホップ数が少なくなり、パフォーマンスが向上します。

Application Gateway には組み込みの自動スケール機能があり、これは、不要な量のコンピューティングリソースを消費する場合にスケールアウトする必要があるクラスター内イングレスコントローラーとは異なります。 Application Gateway では、レイヤー 7 のルーティングと SSL 終了を実行でき、エンドツーエンドのトランスポート層セキュリティ (TLS) が、組み込みの "Web アプリケーションファイアウォール (WAF) " と統合されています。

AGIC イングレスオプションでは、AKS クラスターを構成するときに CNI ネットワークを有効にする必要があります。これは、Application Gateway が 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

制限の厳しいポリシーが準備できたら、マイクロサービス内の各ポッドとの間で送受信されるトラフィックを許可する特定のネットワークルールを定義します。次の例では、ネットワークポリシーは、 app.kubernetes.io/component: backendに一致するラベルを持つバックエンド dev 名前空間内の任意のポッドに適用されます。このポリシーは、 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 のドキュメントの「ネットワークポリシー」を参照してください。

リソースクォータ

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

コンピューティングリソース: CPU とメモリ、GPU など。
ストレージリソース: ボリュームの数または特定のストレージクラスのディスク領域の量が含まれます。
オブジェクト数: 作成可能なシークレット、サービス、ジョブの最大数など。

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

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

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

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

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

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

自動スケール

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

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

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

次の例は、ARM テンプレートの 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"
},

ARM テンプレートの次の行では、CA の最小および最大ノードの例を設定しています。

"minCount": 2,
"maxCount": 5,

ポッドの自動スケール

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

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

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

apiVersion: autoscaling/v2beta2
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
        targetAverageUtilization: 60

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

正常性プローブ

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

Kubernetes では、ポッドは 2 種類の正常性プローブを公開できます。

"liveness probe" は、ポッドが正常に開始されて正常であるかどうかを Kubernetes に伝えます。
"readiness probe" は、ポッドが要求を受け付ける準備ができたかどうかを Kubernetes に通知します。

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

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

マイクロサービスでは、実行するチェック用に特別に調整された遅延とタイムアウトを指定して、正常性プローブを促進するエンドポイントをコード内で公開する必要があります。 HPA 式のキーは、ポッドの準備フェーズからほぼ外れているため、正常性プローブが存在して正確であることが重要です。

監視

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

Application Insights:

待機時間や結果コードなど、HTTP 要求が記録されます。
分散トレースが既定で有効になります。
トレースに操作 ID が含まれるので、すべてのトレースを特定の操作と照合できます。
多くの場合、トレースに追加のコンテキスト情報が含まれます。

サービステレメトリを Kubernetes でコンテキスト化するには、Azure Monitor テレメトリを AKS と統合して、コントローラー、ノード、コンテナーのほか、コンテナーとノードのログからメトリックを収集します。 .NET を使用している場合 Application Insights for Kubernetes ライブラリでは、イメージ、コンテナー、ノード、ポッド、ラベル、レプリカセットの情報を使用して Application Insights テレメトリを強化します。

次の図は、AKS マイクロサービステレメトリトレース用に Application Insights で生成されるアプリケーション依存関係マップの例を示しています。

AKS マイクロサービスアプリケーション用の Application Insights 依存関係マップの例。

Application Insights 統合用の共通言語をインストルメント化するためのオプションの詳細については、Kubernetes 用のアプリケーション監視に関する記事を参照してください。

考慮事項

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

スケーラビリティ

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

レプリカの数の自動スケールと命令型または宣言型の管理を組み合わせないでください。ユーザーと自動スケーラーの両方がレプリカの数を変更しようとすると、予期しない動作が発生する可能性があります。 HPA が有効になっている場合は、レプリカの数をデプロイする最小数に減らします。
ポッドの自動スケールの副作用は、スケールアウトおよびスケールインイベントが発生すると、ポッドがより頻繁に作成または削除される可能性があることです。これらの影響を軽減するには、次の手順を実行します。
- 準備プローブを使用して、新しいポッドがトラフィックを受け付ける準備ができたら Kubernetes に認識されるようにします。
- ポッド中断バジェットを使用して、サービスから一度に削除できるポッドの数を制限します。
クラスターを作成した後に VM サイズを変更することはできないため、クラスターの作成時にエージェントノードの適切な VM サイズを選択するために、初期の容量計画を実行する必要があります。
マルチテナントまたはその他の高度なワークロードには、より小さなサブネットを必要とするノードプール分離要件がある場合があります。一意のサブネットを持つノードプールの作成の詳細については、「一意なサブネットを持つノードプールを追加する」をご覧ください。ハブスポーク実装の基準は組織によって異なります。必ず組織のガイドラインに従ってください。

管理の容易性

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

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

セキュリティ

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

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

AKS ポッドは、Microsoft Entra ID に格納されている "ワークロード ID" を使用して自身を認証します。クライアントシークレットが不要なため、ワークロード ID を使用することをお勧めします。
マネージド ID を使用すると、実行中のプロセスで Azure Resource Manager OAuth 2.0 トークンをすばやく取得できます。パスワードや接続文字列は必要ありません。 AKS では、Microsoft Entra ワークロード ID を使用して、ID を個々のポッドに割り当てることができます。
マイクロサービスアプリケーションの各サービスには、最小特権の RBAC 割り当てを支援するための一意のワークロード ID を割り当てる必要があります。 ID は、それを必要とするサービスにのみ割り当てる必要があります。
アプリケーションコンポーネントで Kubernetes API アクセスが必要な場合、API アクセスが適切にスコープ設定されたサービスアカウントを使用するようにアプリケーションポッドが構成されていることを確認します。 Kubernetes サービスアカウントの構成と管理の詳細については、「Managing Kubernetes Service Accounts (Kubernetes サービスアカウントの管理)」を参照してください。
すべての Azure サービスが、Microsoft Entra ID を使用したデータプレーン認証をサポートしているわけではありません。これらのサービス、サードパーティのサービス、または API キーの資格情報またはアプリケーションシークレットを格納するには、Azure Key Vault を使用します。 Azure Key Vault では、一元管理、アクセス制御、保存時の暗号化、すべてのキーとシークレットの監査が行われます。
AKS では、1 つ以上のシークレットを Key Vault からボリュームとしてマウントできます。ポッドはその後、これらの Key Vault シークレットを通常のボリュームと同様に読み取ることができます。詳細については、GitHub の secrets-store-csi-driver-provider-azure プロジェクトに関するページを参照してください。

コストの最適化

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

Microsoft Azure Well-Architected Framework のコストセクションには、コストに関する考慮事項が記載されています。具体的なシナリオのコストを見積もるには、Azure 料金計算ツールを使用します。
AKS には、Kubernetes クラスターのデプロイ、管理、操作に関連付けられたコストはありません。ユーザーは、クラスターで消費される VM インスタンス、ストレージ、およびネットワークリソースについてのみ支払います。クラスターの自動スケールでは、空または未使用のノードを削除することで、クラスターのコストを大幅に削減できます。
必要なリソースのコストを見積もるには、コンテナーサービスの計算ツールに関するページを参照してください。
Kubernetes 固有のコンストラクトによる詳細なクラスターインフラストラクチャコストの割り当てに対して、AKS コスト分析を有効にすることを検討してください。

次の方法で共有

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

アーキテクチャ

ワークフロー

Components

シナリオの詳細

考えられるユースケース

Recommendations

Application Gateway イングレスコントローラー (AGIC)

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

リソースクォータ

自動スケール

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

ポッドの自動スケール

正常性プローブ

監視

考慮事項

スケーラビリティ

管理の容易性

セキュリティ

コストの最適化

次のステップ

フィードバック

その他のリソース

次の方法で共有

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

アーキテクチャ

ワークフロー

Components

シナリオの詳細

考えられるユース ケース

Recommendations

Application Gateway イングレス コントローラー (AGIC)

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

リソース クォータ

自動スケール

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

ポッドの自動スケール

正常性プローブ

監視

考慮事項

スケーラビリティ

管理の容易性

セキュリティ

コストの最適化

次のステップ

関連リソース

フィードバック

その他のリソース

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

考えられるユースケース

Application Gateway イングレスコントローラー (AGIC)

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

リソースクォータ