Container Service for Kubernetes:大規模クラスターの使用に関する提案

大きなACKクラスターの使用に関する注意事項

複数のクラスターを使用する場合と比較して、1つの大きなクラスターを使用すると、クラスターのO&Mが効率的に簡素化され、リソース使用率が向上します。 複雑なビジネスシナリオでは、ビジネスロジックまたはサービス需要によってサービスを複数のクラスターに分割することを推奨します。 たとえば、サービスを非運用 (テスト) サービスと運用 (開発) サービスに分割したり、フロントエンドアプリケーションからデータベースサービスを分離したりできます。

次の要件がある場合は、大規模なクラスターを作成するのではなく、複数のクラスターを使用することを推奨します。

アプリケーションのデプロイ、トラフィック管理、ジョブの配布、グローバル監視などのマルチクラスター管理が必要な場合は、マルチクラスターフリートを有効にすることを推奨します。

このトピックについて

このトピックは、ACK Proクラスターの開発者および管理者を対象としています。 このトピックでは、大規模なACKクラスターの計画と使用に関する提案を示します。 実際のクラスター環境とビジネス要件が優先されます。

• 新しいバージョンのクラスターの使用

• クラスターリソースの制限に注意

• 制御プレーンコンポーネントパラメータを適切に設定

• クラスターリソースのスケーリング頻度の計画

• クライアントがクラスターにアクセスするモードの最適化

• 大規模なワークロードを適切に計画する

• 注意を払うメトリックの制御面

新しいバージョンのクラスターを使用する

新しいKubernetesバージョンがリリースされると、ACKでサポートされているKubernetesバージョンのリストも変更されます。 新しいKubernetesバージョンがリストに追加され、古いKubernetesバージョンは廃止されます。 ACKは、古いKubernetesバージョンの新機能、機能パッチ、またはセキュリティパッチのリリースを停止します。 ACKは、これらのバージョンの限定的な技術サポートのみを提供します。

クラスターを更新する前に、ドキュメント、コンソール情報、内部メッセージから新しい更新に関する情報を確認し、目的のKubernetesバージョンの更新ノートを読むことができます。 これにより、セキュリティリスクを軽減し、安定性の問題を解決するために、できるだけ早い機会にクラスターを更新できます。 クラスターの更新の詳細については、「ACKクラスターの手動アップグレード」および「クラスターの自動アップグレード」をご参照ください。 ACKでサポートされているKubernetesバージョンの詳細については、「Kubernetesバージョンのサポート」をご参照ください。

クラスターリソースの制限に注意してください

次の表に、大規模なACKクラスターの可用性、安定性、パフォーマンスを保証するための制限と、対応するソリューションを示します。

制御プレーンコンポーネントパラメータを適切に設定

ACK Proクラスターを使用すると、制御プレーンコンポーネントのパラメーターをカスタマイズできます。 kube-apiserver、kube-controller-manager、kube-schedulerなどの主要管理コンポーネントのパラメーターをカスタマイズできます。 大規模なクラスターでは、制御プレーンコンポーネントのスロットリングパラメーターを適切に設定する必要があります。

kube-apiserver

多数の要求が制御プレーンをオーバーロードするのを防ぐために、kube-apiserverは一定期間内に処理できる同時要求の数を制限します。 上限を超えると、APIサーバーはリクエストスロットリングをトリガーし、HTTPステータスコード429をクライアントに返します。 ステータスコードは、過剰な数の要求が受信され、クライアントが後で再試行しなければならないことを示す。 サーバーにスロットリングが設定されていない場合、制御プレーンはリクエストによってオーバーロードされる可能性があります。 その結果、サービスクラスタ全体の安定性と可用性が影響を受けます。 そのため、コントロールプレーンを保護するために、サーバーでリクエストスロットリングを構成することをお勧めします。

リクエストスロットリング方法

kube-apiserverは、次のリクエストスロットリングメソッドをサポートしています。

• v1.18より前のバージョン: kube-apiserverは最大同時実行性のみを制限できます。 要求は、読み出し要求と書き込み要求とに分類される。 kube-apiserverは、ブートパラメーター -- max-requests-inflightおよび -- max-mutating-requests-inflightを使用して、読み取りおよび書き込み要求の最大同時実行性を制限します。 このメソッドは、優先順位に基づいて要求を処理しません。 優先度の低い遅いリクエストは、大量のリソースを占有し、APIサーバーのリクエストが蓄積する可能性があります。 このシナリオでは、優先度の高い要求または緊急の要求を迅速に処理することはできません。

  ACK Proクラスターを使用すると、kube-apiserverのmax-requests-inflightおよびmax-mutating-requests-inflightパラメーターをカスタマイズできます。 詳細については、「ACK Proクラスターの制御プレーンコンポーネントのパラメーターのカスタマイズ」をご参照ください。

