メインコンテンツまでスキップ
バージョン: 3.13
    Features and pricing

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

    注記

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

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

    あなたが始める前に​

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

    要件​

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

    警告

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

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

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

    少なくとも 3 つのワーカーノードと 3 つのポッドを作成します​

    AKS クラスターの高可用性を確保するには、少なくとも 3 つのワーカーノードを使用し、ワーカーノード全体に少なくとも 3 つのポッドをデプロイする必要があります。 3 つのポッドをワーカーノードに分散させるための podAntiAffinity の サンプル構成 を参照できます。

    注記

    ワーカーノードを異なる availability zones (AZ) に配置すると、AZ の障害に耐えることができます。

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

    商用ライセンスの観点から、ScalarDL Ledger を実行する 1 つのポッドのリソースは 2vCPU / 4GB メモリに制限されます。 ScalarDL Ledger ポッドに加えて、Kubernetes は次のコンポーネントの一部を各ワーカーノードにデプロイできます。

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

    これを念頭に置き、少なくとも 3 つのワーカーノードと 3 つのポッドを作成する で説明されているように、少なくとも 4vCPU / 8 GB のメモリ リソースを持つワーカーノードを使用し、可用性のために少なくとも 3 つのワーカーノードを使用する必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

    ScalarDL Ledger では未使用の接続を制限する必要があります。 未使用の接続を制限するには、[ネットワーク セキュリティ グループ] など、Azure のいくつかのセキュリティ機能を使用できます。

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

    • ScalarDL Ledger
      • 50051/TCP (クライアントからのリクエストを受け付ける)
      • 50052/TCP (クライアントからの特権リクエストを受け入れます)
      • 50053/TCP (scalar-admin クライアント ツールからの一時停止および一時停止解除リクエストを受け入れます)
      • 8080/TCP (監視リクエストを受け付ける)
    • Scalar Envoy (ScalarDL Ledger とともに使用)
      • 50051/TCP (ScalarDL Ledger の負荷分散)
      • 50052/TCP (ScalarDL Ledger の負荷分散)
      • 9001/TCP (Scalar Envoy 自体の監視リクエストを受け入れます)
    注記