Azure Well-Architected Framework レビュー - Azure Kubernetes Service (AKS)

  • [アーティクル]

この記事では、Azure Kubernetes Service (AKS) のアーキテクチャのベスト プラクティスについて説明します。 このガイダンスは、アーキテクチャの卓越性の 5 つの柱に基づいています。

  • [信頼性]
  • セキュリティ
  • コストの最適化
  • オペレーショナル エクセレンス
  • パフォーマンス効率

システム設計の原則を理解し、Azure Kubernetes Serviceに関する実用的な知識を持ち、その機能に精通していることを前提としています。 詳細については、「Azure Kubernetes Service」を参照してください。

前提条件

Well-Architected Framework の柱を理解することは、高品質で安定した効率的なクラウド アーキテクチャを作成するのに役立ちます。 Azure Well-Architected Framework Review 評価を使用してワークロードを確認することをお勧めします。

コンテキストについては、これらの考慮事項を設計に反映する参照アーキテクチャを確認することを検討してください。 Azure Kubernetes Service (AKS) クラスターのベースライン アーキテクチャと、Azure Kubernetes Service上のマイクロサービス アーキテクチャから開始することをお勧めします。 また、スケーラブルなAzure Kubernetes Service (AKS) クラスター用にランディング ゾーン サブスクリプションを準備するためのアーキテクチャ アプローチと参照実装を提供する AKS ランディング ゾーン アクセラレータについても確認します。

[信頼性]

クラウドでは、障害が発生することを認識しています。 目標は、障害がまったく発生しないように努力することではなく、障害が発生した単一コンポーネントの影響を最小限に抑えることです。 失敗したインスタンスを最小限に抑えるには、次の情報を使用します。

Azure Kubernetes Serviceで信頼性について説明する場合は、クラスターの信頼性とワークロードの信頼性を区別することが重要です。 クラスターの信頼性はクラスター管理者とそのリソース プロバイダーの間で共有される責任ですが、ワークロードの信頼性は開発者のドメインです。 Azure Kubernetes Service には、これらの両方のロールに関する考慮事項とレコメンデーションがあります。

以下の 設計チェックリスト と 推奨事項の一覧 では、各選択がクラスター アーキテクチャ、ワークロード アーキテクチャ、またはその両方に適用できるかどうかを示すコールアウトが行われます。

設計チェック リスト

  • クラスター アーキテクチャ: 重要なワークロードの場合は、AKS クラスターの 可用性ゾーン を使用します。
  • クラスター アーキテクチャ: IP アドレス空間を計画して、マルチクラスター トポロジでのフェールオーバー トラフィックの処理など、クラスターを確実にスケーリングできるようにします。
  • クラスター アーキテクチャ:Container insights を有効にしてクラスターを監視し、信頼性に影響を与えるイベントのアラートを構成します。
  • ワークロード アーキテクチャ: 水平スケーリングをサポートし、アプリケーションの準備と正常性をレポートするようにワークロードが構築されていることを確認します。
  • クラスターとワークロードのアーキテクチャ: ワークロードがユーザー ノード プールで実行されていることを確認し、適切なサイズの SKU を選択します。 少なくとも、ユーザー ノード プール用の 2 つのノードと、システム ノード プール用の 3 つのノードを含めます。
  • クラスター アーキテクチャ: AKS アップタイム SLA を使用して、運用ワークロードの可用性目標を満たします。

AKS の構成に関する推奨事項

次の推奨事項の表を参照して、信頼性の AKS 構成を最適化します。

