Azure Well-Architected Framework レビュー - Azure Kubernetes Service (AKS)
この記事では、Azure Kubernetes Service (AKS) のアーキテクチャに関するベスト プラクティスについて説明します。 このガイダンスは、アーキテクチャの卓越性の 5 つの柱に基づいています。
- 信頼性
- セキュリティ
- コストの最適化
- オペレーショナルエクセレンス
- パフォーマンス効率
システム設計の原則を理解し、Azure Kubernetes Service に関する実践的な知識があり、その機能に精通している読者を前提としています。 詳細については、「Azure Kubernetes Service」を参照してください。
前提条件
Well-Architected フレームワークの柱に関するガイダンスを理解すると、高品質で安定した効率的なクラウド アーキテクチャを作成するのに役立ちます。 Azure Well-Architected フレームワーク レビューの評価を使用してワークロードを確認することをお勧めします。
コンテキストについては、これらの考慮事項を設計に反映した参照アーキテクチャを確認することを検討してください。 Azure Kubernetes Service (AKS) クラスターのベースライン アーキテクチャと、Azure Kubernetes Service 上のマイクロサービス アーキテクチャから始めることをお勧めします。 また、AKS ランディング ゾーン アクセラレータも確認してください。スケーラブルな Azure Kubernetes Service (AKS) クラスターのランディング ゾーン サブスクリプションを準備するためのアーキテクチャのアプローチと参照の実装が用意されています。
信頼性
クラウドでは、障害が発生することを認識しています。 目標は、障害がまったく発生しないように努力することではなく、障害が発生した単一コンポーネントの影響を最小限に抑えることです。 次の情報を使用して、失敗したインスタンスを最小限に抑えます。
Azure Kubernetes Service での信頼性について検討する場合は、"クラスターの信頼性" と "ワークロードの信頼性" を区別することが重要です。 クラスターの信頼性は、クラスター管理者とそのリソース プロバイダーの間で共有される責任ですが、ワークロードの信頼性は開発者の領域です。 Azure Kubernetes Service には、これらの両方のロールに関する考慮事項とレコメンデーションがあります。
以下の設計チェックリストと推奨事項のリストでは各選択がクラスター アーキテクチャ、ワークロード アーキテクチャ、またはその両方に適用されるかどうかをコールアウトで示しています。
設計チェック リスト
- クラスター アーキテクチャ: 重要なワークロードの場合は、AKS クラスターの可用性ゾーンを使用します。
- クラスター アーキテクチャ: マルチクラスター トポロジでのフェールオーバー トラフィックの処理を含め、クラスターが確実にスケーリングできるように IP アドレス空間を計画します。
- クラスター アーキテクチャ: 「Azure Monitor を使用して Kubernetes を監視するためのベスト プラクティス」を参照して、実際のワークロードに最適な監視戦略を決定します。
- ワークロード アーキテクチャ: 水平スケーリングをサポートし、アプリケーションの準備状況と正常性を報告するようにワークロードが構築されていることを確認します。
- クラスターおよびワークロード アーキテクチャ: ワークロードがユーザー ノード プール上で実行されていることを確認し、適切なサイズの SKU を選択します。 少なくとも、ユーザー ノード プール用に 2 つのノード、システム ノード プール用に 3 つのノードを含めます。
- クラスター アーキテクチャ: AKS Uptime SLA を使用して、運用ワークロードの可用性目標を満たします。
AKS の構成に関する推奨事項
次のレコメンデーションの表を参照して、信頼性について AKS 構成を最適化します。
| 推奨 | 特長 |
|---|---|
| クラスターおよびワークロード アーキテクチャ: ノード セレクターとアフィニティを使用してポッドのスケジュールを制御します。 | Kubernetes のスケジューラが、ノード内のハードウェアによってワークロードを論理的に分離できるようにします。 容認とは異なり、ノード セレクターが一致しないポッドはラベル付きノードでスケジュールできます。これにより、ノード上の未使用リソースを使用できますが、一致するノード セレクターを定義するポッドが優先されます。 ノードのアフィニティを使用すると柔軟性が向上し、ポッドをノードと一致させることができない場合に起こる事象を定義できるようになります。 |
| クラスター アーキテクチャ: ネットワーク要件とクラスターのサイズ設定に基づいてネットワーク プラグインを適切に選択してください。 | Windows ベースのノード プール、特定のネットワーク要件、Kubernetes ネットワークポリシーなどといった特定のシナリオには Azure CNI が必要です。 詳細については、Kubernet と Azure CNI の比較に関する記事を参照してください。 |
| クラスターおよびワークロード アーキテクチャ: 運用グレードのクラスターには、AKS アップタイム SLA を使用します。 | AKS アップタイム SLA は、次のことを保証します。 - Azure Availability Zones を使用する AKS クラスターに対する Kubernetes API サーバー エンドポイントの 99.95% の可用性、または- 99.9% Azure Availability Zones を使用しない AKS クラスターに対する可用性 |
| クラスターおよびワークロード アーキテクチャ: 「Azure Monitor を使用して Kubernetes を監視するためのベスト プラクティス」を参照して、実際のワークロードに最適な監視戦略を決定します。 | 該当なし |
| クラスター アーキテクチャ: 可用性ゾーンを使用して、物理的に分離されたデータセンターに 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 Gateway を使用して、大規模な信頼性の高いエグレス トラフィックをサポートします。 |
その他の推奨事項については、信頼性の柱の原則を参照してください。
Azure Policy
Azure Kubernetes Service には、さまざまな組み込みの Azure ポリシーが用意されており、一般的な Azure ポリシーと同様に Azure リソースと、Kubernetes 用 Azure Policy アドオンを使用することでクラスター内にも適用されます。 ポリシーは数多くありますが、ここでは、この柱に関連する主要なポリシーをまとめます。 詳細については、Kubernetes の組み込みポリシー定義に関する記事を参照してください。
クラスターおよびワークロード アーキテクチャ
- クラスターには、ポッド仕様に合わせて構成された準備状況または稼働状況の正常性プローブがあります。
組み込みの Azure Policy 定義に加えて、AKS リソースと Kubernetes 用 Azure Policy アドオンの両方に対してカスタム ポリシーを作成できます。 こうすると、クラスターおよびワークロード アーキテクチャに適用する信頼性の制約をさらに追加できます。
セキュリティ
セキュリティは、あらゆるアーキテクチャの最も重要な側面の 1 つです。 AKS でアプリケーション ワークロードのセキュリティを強化する方法については、「セキュリティ設計原則」を参照することをお勧めします。 Payment Card Industry Data Security Standard (PCI-DSS 3.2.1) の規制要件を満たす機密性の高いワークロードを実行するように Azure Kubernetes Service クラスターを設計する必要がある場合は、PCI-DSS 3.2.1 の AKS 規制クラスターに関する記事を参照してください。
AKS での DoD Impact Level 5 (IL5) のサポートと要件については、Azure Government IL5 の分離要件に関する記事を参照してください。
Azure Kubernetes Service でのセキュリティについて検討する場合は、"クラスターのセキュリティ" と "ワークロードのセキュリティ" を区別することが重要です。 クラスターのセキュリティは、クラスター管理者とそのリソース プロバイダーの間で共有される責任ですが、ワークロードのセキュリティは開発者の領域です。 Azure Kubernetes Service には、これらの両方のロールに関する考慮事項とレコメンデーションがあります。
以下の設計チェックリストおよび推奨事項のリストでは各選択がクラスター アーキテクチャ、ワークロード アーキテクチャ、またはその両方に適用されるかどうかをコールアウト表示で示しています。
設計チェック リスト
- クラスター アーキテクチャ: マネージド ID を使用して、サービス原則の管理とローテーションを回避します。
- クラスター アーキテクチャ: Microsoft Entra ID で Kubernetes ロールベースのアクセス制御 (RBAC) を使用して最小限の特権のアクセスを実現し、構成とシークレットのアクセスを保護するために管理者特権の付与を最小限に抑えます。
- クラスター アーキテクチャ: Microsoft Defender for Containers と Azure Sentinel を使用して、クラスターとそこで実行されているワークロード全体の脅威を検出し、迅速に対応します。
- クラスター アーキテクチャ: プライベート AKS クラスターをデプロイして、API サーバーへのクラスター管理トラフィックがプライベート ネットワーク上に留まるようにします。 または、非プライベート クラスターに対して API サーバー許可リストを使用します。
- ワークロード アーキテクチャ: Web Application Firewall を使用して HTTP(S) トラフィックをセキュリティで保護します。
- ワークロード アーキテクチャ: CI/CID パイプラインがコンテナー対応スキャンで強化されていることを確認します。
推奨事項
次のレコメンデーションの表を参照して、セキュリティについて AKS 構成を最適化します。
| 推奨 | 特長 |
|---|---|
| クラスター アーキテクチャ: Microsoft Entra 統合を使用します。 | Microsoft Entra ID を使うと、ID 管理コンポーネントが一元化されます。 ユーザー アカウントまたはグループの状態が変わると、AKS クラスターにアクセスしたとき、その変更内容が自動的に更新されます。 お使いの Kubernetes クラスターの開発者とアプリケーション所有者はさまざまなリソースへのアクセスを必要とします。 |
| クラスター アーキテクチャ: Azure Container Registry に対して Microsoft Entra ID を使用して認証します。 | AKS と Microsoft Entra ID では、imagePullSecrets シークレットを使用せずに Azure Container Registry で認証を可能にします。 詳細については、「Azure Kubernetes Service から Azure Container Registry の認証を受ける」を参照してください。 |
| クラスター アーキテクチャ: プライベート AKS クラスターを使用して、API サーバーへのネットワーク トラフィックをセキュリティで保護します。 | 既定では、ノード プールと API サーバー間のネットワーク トラフィックは Microsoft バックボーン ネットワークを経由します。プライベート クラスターを使用すると、API サーバーへのネットワーク トラフィックがプライベート ネットワーク上にのみ留まるようにすることができます。 |
| クラスター アーキテクチャ: 非プライベート AKS クラスターの場合は、API サーバーの認可された IP 範囲を使用します。 | パブリック クラスターを使用する場合でも、認可された IP 範囲機能を使用して、クラスター API サーバーに到達できるトラフィックを制限できます。 デプロイ ビルド エージェント、運用管理、ノード プールのエグレス ポイント (Azure Firewall など) のパブリック IP などのソースを含めます。 |
| クラスター アーキテクチャ: Microsoft Entra RBAC を使用して API サーバーを保護します。 | Kubernetes API Server へのアクセスをセキュリティで保護することは、クラスターをセキュリティで保護するためにできる最も重要な方法の 1 つです。 Kubernetes のロールベースのアクセス制御 (RBAC) を Microsoft Entra ID と統合して、API サーバーへのアクセスを制御します。 ローカル アカウントを無効にし、Microsoft Entra ID ベースの ID を使用してすべてのクラスター アクセスを適用します。 |
| クラスター アーキテクチャ: Azure ネットワーク ポリシーまたは Calico を使用します。 | クラスター内のポッド間のネットワーク トラフィックをセキュリティで保護し、制御します。 |
| クラスター アーキテクチャ: Azure Policy を使用してクラスターとポッドをセキュリティで保護します。 | Azure Policy は一貫した一元的な方法で、大規模な実施と保護をクラスターに適用します。 また、ポッドに付与される機能や、会社のポリシーに反する機能が実行されているかどうかを制御することもできます。 |
| クラスター アーキテクチャ: コンテナーからリソースへアクセスをセキュリティで保護します。 | コンテナーで実行できるアクションへのアクセスを制限します。 最小限のアクセス許可を付与し、ルートまたは特権エスカレーションの使用を避けます。 |
| ワークロード アーキテクチャ: Web Application Firewall を使用して HTTP(S) トラフィックをセキュリティで保護します。 | 受信トラフィックをスキャンして潜在的な攻撃を検出するには、Azure Application Gateway 上の Azure Web Application Firewall (WAF) や Azure Front Door などの Web アプリケーション ファイアウォールを使用します。 |
| クラスター アーキテクチャ: クラスターのエグレス トラフィックを制御します。 | クラスターの送信トラフィックが、Azure Firewall や HTTP プロキシなどのネットワーク セキュリティ ポイントを通過していることを確認します。 |
| クラスター アーキテクチャ: オープンソースの Microsoft Entra Workload ID と Secrets Store CSI Driver を Azure Key Vault と共に使用します。 | Azure Key Vault のシークレット、証明書、接続文字列を強力な暗号化で保護し、ローテーションします。 アクセス監査ログが用意されており、コア シークレットがデプロイ パイプラインに含まれないようにすることができます。 |
| クラスター アーキテクチャ: Microsoft Defender for Containers を使用します。 | クラスター、コンテナー、それらのアプリケーションのセキュリティを監視および維持します。 |
その他の推奨事項については、「セキュリティの重要な原則」を参照してください。
Azure Advisor は、Azure Kubernetes Service の確保と改善に役立ちます。 RBAC が構成されていないクラスター、Microsoft Defender 構成の欠落、API サーバーへの無制限のネットワーク アクセスなど、後述するポリシー セクションに記載されている項目の一部について推奨事項が作成されます。 同様に、ポッド セキュリティ イニシアティブ項目の一部についてワークロードに関する推奨事項が作成されます。 推奨事項の記事を参照してください。
ポリシーの定義
Azure Policy には、さまざまな組み込みのポリシー定義が用意されており、標準のポリシー定義と同様に Azure リソースと AKS と、Kubernetes 用 Azure Policy アドオンを使用することでクラスター内にも適用されます。 Azure リソース ポリシーの多くには、[監査] と [拒否] の両方が用意されていますが、[存在しない場合はデプロイする] のバリアントもあります。
ポリシーは数多くありますが、ここでは、この柱に関連する主要なポリシーをまとめます。 詳細については、Kubernetes の組み込みポリシー定義に関する記事を参照してください。
クラスター アーキテクチャ
- Microsoft Defender for Cloud ベースのポリシー
- 認証モードと構成ポリシー (Microsoft Entra ID、RBAC、ローカル認証の無効化)
- API サーバーのネットワーク アクセス ポリシー (プライベート クラスターを含む)
クラスターおよびワークロード アーキテクチャ
- Kubernetes クラスター ポッドのセキュリティ イニシアティブ Linux ベースのワークロード
- AppArmor、sysctl、セキュリティ キャップ、SELinux、seccomp、特権コンテナー、自動マウント クラスター API 資格情報などのポッドおよびコンテナー機能ポリシーを含めます
- マウント、ボリューム ドライバー、ファイルシステムのポリシー
- ポッドまたはコンテナーのネットワーク ポリシー (ホスト ネットワーク、ポート、許可される外部 IP、HTTP、内部ロード バランサーなど)
多くの場合、Azure Kubernetes Service デプロイでは、Helm chart とコンテナー イメージに Azure Container Registry も使用されます。 また、Azure Container Registry は、ネットワーク制限、アクセス制御、セキュリティで保護された AKS アーキテクチャを補完する Microsoft Defender for Cloud に及ぶさまざまな Azure ポリシーもサポートしています。
組み込みのポリシーに加えて、AKS リソースと Kubernetes 用 Azure Policy アドオンの両方に対してカスタム ポリシーを作成できます。 こうすると、クラスターおよびワークロード アーキテクチャに適用するセキュリティの制約をさらに追加できます。
その他の提案については、AKS のセキュリティの概念に関する記事を参照し、CIS Kubernetes ベンチマークに基づいてセキュリティ強化の推奨事項を評価してください。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させるために、さまざまな構成オプションと推奨されるベスト プラクティスを理解することです。 この記事のガイダンスに従う前に、次のリソースを確認することをお勧めします。
- コスト最適化の設計原則。
- Azure Kubernetes Service (AKS) における価格とコスト管理のしくみと Amazon Elastic Kubernetes Service (Amazon EKS) の比較。
- AKS をオンプレミスまたはエッジで実行している場合は、Azure ハイブリッド特典を使用して、そのようなシナリオでコンテナ化されたアプリケーションを実行する際のコストをさらに削減することもできます。
Azure Kubernetes Service によるコストの最適化を議論する場合は、"クラスター リソースのコスト" と "ワークロード リソースのコスト" を区別することが重要です。 クラスター リソースはクラスター管理者とそのリソース プロバイダー間の共有責任ですが、ワークロード リソースは開発者のドメインです。 Azure Kubernetes Service には、これらの両方のロールに関する考慮事項とレコメンデーションがあります。
設計チェックリストおよび推奨事項のリストでは各選択がクラスター アーキテクチャ、ワークロード アーキテクチャ、またはその両方に適用されるかどうかをコールアウト表示で示しています。
クラスターのコストの最適化については、Azure 料金計算ツールに移動し利用可能な製品から Azure Kubernetes Service を選択します。 計算ツールでは、さまざまな構成と支払いプランを試すことができます。
設計チェック リスト
- クラスター アーキテクチャ: 長期的な容量が必要なノード プールと予約インスタンスごとに適切な VM SKU を使用します。
- クラスターとワークロードのアーキテクチャ: 適切なマネージド ディスク層とサイズを使用します。
- クラスター アーキテクチャ: CPU、メモリ、ストレージ、ネットワークなどのパフォーマンス メトリックを確認して、クラスター、ノード、名前空間ごとのコスト最適化の機会を特定します。
- クラスターおよびワークロード アーキテクチャ: ワークロードのアクティブ性が低い場合は、自動スケーラーを使用してスケールインします。
推奨事項
次のレコメンデーションの表を参照して、コストについて AKS 構成を最適化します。
| 推奨 | 特長 |
|---|---|
| クラスターおよびワークロード アーキテクチャ: SKU の選択とマネージド ディスクのサイズをワークロードの要件に合わせます。 | 選択内容をワークロードの需要と一致させると、不要なリソースに対する支払いが発生しません。 |
| クラスター アーキテクチャ: 適切な仮想マシン インスタンスの種類を選択します。 | 適切な仮想マシン インスタンスの種類を選択することは、AKS でのアプリケーションの実行コストに直接影響するため、非常に重要です。 適切な使用率を考慮せずにハイパフォーマンスのインスタンスを選択すると、無駄な支出につながる可能性があります。一方、あまり強力ではないインスタンスを選択すると、パフォーマンスの問題やダウンタイムの増加につながる可能性があります。 適切な仮想マシン インスタンスの種類を決定するには、ワークロードの特性、リソース要件、可用性のニーズを考慮してください。 |
| クラスター アーキテクチャ: Arm アーキテクチャに基づいて仮想マシンを選択します。 | AKS は、ARM64 Ubuntu エージェント ノードの作成に加え、クラスター内での Intel と ARM アーキテクチャ ノードの混合をサポートしているため、より低コストで優れたパフォーマンスを実現できます。 |
| クラスター アーキテクチャ: Azure Spot Virtual Machines を選択します。 | スポット VM を使用すると、大幅な割引価格 (従量課金制の価格と比較して最大 90%) で未使用の Azure 容量を利用できます。 容量が Azure で再び必要になると、Azure インフラストラクチャはスポット ノードを削除します。 |
| クラスター アーキテクチャ: 適切なリージョンを選択します。 | 多くの要因があるため、リソースのコストは Azure のリージョンごとに異なります。 コスト、待機時間、コンプライアンスの要件を評価して、ワークロードをコスト効率よく実行し、エンドユーザーに影響を与えたり、追加のネットワーク料金が発生したりしないようにします。 |
| ワークロード アーキテクチャ: 小さく最適化されたイメージを維持します。 | イメージを合理化すると、コストの削減に役立ちます。新しいノードではこのようなイメージをダウンロードする必要があるからです。 コンテナーができるだけ早く起動できる方法でイメージをビルドし、オーバープロビジョニングにつながる可能性がある要求の失敗やタイムアウトがアプリケーションの起動中に発生しないようにします。 |
| クラスター アーキテクチャ: クラスター自動スケーラーを有効にして、過剰なリソース容量に対してエージェント ノード数が自動的に削減されるようにします。 | AKS クラスター内のノード数を自動的にスケールダウンすると、需要が低いときに効率的なクラスターを実行し、需要が戻ったときにスケールアップできます。 |
| クラスター アーキテクチャ: ノードの自動プロビジョニングを有効にして、VM SKU の選択を自動化します。 | ノードの自動プロビジョニングにより、SKU の選択プロセスが簡単になり、最も効率的でコスト効果の高い方法でワークロードを実行するために最適な VM 構成が保留中のポッド リソース要件に基づいて決定されます。 |
| ワークロード アーキテクチャ: 水平ポッド自動スケーラーを使用します。 | CPU 使用率または他の選択したメトリック (クラスターのスケールイン操作をサポートするもの) に応じて、デプロイ内のポッド数を調整します。 |
| ワークロード アーキテクチャ: 垂直ポッド自動スケーラー (プレビュー) を使用します。 | ポッドのサイズを適切にし、過去の使用状況に基づいて要求と制限を動的に設定します。 |
| ワークロード アーキテクチャ: Kubernetes Event Driven Autoscaling (KEDA) を使用します。 | 処理されるイベント数に基づいてスケーリングします。 50 個以上の KEDA スケーラーがそろう豊富なカタログから選択します。 |
| クラスターおよびワークロード アーキテクチャ: クラウドの財務規範と文化的プラクティスを採用して、クラウド使用の所有権を推進します。 | コスト最適化を可能にする基礎には、コスト削減クラスターの普及があります。 財務運用アプローチ (FinOps) は、組織がクラウドのコストを削減するためによく使用されます。 これは、コスト削減目標の調整を推進し、クラウド コストの透明性を実現するために、財務、運用、エンジニアリングの各チームが協力する手法です。 |
| クラスター アーキテクチャ: Azure Reservations または Azure 節約プランにサインアップします。 | 容量を適切に計画した場合、ワークロードは予測可能であり、長期間存在します。リソース コストをさらに削減するには、Azure 予約または節約プランにサインアップします。 |
| クラスター アーキテクチャ: 「Azure Monitor を使用して Kubernetes を監視するためのベスト プラクティス」を参照して、実際のワークロードに最適な監視戦略を決定します。 | 該当なし |
| クラスター アーキテクチャ: AKS Cost Analysis アドオンを構成します。 | コスト分析クラスター拡張機能を使用すると、クラスターまたは名前空間内のさまざまな Kubernetes リソースに関連付けられたコストについて詳細な分析情報を得ることができます。 |
その他の提案については、コスト最適化の柱の原則と Azure Kubernetes Service のコストの最適化に関する記事を参照してください。
ポリシーの定義
コストの最適化に関連する組み込みのポリシーはありませんが、AKS リソースと Kubernetes 用 Azure Policy アドオンの両方に対してカスタム ポリシーを作成できます。 こうすると、クラスターおよびワークロード アーキテクチャに適用するコスト最適化の制約をさらに追加できます。
クラウドの効率
ワークロードの持続可能性とクラウド効率を高めるには、コストの最適化、炭素排出量の削減、エネルギー消費の最適化に関する取り組みを組み合わせる必要があります。 アプリケーションのコストを最適化することは、ワークロードをより持続可能にするための第一歩です。
持続可能で効率的な AKS ワークロードを構築する方法については、Azure Kubernetes Service (AKS) における持続可能なソフトウェア エンジニアリングの原則に関する記事を参照してください。
オペレーショナルエクセレンス
監視と診断は非常に重要です。 パフォーマンス統計を測定するだけでなく、メトリックをトラブルシューティングと問題の迅速な修復に使用することもできます。 「オペレーショナル エクセレンスの設計原則」と Day-2 Operations ガイドに関する記事を確認することをお勧めします。
Azure Kubernetes Service を使ったオペレーショナル エクセレンスについて検討する場合は、"クラスターのオペレーショナル エクセレンス" と "ワークロードのオペレーショナル エクセレンス" を区別することが重要です。 クラスター操作はクラスター管理者とそのリソース プロバイダー間の共有責任ですが、ワークロード操作は開発者のドメインです。 Azure Kubernetes Service には、これらの両方のロールに関する考慮事項とレコメンデーションがあります。
以下の設計チェックリストおよび推奨事項のリストでは各選択がクラスター アーキテクチャ、ワークロード アーキテクチャ、またはその両方に適用されるかどうかをコールアウト表示で示しています。
設計チェック リスト
- クラスター アーキテクチャ: Bicep、Terraform などを使用したテンプレートベースのデプロイを使用します。 すべてのデプロイが反復可能でトレース可能であり、ソース コードのリポジトリに保存されている必要があります。
- クラスター アーキテクチャ: 必要なクラスター全体の構成とデプロイでクラスターがブートストラップされるように、自動プロセスを構築します。 多くの場合、これは GitOps を使用して実行されます。
- ワークロード アーキテクチャ: ソフトウェア開発ライフサイクル内のワークロードに対して、反復可能で自動化されたデプロイ プロセスを使用します。
- クラスター アーキテクチャ: 診断設定を有効にして、コントロール プレーンまたはコア API サーバーの対話が確実にログされるようにします。
- クラスターおよびワークロード アーキテクチャ: 「Azure Monitor を使用して Kubernetes を監視するためのベスト プラクティス」を参照して、実際のワークロードに最適な監視戦略を決定します。
- ワークロード アーキテクチャ: ワークロードは、収集可能なテレメトリを発行するように設計する必要があります。これには、稼働状態と準備状態も含める必要があります。
- クラスターおよびワークロード アーキテクチャ: Kubernetes を対象としたカオス エンジニアリング手法を使用して、アプリケーションまたはプラットフォームの信頼性の問題を特定します。
- ワークロード アーキテクチャ: コンテナー内で効率的に運用およびデプロイするようにワークロードを最適化します。
- クラスターおよびワークロード アーキテクチャ: Azure Policy を使用してクラスターとワークロードのガバナンスを適用します。
推奨事項
次のレコメンデーションの表を参照して、操作について AKS 構成を最適化します。
| 推奨 | 特長 |
|---|---|
| クラスターおよびワークロード アーキテクチャ: AKS のベスト プラクティスのドキュメントを参照してください。 | AKS でのアプリケーションを構築して実行するには、重要な考慮事項を理解して実装する必要があります。 これらの領域には、マルチ テナント機能とスケジューラ機能、クラスターとポッドのセキュリティ、または事業継続とディザスター リカバリーが含まれます。 |
| クラスターおよびワークロード アーキテクチャ: Azure Chaos Studio の記事を参照してください。 | Azure Chaos Studio は、障害をシミュレートし、ディザスター リカバリーの状況をトリガーするのに役立ちます。 |
| クラスターおよびワークロード アーキテクチャ: 「Azure Monitor を使用して Kubernetes を監視するためのベスト プラクティス」を参照して、実際のワークロードに最適な監視戦略を決定します。 | 該当なし |
| クラスター アーキテクチャ: 可用性を最大化し、ビジネス継続性を提供するために、異なる 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 リソース ポリシーの多くには、[監査] と [拒否] の両方が用意されていますが、[存在しない場合はデプロイする] のバリアントもあります。
ポリシーは数多くありますが、ここでは、この柱に関連する主要なポリシーをまとめます。 詳細については、Kubernetes の組み込みポリシー定義に関する記事を参照してください。
クラスター アーキテクチャ
- Kubernetes 用の Azure Policy アドオン
- GitOps 構成ポリシー
- 診断設定ポリシー
- AKS バージョンの制限事項
- コマンドの呼び出しを防ぐ
クラスターおよびワークロード アーキテクチャ
- 名前空間のデプロイに関する制限事項
組み込みのポリシーに加えて、AKS リソースと Kubernetes 用 Azure Policy アドオンの両方に対してカスタム ポリシーを作成できます。 こうすると、クラスターおよびワークロード アーキテクチャに適用するセキュリティの制約をさらに追加できます。
パフォーマンス効率
パフォーマンス効率とは、ユーザーからの要求に合わせて効率的な方法でワークロードをスケーリングできることです。 パフォーマンス効率の原則に関するページを確認することをお勧めします。
Azure Kubernetes Service のパフォーマンスについて検討する場合は、"クラスターのパフォーマンス" と "ワークロードのパフォーマンス" を区別することが重要です。 クラスターのパフォーマンスは、クラスター管理者とそのリソース プロバイダーの間で共有される責任ですが、ワークロードのパフォーマンスは開発者の領域です。 Azure Kubernetes Service には、これらの両方のロールに関する考慮事項とレコメンデーションがあります。
以下の設計チェックリストおよび推奨事項のリストでは各選択がクラスター アーキテクチャ、ワークロード アーキテクチャ、またはその両方に適用されるかどうかをコールアウト表示で示しています。
設計チェック リスト
Azure Kubernetes Service の設計を選択する際には、パフォーマンス効率の原則に関する記事を参照してください。
- クラスターおよびワークロード アーキテクチャ: SKU、自動スケーリング設定、IP アドレス指定、フェールオーバーに関する考慮事項を含む詳細な容量計画の演習を実行し、繰り返します。
- クラスター アーキテクチャ: クラスター自動スケーラーを有効にし、ワークロードの需要に従ってエージェント ノード数を自動的に調整します。
- クラスター アーキテクチャ: 水平ポッド自動スケーラーを使用して、CPU 使用率やその他の選択したメトリックに応じてデプロイ内のポッドの数を調整します。
- クラスターおよびワークロード アーキテクチャ: ポッドとクラスター自動スケーラーの両方を実行する継続的なロード テスト アクティビティを実行します。
- クラスターおよびワークロード アーキテクチャ: ワークロードを異なるノード プールに分割し、独立したスケーリングを可能にします。
推奨事項
次の表に記載されている推奨事項を参照して、パフォーマンスを向上させるために Azure Kubernetes Service 構成を最適化します。
| 推奨 | 特長 |
|---|---|
| クラスターおよびワークロード アーキテクチャ: 詳細な容量計画を作成し、継続的に確認と修正を行います。 | 容量計画を正式に策定した後は、クラスターのリソース使用率を継続的に監視して、頻繁に更新する必要があります。 |
| クラスター アーキテクチャ: クラスター自動スケーラーを有効にし、リソースの制約に従ってエージェント ノード数を自動的に調整します。 | AKS クラスター内のノードの数を自動的に増減するこの機能を使用すると、効率的で、コスト効率の高いクラスターを実行できます。 |
| クラスターおよびワークロード アーキテクチャ: ワークロードを異なるノード プールに分割し、ユーザー ノード プールをスケーリングすることを検討します。 | 常にノードを実行しておく必要があるシステム ノード プールとは異なり、ユーザー ノード プールはスケールアップまたはダウンできます。 |
| ワークロード アーキテクチャ: AKS の高度なスケジューラ機能を使用します。 | ワークロードに必要なリソースのバランスを制御するのに役立ちます。 |
| ワークロード アーキテクチャ: 意味のあるワークロード スケーリング メトリックを使用します。 | すべてのスケールの決定を CPU またはメモリのメトリックから導き出せるわけではありません。 多くの場合、スケールに関する考慮事項は、より複雑な、または外部のデータ ポイントから生まれます。 KEDA を使用して、ワークロードに固有のシグナルに基づいて意味のある自動スケーリング ルールセットを構築します。 |
その他の推奨事項については、パフォーマンス効率の柱の原則を参照してください。
ポリシーの定義
Azure Policy には、さまざまな組み込みのポリシー定義が用意されており、標準のポリシー定義と同様に Azure リソースと AKS と、Kubernetes 用 Azure Policy アドオンを使用することでクラスター内にも適用されます。 Azure リソース ポリシーの多くには、[監査] と [拒否] の両方が用意されていますが、[存在しない場合はデプロイする] のバリアントもあります。
ポリシーは数多くありますが、ここでは、この柱に関連する主要なポリシーをまとめます。 詳細については、Kubernetes の組み込みポリシー定義に関する記事を参照してください。
クラスターおよびワークロード アーキテクチャ
- CPU とメモリ リソースの制限
組み込みのポリシーに加えて、AKS リソースと Kubernetes 用 Azure Policy アドオンの両方に対してカスタム ポリシーを作成できます。 こうすると、クラスターおよびワークロード アーキテクチャに適用するセキュリティの制約をさらに追加できます。
その他のリソース
Azure アーキテクチャ センター ガイダンス
クラウド導入フレームワークのガイダンス
次のステップ
- Azure CLI を使用して Azure Kubernetes Service (AKS) クラスターをデプロイします。「クイックスタート: Azure CLI を使用して Azure Kubernetes Service (AKS) クラスターをデプロイする」