ALBクォータの計算方法 - Container Service for Kubernetes - Alibaba Cloud ドキュメントセンター

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

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

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

次の表は、標準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: 左側のナビゲーションウィンドウで、[クォータアラート] をクリックします。 クォータアラートページで、クォータアラートルールの作成をクリックします。 一般クォータページで、[製品名] ドロップダウンリストから [Application Load Balancer] を選択します。
[一般クォータ] ページで、管理するクォータを見つけ、[操作] 列の [アラートルールの作成] をクリックします。

[アラームルールの作成] ページで、パラメーターを設定し、[確認] をクリックします。

表1クォータ項目のアラートルールを作成するためのパラメーター

パラメーター	説明	例
アラームルール名	アラートルールの名前です。	購入制限付きプリエンプティブルインスタンスのvCPUの最大数
アラームメトリック	アラートルールで使用されるメトリック。有効な値：クォータ使用済みクォータ使用済みクォータの割合 (%) 利用可能なクォータの割合 (%)	使用済みクォータの割合 (%)
しきい値とアラートレベル	アラートレベルと、このレベルに対応するしきい値。次のデフォルトの通知方法は、さまざまなアラートレベルに設定されています。重要: メールとコールバック警告: メールとコールバック情報: メールとコールバックまた、アラートがトリガーされる前にしきい値に達した回数を選択する必要があります。有効値: 1連続サイクル、3連続サイクル、5連続サイクル、10連続サイクル、15連続サイクル、30連続サイクル、60連続サイクル、70連続サイクル、90連続サイクル、120連続サイクル、180連続サイクル。さまざまなアラートレベルの設定を構成できます。このように、CloudMonitorは、レベルに対応するしきい値に基づいて特定のレベルでアラートを生成し、指定された方法を使用してアラート通知を送信します。	アラートレベル: 情報。このアラートレベルのデフォルトの通知方法は、[メールとコールバック] です。閾値: ≧ 80% 。
ミュート用	生成されたアラートがクリアされない場合にアラート通知が送信される間隔。この値は、無音期間も示す。有効な値: 5分、15分、30分、60分、3時間、6時間、12時間、および24時間。メトリックがアラートしきい値に達すると、アラート通知が送信されます。無音期間中、メトリックがアラートしきい値を繰り返し超えた場合、新しいアラート通知は送信されません。無音期間が終了した後、メトリックが通常状態に戻らない場合、新しいアラート通知が送信されます。たとえば、[ミュート] パラメーターを24時間に設定した場合、CloudMonitorは生成されたアラートのアラート通知を送信し、アラートは未解決のままで、CloudMonitorは24時間後に新しいアラート通知を送信します。	5 分
アクティブ化の時刻	アラートルールが有効になる期間。アラートルールが有効になり、指定された曜日の指定された時間にのみアラートが生成されます。	サイクル: 月曜日から日曜日時間: 00:00から23:59
アラーム連絡先グループ	アラート通知の送信先の連絡先グループ。アプリケーショングループのアラート通知は、アラート連絡先グループのアラート連絡先に送信されます。アラート連絡先グループは、1つ以上のアラート連絡先を含むアラート連絡先のグループです。アラート送信先またはアラート送信先グループを作成する方法の詳細については、「アラート送信先またはアラート送信先グループの作成」をご参照ください。	ECSインスタンスタイプのクォータ管理者
アラームコールバック	HTTP POSTリクエストを使用してCloudMonitorによってプッシュされたアラート情報を受信するためにインターネット経由でアクセス可能なURL。 HTTPプロトコルのみがサポートされています。コールバックURLの接続をテストするには、次の操作を実行します。コールバックURLの横にある [テスト] をクリックします。 [テスト結果] ページでは、返されたステータスコードとテスト結果の詳細に基づいて、コールバックURLの接続性を確認できます。説明 [言語] パラメーターを設定し、再度 [テスト] をクリックして、指定した言語のテスト結果の詳細を取得することもできます。閉じるをクリックします。	http://alert.aliyun.com:8080/callback
ラベル	アラートルールのタグ。タグは、タグキーとタグ値で構成されます。アラートルールには最大6つのタグを指定できます。	`k1,v1`
プッシュチャンネル	アラート情報の配信に使用されるAlibaba Cloudサービス。有効な値：シンプルなLog Service Simple Log Serviceをオンにすると、アラートが生成されると、アラート情報がSimple Log ServiceのLogstoreに送信されます。この場合、Region、ProjectName、およびLogstoreパラメーターを設定する必要があります。プロジェクトとLogstoreの作成方法については、「入門」をご参照ください。メッセージサービス-トピック Message Service - topicをオンにすると、アラートが生成されると、アラート情報がSimple Message Queue (formerly MNS) のトピックに送信されます。この場合、リージョンとトピックを指定する必要があります。Simple Message Queue (formerly MNS) トピックの作成方法の詳細については、「トピックベースのメッセージングの使用開始」をご参照ください。 Function Compute Function Computeをオンにすると、アラートが生成されると、アラート情報がFunction Computeに送信され、フォーマットされます。この場合、リージョン、サービス、および関数を指定する必要があります。サービスと関数の作成方法については、「関数の迅速な作成」をご参照ください。	すべてのスイッチをオフにする
リカバリ通知	アラートがクリアされたときに通知を送信するかどうかを指定します。スイッチはデフォルトでオンになっています。	スイッチをオンにする
モニタリングデータが見つからない場合にアラームを処理するメソッド	モニタリングデータが利用できない場合にアラートを処理するために使用されるメソッド。有効な値：何もしない (デフォルト) アラーム通知の送信通常通り	何もしない

左側のナビゲーションウィンドウで、[クォータアラート] をクリックします。 [クォータアラート] ページで、アラートルールの詳細を表示します。
[クォータアラート] ページで、アラートルールを管理できます。たとえば、アラートルールを表示、変更、削除できます。
必要に応じて、アラートコールバックの結果を表示します。
アラートコールバックパラメーターを設定すると、アラートコールバックが成功した後にクォータを増やすために自動的に送信されるアラートコールバックレコードとアプリケーションを表示できます。
1. 左側のナビゲーションウィンドウで、[アラート履歴] をクリックして、アラートコールバックレコードを表示します。
  レコードの [通知方法] 列に [アラートコールバック] が表示された場合、アラートコールバックは成功しました。
2. 左側のナビゲーションウィンドウで、[アプリケーションレコード] をクリックして、クォータを増やすために自動的に送信されるアプリケーションを表示します。

手順 (SLBコンソール)

SLBコンソールにログインします。左側のナビゲーションウィンドウで、[クォータセンター] をクリックします。
On theクォータセンターページをクリックし、ALBタブをクリックします。
[クォータタイプ] セクションで、[一般クォータ] タブをクリックし、管理するクォータを見つけて、[アクション] 列の [アラートルールの作成] をクリックします。