Container Service for Kubernetes:大規模クラスターの使用に関する推奨事項

大規模クラスターを使用する際の考慮事項

単一の大規模クラスターを構築すると、複数のクラスターを使用する場合と比較して、クラスター管理と運用保守のオーバーヘッドを削減し、リソース使用率を向上させることができます。しかし、一部の複雑なビジネスシナリオでは、ビジネスロジックや要件に基づいてサービスを複数のクラスターに分割する必要がある場合があります。たとえば、非本番 (テスト) サービスを本番 (開発) サービスから分離したり、データベースサービスをフロントエンドアプリケーションから分離したりできます。

以下の考慮事項がある場合は、単一の大規模クラスターではなく、複数のクラスターを使用することを推奨します。

アプリケーションのデプロイ、トラフィック管理、ジョブの分散、グローバルモニタリングなどのタスクで複数のクラスターを管理するには、フリート管理を有効にすることができます。

本トピックの使い方

本トピックでは、大規模クラスターの計画と使用に関する一般的な推奨事項を説明します。これは、ACK Pro マネージドクラスターの開発者と管理者を対象としています。特定のクラスター環境とビジネスニーズに基づいて、推奨事項を調整できます。

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

• クラスターリソース制限のモニタリング

• コントロールプレーンコンポーネントのパラメーター設定

• クラスターリソースのスケーリングレートの計画

• クラスターへのクライアントアクセスパターンの最適化

• 大規模ワークロードの計画

• コントロールプレーンメトリクスのモニタリング

最新のクラスターバージョンの使用

Kubernetes コミュニティは定期的に新しいバージョンをリリースし、新機能や最適化を導入しています。新しい Kubernetes バージョンは、安定性、パフォーマンス、スケーラビリティの向上を提供します。一般的な最適化には以下が含まれます：

• バージョン 1.31 では、kube-apiserver はキャッシュからの List リクエストに対して一貫性のある読み取りを提供します。これにより、リクエストを etcd に渡す必要性が減り、List リクエストの効率が向上し、etcd の負荷が大幅に軽減されます。詳細については、「Consistent Reads from Cache」をご参照ください。

• バージョン 1.33 では、kube-apiserver は StreamingCollectionEncodingToJSON と StreamingCollectionEncodingToProtobuf を含むストリーミングエンコーディングメカニズムを使用します。この改善により、リソース取得リクエストをストリームとして処理することで、List 操作のパフォーマンスが最適化されます。多くのリソースを含む List リクエストの場合、これにより kube-apiserver のメモリ使用量が効果的に削減され、システムの安定性が向上します。詳細については、「Streaming List responses」をご参照ください。

ACK は、Kubernetes コミュニティと同期してサポートされている Kubernetes バージョンを定期的にリリースし、期限切れのバージョンに対する技術サポートを段階的に終了します。期限切れのバージョンについては、ACK は新機能のリリース、機能またはセキュリティバグの修正を停止し、限定的な技術サポートのみを提供します。

ヘルプドキュメント、コンソールメッセージ、および内部メッセージを通じてバージョンリリース情報を追跡できます。潜在的なセキュリティと安定性の問題を回避するために、クラスターを迅速にアップグレードする必要があります。

• ACK がサポートする Kubernetes バージョンについては、「バージョンガイド」をご参照ください。

• 影響、手順、注意事項、方法など、クラスターのアップグレードに関する情報については、「クラスターのアップグレード」をご参照ください。

• クラスターのアップグレード操作については、「ACK クラスターの手動アップグレード」および「クラスターの自動アップグレード」をご参照ください。

クラスターリソース制限のモニタリング

大規模クラスターの可用性、安定性、パフォーマンスを確保するために、以下の表に記載されている制限を監視し、推奨されるソリューションに従ってください。

コントロールプレーンコンポーネントのパラメーター設定

ACK Pro マネージドクラスターは、コントロールプレーンコンポーネントのパラメーターをカスタマイズする機能を提供します。この機能は、kube-apiserver、kube-controller-manager、kube-scheduler などのコアマネージドコンポーネントのパラメーター変更をサポートします。大規模クラスターでは、コントロールプレーンコンポーネントのスロットリング関連パラメーターを適切に調整する必要があります。

kube-apiserver