• v1.18以降: API Priority and Fairness (APF) 機能が導入され、よりきめ細かい方法でリクエストを管理します。 この機能により、事前定義されたルールと優先度に基づいてリクエストを分類および分離し、重要かつ緊急のリクエストが優先されるようにします。 この機能では、公平なキューイングアルゴリズムを使用して、さまざまなタイプの要求が公平に処理されるようにします。 この機能はKubernetes 1.20のベータ段階に達し、デフォルトで有効になっています。

  APFの紹介を見る

  Kubernetes 1.20以降を実行するACKクラスターでは、kube-apiserverによって処理される同時リクエストの最大数は、-- max-requests-inflightパラメーターと -- max-mutating-requests-inflightパラメーターの合計に基づいています。 kube-apiserverは、FlowSchemaとPriorityLevelConfiguration CustomResourceDefinitions (CRD) を使用して、各タイプのリクエストの同時実行を制御し、きめ細かい方法でリクエストのスロットリングを実行します。

  • PriorityLevelConfiguration: 優先度レベルを定義します。 これにより、各優先レベルが処理できる使用可能な同時実行予算の割合が決まります。

  • FlowSchema: リクエストを単一のPriorityLevelConfigurationに照合します。

  PriorityLevelConfigurationsとFlowSchemasは、kube-apiserverによって管理されます。 Kubernetesクラスターは、現在のKubernetesバージョンに基づいて、デフォルトのPriorityLevelConfigurationsとFlowSchemasを自動的に生成します。 次のコマンドを実行して、PriorityLevelConfigurationsとFlowSchemasを照会できます。

  PriorityLevelConfigurationsのクエリに使用されるコマンドと出力の表示

  kubectl get PriorityLevelConfiguration
  # Expected output:
  NAME              TYPE      ASSUREDCONCURRENCYSHARES   QUEUES   HANDSIZE   QUEUELENGTHLIMIT   AGE
  catch-all         Limited   5                          <none>   <none>     <none>             4m20s
  exempt            Exempt    <none>                     <none>   <none>     <none>             4m20s
  global-default    Limited   20                         128      6          50                 4m20s
  leader-election   Limited   10                         16       4          50                 4m20s
  node-high         Limited   40                         64       6          50                 4m20s
  system            Limited   30                         64       6          50                 4m20s
  workload-high     Limited   40                         128      6          50                 4m20s
  workload-low      Limited   100                        128      6          50                 4m20s

  FlowSchemasおよび出力のクエリに使用されるコマンドの表示

  説明

  ACKでは、ackキーコンポーネントに関連するack-system-leader-electionとACK-default FlowSchemasが追加されます。 その他のFlowSchemasはKubernetesと同じです。

  kubectl get flowschemas
  # Expected output:
  NAME                           PRIORITYLEVEL     MATCHINGPRECEDENCE   DISTINGUISHERMETHOD   AGE     MISSINGPL
  exempt                         exempt            1                    <none>                4d18h   False
  probes                         exempt            2                    <none>                4d18h   False
  system-leader-election         leader-election   100                  ByUser                4d18h   False
  endpoint-controller            workload-high     150                  ByUser                4d18h   False
  workload-leader-election       leader-election   200                  ByUser                4d18h   False
  system-node-high               node-high         400                  ByUser                4d18h   False
  system-nodes                   system            500                  ByUser                4d18h   False
  ack-system-leader-election     leader-election   700                  ByNamespace           4d18h   False
  ack-default                    workload-high     800                  ByNamespace           4d18h   False
  kube-controller-manager        workload-high     800                  ByNamespace           4d18h   False
  kube-scheduler                 workload-high     800                  ByNamespace           4d18h   False
  kube-system-service-accounts   workload-high     900                  ByNamespace           4d18h   False
  service-accounts               workload-low      9000                 ByUser                4d18h   False
  global-default                 global-default    9900                 ByUser                4d18h   False
  catch-all                      catch-all         10000                ByUser                4d18h   False

リクエストスロットリングモニタリングと推奨ソリューション

クライアントは、ステータスコード429またはapiserver_flowcontrol_rejected_requests_totalメトリックに基づいて、サーバーがリクエストスロットリングをトリガーするかどうかを判断できます。 リクエストスロットリングがトリガーされたら、次のソリューションを使用します。

