メインコンテンツまでスキップ
バージョン: 3.14

ScalarDL Ledger および ScalarDL Auditor 用の AKS クラスターを作成するためのガイドライン

注記

このページは英語版のページが機械翻訳されたものです。英語版との間に矛盾または不一致がある場合は、英語版を正としてください。

このドキュメントでは、ScalarDL Ledger および ScalarDL Auditor のデプロイ用の Azure Kubernetes Service (AKS) クラスターを作成するための要件と推奨事項について説明します。AKS クラスターに ScalarDL Ledger と ScalarDL Auditor をデプロイする方法の詳細については、AKS に ScalarDL Ledger と ScalarDL Auditor をデプロイするを参照してください。

あなたが始める前に​

次の要件、推奨事項、およびプロジェクトの要件に基づいて AKS クラスターを作成する必要があります。AKS クラスターの作成方法の詳細については、環境で使用しているツールに基づいて、次の Microsoft 公式ドキュメントを参照してください。

要件​

ScalarDL Ledger と ScalarDL Auditor を展開する場合は、次のことを行う必要があります。

  • サポートされている Kubernetes バージョンを使用して2つの AKS クラスターを作成します。
    • ScalarDL Ledger 用の1つの AKS クラスター
    • ScalarDL Auditor 用の1つの AKS クラスター
  • Kubernetes のバージョンとプロジェクトの要件に基づいて AKS クラスターを構成します。
    • 仮想ネットワーク(VNet) は以下のように設定します。
    • Virtual network peering を使用して、AKS の VNet (Ledger 用) と AKS の VNet (Auditor 用) を接続します。これを行うには、VNet の作成時に AKS の VNet (Ledger 用) と AKS の VNet (Auditor 用) に異なる IP 範囲を指定する必要があります。
    • ScalarDL (Auditor モード) が適切に動作するように Ledger と Auditor 間の接続を許可します。
    • これらのネットワーク要件の詳細については、ScalarDL Auditor Mode のネットワークピアリングの構成を参照してください。
警告

ScalarDL でのビザンチン障害検出が適切に機能するには、ScalarDL Ledger および ScalarDL Auditor のデプロイと同じ AKS クラスターにアプリケーションポッドをデプロイしないでください。

推奨事項 (オプション)​

以下は、ScalarDL Ledger および ScalarDL Auditor を展開するための推奨事項の一部です。これらの推奨事項は必須ではないため、ニーズに基づいてこれらの推奨事項を適用するかどうかを選択できます。

AKS クラスターごとに少なくとも3つのワーカーノードと3つのポッドを作成します。​

AKS クラスターの高可用性を確保するには、少なくとも3つのワーカーノードを使用し、ワーカーノード全体に少なくとも3つのポッドをデプロイする必要があります。ワーカーノードに3つのPodを分散させるための podAntiAffinity の ScalarDL Ledgerサンプル設定 と ScalarDL Auditorサンプル設定をご覧ください。

注記

ワーカーノードを異なるアベイラビリティゾーン (AZ) に配置すると、AZ の障害に耐えることができます。

ScalarDL Ledger および ScalarDL Auditor ノードプールのワーカーノードには 4vCPU / 8GB メモリノードを使用します。​

Bring-your-own-license (BYOL) コンテナを使用する場合は、少なくとも 2vCPU / 4GB メモリを設定することをお勧めします。ScalarDL Ledger および ScalarDL Auditor ポッドに加えて、Kubernetes は次のコンポーネントの一部を各ワーカーノードにデプロイできます。

  • ScalarDL Ledger の AKS クラスター
    • ScalarDL Ledger ポッド (2vCPU / 4GB)
    • Envoy プロキシ
    • 監視コンポーネント (kube-prometheus-stack などの監視コンポーネントをデプロイする場合)
    • Kubernetes コンポーネント
  • ScalarDL Auditor 用の AKS クラスター
    • ScalarDL Auditor ポッド (2vCPU / 4GB)
    • Envoy プロキシ
    • 監視コンポーネント (kube-prometheus-stack などの監視コンポーネントをデプロイする場合)
    • Kubernetes コンポーネント

これを念頭に置き、少なくとも3つのワーカーノードと3つのポッドを作成するで説明されているように、少なくとも 4vCPU / 8 GB のメモリリソースを持つワーカーノードを使用し、可用性のために少なくとも3つのワーカーノードを使用する必要があります。また、ビザンチン障害検出が適切に機能するには、ScalarDL Ledger および ScalarDL Auditor のデプロイと同じ AKS クラスターにアプリケーションポッドをデプロイできないことに注意してください。

ただし、ノードあたり少なくとも 4vCPU / 8GB のメモリリソースを備えた3つのノードが運用環境の最小環境となります。また、システムのワークロードに応じて、AKS クラスターのリソース (ワーカーノードの数、ノードあたりの vCPU、ノードあたりのメモリ、ScalarDL Ledger ポッド、ScalarDL Auditor ポッドなど) も考慮する必要があります。また、Horizontal Pod Autoscaling (HPA) などの機能を使用してポッドを自動的にスケーリングする予定の場合は、ワーカーノードのリソースを決定するときにワーカーノード上の最大ポッド数を考慮する必要があります。