多数の同時リクエストがコントロールプレーンに過負荷をかけるのを防ぐために、kube-apiserver はいつでも処理できる同時リクエストの数を制限します。この制限を超えると、API サーバーはリクエストのスロットリングを開始し、クライアントに HTTP 429 レスポンスコード (Too Many Requests) を返し、後で再試行するように指示します。サーバー側にスロットリング措置がない場合、コントロールプレーンは容量を超えるリクエストの処理で過負荷になり、サービスまたはクラスター全体の安定性と可用性に深刻な影響を与える可能性があります。したがって、コントロールプレーンのクラッシュによる広範な問題を回避するために、サーバー側のスロットリングメカニズムを構成する必要があります。

スロットリングの分類

kube-apiserver のスロットリングは 2 種類に分けられます。

• v1.18 より前のバージョン：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 優先度と公平性 (APF) メカニズムが導入されました。これは、事前設定されたルールと優先度に基づいてリクエストを分類および分離することをサポートします。これにより、より重要で緊急のリクエストが最初に処理されることが保証され、異なるタイプのリクエストが合理的な処理機会を得られるように、特定の公平性ポリシーに従います。この機能は v1.20 でベータ段階に入り、デフォルトで有効になっています。

  クリックして APF の説明を表示

  v1.20 以降の Kubernetes クラスターでは、kube-apiserver は --max-requests-inflight と --max-mutating-requests-inflight パラメーターの合計を通じて、同時に処理できるリクエストの総数を構成します。より詳細なトラフィック制御のために、FlowSchema と PriorityLevelConfiguration の 2 種類のカスタムリソース定義 (CRD) を使用して、異なるタイプのリクエスト間で割り当てられる同時実行数を制御します。

  • PriorityLevelConfiguration：特定の優先度レベルが割り当てられることができる合計同時実行数の割合を決定する優先度構成。

  • FlowSchema：リクエストがどの PriorityLevelConfiguration に属するかを決定します。

  PriorityLevelConfiguration と FlowSchema は kube-apiserver によって自動的に維持されます。現在のクラスターバージョンのデフォルト構成は、Kubernetes クラスターで自動的に生成されます。以下のコマンドを実行して表示できます。

  クリックして PriorityLevelConfiguration のクエリコマンドと期待される出力を表示

  kubectl get PriorityLevelConfiguration
  # 期待される出力
  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

  クリックして FlowSchema のクエリコマンドと期待される出力を表示

  説明

  ACK は、ACK コアコンポーネントに関連する分類 ack-system-leader-election と ack-default を FlowSchema に追加します。残りはコミュニティと一致しています。

  kubectl get flowschemas
  # 期待される出力
  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 ノードを超えるクラスターでは、パラメーターの合計を 2,000 から 3,000 の間に設定することを推奨します。3,000 ノードを超えるクラスターでは、3,000 から 5,000 の間に設定することを推奨します。

• PriorityLevelConfiguration を再構成します。

  • 高優先度リクエスト：スロットリングされたくないリクエストについては、新しい FlowSchema を作成し、workload-high や exempt などの高優先度の PriorityLevelConfiguration と一致させることができます。ただし、exempt 優先度のリクエストは APF によってスロットリングされないため、注意して構成する必要があります。また、高優先度リクエスト用に新しい PriorityLevelConfiguration を構成して、より高い同時実行性を与えることもできます。

  • 低優先度リクエスト：特定の遅いクライアントリクエストが API サーバーの高いリソース使用量や遅い応答を引き起こす場合、このタイプのリクエスト用に新しい FlowSchema を追加し、低同時実行性の PriorityLevelConfiguration と一致させることができます。

kube-controller-manager と kube-scheduler

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

• kube-controller-manager：1,000 ノードを超えるクラスターでは、kubeAPIQPS/kubeAPIBurst を 300/500 以上に調整することを推奨します。

• kube-scheduler：通常、調整は不要です。Pod レートが 300/s を超える場合、connectionQPS/connectionBurst を 800/1000 に調整することを推奨します。

kubelet

kubelet コンポーネントの kube-api-burst/qps のデフォルト値は 5/10 であり、通常は調整する必要はありません。クラスターで Pod のステータス更新の遅延、スケジューリングの遅延、永続ボリュームのマウントの遅延などの重大なパフォーマンス問題が発生した場合は、パラメーター値を増やすことを推奨します。手順と説明については、「ノードプールの kubelet 構成をカスタマイズする」をご参照ください。

クラスターリソースのスケーリングレートの計画

