編集

AKS on Azure Stack HCI のネットワーク アーキテクチャ

Azure Stack
Windows Server

このシナリオでは、Azure Kubernetes Service (AKS) ハイブリッド クラスターに AKS ノードをデプロイするためのネットワークの概念を設計して実装する方法を説明します。

この記事には、Kubernetes ノードと Kubernetes コンテナーのネットワーク設計に関する推奨事項が記載されています。 これは、2 つの記事から成るアーキテクチャ ベースライン ガイダンス セットの一部です。 ベースライン アーキテクチャに関する推奨事項については、こちらを参照してください。

アーキテクチャ

次の図は、Azure Stack HCI または Windows Server 2019/2022 Datacenter クラスター上の Azure Kubernetes Service のネットワーク アーキテクチャを示しています。

Conceptual graphic showing network baseline architecture.

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

このシナリオは、次のコンポーネントと機能で構成されています。

  • Azure Stack HCI (20H2) は、オンプレミスのハイブリッド環境で仮想化された Windows および Linux のワークロードとそのストレージをホストするハイパーコンバージド インフラストラクチャ (HCI) クラスター ソリューションです。 Azure Stack HCI クラスターは、2 から 4 ノードのクラスターとして実装されます。
  • Windows Server 2019/2022 Datacenter フェールオーバー クラスターは、クラスター化されたロールの可用性およびスケーラビリティを向上させるために、互いに連携する独立したコンピューターをグループ化したものです。
  • Azure Kubernetes Service on Azure Stack HCI (AKS ハイブリッド) は、Azure Kubernetes Service (AKS) のオンプレミスの実装であり、コンテナー化されたアプリケーションの大規模な実行を自動化します。
  • [Active Directory Domain Services][] は、ネットワーク上のオブジェクトに関する情報を保存する階層構造です。 ユーザー、コンピューター、アプリケーション、またはセキュリティ境界内に含まれているその他のリソースに関連付けられている ID の ID およびアクセス ソリューションを提供します。
  • AKS ホストとも呼ばれる [管理クラスター][] は、複数のワークロード クラスターのデプロイと管理を担当します。 管理クラスターはノード プールから 1 つの IP アドレスを使用しますが、更新操作のために別に 2 つの IP を予約しておく必要があります。 また、管理クラスターは VIP プールから 1 つの IP も使用します。
  • [ワークロード クラスター][] は Kubernetes の高可用性デプロイであり、Kubernetes コントロール プレーン コンポーネントおよび Linux/Windows ワーカー ノードを実行するために Linux VM を使用しています。
    • コントロール プレーン。 Linux ディストリビューションで実行され、Kubernetes API と分散キー値ストア etcd との対話用の API サーバー コンポーネントが含まれており、クラスターのすべての構成とデータを格納します。 ノード プールから 1 つの IP と VIP プールから 1 つの IP を使用します。
    • ロード バランサー。 Linux VM 上で実行され、ワークロード クラスターに負荷分散サービスを提供します。 ノード プールから 1 つの IP と VIP プールから 1 つの IP を使用します。
    • ワーカー ノード。 コンテナー化されたアプリケーションをホストする Windows または Linux オペレーティング システムで実行されます。 ノード プールからの IP アドレスが使用されますが、更新操作のためにさらに 3 つ以上の IP アドレスを計画する必要があります。
    • Kubernetes リソース。 ポッドはアプリケーションの単一のインスタンスを表します。通常、ポッドはコンテナーと 1 対 1 でマッピングされますが、特定のポッドに複数のコンテナーが含まれる場合もあります。 デプロイは、1 つ以上の同一のポッドを表します。 ポッドとデプロイは、リソースの管理へのアクセスを制御する 1 つの名前空間に論理的にグループ化されます。 VIP プールからポッドごとに 1 つの IP を使用します。
  • [Azure Arc][] はクラウドベースのサービスであり、Azure Resource Manager ベースの管理モデルは仮想マシン (VM)、Kubernetes クラスター、コンテナー化データベースなど Azure 以外のリソースにまで拡張されます。
  • [Azure Policy][] は、プロパティをカスタマイズ可能なビジネス ルールと比較して、Azure とオンプレミスのリソースを Azure Arc との統合によって評価するクラウドベースのサービスです。
  • [Azure Monitor][] は、クラウドおよびオンプレミス環境からテレメトリを収集、分析し、それに対応する包括的なソリューションを提供して、アプリケーションやサービスの可用性とパフォーマンスを最大限に高めるクラウドベースのサービスです。
  • [Microsoft Defender for Cloud][] は統合されたインフラストラクチャ セキュリティ管理システムであり、データ センターのセキュリティ体制を強化し、クラウドとオンプレミスのハイブリッド ワークロード全体に高度な脅威保護を提供します。