推奨 特長
クラスターとワークロードのアーキテクチャ: ノード セレクターとアフィニティを使用してポッドのスケジュールを制御します。 Kubernetes のスケジューラが、ノード内のハードウェアによってワークロードを論理的に分離できるようにします。 容認とは異なり、ノード セレクターが一致しないポッドは、ラベル付けされたノードでスケジュールできます。これにより、ノード上の未使用のリソースを使用できますが、一致するノード セレクターを定義するポッドが優先されます。 ノードのアフィニティを使用すると柔軟性が向上し、ポッドをノードと一致させることができない場合に起こる事象を定義できるようになります。
クラスター アーキテクチャ: ネットワーク要件とクラスターのサイズ設定に基づいて、ネットワーク プラグインを適切に選択してください。 Windows ベースのノード プール、特定のネットワーク要件、Kubernetes ネットワークポリシーなどといった特定のシナリオには Azure CNI が必要です。 詳細については、 Kubenet と Azure CNI を参照してください。
クラスターとワークロードのアーキテクチャ: 運用グレードクラスターには AKS アップタイム SLA を使用します。 AKS アップタイム SLA は、次のことを保証します。
- 99.95%Azure Availability Zones を使用する AKS クラスターに対する Kubernetes　API サーバー エンドポイントの可用性
- 99.9% Azure Availability Zones を使用しない AKS クラスターに対する可用性
クラスターとワークロードのアーキテクチャ:Container insights を使用してクラスターの監視を構成します。 Container insights は、メトリック API を介して Kubernetes で使用できるコントローラー、ノード、コンテナーの正常性とパフォーマンスを監視するのに役立ちます。 Prometheus との統合により、アプリケーションとワークロードのメトリックを収集できます。
クラスター アーキテクチャ: AKS エージェント ノードを物理的に分離されたデータ センターに分散することで、 可用性ゾーン を使用して Azure リージョン内の回復性を最大化します。 ノード プールを複数のゾーンに分散することで、別のゾーンがダウンした場合でも、1 つのノード プール内のノードは引き続き実行されます。 併置要件が存在する場合は、単一ゾーンへの通常の VMSS ベースの AKS デプロイまたは 近接配置グループ を使用して、ノード間の待機時間を最小限に抑えることができます。
クラスター アーキテクチャ: 可用性を最大化し、ビジネス継続性を提供するために、さまざまな Azure リージョンにデプロイされた AKS クラスターをデプロイすることで 、マルチリージョン戦略 を採用します。 インターネットに接続するワークロードでは、 Azure Front Door または Azure Traffic Manager を利用して、AKS クラスター間でトラフィックをグローバルにルーティングする必要があります。
クラスターとワークロードのアーキテクチャ:アプリケーション配置マニフェストでポッド リソースの要求と制限を定義し、Azure Policyで適用します。 Kubernetes クラスターのリソース枯渇を防ぐために、コンテナーの CPU とメモリのリソース制限が必要です。
クラスターとワークロードのアーキテクチャ: システム ノード プールをアプリケーション ワークロードから分離したままにしておきます。 システム ノード プールには、少なくとも 2 つの vCPU と 4 GB のメモリの VM SKU が必要ですが、4 vCPU 以上をお勧めします。 詳細な要件については、「システムおよびユーザー ノード プール」をご覧ください。
クラスターとワークロードのアーキテクチャ: 特定の要件に基づいて、アプリケーションを専用ノード プールに分離します。 アプリケーションは同じ構成を共有し、GPU 対応 VM、CPU またはメモリ最適化 VM、またはゼロにスケーリングする機能が必要な場合があります。 追加の管理オーバーヘッドを減らすために、ノード プールの数が多くないようにします。
クラスター アーキテクチャ: 多数の同時送信接続を行うワークロードを実行するクラスターには、NAT ゲートウェイを使用します。 同時送信トラフィックの数が多いAzure Load Balancer制限に関する信頼性の問題を回避するために、NAT ゲートウェイを使用して大規模な信頼性の高いエグレス トラフィックをサポートします。

その他の提案については、「 信頼性の柱の原則」を参照してください。

Azure Policy

Azure Kubernetes Serviceには、一般的な Azure ポリシーと、Kubernetes 用のAzure Policy アドオンを使用するクラスター内の両方の Azure リソースに適用される、さまざまな組み込みの Azure ポリシーが用意されています。 多数のポリシーがあり、この柱に関連する主要なポリシーをここにまとめます。 詳細なビューについては、「 Kubernetes の組み込みポリシー定義」を参照してください。

クラスターとワークロードのアーキテクチャ

  • クラスターには、ポッド スペック用に構成された準備状態またはライブネス 正常性プローブ があります。

組み込みのAzure Policy定義に加えて、カスタム ポリシーは、AKS リソースと Kubernetes 用のAzure Policy アドオンの両方に対して作成できます。 これにより、クラスターとワークロードのアーキテクチャで適用する信頼性の制約をさらに追加できます。

Security

セキュリティは、あらゆるアーキテクチャの最も重要な側面の 1 つです。 AKS がアプリケーション ワークロードのセキュリティを強化する方法を調べるには、 セキュリティ設計の原則を確認することをお勧めします。 Azure Kubernetes Service クラスターを、Payment Card Industry Data Security Standard (PCI-DSS 3.2.1) の規制要件を満たす機密性の高いワークロードを実行するように設計する必要がある場合は、PCI-DSS 3.2.1 の AKS 規制クラスターを確認してください。

AKS での DoD 影響レベル 5 (IL5) のサポートと要件については、「IL5 分離要件Azure Government確認してください。