ScalarDL Ledger および ScalarDL Auditor ポッドのノードプールを作成する​

AKS は、既定でシステムポッド (AKS を実行し続けるために使用される) に優先される agentpool という名前のシステムノードプールを1つ作成します。ScalarDL Ledger および ScalarDL Auditor ポッド用に user モードで追加のノードプールを作成し、それらの追加のノードプールに ScalarDL Ledger および ScalarDL Auditor ポッドをデプロイすることをお勧めします。

AKS でクラスターオートスケーラーを構成する​

Horizontal Pod Autoscaler) を使用して ScalarDL Ledger および ScalarDL Auditor ポッドを自動的にスケーリングする場合は、AKS でもクラスターオートスケーラーを構成する必要があります。詳細については、Microsoft の公式ドキュメント Cluster autoscaler を参照してください。

さらに、クラスターオートスケーラーを構成する場合は、AKS がスケーリング後にネットワークの問題なく動作できるように、十分な数の IP が存在することを確認するために AKS 用の VNet にサブネットを作成する必要があります。必要な IP の数は、ネットワークプラグインによって異なります。必要な IP 数の詳細については、以下を参照してください。

プライベートネットワーク上に AKS クラスターを作成する​

ScalarDL Ledger と ScalarDL Auditor はインターネットアクセス経由でユーザーに直接サービスを提供しないため、プライベートネットワーク (VNet のプライベートサブネット) 上に AKS クラスターを作成する必要があります。アプリケーションからプライベートネットワーク経由で ScalarDL Ledger および ScalarDL Auditor にアクセスすることをお勧めします。

必要に応じて、Azure CNI を使用して AKS クラスターを作成します。​

AKS の既定のネットワークプラグインは kubenet です。要件が kubenet と一致しない場合は、Azure Container Networking Interface (CNI) を使用する必要があります。

たとえば、複数の ScalarDL Ledger 環境と ScalarDL Auditor 環境を2つの AKS クラスターではなく1つの AKS クラスターのみにデプロイし (マルチテナントの ScalarDL をデプロイするなど)、Kubernetes NetworkPolicies を使用して各テナント間の接続を制御する場合、kubenet は Calico ネットワークポリシーのみ。Azure サポートチームはサポートしていません。Calico ネットワークポリシーは、Calico コミュニティまたは追加の有料サポートを通じてのみサポートされることに注意してください。

ただし、Azure サポートチームとエンジニアリングチームは Azure CNI をサポートします。したがって、Kubernetes NetworkPolicies を使用して Azure サポートチームからサポートを受けたい場合は、Azure CNI を使用する必要があります。kubenet と Azure CNI の違いの詳細については、次の Microsoft 公式ドキュメントを参照してください。

要件に基づいていくつかのセキュリティ機能を使用して接続を制限する​

ScalarDL および ScalarDL Auditor では、未使用の接続を制限する必要があります。未使用の接続を制限するには、network security groups などの Azure のセキュリティ機能を使用できます。

ScalarDL Ledger および ScalarDL Auditor がデフォルトで使用する接続 (ポート) は次のとおりです。

  • ScalarDL Ledger
    • 50051/TCP (クライアントおよび ScalarDL Auditor からのリクエストを受け入れる)
    • 50052/TCP (クライアントおよび ScalarDL Auditor からの特権リクエストを受け入れます)
    • 50053/TCP (scalar-admin クライアントツールからの一時停止/一時停止解除リクエストを受け入れます)
    • 8080/TCP (監視リクエストを受け付ける)
  • ScalarDL Auditor
    • 40051/TCP (クライアントからのリクエストを受け付ける)
    • 40052/TCP (クライアントからの特権リクエストを受け入れます)
    • 40053/TCP (scalar-admin クライアントツールからの一時停止および一時停止解除リクエストを受け入れます)
    • 8080/TCP (監視リクエストを受け付ける)
  • Scalar Envoy (ScalarDL Ledger および ScalarDL Auditor とともに使用)
    • 50051/TCP (ScalarDL Ledger の負荷分散)
    • 50052/TCP (ScalarDL Ledger の負荷分散)
    • 40051/TCP (ScalarDL Auditor の負荷分散)
    • 40052/TCP (ScalarDL Auditor の負荷分散)
    • 9001/TCP (Scalar Envoy 自体の監視リクエストを受け入れます)
注記
  • 設定ファイル (それぞれ ledger.properties と auditor.properties) で ScalarDL Ledger と ScalarDL Auditor のデフォルトのリスニングポートを変更する場合は、設定したポートを使用して接続を許可する必要があります。
  • AKS 自体が使用する接続も許可する必要があります。AKS トラフィック要件の詳細については、Control egress traffic using Azure Firewall in Azure Kubernetes Service (AKS) を参照してください。