コンポーネント

  • [Azure Stack HCI (20H2)][1]
  • [Windows Server 2019/2022 Datacenter フェールオーバー クラスター][]
  • [Azure Kubernetes Service (AKS)][]
  • [Windows Admin Center][]
  • [Azure サブスクリプション][]
  • [Azure Arc][2]
  • [Azure のロールベースのアクセス制御 (RBAC)][]
  • [Azure Monitor][3]
  • [Microsoft Defender for Cloud][4]

シナリオの詳細

このシナリオのユース ケースについては、シリーズの最初の記事であるベースライン アーキテクチャを参照してください。

Kubernetes ノード ネットワーク

AKS on Azure Stack HCI のネットワーク設計における主な考慮事項は、十分な IP アドレスを提供するネットワーク モデルを選択することです。 AKS on Azure Stack HCI では、仮想ネットワークを使用して、Kubernetes ノード リソースに IP アドレスを割り当てます。 次の 2 つの IP アドレス割り当てモデルを使用できます。

  • 静的 IP ネットワークは予測可能ですが、初期構成に余分な作業が追加されます。
  • 動的ホスト構成プロトコル (DHCP) ネットワークでは、IP アドレスの動的割り当てを使用し、作業は少なくなりますが、使用可能な IP プールを使い果たさないように注意する必要があります。 また、仮想 IP プールやクラウド エージェント サービスなどの特定のクラスター全体のリソースに対する予約と除外範囲を管理する必要もあります。

どちらの割り当てモデルでも、次の IP アドレスを計画する必要があります。

  • 仮想 IP プール
  • Kubernetes ノード VM IP プール

仮想 IP プール

仮想 IP プールは、すべての AKS on Azure Stack HCI デプロイに必須の IP アドレスのセットです。 ワークロード クラスターと Kubernetes サービスの数に基づいて、仮想 IP プール内の IP アドレスの数を計画します。 仮想 IP プールは、次の種類のリソースに IP アドレスを提供します。

  • クラウド エージェントには、仮想 IP プールからのフローティング IP アドレスが必要です。

  • Kubernetes 仮想アプライアンス (KVA) 仮想マシン (管理クラスター) 内で実行される API サーバー コンポーネントは、仮想 IP プールからの IP アドレスを使用します。 API サーバーは、Kubernetes API を公開する Kubernetes コントロール プレーンのコンポーネントです。 API サーバーは、Kubernetes コントロール プレーンのフロントエンドです。 KVA は Mariner Linux を実行する仮想マシンであり、Kubernetes クラスターをホストします。 IP アドレスはフローティングであり、AKS on Azure Stack HCI にデプロイする他の KVA VM にも使用されます。 また、KVA 仮想マシンは、Kubernetes 仮想 IP ロード バランサー サービスをホストします。

  • ターゲット サーバーにデプロイされているコントロール プレーン VM の数の IP アドレス指定を計画します。仮想 IP プールからさらに IP アドレスが使用されるためです。 考慮事項については、次のセクションで説明します。

  • ターゲット クラスターにはロード バランサー VM が含まれています。これは HAProxy であり、ターゲット クラスターの仮想 IP プールを所有します。 この VM は、仮想 IP プールを介してすべての Kubernetes サービスを公開します。

  • Kubernetes ポッドで実行されるアプリケーションでは、仮想 IP プールからの IP アドレスが使用されます。

  • HAProxy ロード バランサーは、特殊な仮想マシンとしてデプロイされ、複数のエンドポイント全体で受信要求を負荷分散するために使用できます。 仮想 IP プールからの IP アドレスが使用されるため、すべてのワークロード クラスターの IP アドレス指定を計画する必要があります。