セキュリティについてAzure Kubernetes Serviceで説明するときは、クラスターのセキュリティとワークロードのセキュリティを区別することが重要です。 クラスター セキュリティはクラスター管理者とそのリソース プロバイダーの間で共有される責任ですが、ワークロード セキュリティは開発者のドメインです。 Azure Kubernetes Service には、これらの両方のロールに関する考慮事項とレコメンデーションがあります。

以下の 設計チェックリスト と 推奨事項の一覧 では、各選択がクラスター アーキテクチャ、ワークロード アーキテクチャ、またはその両方に適用できるかどうかを示すコールアウトが行われます。

設計チェック リスト

  • クラスター アーキテクチャ:マネージド ID を使用して、サービス原則の管理とローテーションを回避します。
  • クラスター アーキテクチャ:最小限の特権アクセスを得るために、Microsoft Entra IDで Kubernetes ロールベースのアクセス制御 (RBAC) を使用し、構成とシークレット アクセスを保護するための管理者特権の付与を最小限に抑えます。
  • クラスター アーキテクチャ:Azure Sentinel を使用したコンテナーのMicrosoft Defenderを使用して、クラスターとその上で実行されているワークロード全体の脅威を検出して迅速に対応します。
  • クラスター アーキテクチャ: プライベート AKS クラスターをデプロイして、API サーバーへのクラスター管理トラフィックがプライベート ネットワークに残っていることを確認します。 または、プライベート以外のクラスターの API サーバー許可リストを使用します。
  • ワークロード アーキテクチャ:HTTP(S) トラフィックをセキュリティで保護するには、Web Application Firewallを使用します。
  • ワークロード アーキテクチャ: CI/CID パイプラインがコンテナー対応スキャンで強化されていることを確認します。

Recommendations

次の推奨事項の表を調べて、セキュリティのために AKS 構成を最適化します。

推奨 特長
クラスター アーキテクチャ:Microsoft Entra統合を使用します。 Microsoft Entra IDを使用すると、ID 管理コンポーネントが一元化されます。 ユーザー アカウントまたはグループの状態が変わると、AKS クラスターにアクセスしたとき、その変更内容が自動的に更新されます。 お使いの Kubernetes クラスターの開発者とアプリケーション所有者はさまざまなリソースへのアクセスを必要とします。
クラスター アーキテクチャ:Azure Container RegistryにMicrosoft Entra IDを使用して認証します。 AKS とMicrosoft Entra IDを使用すると、シークレットを使用せずにAzure Container RegistryをimagePullSecrets使用した認証が可能になります。 詳細については、「Azure Kubernetes Service からのAzure Container Registryを使用した認証」を参照してください。
クラスター アーキテクチャ:プライベート AKS クラスターを使用して API サーバーへのネットワーク トラフィックをセキュリティで保護します。 既定では、ノード プールと API サーバー間のネットワーク トラフィックは、Microsoft バックボーン ネットワークを移動します。プライベート クラスターを使用することで、API サーバーへのネットワーク トラフィックがプライベート ネットワークのみに残ることを確認できます。
クラスター アーキテクチャ: プライベートではない AKS クラスターの場合は、API サーバーの承認された IP 範囲を使用します。 パブリック クラスターを使用する場合でも、承認された IP 範囲機能を使用して、クラスター API サーバーに到達できるトラフィックを制限できます。 デプロイ ビルド エージェントのパブリック IP、運用管理、ノード プールのエグレス ポイント (Azure Firewall など) などのソースを含めます。
クラスター アーキテクチャ:MICROSOFT ENTRA RBAC を使用して API サーバーを保護します。 Kubernetes API Server へのアクセスをセキュリティで保護することは、クラスターをセキュリティで保護するためにできる最も重要な方法の 1 つです。 Kubernetes ロールベースのアクセス制御 (RBAC) と Microsoft Entra ID を統合して、API サーバーへのアクセスを制御します。 Microsoft Entra ID ベースの ID を使用してすべてのクラスター アクセスを適用するには、ローカル アカウントを無効にします。
クラスター アーキテクチャ:Azure ネットワーク ポリシーまたは Calico を使用します。 クラスター内のポッド間のネットワーク トラフィックをセキュリティで保護し、制御します。
クラスター アーキテクチャ:Azure Policyを使用してクラスターとポッドをセキュリティで保護します。 Azure Policyは、一元化された一貫性のある方法でクラスターに大規模な適用と保護を適用するのに役立ちます。 また、ポッドに付与される機能や、会社のポリシーに反する機能が実行されているかどうかを制御することもできます。
クラスター アーキテクチャ: リソースへのコンテナー アクセスをセキュリティで保護します。 コンテナーで実行できるアクションへのアクセスを制限します。 最小限のアクセス許可を付与し、ルートまたは特権エスカレーションの使用を避けます。
ワークロード アーキテクチャ:HTTP(S) トラフィックをセキュリティで保護するには、Web Application Firewallを使用します。 受信トラフィックで潜在的な攻撃をスキャンするには、Azure Application Gatewayまたは Azure Front Doorの Azure Web Application Firewall (WAF) などの Web アプリケーション ファイアウォールを使用します。
クラスター アーキテクチャ: クラスターエグレス トラフィックを制御します。 クラスターの送信トラフィックが、Azure Firewallや HTTP プロキシなどのネットワーク セキュリティ ポイントを通過していることを確認します。
クラスター アーキテクチャ:Azure Key VaultでオープンソースのMicrosoft Entraワークロード ID とシークレット ストア CSI ドライバーを使用します。 強力な暗号化を使用して、Azure Key Vaultでシークレット、証明書、接続文字列を保護してローテーションします。 アクセス監査ログを提供し、コア シークレットをデプロイ パイプラインから保持します。
クラスター アーキテクチャ:コンテナーのMicrosoft Defenderを使用します。 クラスター、コンテナー、およびそれらのアプリケーションのセキュリティを監視および維持します。

