Azure Kubernetes Service (AKS) の AKS on Azure Local のベースライン アーキテクチャ
このシナリオでは、Azure Local で実行される Microsoft Azure Kubernetes Service (AKS) のベースライン アーキテクチャを設計して実装する方法を示します。
この記事には、組織のビジネス要件に基づいたクラスターのネットワーク、セキュリティ、ID、管理、監視に関する推奨事項が記載されています。
重要
この記事の情報は、Azure Local の AKS と Windows Server 上の AKS に適用されます。 最新バージョンの AKS は、Azure Stack HCI バージョン 23H2 オペレーティング システムで実行されます。 最新バージョンの詳細については、「 AKS on Azure Local」を参照してください。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
コンポーネント
エッジまたはオンプレミスには、次のコンポーネントがインストールされます。
Azure Local は、仮想化された Linux および Windows ワークロードとそのストレージをハイブリッドオンプレミス環境でホストするハイパーコンバージド インフラストラクチャ (HCI) クラスター ソリューションです。 Azure ローカル インスタンスは、1 から 16 ノードの範囲のクラスターで構成されます。
Azure Arc リソース ブリッジ は、Azure Local で実行される高可用性仮想マシン (VM) です。 リソース ブリッジは、複数の AKS クラスターのデプロイと管理を担当します。
AKS on Azure Local は、大規模なコンテナー化されたアプリケーションの実行を自動化する AKS のオンプレミス実装です。 AKS on Azure Local クラスターには、高可用性コントロール プレーン ノードとワーカー ノードが含まれています。 コンテナー化されたアプリケーションは、AKS クラスター内のワーカー ノードで実行されます。 アプリケーションの分離を実現するには、最大 32 個の AKS クラスターをデプロイできます。 AKS クラスターは、次のコンポーネントで構成されます。
コントロール プレーンは Azure Linux 上で実行され、Kubernetes API と対話する API サーバー コンポーネントが含まれています。 また、分散キー値ストアである etcd を使用して、クラスターのすべての構成とデータを格納します。
ワーカー ノードは 、Azure Linux オペレーティング システムまたは Windows Server オペレーティング システムで実行されます。 コンテナー化されたアプリケーションをポッドでホストします。 ポッドはアプリケーションの単一インスタンスを表し、通常はコンテナーに 1 対 1 でマップします。 ただし、一部のポッドには複数のコンテナーが含まれています。 デプロイは、1 つ以上の同一ポッドで構成されます。 ポッドとデプロイは、これらのリソースの管理へのアクセスを定義する名前空間に論理的にグループ化されます。
次のコンポーネントが Azure にインストールされています。
Azure Arc は、Azure Resource Manager ベースの管理モデルを Azure 以外のリソース (Azure 以外の VM、Kubernetes クラスター、コンテナー化されたデータベースなど) に拡張するクラウドベースのサービスです。
Azure Automation は、Azure 環境と Azure 以外の環境にまたがる一貫した管理をサポートするクラウド ベースの自動化および構成サービスを提供します。
Azure Monitor は、クラウドおよびオンプレミス環境からテレメトリを収集、分析し、それに対応する包括的なソリューションを提供することで、アプリケーションやサービスの可用性とパフォーマンスを最大限に高めるクラウドベースのサービスです。
Azure Policy は、組織の標準を適用し、Azure Arc で有効になっているリソースを含む Azure をビジネス ルールに対するリソースのプロパティに評価することで、大規模なコンプライアンスを評価するのに役立つクラウドベースのサービスです。 これらの標準には、クラスター内で実行されるワークロードにポリシーを適用する Kubernetes 用の Azure Policy も含まれます。
Microsoft Defender for Cloud は、データセンターのセキュリティ体制を強化し、クラウドとオンプレミスのハイブリッド ワークロード全体で高度な脅威保護を提供する統合インフラストラクチャ セキュリティ管理システムです。
シナリオの詳細
考えられるユース ケース
AKS のオンプレミス Kubernetes 実装で、高可用性に対応したコンテナーベースのワークロードを実装する。
コンテナー化されたアプリケーションの大規模な実行を自動化する。
Microsoft 認定ソリューション、クラウドベースの自動化、一元管理、一元的な監視を使用して、総保有コスト (TCO) を削減します。
認定ハードウェア
セキュア ブート、United Extensible Firmware Interface (UEFI)、トラステッド プラットフォーム モジュール (TPM) の設定をすぐに利用できる Azure Local 認定ハードウェアを使用します。 コンピューティング要件は、アプリケーションと、Azure Local で実行されるすべての AKS クラスター内のコントロール プレーン ノードとワーカー ノードの合計数によって異なります。 高可用性を実現するには、Azure Local のデプロイに複数の物理ノードを使用します。 すべてのサーバーは同じ製造元とモデルであり、64 ビット Intel Nehalem グレード、AMD EPYC グレード、またはそれ以降の互換性のあるプロセッサを使用して、第 2 レベルのアドレス変換をサポートする必要があります。
ネットワークの要件
Kubernetes は、Kubernetes ノードを仮想オーバーレイ ネットワークに接続することで、ネットワークに抽象化レイヤーを提供します。 また、kube-proxy コンポーネントを介したポッドの受信接続と送信接続も提供します。
このアーキテクチャでは、静的 IP アドレス ネットワークを使用して IP アドレスを割り当てる仮想オーバーレイ ネットワークを使用します。 このアーキテクチャでは、コンテナー ネットワーク インターフェイス プロバイダーとして Calico が使用されます。 静的 IP アドレス ネットワークには、デプロイ内のすべてのオブジェクトに対して定義済みのアドレス プールが必要です。 追加の利点が追加され、ワークロードとアプリケーションに常に到達可能であることを保証します。 別の IP アドレス プールを使用して、Kubernetes サービスに IP アドレスを割り当てます。
ネットワーク仕様は、Azure Local の 論理ネットワーク として定義されます。 Azure Local で論理ネットワークを作成する前に、 ネットワーク要件 と IP アドレスの計画を参照してください。
ストレージの要件
クラスター内のすべてのサーバーで、サイズとモデルが同じである同じ種類のドライブを使用します。 Azure Local は、直接接続されたシリアル高度なテクノロジの添付ファイル、シリアル接続された小さなコンピューター システム インターフェイス、不揮発性メモリエクスプレス、または 1 台のサーバーに物理的に接続された永続メモリ ドライブと連携します。 クラスター ボリュームの場合、HCI は記憶域スペース ダイレクトなどのソフトウェアで定義された記憶域テクノロジを使用して、フォールト トレランス、スケーラビリティ、パフォーマンスのために記憶域プール内の物理ドライブを結合します。 AKS on Azure Local で実行されるアプリケーションでは、多くの場合、次のストレージ オプションが使用できる必要があります。
ボリュームは 、ポッド間およびアプリケーションライフ サイクルを通じてデータを格納、取得、保持する方法を表します。
永続ボリューム は、Kubernetes API によって作成および管理されるストレージ リソースです。 これらは、個々のポッドの有効期間を超えて存在する可能性があります。
コストとパフォーマンスを最適化するために、さまざまな層と場所にストレージ クラスを定義することを検討してください。 ストレージ クラスは、永続ボリュームの動的プロビジョニングをサポートします。また、ポッドが削除されたときに永続ボリュームを管理するために、基盤となるストレージ リソースのアクションを指定する reclaimPolicy を定義します。
Azure Local での AKS の作成と管理
管理する他の Azure リソースと同様に、Azure Local で AKS を作成して管理する必要があります。 Azure portal、Azure CLI、Azure Resource Manager テンプレート (ARM テンプレート)、または Bicep を使用できます。
Azure Arc 対応 Kubernetes サービスは、Azure ローカル インスタンス上の AKS の Resource Manager 表現を提供します。 AKS on Azure Local クラスターを作成すると、Azure Arc エージェントが Kubernetes 名前空間に自動的にデプロイされ、ログとメトリックが収集され、クラスター メタデータ、Kubernetes のバージョン、ノード数が収集されます。
推奨されるサービスと拡張機能
ほとんどのシナリオには、次の推奨事項が適用されます。 優先すべき特定の要件がない限り、これらの推奨事項に従ってください。 次の Azure サービスは、AKS クラスターと同じ Azure リージョンにデプロイする必要があります。
MetalLB 拡張機能を使用して、L2 負荷分散のために AKS クラスターに MetalLB ロード バランサーをデプロイします。
Azure Monitor Container Insights を有効にして、Linux ノード プールと Windows ノード プールの両方で実行されるコンテナー ワークロードのパフォーマンスを監視します。 メトリック API を使用して、コントローラー、ノード、コンテナーからメモリとプロセッサのメトリックを収集します。 Container Insights を使用すると、メモリとプロセッサの使用状況を特定し、Kubernetes クラスターの全体的なパフォーマンスを検出し、クラスターの動作を理解し、事前に監視するためのアラートを構成できます。
エンド ツー エンド管理に使用可能な Automation 機能を使用します。 AKS には、OS の更新プログラムや、Azure Local ベンダーやパートナーのファームウェアやドライバーなどのフル スタック更新プログラムなど、さまざまな自動化機能が用意されています。 Windows PowerShell は、Azure ローカル コンピューターのいずれかからローカルに実行することも、管理コンピューターからリモートで実行することもできます。 Azure Automation と Azure Arc との統合では、仮想化されたワークロードとコンテナー化されたワークロードに対するさまざまな自動化シナリオがサポートされます。
Azure Policy でガバナンスを適用して、大規模なリソース制御を適用します。 Azure Policy は、Open Policy Agent のアドミッション コントローラー Webhook である Gatekeeper v3 を拡張して、ポッド、コンテナー、名前空間などの AKS コンポーネントにセーフガードを一元的に適用します。
Flux v2 構成と Kubernetes 用 Azure Policy を使用してアプリケーションを一貫してデプロイし、スケーラブルなポリシー駆動型デプロイを実現します。 組み込みのポリシー定義を選択し、Flux セットアップ用の特定のパラメーターを持つポリシー割り当てを作成できます。 懸念事項の分離をサポートするには、クラスター管理者用の 1 つの Git リポジトリとアプリケーション チーム用の別のリポジトリなど、別々のソースを指す異なる Flux 構成を持つ複数の割り当てを作成します。
考慮事項
これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「 Well-Architected Framework」を参照してください。
[信頼性]
信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。
アプリケーションの最小可用性要件を満たすために、Kubernetes クラスターに 3 ~ 5 個のコントロール プレーン ノードと複数のワーカー ノードを実装します。
フェールオーバー クラスタリングの要件を確認します。 AKS デプロイでは、高可用性とフォールト トレランスのためにフェールオーバー クラスタリングとライブ マイグレーションが使用されます。 ライブ マイグレーションは Hyper-V 機能であり、実行中の VM を 1 つの Hyper-V ホストから別のホストに透過的に移動でき、ダウンタイムが発生しません。
デプロイ、アフィニティ マッピング、ReplicaSets などの Kubernetes 機能を使用するようにデプロイを構成して、中断シナリオでポッドの回復性を確保します。
パブリック コンテナー イメージの使用を制限し、Azure Container Registry などのサービス レベル アグリーメントを制御できるコンテナー レジストリからのみプルします。
セキュリティ
セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。 詳細については、「セキュリティの設計レビュー チェックリスト」を参照してください。
ホストとそのコンテナーの両方をセキュリティで保護して、スタック全体に焦点を当てます。
インフラストラクチャのセキュリティ
セキュア ブート、UEFI、TPM の設定をすぐに利用できる Azure Local 認定ハードウェアを使用します。 これらのテクノロジは、 仮想化ベースのセキュリティと組み合わせることで、セキュリティに依存するワークロードを保護するのに役立ちます。 検証済みソリューションの詳細については、 Azure ローカル ソリューションに関するページを参照してください。
セキュア ブートを使用して、元の機器の製造元が信頼するソフトウェアのみをサーバーが起動するようにします。
UEFI を使用して、サーバーの起動プロセスを制御します。
TPM を使用して暗号化キーを保存し、ハードウェアベースのセキュリティ関連のすべての機能を分離します。
BitLocker ドライブ暗号化を使用して、保存時の記憶域スペース ダイレクト ボリュームを暗号化します。
Defender for Cloud を使用して、サーバーとクラスターのセキュリティ設定を管理します。 Azure Arc 対応 Kubernetes クラスターに脅威保護を提供します。 Defender for Cloud 拡張機能は、クラスター内のノードからデータを収集し、さらに分析するためにクラウドの Azure Defender for Kubernetes バックエンドに送信します。
ロールの割り当てと AKS クラスターへのアクセスの管理には 、Azure ロールベースのアクセス制御 (Azure RBAC) を使用します。
ワークロード ポッドから Azure リソースにアクセスするための ID をセキュリティで保護および管理するには、ワークロード ID を使用します。
AKS には、キー管理サービス (KMS) プラグインを使用した etcd シークレットの暗号化が付属しています。 すべての AKS クラスターでは、組み込みの KMS プラグインが既定で有効になっています。 このプラグインは暗号化キーを生成し、30 日ごとに自動的にローテーションします。
アプリケーションのセキュリティ
AKS on Azure Local インスタンスで Azure Key Vault シークレット プロバイダー拡張機能 を使用して、さまざまなアプリケーションで使用されるシークレットを Key Vault に格納することでさらに保護します。
Kubernetes 用の Azure Policy を使用して、特権ポッドがないなどのクラスター セキュリティ ポリシーを適用します。
コンテナー リポジトリで脆弱性スキャンを含む Container Registry インスタンスを使用します。
コンテナーのセキュリティ
不要なサービスを削除して、ホストとデーモンの環境を強化します。
イメージとは別にシークレットを保持し、コンテナー オーケストレーション エンジン経由でのみそれらをマウントします。
脆弱性スキャンと Azure RBAC をサポートする Container Registry インスタンス内のイメージをセキュリティで保護します。
コンテナーの分離を使用 し、コンテナーが侵害された場合に攻撃者が特権をエスカレートするのを防ぐために、特権モードでコンテナーを実行しないようにします。
コストの最適化
コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。
- Azure 料金計算ツールを使用して、アーキテクチャで使用される Azure Monitor Container Insights などの Azure サービスのコストを見積もります。 Well-Architected Framework のコスト最適化セクションでは、他のベスト プラクティスについて説明します。 AKS は、Azure Local で使用するときに追加料金なしで利用できます。 詳細については、「 Azure Local の価格の詳細」を参照してください。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスのデザイン レビュー チェック一覧」を参照してください。
コードとしてのインフラストラクチャ: ARM テンプレート、Bicep、または Terraform を使用して、クラスターのデプロイを大規模に自動化します。 Azure portal を使用して、クラスターの作成に使用できるオプションとサポートされているオプションを調べ、選択内容をテンプレートとしてエクスポートします。 スケーラブルなデプロイ オプションについては 、Azure 検証済みモジュール を確認してください。 詳細については、GitHub の ハイブリッド コンテナー サービス モジュール を参照してください。
Azure Arc: 追加の管理、メンテナンス、回復性の機能を提供する Azure Arc または Azure サービス (Azure Monitor や Log Analytics など) と統合します。
GitOps: Kubernetes コンポーネントを手動で構成する代わりに、自動ツールを使用して Kubernetes クラスターに構成を適用します。これらの構成はソース リポジトリにチェックインされるためです。 このプロセスは、多くの場合、 GitOps と呼ばれます。 Kubernetes の一般的な GitOps ソリューションには、Flux と Argo CD が含まれます。 このアーキテクチャでは、Flux に基づく Microsoft 提供の GitOps 拡張機能を使用することをお勧めします。
パフォーマンス効率
パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。 詳細については、「パフォーマンス効率の設計レビュー チェックリスト」を参照してください。
Azure Local 認定ハードウェアを使用して、アプリケーションのアップタイムとパフォーマンスの向上、管理と運用の簡素化、TCO の削減を実現します。
Azure Local での AKS の制限について説明します。 Microsoft では、クラスターあたり最大 16 台の物理サーバー、32 個の Kubernetes クラスター、200 台の VM を持つ Azure ローカル デプロイ上の AKS をサポートしています。
コントロール プレーン ノード、ワーカー ノード、および AKS クラスターの数に基づいて、Azure Local の AKS 要件を決定します。 ハードウェアのサイズを適切に設定するには、各 AKS クラスターに必要なポッド、コンテナー、ワーカー ノードの数を予測します。 計画された障害と計画外の障害の両方に対応するために、Azure ローカル容量の少なくとも 15% を予約します。
パフォーマンスの効率を高めるには、需要の変化やテクノロジの進化に合わせてその効率を維持しながら、システム要件を満たす方法でコンピューティング リソースを使用します。 一般に、メンテナンスや予期しない障害が原因でノードがオフラインになった場合、残りのノードには負荷の増加に対応できる十分な容量が必要です。
AKS ノード配置ロジックを確認します。 AKS on Azure Local は、 可用性セットを介して Azure ローカル配置ロジックを使用して、AKS クラスター内の各ノード プールのワーカー ノードを分散します。
IP アドレスの予約を計画して、AKS クラスターと Kubernetes サービスを構成します。
トラフィックの帯域幅の割り当てのために、ネットワーク パフォーマンスの最適化を実施します。
広範なワークロードにグラフィックス処理装置アクセラレーションを使用します。
共同作成者
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
プリンシパルの作成者:
- パラメッシュ・バブ |プリンシパル プログラム マネージャー
- Lisa DenBeste | プロジェクト管理プログラム マネージャー
- Kenny Harder | プロジェクト マネージャー
- Mike Kostersitz | プリンシパル プログラム マネージャー リード
- Meg Olsen | プリンシパル
- Nate Waters | 製品マーケティング マネージャー
その他の共同作成者:
- Walter Oliver | シニア プログラム マネージャー
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。