• APIサーバーのリソース使用量を監視する: リソース使用量が少ない場合は、max-requests-inflightパラメーターとmax-mutating-requests-inflightパラメーターの合計を変更して、合計同時実行制限を増やします。

  500を超えるノードを含むクラスターの場合、合計を2000〜3000の値に設定することを推奨します。 3,000を超えるノードを含むクラスターの場合、合計を3000〜5000の値に設定することを推奨します。

• PriorityLevelConfigurationsの再設定:

  • 優先度の高いリクエスト: 優先度の高いPriorityLevelConfigurationにスロットルしないリクエストを一致させるFlowSchemaを作成します。 例: workload-highまたはexempt。 免除優先度レベルのリクエストはAPFから免除されることに注意してください。 作業は慎重に行ってください。 新しいPriorityLevelConfigurationを設定して、優先度の高いリクエストに同時実行予算の大部分を割り当てることができます。

  • 優先度の低いリクエスト: APIサーバーのリソース使用率が高い場合、またはリクエストが遅いためにAPIサーバーの応答が遅い場合は、これらのリクエストを優先度の低いPriorityLevelConfigurationに一致させるFlowSchemaを作成できます。

kube-controller-managerおよびkube-scheduler

kube-controller-managerはkubeAPIQPSおよびkubeAPIBurstパラメーターを使用し、kube-schedulerはconnectionQPSおよびconnectionBurstパラメーターを使用してAPIサーバーとの通信のQPSを制御します。 詳細については、「ACK Proクラスターの制御プレーンコンポーネントのパラメーターのカスタマイズ」および「kube-schedulerのカスタムパラメーター」をご参照ください。

• kube-controller-manager: 1,000を超えるノードを含むクラスターの場合、kubeAPIQPSを300を超える値に設定し、kubeAPIBurstを500を超える値に設定することを推奨します。

• kube-scheduler: ほとんどの場合、変更は必要ありません。 ポッドのQPSが300 /秒を超える場合は、connectionQPSを800に、connectionBurstを1000に設定することを推奨します。

kubelet

kubeletのkube-api-burstおよびkube-api-qpsパラメーターのデフォルト値は5と10です。 ほとんどの場合、修正は必要ありません。 クラスター内のポッドのステータスがゆっくり更新された場合、ポッドがレイテンシーでスケジュールされた場合、またはボリュームがゆっくりマウントされた場合は、パラメーターの値を増やすことをお勧めします。 詳細については、「ノードプールのkubeletパラメーターのカスタマイズ」をご参照ください。

クラスターリソースのスケーリング頻度の計画

典型的には、大きなクラスタが安定して動作するとき、クラスタ内の制御プレーンはストレスを有さない。 大量のリソースを作成または削除したり、多数のノードをスケールアウトまたはスケールインしたりするなど、クラスタが大規模な操作を開始すると、制御プレーンが過負荷になる可能性があります。 その結果、クラスターのパフォーマンスが低下し、応答遅延が増加し、サービスが中断される可能性があります。

例えば、クラスタは5,000ノードを含む。 長期ビジネスのために多数のポッドがクラスタ内で安定して動作する場合、制御プレーンの負荷は増加しない。 ただし、クラスターに1,000ノードが含まれていて、10,000の一時ジョブを作成するか、1分以内に2,000ノードを追加する場合、制御プレーンの負荷が急上昇します。

したがって、大規模なクラスターでリソースの更新操作を実行する場合は、クラスターと制御プレーンの安定性を確保するために、クラスターのステータスに基づいて更新頻度を制限する必要があります。

次の方法で更新操作を実行することを推奨します。

• ノードスケーリング: 2,000を超えるノードを含むクラスターの場合、ノードプールを手動でスケールする場合は各バッチのノード数を100以下に制限し、複数のノードプールを手動でスケールする場合は各バッチのノード数を300以下に制限することを推奨します。

• アプリケーションポッドのスケーリング: アプリケーションがサービスに関連付けられている場合、EndpointおよびEndpointSliceの更新は、スケーリングアクティビティ中にすべてのノードにプッシュされます。 更新されるデータは、クラスター内のノード数とともに増加します。 クラスターに多数のノードが含まれている場合、クラスターストームが発生します。 5,000を超えるノードを含むクラスターの場合、エンドポイントに関連付けられていないポッドの更新QPSを300 /秒以下に制限し、エンドポイントに関連付けられているポッドの更新QPSを10 /秒以下に制限することを推奨します。 たとえば、デプロイでポッドローリングアップデートポリシーを要求する場合、ポッドの更新頻度を減らすために、maxUnavailableとmaxSurgeを小さな値に設定することを推奨します。