その他の推奨事項については、「セキュリティの重要な原則」を参照してください。

Azure Advisor は、Azure Kubernetes サービスの確保と改善に役立ちます。 RBAC が構成されていないクラスター、Microsoft Defender構成がない、API Server への無制限のネットワーク アクセスなど、以下のポリシー セクションに記載されている項目のサブセットに関する推奨事項が作成されます。 同様に、一部のポッド セキュリティ イニシアチブ項目に対してワークロードの推奨事項を作成します。 推奨事項を確認 します。

ポリシーの定義

Azure Policyでは、Azure リソースと AKS の両方に適用されるさまざまな組み込みポリシー定義 (標準ポリシー定義など) と、Kubernetes 用のAzure Policy アドオンをクラスター内で使用できます。 Azure リソース ポリシーの多くは 、Audit/Deny の両方に含まれていますが、 Deploy If Not Exists バリアントにも含まれています。

多数のポリシーがあり、この柱に関連する主要なポリシーをここにまとめます。 詳細なビューについては、「 Kubernetes の組み込みポリシー定義」を参照してください。

クラスター アーキテクチャ

  • クラウドベースのポリシーのMicrosoft Defender
  • 認証モードと構成ポリシー (Microsoft Entra ID、RBAC、ローカル認証の無効化)
  • プライベート クラスターを含む API Server ネットワーク アクセス ポリシー

クラスターとワークロードのアーキテクチャ

  • Kubernetes クラスター ポッドのセキュリティ イニシアチブ Linux ベースのワークロード
  • AppArmor、sysctl、セキュリティ キャップ、SELinux、seccomp、特権コンテナー、自動マウント クラスター API 資格情報などのポッドとコンテナーの機能ポリシーを含める
  • マウント、ボリューム ドライバー、およびファイルシステム ポリシー
  • ホスト ネットワーク、ポート、許可された外部 IP、HTTP、内部ロード バランサーなどのポッド/コンテナー ネットワーク ポリシー

Azure Kubernetes Serviceデプロイでは、多くの場合、Helm チャートとコンテナー イメージにAzure Container Registryが使用されます。 Azure Container Registryでは、セキュリティで保護された AKS アーキテクチャを補完する、ネットワーク制限、アクセス制御、Microsoft Defender for Cloud にまたがるさまざまな Azure ポリシーもサポートされています。

組み込みのポリシーに加えて、カスタム ポリシーは、AKS リソースと Kubernetes 用のAzure Policy アドオンの両方に対して作成できます。 これにより、クラスターとワークロードのアーキテクチャで適用するセキュリティ制約を追加できます。

その他の推奨事項については、「 AKS セキュリティの概念 」を参照し、 CIS Kubernetes ベンチマークに基づいてセキュリティ強化に関する推奨事項を評価してください。

コスト最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させるために、さまざまな構成オプションと推奨されるベスト プラクティスを理解することです。 この記事のガイダンスに従う前に、次のリソースを確認することをお勧めします。

Azure Kubernetes Service によるコストの最適化を議論する場合は、"クラスター リソースのコスト" と "ワークロード リソースのコスト" を区別することが重要です。 クラスター リソースはクラスター管理者とそのリソース プロバイダー間の共有責任ですが、ワークロード リソースは開発者のドメインです。 Azure Kubernetes Service には、これらの両方のロールに関する考慮事項とレコメンデーションがあります。