大規模クラスターでは、安定した運用中はコントロールプレーンの負荷は通常低いです。しかし、クラスターが大規模な変更、たとえば多数のリソースを迅速に作成または削除したり、多数のノードをスケーリングしたりすると、負荷が過剰になり、クラスターのパフォーマンスと応答速度に影響を与える可能性があります。

たとえば、5,000 ノードのクラスターで多数の固定 Pod が安定して実行されている場合、コントロールプレーンへの負荷は通常それほど高くありません。しかし、1,000 ノードのクラスターで、1 分以内に 10,000 の短命ジョブを作成したり、2,000 ノードを同時にスケールアウトしたりすると、コントロールプレーンへの負荷は急増します。

したがって、大規模クラスターでリソース変更操作を実行する場合は、クラスターとコントロールプレーンの安定性を確保するために、クラスターの実行状態に基づいてスケーリング操作の変更率を慎重に計画する必要があります。

推奨される操作は次のとおりです。

• ノードのスケールアウトとスケールイン：2,000 ノードを超えるクラスターで、ノードプールを介して手動でノードをスケーリングする場合、単一ノードプールの 1 回の操作でのノード数は 100 を超えないようにする必要があります。複数のノードプールにまたがる 1 回の操作での合計ノード数は 300 を超えないようにする必要があります。

• アプリケーション Pod のスケールアウトとスケールイン：アプリケーションがサービスに関連付けられている場合、スケーリング中の Endpoint と EndpointSlice の更新はすべてのノードにプッシュされます。ノード数が多いシナリオでは、更新する必要のあるデータが多くなり、クラスターのストーム効果を引き起こす可能性があります。5,000 ノードを超えるクラスターでは、Endpoint に関連付けられていない Pod の更新 QPS は 300/s を超えないようにすることを推奨します。Endpoint に関連付けられている Pod の更新 QPS は 10/s を超えないようにすることを推奨します。たとえば、Deployment のローリングアップデート戦略を宣言する場合、Pod の更新レートを減らすために、最初に maxUnavailable と maxSurge に小さい値を設定することを推奨します。

クラスターへのクライアントアクセスパターンの最適化

Kubernetes クラスターでは、クライアントは API サーバーを通じてクラスターリソース情報を取得します。クラスター内のリソース数が増加するにつれて、クライアントからの頻繁なリクエストはクラスターコントロールプレーンの負担を増大させ、応答遅延や雪崩効果につながる可能性があります。リソースアクセスのサイズと頻度を理解し、計画する必要があります。推奨事項は次のとおりです。

ローカルキャッシュデータへのアクセスには informer を優先的に使用する

リソースを取得するには、client-go の informer を優先的に使用します。ローカルキャッシュからデータをクエリして、API サーバーに直接アクセスする List リクエストを回避し、API サーバーの負荷を軽減します。

API サーバーを介したリソース取得方法の最適化

アクセスされていないローカルキャッシュについては、引き続き API サーバーを介して直接リソースを取得する必要があります。ただし、以下の推奨事項に従うことができます。

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

  resourceVersion はリソースの状態のバージョンを示します。0 に設定すると、リクエストは etcd に直接アクセスする代わりに API サーバーからキャッシュされたデータを取得します。これにより、API サーバーと etcd 間の内部相互作用の数が減り、クライアントの List リクエストへの応答が速くなります。以下は例です。

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

• 過剰なデータ取得を防ぐために、すべてのリソースをリスト表示することを避けます。

  リクエストによって返されるデータ量を減らすために、ラベルセレクター (リソースタグに基づく) やフィールドセレクター (リソースフィールドに基づく) などのフィルター条件を使用して、List リクエストの範囲を制限できます。

  説明

  etcd はキー・バリュー (KV) ストレージシステムであり、ラベルやフィールドでデータをフィルタリングする機能はありません。リクエストに含まれるフィルター条件は、実際には API サーバーによって処理されます。したがって、フィルター機能を使用する場合は、List リクエストの resourceVersion を同時に 0 に設定することを推奨します。リクエストデータは API サーバーのキャッシュから取得され、etcd に直接アクセスしないため、etcd への負荷が軽減されます。

• CRD 以外のリソースへのアクセスには、JSON ではなく Protobuf を使用します。

  API サーバーは、JSON や Protobuf など、さまざまなデータ形式でリソースオブジェクトをクライアントに返すことができます。デフォルトでは、クライアントが Kubernetes API をリクエストすると、Kubernetes は JSON としてシリアル化されたオブジェクトを返し、コンテンツタイプは application/json です。クライアントは、リクエストが 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 リクエストのみを開始し、必要な数の Watch 接続のみを維持するため、API サーバーへの負荷が大幅に軽減されます。