Kubernetes ノード VM IP プール

Kubernetes ノードは、AKS on Azure Stack HCI デプロイ内の仮想マシンとしてデプロイされます。 Kubernetes ノードの合計数に応じて IP アドレスの数を計画し、アップグレード プロセス中に使用される IP アドレスをさらに 3 つ以上含めてください。 静的 IP アドレス構成の場合は、Kubernetes ノード VM IP プールの範囲を指定する必要があります。これは DHCP 割り当てには不要です。 次の追加 IP アドレスを計画します。

  • KVA VM では、Kubernetes ノード VM IP プールから Kubernetes 用にさらに多くの IP アドレスが使用されます。 KVA VM は API サービスに同じ仮想 IP を使用しますが、Kubernetes ノード VM IP プールとは別の IP を必要とするため、更新プロセス中に IP アドレスを追加することを計画します。
  • コントロール プレーン VM は、API サーバー サービスに Kubernetes ノード VM IP プールから 1 つの IP を使用します。 これらの仮想マシンでは、管理目的で Azure portal に接続している Azure ARC エージェントもホストされます。
  • ノード プール内のノード (Linux または Windows) は、Kubernetes ノード VM に割り当てられた IP プールから IP アドレスを使用します。

Microsoft オンプレミス クラウド サービス

Azure Stack HCI 上の VM がクラウドで管理されるように管理スタックを有効にする、Microsoft オンプレミス クラウド (MOC) の IP アドレス範囲を計画します。 MOC サービスの IP アドレス割り当ては、基になる物理ネットワーク上で行われ、Azure Stack HCI クラスター ノード用に構成された IP アドレスはお使いのデータ センター内にあります。 Azure Stack HCI の物理ノードの IP アドレスは、次のいずれかの方法で構成できます。

  • DHCP ベースの IP アドレス割り当てモードを使用した Azure Stack HCI クラスター ノード。 MOC サービスでは、物理ネットワーク上に表示される IP アドレスを DHCP サービスから取得します。
  • 静的 IP 割り当てモデルを使用した Azure Stack HCI クラスター ノード。 MOC クラウド サービスの IP アドレスは、クラスレス ドメイン間ルーティング (CIDR) 形式で IP 範囲として明示的に指定する必要があり、Azure Stack HCI クラスター ノードの IP アドレスと同じサブネット内に存在する必要があります。

AKS on Azure Stack HCI のロード バランサー

小規模なデプロイの場合、HAProxy + KeepAlive を使用する Linux VM としてデプロイされた組み込みのロード バランサーを使用して、AKS クラスターの一部としてデプロイされたアプリケーション サービスにトラフィックを送信できます。 HAProxy ロード バランサーは、ポッドをロード バランサーのエンドポイントとして構成します。 これにより、Kubernetes API サーバーへの要求が負荷分散され、アプリケーション サービスへのトラフィックが管理されます。

また、サービスへのトラフィックを管理するためにカスタム ロード バランサーを使用することもできます。 カスタム ロード バランサーを使用すると、デプロイの柔軟性が向上し、AKS on Azure Stack HCI が、ロード バランサーを使用するソフトウェア定義ネットワーク (SDN) デプロイなどの既存のデプロイと共に機能することが確実になります。 カスタム ロード バランサーの場合、kube-virtual IP は Kubernetes クラスターに、コントロール プレーンと LoadBalancer という種類の Kubernetes サービスの両方の仮想 IP とロード バランサーを提供します。 kube-virtual IP サービスは、すべてのワーカー ノードに自動的にデプロイされます。

AKS on Azure Stack HCI では、ワークロード クラスター内のサービス宛てのトラフィックのバランスを取るために、MetalLB または他の OSS Kubernetes ベースのロード バランサーの使用もサポートされています。 MetalLB とは、Border Gateway Protocol BGP などの標準ルーティング プロトコルを使用する、ベアメタル Kubernetes クラスター用のロード バランサー実装です。 これは、Calico と Flannel の両方のネットワーク アドオンで機能しますが、AKS on Azure Stack HCI のインストール時に提供される仮想 IP アドレス範囲が、カスタム ロード バランサー用に計画されている IP アドレス範囲と重複しないようにする必要があります。