設計チェックリストと推奨事項の一覧では、各選択がクラスター アーキテクチャ、ワークロード アーキテクチャ、またはその両方に適用できるかどうかを示すコールアウトが行われます。

クラスター コストの最適化については、Azure 料金計算ツールに移動し、利用可能な製品から [Azure Kubernetes Service] を選択します。 電卓では、さまざまな構成と支払いプランをテストできます。

設計チェック リスト

  • クラスター アーキテクチャ: 長期的な容量が必要なノード プールと予約インスタンスごとに適切な VM SKU を使用します。
  • クラスターとワークロードのアーキテクチャ: 適切なマネージド ディスク層とサイズを使用します。
  • クラスター アーキテクチャ: CPU、メモリ、ストレージ、ネットワークなどのパフォーマンス メトリックを確認して、クラスター、ノード、名前空間ごとのコスト最適化の機会を特定します。
  • クラスターとワークロードのアーキテクチャ: ワークロードのアクティブ性が低い場合は、自動スケーラーを使用してスケールインします。

Recommendations

次のレコメンデーションの表を参照して、コストについて AKS 構成を最適化します。

推奨 特長
クラスターとワークロードのアーキテクチャ: SKU の選択とマネージド ディスク サイズをワークロード要件に合わせます。 選択内容をワークロードの需要と一致させると、不要なリソースに対して支払いが行われません。
クラスター アーキテクチャ: 適切な仮想マシン インスタンスの種類を選択します。 適切な仮想マシン インスタンスの種類を選択することは、AKS でのアプリケーションの実行コストに直接影響を与えるので、重要です。 適切な使用率のない高パフォーマンスインスタンスを選択すると無駄な支出が発生する可能性があり、強力なインスタンスを選択すると、パフォーマンスの問題やダウンタイムが増加する可能性があります。 適切な仮想マシン インスタンスの種類を決定するには、ワークロードの特性、リソース要件、可用性のニーズを考慮してください。
クラスター アーキテクチャ:Arm アーキテクチャに基づいて仮想マシンを選択します。 AKS では 、ARM64 Ubuntu エージェント ノードの作成と、クラスター内に Intel と ARM のアーキテクチャ ノードを混在させ、低コストでパフォーマンスを向上させることができます。
クラスター アーキテクチャ:[Azure Spot Virtual Machines] を選択します。 スポット VM を使用すると、大量の割引 (従量課金制の価格と比較して最大 90%) で、未使用の Azure 容量を利用できます。 Azure で容量が戻る必要がある場合は、Azure インフラストラクチャによってスポット ノードが削除されます。
クラスター アーキテクチャ: 適切なリージョンを選択します。 多くの要因により、リソースのコストは Azure のリージョンごとに異なります。 コスト、待機時間、コンプライアンスの要件を評価して、ワークロードをコスト効率よく実行し、エンド ユーザーに影響を与えたり、追加のネットワーク料金を作成したりしないようにします。
ワークロード アーキテクチャ: 小さく最適化されたイメージを維持します。 イメージを合理化すると、新しいノードでこれらのイメージをダウンロードする必要があるため、コストを削減できます。 アプリケーションの起動中にユーザーの要求エラーやタイムアウトを回避できるように、コンテナーをできるだけ早く起動できるようにイメージをビルドすると、オーバープロビジョニングにつながる可能性があります。
クラスター アーキテクチャ:クラスター オートスケーラーを有効にして、過剰なリソース容量に応じてエージェント ノードの数を自動的に減らします。 AKS クラスター内のノード数を自動的にスケールダウンすると、需要が少ない場合に効率的なクラスターを実行し、需要が返されたときにスケールアップできます。
クラスター アーキテクチャ:ノードの自動プロビジョニングを有効にして、VM SKU の選択を自動化します。 Node Autoprovision により、SKU の選択プロセスが簡素化され、保留中のポッド リソース要件に基づいて、最も効率的でコスト効率の高い方法でワークロードを実行するための最適な VM 構成が決定されます。
ワークロード アーキテクチャ: ポッドの 水平オートスケーラーを使用します。 クラスターのスケールイン操作をサポートする CPU 使用率やその他の選択メトリックに応じて、デプロイ内のポッドの数を調整します。
ワークロード アーキテクチャ:Vertical Pod Autoscaler (プレビュー) を使用します。 ポッドを右サイズし、履歴の使用状況に基づいて 要求と制限を 動的に設定します。
ワークロード アーキテクチャ:Kubernetes イベント ドリブン自動スケーリング (KEDA) を使用します。 処理されるイベントの数に基づいてスケーリングします。 50以上のKEDAスケーラーの豊富なカタログから選択してください。
クラスターとワークロードのアーキテクチャ: クラウドの使用状況の所有権を促進するために、クラウド財務規範とカルチャプラクティスを採用します。 コストの最適化を可能にする基盤は、コスト削減クラスターの広がりです。 多くの場合、 財務運用アプローチ (FinOps) は、組織がクラウド コストを削減するのに役立ちます。 これは、財務チーム、運用チーム、エンジニアリング チーム間のコラボレーションを含むプラクティスであり、コスト削減の目標に合わせて調整を進め、クラウド コストに透明性をもたらします。
クラスター アーキテクチャ:Azure Reservations または Azure Savings プランにサインアップします。 容量を適切に計画した場合、ワークロードは予測可能であり、長期間存在する場合は、 Azure Reservation または 節約プラン にサインアップして、リソース コストをさらに削減します。
クラスター アーキテクチャ:Container insights を使用してクラスターの監視を構成します。 コンテナー分析情報のヘルプは、クラスターのアイドル状態と割り当てられていないリソースに関する実用的な分析情報を提供します。 Container insights では、Prometheus メトリックの収集もサポートされ、Azure Managed Grafana と統合され、アプリケーションとインフラストラクチャの全体像が得られます。
クラスター アーキテクチャ:AKS Cost Analysis アドオンを構成します。 コスト分析クラスター拡張機能を使用すると、クラスターまたは名前空間のさまざまな Kubernetes リソースに関連するコストに関する詳細な分析情報を取得できます。

