メインコンテンツまでスキップ
バージョン: 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 自体の監視リクエストを受け入れます)
    注記