このシナリオのデプロイ

イングレス コントローラーをデプロイする

TLS 終端、リバーシブル プロキシ、または構成可能なトラフィック ルーティング用の [イングレス コントローラー][] を実装することを検討してください。 イングレス コントローラーはレイヤー 7 で動作し、インテリジェントなルールを使用してアプリケーションのトラフィックを分散させることができます。 個別の Kubernetes サービスのイングレス ルールとルートを構成するには、Kubernetes イングレス リソースが使われます。 イングレス コントローラーを定義すると、トラフィックのルーティング規則がクラスターの一部として実行される 1 つのリソースに統合されます。

イングレス コントローラーを使用して外部から到達可能な URL を介してサービスを公開します。 イングレスが、クラスターの外部からクラスター内のサービスへの HTTP と HTTPS のルートを公開します。 トラフィック ルーティングは、イングレス リソースで定義されるルールによって制御されます。 イングレス HTTP ルールには、次の情報が含まれます。

  • オプションのホスト。 ホスト情報を指定しない場合、ルールはすべての受信 HTTP トラフィックに適用されます。
  • service.name と service.port.name または service.port.number で定義されたバックエンドが関連付けられているパスの一覧。
  • サービス名とポート名の組み合わせを提供するバックエンド。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: test.example.com
     http:
       paths:
       - path: /hello-world
          pathType: Prefix
          backend:
            service:
              name: hello-world
              port:
                 number: 8080

イングレス コントローラーを使用して、アプリケーションのさまざまなバックエンド間でトラフィックのバランスを取ります。 トラフィックは、パス情報に基づいて分割され、さまざまなサービス エンドポイントとデプロイに送信されます。

HTTP トラフィックを同じ IP アドレス上の複数のホスト名にルーティングするには、ホストごとに異なるイングレス リソースを使用できます。 ロード バランサーの IP アドレスを経由するトラフィックは、ホスト名とイングレス ルールで指定されたパスに基づいてルーティングされます。

Azure Kubernetes Service (AKS) on Azure Stack HCI 内のコンテナー ネットワークの概念

Kubernetes は仮想ネットワークに抽象化レイヤーを提供するため、コンテナー ベースのアプリケーションは内部または外部で通信できます。 kube-proxy コンポーネントは各ノードで実行され、サービスへの直接アクセスを提供するか、負荷分散を使用してトラフィックを分散するか、より複雑なアプリケーション ルーティングにイングレス コントローラーを使用できます。 Kubernetes は、サービスを使用して一連のポッドを論理的にグループ化し、ネットワーク接続を提供します。 次の Kubernetes サービスを使用できます。

  • クラスター IP: このサービスは、内部専用アプリケーションの内部 IP アドレスを作成します。
  • NodePort: このサービスでは、基になるノード上にポート マッピングが作成されるため、ノードの IP アドレスとポートによるアプリケーションへの直接アクセスが可能になります。
  • LoadBalancer: ロード バランサー ルールまたはイングレス コントローラーを使用して、Kubernetes サービスを外部で公開できます。
  • ExternalName: このサービスでは、Kubernetes アプリケーションに特定の DNS エントリを使用します。

Kubernetes ネットワーク