その他の提案については、「コスト最適化の柱の原則」および「Azure Kubernetes Serviceでのコストの最適化」を参照してください。

ポリシーの定義

コストの最適化に関連する組み込みのポリシーはありませんが、カスタム ポリシーは、AKS リソースと Kubernetes 用のAzure Policy アドオンの両方に対して作成できます。 これにより、クラスターとワークロードのアーキテクチャで適用するコスト最適化の制約を追加できます。

クラウドの効率性

ワークロードの 持続可能でクラウド効率を高めるには、 コストの最適化、 二酸化炭素排出量の削減、 エネルギー消費の最適化に関する取り組みを組み合わせる必要があります。 アプリケーションのコストを最適化することは、ワークロードをより持続可能にするための最初のステップです。

Azure Kubernetes Service (AKS) の持続可能なソフトウェア エンジニアリングの原則で、持続可能で効率的な AKS ワークロードを構築する方法について説明します。

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

監視と診断は非常に重要です。 パフォーマンス統計を測定できるだけでなく、メトリックを使用して問題のトラブルシューティングと修復を迅速に行うことができます。 オペレーショナル エクセレンス設計の原則と Day-2 運用ガイドを確認することをお勧めします。

Azure Kubernetes Serviceでオペレーショナル エクセレンスについて説明する場合は、クラスターのオペレーショナル エクセレンスとワークロードのオペレーショナル エクセレンスを区別することが重要です。 クラスター操作はクラスター管理者とそのリソース プロバイダー間の共有責任ですが、ワークロード操作は開発者のドメインです。 Azure Kubernetes Service には、これらの両方のロールに関する考慮事項とレコメンデーションがあります。

以下の 設計チェックリスト と 推奨事項の一覧 では、各選択肢がクラスター アーキテクチャ、ワークロード アーキテクチャ、またはその両方に適用されるかどうかを示すコールアウトが行われます。

設計チェック リスト

  • クラスター アーキテクチャ: Bicep、Terraform などを使用して、テンプレートベースのデプロイを使用します。 すべてのデプロイが反復可能で、トレース可能であり、ソース コード リポジトリに格納されていることを確認します。
  • クラスター アーキテクチャ: 必要なクラスター全体の構成とデプロイでクラスターがブートストラップされるように、自動化されたプロセスを構築します。 これは多くの場合、GitOps を使用して実行されます。
  • ワークロード アーキテクチャ: ソフトウェア開発ライフサイクル内で、ワークロードに対して反復可能で自動化されたデプロイ プロセスを使用します。
  • クラスター アーキテクチャ:診断設定を有効にして、コントロール プレーンまたはコア API サーバーの対話がログに記録されるようにします。
  • クラスターとワークロードのアーキテクチャ:Container insights でメトリック、ログ、診断を収集し、クラスターとそのクラスターで実行されているワークロードの可用性とパフォーマンスを監視できるようにします。
  • ワークロード アーキテクチャ: ワークロードは、収集できるテレメトリを出力するように設計する必要があります。これには、ライブラインと準備状態も含める必要があります。
  • クラスターとワークロードのアーキテクチャ: Kubernetes を対象とするカオス エンジニアリング プラクティスを使用して、アプリケーションまたはプラットフォームの信頼性の問題を特定します。
  • ワークロード アーキテクチャ: コンテナー内で効率的に運用およびデプロイするようにワークロードを最適化します。
  • クラスターとワークロードのアーキテクチャ:Azure Policyを使用してクラスターとワークロードのガバナンスを適用します。