クライアントがクラスターにアクセスするモードを最適化する

Kubernetesクラスターでは、アプリケーションやkubectlクライアントなどのクライアントは、APIサーバー。 クラスタ内のリソースの量が増加しても、クライアントが依然として同じ頻度で要求を送信する場合、要求は制御プレーンを過負荷にする可能性がある。 その結果、制御プレーンはゆっくりと応答するか、あるいはクラッシュする。 したがって、Kubernetesクラスターにデプロイされたリソースにアクセスする前に、アクセスするリソースのサイズとアクセス頻度を計画する必要があります。 大規模なクラスター内のリソースにアクセスする場合は、次の提案を読むことをお勧めします。

できれば、情報提供者を使用してローカルキャッシュにアクセス

リソースを取得するには、クライアント情報提供者を使用することが望ましい。 LISTリクエストをAPIサーバーに送信する代わりに、ローカルキャッシュからデータを取得します。 これにより、APIサーバーの負荷が軽減されます。

からリソースを取得するために使用されるメソッドを最適化します。APIサーバー

ローカルキャッシュにヒットしないリクエストは、リソースを取得するためにAPIサーバーに送信されます。 このシナリオでは、次の提案をお読みください。

• LISTリクエストでresourceVersion=0を指定します。

  resourceVersionは、リソースのバージョンを示します。 値が0の場合、キャッシュデータはetcdではなくAPIサーバーから取得されます。 これにより、APIサーバーとetcd間の通信頻度が減少します。 LISTリクエストは、はるかに高速に処理できます。 例：

  k8sClient.CoreV1().Pods("").List(metav1.ListOptions{ResourceVersion: "0"})

• すべてのリソースをリストしないでください。

  返されるデータの量を減らすには、フィルターを使用してLISTリクエストの範囲を制限します。 たとえば、LISTリクエストをフィルタリングするには、lable-selector (リソースラベルに基づくフィルタ) またはfield-selector (リソースフィールドに基づくフィルタ) を使用します。

  説明

  etcdはkey-valueストレージシステムです。 etcdは、ラベルまたはフィールドでデータをフィルタできません。 APIサーバーは、指定されたフィルター条件に基づいてすべてのリクエストをフィルターします。 フィルターを使用する場合は、LISTリクエストに対してresourceVersionを0に設定することを推奨します。 要求されたデータは、etcdの代わりにAPIサーバー上のキャッシュから取得されるため、etcdの負荷が軽減されます。

• 非CRDリソースにアクセスするには、JSONではなくprotobufを使用します。

  APIサーバーは、JSONやprotobufなど、さまざまな形式のリソースオブジェクトをクライアントに返すことができます。 デフォルトでは、クライアントがKubernetes APIリクエストを送信すると、Kubernetesはシリアル化されたJSONオブジェクトを返します。 オブジェクトのコンテンツタイプ (content-type) はapplication/jsonです。 クライアントはKubernetesにprotobuf形式のデータを返すように要求できます。 Protobufは、メモリ使用量とデータ転送においてJSONよりも優れています。

  ただし、すべてのAPIリソースタイプがprotobuf形式をサポートしているわけではありません。 [Accept] リクエストヘッダーには、application/jsonやapplication/vnd.kubernetes.protobufなど、複数のコンテンツタイプを指定できます。 このように、protobuf形式がサポートされていない場合、JSON形式のリソースが返されます。 詳細については、「リソースの代替表現」をご参照ください。 例：

  Accept: application/vnd.kubernetes.protobuf, application/json

集中コントローラの使用

クラスタデータを監視するために、各ノードに個別のコントローラを作成しないようにする必要があります。 そうしないと、コントローラが起動すると、大量のLISTリクエストが同時にAPIサーバーに送信され、クラスターのステータスが同期されます。 これは、制御プレーンの負荷を増加させ、サービスの安定性を損ない、またはサービスの中断を引き起こす。

この問題を回避するには、集中コントローラの使用を推奨します。 1つのノードで実行されるコントローラインスタンス、または少数のノードで実行されるコントローラインスタンスのグループを作成して、集中管理を行うことができます。 集中コントローラは、1回または数回起動することによって、LIST要求をリッスンし、処理することができる。 さらに、集中型コントローラは、少数のウォッチ接続を維持するだけでよいため、APIサーバの負荷が大幅に低減される。