AKS on Azure Stack HCI では、次のいずれかのネットワーク モデルを使用してクラスターをデプロイできます。

  • [Project Calico ネットワーク][]。 これは、AKS on Azure Stack HCI の既定のネットワーク モデルであり、コンテナー、仮想マシン、ネイティブ ホスト ベースのワークロードにネットワーク セキュリティを提供するオープンソース ネットワークに基づいています。 Calico ネットワーク ポリシーは、ポッド、コンテナー、VM、ホスト インターフェイスなど、あらゆる種類のエンドポイントに適用できます。 各ポリシーは、ソース エンドポイントとターゲット エンドポイントの間でトラフィックを許可、拒否、ログに記録、または渡すことができるアクションを使用して、イングレス トラフィックとエグレス トラフィックを制御するルールで構成されます。 Calico では、トラフィック配信に Linux 拡張 Berkeley Packet Filter (eBPF) または Linux カーネル ネットワーク パイプラインのいずれかを使用できます。 Calico は、コンテナー エンドポイントごとにネットワーク名前空間を作成するために Host Networking Service (HNS) を使用して Windows でもサポートされています。 Kubernetes ネットワーク モデルでは、すべてのポッドは、そのポッド内のコンテナー間で共有される独自の IP アドレスを取得します。 ポッドはポッド IP アドレスを使用してネットワーク上で通信し、ネットワーク ポリシーを使用して分離が定義されます。 Calico では、Kubernetes ポッド ネットワークとの間でポッドを追加または削除するために CNI (コンテナー ネットワーク インターフェイス) プラグインを使用し、IP アドレスの割り当てと解放のために CNI IPAM (IP アドレス管理) プラグインを使用します。
  • [Flannel オーバーレイ ネットワーク。][] Flannel は、ホスト ネットワークをオーバーレイする仮想ネットワーク レイヤーを作成します。 オーバーレイ ネットワークでは、既存の物理ネットワークを介したネットワーク パケットのカプセル化が使用されます。 Flannel は、IP アドレス管理 (IPAM) を簡素化し、異なるアプリケーションと名前空間の間の IP 再利用をサポートし、Kubernetes ノードで使用されるアンダーレイ ネットワークからコンテナー ネットワークを論理的に分離します。 ネットワークの分離は、Virtual eXtensible Local Area Network (VXLAN) を使用して実現されます。これは、トンネリングを使用してデータ センター接続を提供して、基になるレイヤー 3 ネットワーク経由でレイヤー 2 接続を拡張するカプセル化プロトコルです。 Flannel は、DaemonSet を使用する Linux コンテナーと Flannel CNI プラグインを使用する Windows コンテナーの両方でサポートされます。

Azure Stack HCI ネットワーク設計

全体的なネットワーク設計には、Azure Stack HCI の計画作業が含まれます。

まず、Azure Stack HCI のハードウェアとインストールを計画することから始めます。 Microsoft ハードウェア パートナーから Azure Stack HCI オペレーティング システムがプレインストールされている統合システムを購入するか、検証済みノードを購入し、自分でオペレーティング システムをインストールできます。 Azure Stack HCI は仮想化ホストとしての使用が意図されているため、Kubernetes サーバー ロールは VM 内で実行する必要があります。

Azure Stack HCI の物理ネットワーク要件

Microsoft ではネットワーク スイッチを認定していませんが、機器のベンダーが対応する必要がある特定の要件があります。

  • 仮想ローカル エリア ネットワーク (VLAN) を定義する標準: IEEE 802.1Q。
  • 優先順位フロー制御 (PFC) を定義する標準: IEEE 802.1Qbb。
  • Enhanced Transmission Selection (ETS) を定義する標準: IEEE 802.1Qaz。
  • Link Layer Topology Discovery (LLTD) プロトコルを定義する標準: IEEE 802.1AB。

Azure Stack HCI のホスト ネットワーク要件

Standard または Premium の追加資格基準 (AQ) のある、Windows Server の Software Defined Data Center (SDDC) 認定を取得しているネットワーク アダプターの使用を検討してください。

ネットワーク アダプターが以下のものをサポートしていることを確認します。

  • [動的仮想マシン マルチキュー][] (動的 VMMQ または d.VMMQ) は、CPU コアへのネットワーク トラフィック処理を自動チューニングするためのインテリジェントな受信側テクノロジです。
  • リモート ダイレクト メモリ アクセス (RDMA) は、ネットワーク アダプターに対するネットワーク スタック オフロードです。 これにより、SMB 記憶域トラフィックがオペレーティング システムをバイパスして処理できるようになります。
  • ゲスト RDMA を使用すると、ホスト上で RDMA を使用する場合と同じ利点を VM の SMB ワークロードで得ることができます。
  • スイッチ埋め込みチーミング (SET) は、ソフトウェア ベースのチーミング テクノロジです。