Recommendations

次の推奨事項の表を参照して、AKS 構成を操作用に最適化します。

推奨 特長
クラスターとワークロードのアーキテクチャ:AKS のベスト プラクティスに関するドキュメントを確認します。 AKS でアプリケーションを正常にビルドして実行するには、理解して実装する必要がある重要な考慮事項があります。 これらの領域には、マルチ テナント機能とスケジューラ機能、クラスターとポッドのセキュリティ、または事業継続とディザスター リカバリーが含まれます。
クラスターとワークロードのアーキテクチャ:Azure Chaos Studio を確認します。 Azure Chaos Studio は、障害をシミュレートし、ディザスター リカバリーの状況をトリガーするのに役立ちます。
クラスターとワークロードのアーキテクチャ:Container insights を使用してクラスターの監視を構成します。 コンテナーの分析情報は、メトリック API とコンテナー ログを介して Kubernetes で使用できるコントローラー、ノード、コンテナーからメモリとプロセッサのメトリックを収集することで、コンテナーのパフォーマンスを監視するのに役立ちます。
ワークロード アーキテクチャ: Azure Monitor を使用してアプリケーションのパフォーマンスを監視します。 AKS クラスターで実行されているアプリケーションのコードベースの監視用に Application Insights を構成します。
ワークロード アーキテクチャ: Container insights を使用して Prometheus メトリックのスクレイピングを構成します。 Azure Monitor の一部である Container Insights は、Prometheus メトリックを収集するためのシームレスなオンボード エクスペリエンスを提供します。 詳細については、「 Prometheus メトリックのスクレイピングを構成 する」を参照してください。
クラスター アーキテクチャ: さまざまな Azure リージョンにデプロイされた AKS クラスターをデプロイして マルチリージョン戦略 を採用し、可用性を最大化し、ビジネス継続性を提供します。 インターネットに接続するワークロードでは、 Azure Front Door または Azure Traffic Manager を利用して、AKS クラスター全体でトラフィックをグローバルにルーティングする必要があります。
クラスター アーキテクチャ:Azure Policyを使用してクラスターとポッドの構成標準を運用化します。 Azure Policyは、クラスターに大規模な適用とセーフガードを一元的かつ一貫した方法で適用するのに役立ちます。 また、ポッドに付与される機能や、会社のポリシーに反する機能が実行されているかどうかを制御することもできます。
ワークロード アーキテクチャ: リリース エンジニアリング プロセスでプラットフォーム機能を使用します。 Kubernetes とイングレス コントローラーでは、リリース エンジニアリング プロセスに含める多くの高度なデプロイ パターンがサポートされています。 ブルーグリーン デプロイやカナリア リリースなどのパターンを検討してください。
クラスターとワークロードのアーキテクチャ: ミッション クリティカルなワークロードの場合は、スタンプ レベルの青/緑のデプロイを使用します。 デプロイやテストなど、ミッション クリティカルな設計領域を自動化します。

その他の提案については、「 オペレーショナル エクセレンスの柱の原則」を参照してください。

Azure Advisor では、サポートされていない AKS バージョンや未構成の診断設定など、以下のポリシー セクションに記載されている項目のサブセットに関する推奨事項も作成されます。 同様に、既定の名前空間の使用に関するワークロードの推奨事項を作成します。

ポリシーの定義

Azure Policyでは、Azure リソースと AKS の両方に適用されるさまざまな組み込みポリシー定義 (標準ポリシー定義など) と、Kubernetes 用の Azure Policy アドオン (クラスター内) の使用が提供されます。 Azure リソース ポリシーの多くは、 Audit/Deny と Deploy If Not Exists バリアントの 両方に含まれています。

多数のポリシーがあり、この柱に関連する主要なポリシーをここにまとめます。 詳細なビューについては、「 Kubernetes の組み込みポリシー定義」を参照してください。

クラスター アーキテクチャ

  • Kubernetes 用のAzure Policy アドオン
  • GitOps 構成ポリシー
  • 診断設定ポリシー
  • AKS バージョンの制限
  • コマンド呼び出しを禁止する

クラスターとワークロードのアーキテクチャ

  • 名前空間のデプロイの制限