大規模ワークロードの計画

デフォルト ServiceAccount の自動マウントを無効にする

Pod 内の Secret の同期更新を確実にするために、kubelet は Pod に構成された各 Secret に対して永続的な Watch 接続を確立します。Watch メカニズムにより、kubelet は Secret の更新に関するリアルタイムの通知を受け取ることができます。ただし、すべてのノードによって作成された Watch の総数が多すぎると、多数の Watch 接続がクラスターコントロールプレーンのパフォーマンスに影響を与える可能性があります。

• Kubernetes バージョン 1.22 より前：Pod が作成されるとき、ServiceAccount が指定されていない場合、Kubernetes はデフォルトの ServiceAccount の Secret を自動的に Pod にマウントします。これにより、Pod 内のアプリケーションは API サーバーと安全に通信できます。

  バッチ処理システムや API サーバーにアクセスする必要のないアプリケーション Pod については、ServiceAccount トークンの自動マウントを明示的に禁止することを推奨します。これにより、関連する Secret と Watch の作成が回避されます (詳細については、「automountServiceAccountToken」をご参照ください)。大規模クラスターでは、この操作により、不要な Secret と API サーバーとの Watch 接続の作成が回避され、クラスターコントロールプレーンの負担が軽減されます。

• Kubernetes 1.22 以降：TokenRequest API を使用して、短期間で自動的にローテーションされるトークンを取得し、このトークンを projected volume としてマウントできます。Secret のセキュリティを向上させながら、この操作は kubelet が各 ServiceAccount の Secret に対して確立する Watch 接続の数も減らし、クラスターのパフォーマンスオーバーヘッドを低減します。

  ServiceAccount トークン projected volume 機能を有効にする方法については、「ServiceAccount トークンボリュームプロジェクションの使用」をご参照ください。

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

ConfigMap、Secret、PVC などの未使用の Kubernetes リソースを迅速にクリーンアップして、システムリソースの使用量を削減し、クラスターを健全で効率的に保つ必要があります。以下は使用に関する推奨事項です。

• デプロイメント履歴の制限：revisionHistoryLimit は、デプロイメントのために保持する古い ReplicaSet の数を宣言します。値が高すぎると、Kubernetes は多くの履歴バージョンの ReplicaSet を保持し、kube-controller-manager の管理負担が増加します。大規模クラスターで、多くのデプロイメントがあり、頻繁に更新される場合は、デプロイメントの revisionHistoryLimit の値を下げて古い ReplicaSet をクリーンアップできます。デプロイメントの revisionHistoryLimit のデフォルト値は 10 です。

• 未使用のジョブと関連する Pod のクリーンアップ：CronJob または他のメカニズムを通じてクラスター内に多くのジョブオブジェクトが作成される場合、ttlSecondsAfterFinished を使用して、完了したジョブとその関連する Pod を自動的にクリーンアップできます。これにより、ジョブとその関連する Pod が一定期間後に自動的に削除されるように指定されます。

Informer タイプのコンポーネントのリソースを適切に構成する

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

コントローラーコンポーネントや kube-scheduler などの Informer タイプのコンポーネントの場合、コンポーネントのメモリ使用量は、監視するリソースのサイズに関連しています。大規模クラスターでは、Out-of-Memory (OOM) エラーを防ぐために、これらのコンポーネントのメモリ消費に注意を払う必要があります。頻繁な OOM は、コンポーネントによる継続的なリソース監視に問題を引き起こす可能性があります。コンポーネントが頻繁に再起動すると、毎回実行される List-Watch 操作も、クラスターコントロールプレーン、特に API サーバーに追加の負荷をかけます。

コントロールプレーンメトリクスのモニタリング

関連ドキュメント

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

• クラスターの VPC ネットワークとコンテナネットワークを適切に計画する方法については、「ACK マネージドクラスターの CIDR ブロックの計画」をご参照ください。

• クラスター作成とワークロードの高信頼性構成を実現する方法については、「推奨されるワークロード構成」をご参照ください。

• ACK クラスターの使用中にエラーや関連する問題が発生した場合は、トラブルシューティング情報について「トラブルシューティング」および「クラスター管理に関するよくある質問」をご参照ください。