ホスト ネットワーク構成を簡略化するための意図に基づく制御を提供する [Network ATC][] の使用を検討してください。

AKS on an Azure Stack HCI では、各サーバー ノード間に信頼性が高く、高帯域幅で低待機時間のネットワーク接続が必要になります。 クラスター管理専用に少なくとも 1 つのネットワーク アダプターが使用可能であることを確認します。 また、使用するすべての VLAN 上のトラフィックを許可するようにネットワーク内の物理スイッチが構成されていることも確認します。

仮想スイッチ

Azure Stack HCI は、ネットワーク分類に使用できる仮想スイッチを構成することで、ネットワーク設計を簡素化します。 仮想ネットワーク インターフェイス カード (vNIC) は、ホストが以下のネットワークに別々のトラフィック フローを提供するために、異なる VLAN に配置できます。

  • 管理ネットワーク。 管理ネットワークは North-South ネットワークの一部であり、ホスト通信に使用されます。
  • コンピューティング ネットワーク。 コンピューティング ネットワークは、North-South ネットワークの一部であり、仮想マシン トラフィックに使用されます。 サービス品質 (QOS)、シングルルート I/O 仮想化 (SR-IOV)、仮想リモート ダイレクト メモリ アクセス (vRDMA) を使用して、要求に基づいてネットワーク パフォーマンスを調整します。
  • 記憶域ネットワーク。 記憶域ネットワークは East-West ネットワークの一部であり、推奨スループット 10GB 以上の RDMA が必要です。 これは、VM のライブ マイグレーションに使用されます。
  • VM ゲスト ネットワーク。

RDMA トラフィックの East-West トラフィックの利点

East-West ネットワーク トラフィックはホスト間の通信を表し、外部アクセスを公開しません。 トラフィックは、Top of Rac (ToR) スイッチとレイヤー 2 境界内にとどまります。 これには、次の種類のトラフィックが含まれます。

  • クラスター ハートビートとノード間通信
  • [SMB] 記憶域バス レイヤー
  • [SMB] クラスター共有ボリューム
  • [SMB] ストレージの再構築

North-South トラフィック

North-South トラフィックは、AKS on Azure Stack HCI クラスターに到達する外部トラフィックです。 Azure ARC の統合を通じて監視、課金、セキュリティ管理を可能にするさまざまな Azure サービスのトラフィックを計画できます。 North-South トラフィックには次のような特徴があります。

  • トラフィックは ToR スイッチからスパインに流れるか、スパインから ToR スイッチに流れる。
  • トラフィックは物理ラックから出ていくか、レイヤー 3 境界 (IP) を越える。
  • トラフィックに、管理 (PowerShell、Windows Admin Center)、コンピューティング (VM)、サイト間ストレッチ クラスターの各トラフィックを含む。
  • 物理ネットワークへの接続にイーサネット スイッチを使用する。

AKS on Azure Stack HCI では、複数のクラスター ネットワーク デプロイ オプションを使用できます。

  • 複数のネットワーク インテントを組み合わせたコンバージド ネットワーク (MGMT、コンピューティング、ストレージ)。 これは 3 つを超える物理ノードに推奨されるデプロイであり、すべての物理ネットワーク アダプターが同じ ToR スイッチに接続されている必要があります。 ROCEv2 を強くお勧めします。
  • スイッチレスのデプロイでは、コンピューティング ネットワークと管理ネットワークを組み合わせることで、ネットワーク チームとして North-South 通信を使用します。
  • 両方のデプロイの組み合わせとしてのハイブリッド デプロイ。

推奨事項

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

ネットワークの推奨事項

