すべてのプロダクト
Search

このプロダクト

    Container Service for Kubernetes:ALBクォータの計算方法

    ドキュメントセンター

    Container Service for Kubernetes:ALBクォータの計算方法

    最終更新日:Dec 10, 2024

    クォータは、期間内のリソースの最大使用率またはサービスの最大QPSを設定します。 クォータは一般に、リソースの割り当てと消費を管理するために使用されます。 Application Load Balancer (ALB) クォータの計算方法は、リソースタイプとリソース使用量によって異なります。 このトピックでは、標準ALBインスタンス、バックエンドサーバーグループ、リスナー、および転送ルールに関連するALBクォータを計算する方法について説明します。

    シナリオ (前の図を参照)

    ALBインスタンスは、Ingressを使用して外部リクエストを管理および転送します。 Ingressは、リクエストをバックエンドサーバーグループに転送するために使用されるルールを定義します (Service: ポートペア) 。 次に、要求は、ポッドのグループで実行されるバックエンドアプリケーションに送信され、処理されます。 ALBインスタンス、Ingress、バックエンドサーバーグループ (サービス: ポートペア) 、ポッド間のマッピングは、リクエスト転送と負荷分散のためのルーティングシステムを構成します。

    image

    次の表は、標準ALBインスタンス、バックエンドサーバーグループ、リスナー、および転送ルールに関連するALBクォータの計算方法を示しています。

    標準ALBインスタンスに関連するALBクォータ

    クォータの説明

    名前 /ID

    計算方法

    シナリオ (前の図を参照)

    ALBインスタンスに追加できる追加証明書の最大数 (デフォルト証明書を除く)

    alb_quota_loadbalancer_certificates_num_standard_edition

    ALBインスタンスに追加できる追加証明書の最大数は、ALBインスタンスのすべてのリスナーに追加できる追加証明書の合計数に等しくなります。

    ALB Ingressに追加できる追加の証明書の数は、証明書の設定方法によって異なります。

    • 自動証明書検出が設定されている場合、ALB Ingressに追加できる追加の証明書の数は、certificate Management Serviceコンソールでドメイン名に関連付けられている証明書の総数に等しくなります。

    • 証明書がKubernetes Secretsとして管理されている場合、ALB Ingressに追加できる追加の証明書の数は、spec.tlsパラメーターのsecretNameフィールドにリストされているSecretsの数に等しくなります。 すべての名前空間でSecretsとして管理される証明書は、計算の対象となります。 ただし、同じ名前空間でSecretsとして管理される証明書は1回だけカウントされます。

    • 証明書がAlbConfigで指定されている場合、ALB Ingressに追加できる追加の証明書の数は、AlbConfigのCertificateIdフィールドにリストされている証明書の数に等しくなります。

    • 上記の方法を複数使用して同時に証明書を設定する場合、ALB Ingressに追加できる追加の証明書の数は、使用する方法間の互換性によって異なります。

    • ALB Ingressが複数のリスナーに関連付けられている場合、ALB Ingressに設定されている証明書は、リスナーの数に基づいて複数回カウントされます。

    • ALB Ingress 1はHTTPリスナーに関連付けられています。 HTTPは追加の証明書を必要としません。 この場合、ALB Ingress 1に追加できる追加の証明書の数はゼロです。

    • ALB Ingress 2はHTTPリスナーに関連付けられています。 HTTPは追加の証明書を必要としません。 この場合、ALB Ingress 2に追加できる追加の証明書の数はゼロです。

    • ALB Ingress 3は、HTTPSリスナー3およびHTTPSリスナー4に関連付けられています。 HTTPSリスナー3に追加される追加証明書の数は1つであり、HTTPリスナー4の追加証明書の数も1つです。 この場合、ALB Ingress 3に追加できる追加の証明書の数は2です。

    ALBインスタンスに設定できる転送ルールの最大数 (デフォルト転送ルールを除く)

    alb_quota_loadbalancer_rules_num_standard_edition

    ALBインスタンスに設定できる転送ルールの最大数は、ALBインスタンスのすべてのリスナーに関連付けられているALB Ingressの転送ルールの総数に等しくなります。

    ALB Ingressの転送ルールの数は、ALB Ingress設定ファイルのspec.ru lesセクションのhostパラメーターのpathフィールドにリストされているエントリの数と同じです。 ALB Ingressが複数のリスナーに関連付けられている場合、ALB Ingressの転送ルールは、リスナーの数に基づいて複数回カウントされます。

    • ALB Ingress 1には1つの転送ルールがあります。

    • ALB Ingress 2には1つの転送ルールがあります。

    • ALB Ingress 3は、1つの転送ルールを有し、リスナー3およびリスナー4に関連付けられる。 この場合、ALB Ingress 3の転送ルールの数は2である。

    ALBインスタンスに追加できるバックエンドサーバーの最大数

    alb_quota_loadbalancer_servers_num_standard_edition

    ALBインスタンスに追加できるバックエンドサーバーの最大数は、ALBインスタンスのすべてのリスナーに関連付けられているALB Ingressのバックエンドサーバーの総数に等しくなります。

    ALB Ingressのバックエンドサーバーの数は、ALB Ingressのすべての転送ルールで指定されたバックエンドポッドの総数に等しくなります。 ALB Ingressが複数のリスナーに関連付けられている場合、ALB Ingressのバックエンドポッドはリスナーの数に基づいて複数回カウントされます。

    • ALB Ingress 1には3つのバックエンドポッドがあります。

    • ALB Ingress 2には3つのバックエンドポッドがあります。

    • ALB Ingress 3には、1つの転送ルールと2つのバックエンドポッドがあり、リスナー3とリスナー4に関連付けられています。 この場合、ALB Ingress 3のバックエンドポッドの数は4です。

    ALBインスタンスに追加できるリスナーの最大数

    alb_quota_loadbalancer_listeners_num_standard_edition

    ALBインスタンスに追加されるリスナーの数は、ALBインスタンスの設定に使用されるAlbConfigのlistenersパラメーターにリストされているport:protocolペアの数と同じです。

    ALB Ingressに関連付けられているリスナーの数は、alb ingress設定のALB. Ingress. kubernetes.io/listen-portsアノテーションの値によって異なります。

    • ALB Ingress 1は1つのリスナーに関連付けられています。

    • ALB Ingress 2は、1つのリスナーに関連付けられます。

    • ALB Ingress 3は2人のリスナーに関連付けられています。

    サーバーグループに関連するクォータ

    クォータの説明

    名前 /ID

    計算方法

    シナリオ (前の図を参照)

    バックエンドサーバー (IPアドレス) を指定できるALBサーバーグループの最大数

    alb_quota_server_added_num

    ポッドIPアドレスがService:portペアのバックエンドサーバーとして指定され、Service:portペアが複数の転送ルールで指定されている場合、ポッドIPアドレスは転送ルールの数に基づいて複数回カウントされます。 この場合、前述の転送ルールのそれぞれが複数のリスナーに関連付けられている場合、ポッドのIPアドレスもリスナーの数に基づいて複数回カウントされます。

    • ポッド1は、サービス1: ポート80とサービス2: ポート80のバックエンドサーバーとして指定されます。 サービス1: ポート80およびサービス2: ポート80は、それぞれ別個の転送ルールに関連付けられる。 この場合、Pod 1が指定されているALBバックエンドサーバーグループの数は2つです。 同様に、Pod 2が指定されているALBバックエンドサーバーグループの数は2であり、Pod 3のALBバックエンドサーバーグループの数も2です。

    • ポッド4はサービス3: ポート80のバックエンドサーバーとして指定され、サービス3: ポート80は2つのリスナーに関連付けられた転送ルールで指定されます。 この場合、Pod 4が指定されているALBバックエンドサーバーグループの数は2つです。 同様に、Pod 5が指定されているALBバックエンドサーバーグループの数は2です。

    ALBサーバーグループをリスナーと転送ルールに関連付けることができる最大回数

    alb_quota_servergroup_attached_num

    ALBサーバーグループ (Service: ポートペア) をリスナーと転送ルールに関連付けることができる最大回数は、ALBサーバーグループ (Service: ポートペア) が指定されている転送ルールによって異なります。

    ALBサーバーグループ (Service:port pair) が指定されている転送ルールが複数のリスナーに関連付けられている場合、ALBサーバーグループ (Service:port pair) はリスナーの数に基づいて複数回カウントされます。

    • サービス1: ポート80は1つの転送ルールで指定され、転送ルールは1つのリスナーに関連付けられます。 この場合、サービス1: ポート80がリスナーと転送ルールに関連付けられている回数は1回です。 同様に、サービス2: ポート80がリスナーおよび転送ルールに関連付けられている回数は1回です。

    • サービス3: ポート80は1つの転送ルールで指定され、転送ルールは2つのリスナーに関連付けられます。 この場合、サービス3: ポート80がリスナーと転送ルールに関連付けられる回数は2回です。

    サーバーグループに追加できるバックエンドサーバーの最大数 (IPアドレスとポート) (サービス: ポートペア)

    alb_quota_servergroup_servers_num

    サーバーグループに追加できるバックエンドサーバー (IPアドレスとポート) の最大数は、サーバーグループのpod:portペアの数 (Service:portペア) に等しくなります。

    • サービス1: ポート80には3つのバックエンドポッドがあります。 この場合、サービス1: ポート80に追加されるバックエンドサーバーの数は3です。 同様に、サービス2: ポート80に追加されたバックエンドサーバーの数は3です。

    • サービス3: ポート80には2つのバックエンドポッドがあります。 この場合、サービス3: ポート80に追加されるバックエンドサーバーの数は2です。

    リスナーに関連するクォータ

    クォータの説明

    名前 /ID

    計算方法

    シナリオ (前の図を参照)

    リスナーに関連付けることができるネットワークアクセス制御リスト (ACL) の最大数

    -

    リスナーに関連付けることができるネットワークACLの最大数は、AlbConfigのListenersパラメーターのすべてのport:protocolペアの空でないaclConfigフィールドのエントリの総数によって異なります。

    • リスナー1は、1つのネットワークACLに関連付けられる。

    • リスナー2は、1つのネットワークACLに関連付けられる。

    • リスナー3は、ゼロネットワークACLに関連付けられる。

    • リスナー4は、ゼロネットワークACLに関連付けられる。

    リスナーに関連付けることができるネットワークACLエントリの最大数

    -

    リスナーに関連付けることができるネットワークACLエントリの最大数は、AlbConfigのListenersパラメーターのすべてのport:protocolペアの空でないaclConfigフィールドのエントリの総数によって異なります。

    • リスナー1に関連付けられたネットワークACLの数は、acIdフィールドで指定されたネットワークACLの数によって異なります。

    • リスナー2は、2つのネットワークACLに関連付けられる。

    • リスナー3は、ゼロネットワークACLに関連付けられる。

    • リスナー4は、ゼロネットワークACLに関連付けられる。

    転送ルールに関連するクォータ

    クォータの説明

    名前 /ID

    計算方法

    シナリオ (前の図を参照)

    転送ルールで指定できるアクションの最大数

    --​

    • 転送ルールを作成または更新するときに、servicePortフィールドをuse-annotationに設定した場合、転送ルールで指定できるアクションの最大数は、アノテーションを使用して指定されたカスタムアクションの総数に等しくなります。

    • 転送ルールを作成または更新するときに、servicePortフィールドをuse-annotation以外の値に設定した場合、転送ルールで指定できるアクションの最大数は、アノテーションを使用して指定したカスタムアクションの総数に1を加えた数に等しくなります。

    • ALB Ingress 1には、バックエンドサービスポートが80で、アノテーションを使用してカスタムアクションが指定されないという1つの転送ルールがあります。 この場合、ALB Ingress 1の転送ルールで指定できるアクションの最大数は1つです。

    • 同様に、ALB Ingress 2およびALB Ingress 3は、それぞれ1つの転送ルールを有する。

    転送ルールで指定できる一致条件の最大数

    alb_quota_rule_matchevaluations_num

    転送ルールを作成または更新する場合、転送ルールで指定できる一致条件の最大数は、転送ルール内の空でないホストの数、パス一致条件の数、およびアノテーションを使用して指定したカスタム転送条件の一致条件の数の合計に等しくなります。 pathTypeをPrefixに設定した場合、各パスの一致条件の数は2です。 pathTypeを他の値に設定した場合、各パスの一致条件は1つです。

    • ALB Ingress 1には1つの転送ルールがあり、転送ルール内の空でないホストの数は1つ、パスの数は1つ、アノテーションを使用して指定されたカスタム転送条件の一致条件の数は1つです。 この場合、転送ルールで指定できる一致条件の最大数は3です。

    • ALB Ingress 2には転送ルールが1つあり、転送ルール内の空でないホストの数は1つで、パスの数は1つです。 この場合、転送ルールで指定できる一致条件の最大数は2つです。 同様に、ALB Ingress 3の転送ルールで指定できる一致条件の最大数は2です。

    転送ルールで使用できるワイルドカード文字の最大数

    -

    転送ルールを作成または更新する場合、転送ルールで使用できるワイルドカード文字の最大数は、転送ルールで指定されたアクションおよび一致条件に含まれるワイルドカード文字の合計数に等しくなります。

    ALB Ingress 2には1つの転送ルールがあり、転送ルールのホスト一致条件には、アスタリスク (*) であるワイルドカード文字が1つだけあります。 この場合、転送ルールで使用できるワイルドカード文字の最大数は1つです。

    クォータ項目のアラートルールを作成する

    クォータ使用量または使用可能なクォータのしきい値を指定することで、一部のクォータ項目のアラートルールを作成できます。 クォータの使用率が指定されたしきい値に達すると、システムはHTTP POSTリクエストを介してアラートルールで指定したコールバックURLにアラート通知を送信します。 クォータの超過による調整の失敗を回避するために、アラートを考慮し、事前にクォータの増加を申請することをお勧めします。 このような障害により、転送ルールまたはバックエンドノードがALBへのマウントに失敗する可能性があります。 さらに、kubectl describeおよびkubectl get eventコマンドを使用して、クラスター内のAlbConfig、Ingress、Servicesなどのリソースに関連する詳細とイベントを表示することで、リコンシリエーションのステータスを監視できます。

    手続き (クォータセンター)

    1. クォータセンターコンソールにログインします。

    2. 次のいずれかの方法を使用してアラートルールを作成します。

      • 方法1: [一般クォータのある製品] ページで、[ネットワーキング] セクションの [アプリケーションロードバランサ] をクリックし、[一般クォータ] タブをクリックします。

      • 方法2: 左側のナビゲーションウィンドウで、[クォータアラート] をクリックします。 クォータアラートページで、クォータアラートルールの作成をクリックします。 一般クォータページで、[製品名] ドロップダウンリストから [Application Load Balancer] を選択します。

    3. [一般クォータ] ページで、管理するクォータを見つけ、[操作] 列の [アラートルールの作成] をクリックします。

    4. [クォータアラートルールの作成] パネルで、パラメーターを設定し、[OK] をクリックします。 下表に、各パラメーターを説明します。

      パラメーター

      説明

      例

      アラームルール名

      アラートルールの名前です。

      セキュリティグループの数がしきい値の80% に達する

      アラームメトリック

      アラートルールで使用されるメトリック。 有効な値：

      • 使用済みクォータ

      • 使用済みクォータの割合 (%)

      • 利用可能なクォータ

      • 利用可能なクォータの割合 (%)

      使用済みクォータの割合 (%)

      しきい値

      アラートしきい値。

      • [アラームメトリック] パラメーターが [クォータの使用] に設定されている場合、指定されたクォータ項目のクォータ使用量がしきい値に達した場合、アラート通知が現在のAlibaba Cloudアカウントに送信されます。

      • [アラームメトリック] パラメーターが [使用済みクォータの割合 (%)] に設定されている場合、指定されたクォータ項目のクォータ使用率がしきい値に達した場合、アラート通知が現在のAlibaba Cloudアカウントに送信されます。 有効な値: [50%,100%] 。

      • [アラームメトリック] パラメーターが [利用可能なクォータ] に設定されている場合、指定されたクォータ項目の残りクォータがしきい値以下の場合、現在のAlibaba Cloudアカウントにアラート通知が送信されます。

      • [アラームメトリック] パラメーターが [利用可能なクォータの割合 (%)] に設定されている場合、指定されたクォータ項目の残りのクォータの割合がしきい値以下の場合、現在のAlibaba Cloudアカウントにアラート通知が送信されます。 有効な値: (0%,50%) 。

      説明

      クォータセンターは、一般的なクォータ項目のリアルタイム制限を監視し、クォータ使用量とクォータ制限に基づいて、使用済みクォータの割合と残りのクォータの割合を計算します。

      80%

      通知方法

      アラート通知の送信に使用される方法。 デフォルトでは、アラート通知は メール

      電子メール

      アラームコールバック

      クォータセンターでは、アラートコールバック機能を使用してアラートをサブスクライブできます。 O&Mシステムは、アラートコールバックの内容に基づいてクォータを増やすプロセスを自動的に開始できます。

      Quota Centerは、指定されたインターネットURLへのHTTP POSTリクエストを使用してアラート通知を送信します。

      アラートコールバック要求の例とアラートコールバック要求のパラメーターの詳細については、アラートコールバックのリクエストコンテンツは何ですか?

      説明

      • デフォルトでは、Quota Centerは、指定されたアラートしきい値に達してから約15分後にアラート通知を送信します。

      • アラートコールバックがDingTalkチャットボットのwebhookと統合されている場合、DingTalkチャットボットのカスタムキーワードをalertに設定し、アラートコールバックを受信するURLとしてwebhook URLをコピーする必要があります。

      http://alert.aliyun.com:8080/callback

    5. 左側のナビゲーションウィンドウで、[クォータアラート] をクリックします。 [クォータアラート] ページで、アラートルールの詳細を表示します。

      [クォータアラート] ページで、アラートルールを管理できます。 たとえば、アラートルールを表示、変更、削除できます。

    6. オプションです。 アラートコールバックの結果を表示します。

      アラートコールバックパラメーターを設定すると、アラートコールバックが成功した後にクォータを増やすために自動的に送信されるアラートコールバックレコードとアプリケーションを表示できます。

      1. 左側のナビゲーションウィンドウで、[アラート履歴] をクリックして、アラートコールバックレコードを表示します。

        レコードの [通知方法] 列に [アラートコールバック] が表示された場合、アラートコールバックは成功しました。

      2. 左側のナビゲーションウィンドウで、[アプリケーションレコード] をクリックして、クォータを増やすために自動的に送信されるアプリケーションを表示します。

    手順 (SLBコンソール)

    1. SLBコンソールにログインします。 左側のナビゲーションウィンドウで、[クォータセンター] をクリックします。

    2. On theクォータセンターページをクリックし、ALBタブをクリックします。

    3. [クォータタイプ] セクションで、[一般クォータ] タブをクリックし、管理するクォータを見つけて、[アクション] 列の [アラートルールの作成] をクリックします。

    4. [クォータアラートルールの作成] パネルで、パラメーターを設定し、[OK] をクリックします。 下表に、各パラメーターを説明します。

      パラメーター

      説明

      例

      アラームルール名

      アラートルールの名前です。

      セキュリティグループの数がしきい値の80% に達する

      アラームメトリック

      アラートルールで使用されるメトリック。 有効な値：

      • 使用済みクォータ

      • 使用済みクォータの割合 (%)

      • 利用可能なクォータ

      • 利用可能なクォータの割合 (%)

      使用済みクォータの割合 (%)

      しきい値

      アラートしきい値。

      • [アラームメトリック] パラメーターが [クォータの使用] に設定されている場合、指定されたクォータ項目のクォータ使用量がしきい値に達した場合、アラート通知が現在のAlibaba Cloudアカウントに送信されます。

      • [アラームメトリック] パラメーターが [使用済みクォータの割合 (%)] に設定されている場合、指定されたクォータ項目のクォータ使用率がしきい値に達した場合、アラート通知が現在のAlibaba Cloudアカウントに送信されます。 有効な値: [50%,100%] 。

      • [アラームメトリック] パラメーターが [利用可能なクォータ] に設定されている場合、指定されたクォータ項目の残りクォータがしきい値以下の場合、現在のAlibaba Cloudアカウントにアラート通知が送信されます。

      • [アラームメトリック] パラメーターが [利用可能なクォータの割合 (%)] に設定されている場合、指定されたクォータ項目の残りのクォータの割合がしきい値以下の場合、現在のAlibaba Cloudアカウントにアラート通知が送信されます。 有効な値: (0%,50%) 。

      説明

      クォータセンターは、一般的なクォータ項目のリアルタイム制限を監視し、クォータ使用量とクォータ制限に基づいて、使用済みクォータの割合と残りのクォータの割合を計算します。

      80%

      通知方法

      アラート通知の送信に使用される方法。 デフォルトでは、アラート通知は メール

      電子メール

      アラームコールバック

      クォータセンターでは、アラートコールバック機能を使用してアラートをサブスクライブできます。 O&Mシステムは、アラートコールバックの内容に基づいてクォータを増やすプロセスを自動的に開始できます。

      Quota Centerは、指定されたインターネットURLへのHTTP POSTリクエストを使用してアラート通知を送信します。

      アラートコールバック要求の例とアラートコールバック要求のパラメーターの詳細については、アラートコールバックのリクエストコンテンツは何ですか?

      説明

      • デフォルトでは、Quota Centerは、指定されたアラートしきい値に達してから約15分後にアラート通知を送信します。

      • アラートコールバックがDingTalkチャットボットのwebhookと統合されている場合、DingTalkチャットボットのカスタムキーワードをalertに設定し、アラートコールバックを受信するURLとしてwebhook URLをコピーする必要があります。

      http://alert.aliyun.com:8080/callback

    5. 管理するクォータを見つけて、[アクション] 列の image.png > [アラート設定] を選択します。

    6. [アラート] ダイアログボックスで、アラートルールを表示できます。

    参照