大規模なワークロードを適切に計画する

デフォルトのサービスアカウントを自動的にマウントする機能を無効にする

ポッド内のSecretsが同期的に更新されるようにするために、kubeletは各Secretのウォッチ永続接続を作成します。 ウォッチメカニズムにより、kubeletはシークレット更新通知をリアルタイムで受信できます。 過剰な数の腕時計が作成されると、腕時計の接続は、制御プレーンの性能に影響を及ぼす可能性がある。

• 1.22より前のバージョンのKubernetesでは: ポッドを作成すると、サービスアカウントを指定しないと、デフォルトのサービスアカウントが自動的にポッドのシークレットとしてマウントされます。 ポッド内のアプリケーションは、サービスアカウントを使用してAPIサーバーと安全に通信できます。

  バッチシステムのポッドまたはAPIサーバーにアクセスする必要のないポッドの場合は、サービスアカウントのトークンの自動マウントを明示的に禁止することを推奨します。 このように、関連する秘密と時計は作成されません。 詳細については、「automountServiceAccountToken」をご参照ください。 大規模なクラスターでは、この操作により、不要なSecretsとAPIサーバーのwatch接続の作成を回避できます。これにより、コントロールプレーンの負荷が軽減されます。

• Kubernetes 1.22以降の場合: TokenRequest APIを使用して一時的な自動ローテーショントークンを取得し、投影ボリュームを使用してトークンをマウントできます。 この動作は、Secretsのセキュリティを強化するだけでなく、各サービスアカウントのSecretに対してkubeletによって確立された監視接続を減少させる。 このようにして、クラスターのパフォーマンスが保証されます。

  serviceAccountToken投影ボリュームを有効にする方法の詳細については、「ServiceAccountトークンボリューム投影の使用」をご参照ください。

Kubernetesオブジェクトの数とサイズの制御

ConfigMaps、Secrets、永続ボリュームクレーム (PVC) などのアイドル状態のKubernetesリソースをできるだけ早く削除して、システムリソースの使用量を減らし、クラスターパフォーマンスを確保します。 次の提案を読むことをお勧めします。

• 過去のDeployment ReplicaSetsの数を制限する: revisionHistoryLimitは、Deploymentに対して保持される過去のReplicaSetsの数を要求します。 値が大きい場合、Kubernetesは過剰な数の履歴ReplicaSetを保持します。 これにより、kube-controller-managerの負荷が増加します。 大規模なクラスターでは、多数のデプロイメントを頻繁に更新する必要がある場合、デプロイメントのrevisionHistoryLimitの値を減らし、履歴ReplicaSetを削除できます。 デプロイメントのrevisionHistoryLimitのデフォルト値は10です。

• 不要になったジョブとポッドの削除: CronJobsまたはその他のメカニズムによって作成された多数のJobオブジェクトがクラスターに含まれている場合は、ttlSecondsAfterFinishedを使用して、前のサイクル内にジョブ用に作成されたポッドを自動的に削除します。

Informerコンポーネントにリソースを適切に割り当てる

Informerコンポーネントは通常、Kubernetesクラスター内のリソースのステータスを監視および同期するために使用されます。 Informerコンポーネントは、監視接続を確立してAPIサーバーリソースのステータスを監視し、各リソースオブジェクトのローカルキャッシュを維持します。 このようにして、リソースステータスの変更を迅速に同期できます。

コントローラーやkube-schedulerなどのInformerコンポーネントのメモリ使用量は、Watchリソースのサイズによって異なります。 大規模なクラスターでは、メモリ不足 (OOM) の問題を回避するために、Informerコンポーネントのメモリ使用量に注意してください。 InformerコンポーネントがOOMの問題に頻繁に遭遇すると、リソースリスニングエラーが発生する可能性があります。 Informerコンポーネントが頻繁に再起動すると、各List-Watch操作によって制御プレーン (特にAPIサーバー) の負荷が増加します。

コントロールプレーンのメトリックに注意してください

関連ドキュメント

• ACKクラスターのクォータと制限の詳細については、「クォータと制限」をご参照ください。

• 仮想プライベートクラウド (VPC) とコンテナネットワークを計画する方法の詳細については、「ACKクラスターのネットワークを計画する」をご参照ください。

• ACKクラスターとワークロードの高い信頼性を確保する方法の詳細については、「推奨されるワークロード設定」をご参照ください。

• ACKクラスターを使用するときに発生する問題のトラブルシューティング方法の詳細については、 トラブルシューティングとクラスター管理に関するFAQ。