AKS on Azure Stack HCI のネットワーク設計の主な懸念事項は、お使いの Kubernetes クラスターとそのサービスやアプリケーションに十分な IP アドレスを提供するネットワーク モデルを選択することです。

  • AKS on Azure Stack HCI が IP アドレスの割り当てを制御できるように、静的 IP アドレスを実装することを検討してください。

  • Kubernetes ノード プールと仮想 IP プールに使用可能な IP アドレスが十分あるように、IP アドレス範囲を適切に設定します。 アップグレードするときは常に、より多くの IP アドレスを必要とするローリング アップグレードを使用できるように、仮想 IP プールが十分な大きさであることを確認します。 以下を計画することができます。

    • プロキシ設定のアドレス指定/ホスト名
    • ターゲット クラスター コントロール プレーンの IP アドレス
    • Azure ARC の IP アドレス
    • ターゲット クラスター内のワーカー ノードとコントロール プレーン ノードの水平スケーリング用の IP アドレス

  • 仮想 IP プールは、外部ルーターへの接続を必要とするアプリケーション サービスのデプロイを十分にサポートする大きさでなければなりません。

  • Calico CNI を実装して、ポッドとアプリケーションの通信を制御するための拡張ネットワーク ポリシーを提供します。

  • 物理クラスター ノード (HCI または Windows Server) が同じラックに配置され、同じ ToR スイッチに接続されていることを確認します。

  • すべてのネットワーク アダプターの IPv6 を無効にします。

  • 既存の仮想スイッチとその名前が、すべてのクラスター ノードで同じであることを確認します。

  • クラスターに対して定義したすべてのサブネットが相互にルーティング可能であること、およびインターネットにルーティングされていることを確認します。

  • Azure Stack HCI ホストとテナント VM の間にネットワーク接続が存在することを確認します。

  • AKS on Azure Stack HCI で、クラウド エージェントの汎用クラスター名を検出のために DNS システムに登録できるように、DNS 環境で動的 DNS 更新を有効にします。

  • 方向によるネットワーク トラフィックの分類を実装することを検討してください。

    • North-South トラフィックは、Azure Stack HCI とネットワークの残りの部分からのトラフィックです。
      • 管理
      • Compute
      • サイト間ストレッチ クラスター トラフィック
    • Azure Stack HCI 内の East-West トラフィック:
      • 同じクラスター内のノード間のライブ マイグレーションを含むストレージ トラフィック。
      • イーサネット スイッチまたは直接接続。

ストレージ トラフィック モデル

  • 複数のサブネットと VLAN を使用して、Azure Stack HCI でストレージ トラフィックを分離します。
  • さまざまなトラフィックの種類のトラフィック帯域幅割り当てを実装することを検討してください。

考慮事項

[Microsoft Azure Well-Architected フレームワーク][] は、このシナリオの基になっている一連の基本原則です。 以下の考慮事項は、これらの原則のコンテキストで構成されています。

[信頼性]

  • 組み込みの回復性。Microsoft ソフトウェアによるコンピューティング (Hyper-V ノードのフェールオーバー クラスター)、ストレージ (記憶域スペース ダイレクトの入れ子の回復性)、ネットワーク (ソフトウェアによるネットワーク) に固有です。
  • 業界標準をサポートし、ノード間の信頼性の高い通信を保証するネットワーク スイッチを選択することを検討してください。 以下の標準が含まれます。
    • 標準: IEEE 802.1Q
    • 標準 IEEE 802.1Qbb
    • 標準 IEEE 802.1 Qas
    • 標準 IEEE 802.1 AB
  • ワークロードの最小レベルの可用性を達成するために、管理クラスターおよび Kubernetes クラスターに複数のホストを実装することを検討してください。
  • AKS on Azure Stack HCI では、高い可用性とフォールト トレランスのためにフェールオーバー クラスタリングとライブ マイグレーションを使用します。 ライブ マイグレーションは、ダウンタイムを発生させることなく、実行中の仮想マシンを Hyper-V ホスト間で透過的に移動できるようにする Hyper-V 機能です。
  • 「アーキテクチャ」で参照されているサービスが、Azure Arc のデプロイ先のリージョンでサポートされていることを確認する必要があります。