組み込みのポリシーに加えて、カスタム ポリシーは、AKS リソースと Kubernetes 用のAzure Policy アドオンの両方に対して作成できます。 これにより、クラスターとワークロードのアーキテクチャで適用するセキュリティ制約をさらに追加できます。

パフォーマンス効率

パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 パフォーマンス効率の原則を確認することをお勧めします。

Azure Kubernetes Serviceでパフォーマンスについて説明する場合は、クラスターのパフォーマンスとワークロードのパフォーマンスを区別することが重要です。 クラスターのパフォーマンスはクラスター管理者とそのリソース プロバイダーの間で共有される責任ですが、ワークロードのパフォーマンスは開発者のドメインです。 Azure Kubernetes Service には、これらの両方のロールに関する考慮事項とレコメンデーションがあります。

以下の 設計チェックリスト と 推奨事項の一覧 では、各選択肢がクラスター アーキテクチャ、ワークロード アーキテクチャ、またはその両方に適用されるかどうかを示すコールアウトが行われます。

設計チェック リスト

Azure Kubernetes Serviceの設計上の選択を行う際は、パフォーマンス効率の原則を確認してください。

  • クラスターとワークロードのアーキテクチャ: SKU、自動スケーリング設定、IP アドレス指定、フェールオーバーに関する考慮事項を含む詳細な容量プランの演習を実行して反復します。
  • クラスター アーキテクチャ:クラスター オートスケーラーで、ワークロードの要求に応じてエージェント ノードの数を自動的に調整できるようにします。
  • クラスター アーキテクチャ:水平ポッド 自動スケーラーを使用して、CPU 使用率やその他の選択メトリックに応じてデプロイ内のポッドの数を調整します。
  • クラスターとワークロードのアーキテクチャ: ポッドとクラスターオートスケーラーの両方を実行する継続的なロード テスト アクティビティを実行します。
  • クラスターとワークロードのアーキテクチャ: ワークロードを異なるノード プールに分離し、独立したスケーラビリティを実現します。

Recommendations

パフォーマンスのためにAzure Kubernetes Service構成を最適化するための推奨事項の次の表を参照してください。

推奨 特長
クラスターとワークロードのアーキテクチャ: 詳細な容量計画を策定し、継続的に見直しと修正を行います。 容量計画を正式化した後は、クラスターのリソース使用率を継続的に監視することで、頻繁に更新する必要があります。
クラスター アーキテクチャ:クラスター オートスケーラーで、リソースの制約に応じてエージェント ノードの数を自動的に調整できるようにします。 AKS クラスター内のノードの数を自動的に増減するこの機能を使用すると、効率的で、コスト効率の高いクラスターを実行できます。
クラスターとワークロードのアーキテクチャ: ワークロードを異なるノード プールに分割し、ユーザー ノード プール のスケーリング を検討します。 常に実行中のノードを必要とするシステム ノード プールとは異なり、ユーザー ノード プールを使用すると、スケールアップまたはスケールダウンできます。
ワークロード アーキテクチャ: AKS の高度なスケジューラ機能を使用します。 必要なワークロードのリソースの分散を制御するのに役立ちます。
ワークロード アーキテクチャ: 意味のあるワークロード スケーリング メトリックを使用します。 すべてのスケール決定を CPU またはメモリ メトリックから派生できるわけではありません。 多くの場合、スケールに関する考慮事項は、より複雑なデータ ポイントや外部データ ポイントから生まれます。 KEDA を使用して、ワークロードに固有のシグナルに基づいて意味のある自動スケール ルールセットを構築します。

その他の提案については、「 パフォーマンス効率の柱の原則」を参照してください。

ポリシーの定義

Azure Policyでは、Azure リソースと AKS の両方に適用されるさまざまな組み込みポリシー定義 (標準ポリシー定義など) と、Kubernetes 用の Azure Policy アドオン (クラスター内) の使用が提供されます。 Azure リソース ポリシーの多くは、 Audit/Deny と Deploy If Not Exists バリアントの 両方に含まれています。

多数のポリシーがあり、この柱に関連する主要なポリシーをここにまとめます。 詳細なビューについては、「 Kubernetes の組み込みポリシー定義」を参照してください。

クラスターとワークロードのアーキテクチャ

  • CPU リソースとメモリ リソースの制限

組み込みのポリシーに加えて、カスタム ポリシーは、AKS リソースと Kubernetes 用のAzure Policy アドオンの両方に対して作成できます。 これにより、クラスターとワークロードのアーキテクチャで適用するセキュリティ制約をさらに追加できます。

その他のリソース

Azure アーキテクチャ センターのガイダンス

クラウド導入フレームワークのガイダンス

次の手順