セキュリティ

  • AKS on Azure Stack HCI でネットワーク ポリシーを使用したポッド間のトラフィックのセキュリティ保護。
  • AKS on Azure Stack HCI の API サーバーには、Kubernetes API サーバーから kubelet への通信用の証明書に署名する証明機関が含まれています。
  • Microsoft Entra シングル サインオン (SSO) を使用して、Kubernetes API サーバーへのセキュリティで保護された接続を作成します。
  • Azure RBAC を使用して、Microsoft Entra ID を使用した Azure およびオンプレミス環境での Azure Arc 対応 Kubernetes へのアクセスを管理できます。 詳細については、「Kubernetes 認可に Azure RBAC を使用する」を参照してください。

コストの最適化

  • [Azure 料金計算ツール][] を使用して、アーキテクチャで使用するサービスのコストを見積もります。 その他のベスト プラクティスについては、「Microsoft Azure Well-Architected フレームワーク」の「コストの最適化」セクションで説明されています。
  • AKS on Azure Stack HCI の課金単位は仮想コアであるため、コストを最適化するために、物理コンピューターにハイパースレッディングを実装することを検討してください。
  • Azure Arc コントロール プレーン機能は、追加コストなしで提供されます。 これには、Azure 管理グループとタグによるリソース編成、Azure RBAC によるアクセス制御のサポートが含まれます。 Azure Arc 対応サーバーと組み合わせて使用する Azure サービスには、その使用量に応じてコストが発生します。
  • コスト効果を高めるために、4 つのディスクと 1 ノードあたり 64 ギガバイト (GB) のメモリのみを備えた 2 つのクラスター ノードを使用できます。 コストをさらに最小限に抑えるために、ノード間でスイッチレス相互接続を使用すると、冗長なスイッチ デバイスの必要性をなくすことができます。

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

  • Windows Admin Center を使用したシンプルな管理。 Windows Admin Center は、AKS on Azure Stack HCI を作成および管理するためのユーザー インターフェイスです。 Azure に登録する必要があり、Azure Stack HCI または Windows Server Datacenter クラスターと同じドメイン内にある、Windows 10/11 または Windows Server VM にインストールできます。
  • Azure Arc との統合、またはより多くの管理、メンテナンス、回復性の機能 (Azure Monitor、Azure Backup) を提供するさまざまな Azure サービス。
  • Kubernetes クラスターが [Azure Arc][Azure Arc 対応 Kubernetes サービス] にアタッチされている場合は、[GitOps を使用して Kubernetes クラスターを管理][] できます。 ハイブリッド Kubernetes クラスターを Azure Arc に接続するためのベスト プラクティスを確認するには、「Kubernetes クラスター向けの Azure Arc ハイブリッド管理とデプロイ」のシナリオを参照してください。
  • また、Azure Stack HCI プラットフォームでは、「基となる」ネットワークを高可用性の方法で提供することで、AKS on Azure Stack HCI クラスターの仮想ネットワークを簡素化することもできます。

パフォーマンス効率

  • Azure Stack HCI 認定ハードウェアを使用して、アプリケーションのアップタイムとパフォーマンスの向上、管理と運用の簡素化、総保有コストの削減を実現します。
  • 記憶域: 記憶域スペース ダイレクト
    • ボリューム構成 (入れ子になった双方向ミラーと入れ子になったミラー加速パリティの対比)
    • ディスク構成 (キャッシュ、層)
  • クラスター ノードが、同じラックに物理的に配置され、同じ ToR スイッチに接続されていることを確認します。
  • AKS ホスト、ワークロード クラスター、クラスター API サーバー、Kubernetes サービス、およびアプリケーション サービスを構成するために IP アドレスの予約を計画します。 Microsoft では、Azure Stack HCI での AKS デプロイ用に、少なくとも 256 個の IP アドレスを予約することをお勧めします。
  • レイヤー 7 で動作し、よりインテリジェントなルールを使用してアプリケーションのトラフィックを分散させるイングレス コントローラーを実装することを検討してください。
  • 広範なワークロードには、グラフィックス処理装置 (GPU) アクセラレーションを使用します。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

  • Lisa DenBeste | プロジェクト管理プログラム マネージャー
  • Kenny Harder | プロジェクト マネージャー
  • Mike Kostersitz | プリンシパル プログラム マネージャー リード
  • Meg Olsen | プリンシパル
  • Nate Waters | 製品マーケティング マネージャー

その他の共同作成者:

次のステップ