8.8. ワーカーレイテンシープロファイルを使用したレイテンシーの高い環境でのクラスターの安定性の向上

クラスター管理者がプラットフォームの検証に対してレイテンシーテストを実行した場合、レイテンシーが長い場合に安定性を確保するためにクラスターの操作を調整する必要性を検出できます。クラスター管理者は、ファイルに記録された 1 つのパラメーターのみを変更する必要があります。これは、スーパーバイザープロセスがステータスを読み取り、クラスターの正常性を解釈する方法に影響を与える 4 つのパラメーターを制御します。1 つのパラメーターのみを変更すると、簡単にサポート可能な方法でクラスターのチューニングが可能になります。

Kubelet プロセスは、クラスターの正常性をモニターするための開始点を提供します。Kubelet は、OpenShift Container Platform クラスター内のすべてのノードのステータス値を設定します。Kubernetes Controller Manager (kube コントローラー)は、デフォルトで 10 秒ごとにステータス値を読み取ります。kube コントローラー がノードステータス値を読み取ることができない場合、設定された期間が経過するとそのノードとの接続が失われます。デフォルトの動作は次のとおりです。

  1. コントロールプレーンのノードコントローラーはノードの正常性を Unhealthy に更新し、ノードの Ready 状態を Unknown とマークします。
  2. この操作に応じて、スケジューラーはそのノードへの Pod のスケジューリングを停止します。
  3. オンプレミスノードコントローラーは、effect が NoExecute の node.kubernetes.io/unreachable テイントをノードに追加し、デフォルトで 5 分後に、エビクション用にノード上で Pod をスケジュールします。

この動作は、ネットワークが遅延の問題を起こしやすい場合、特にネットワークエッジにノードがある場合に問題が発生する可能性があります。Kubernetes Controller Manager Operator は、ネットワークの遅延により、健全なノードからの更新を受信できない場合があります。Kubelet は、ノードが正常な場合でも Pod をノードからエビクトします。

この問題を回避するには、ワーカーレイテンシープロファイル を使用して kubelet および Kubernetes Controller Manager Operator がステータスの更新を待機する頻度を調節してからアクションを実行することができます。これらの調整により、コントロールプレーンとワーカーノード間のネットワーク遅延が最適でない場合に、クラスターが適切に動作するようになります。

これらのワーカーレイテンシープロファイルには、慎重に調整された値で事前定義された 3 つのパラメーターセットが含まれ、レイテンシーが増加するクラスターの反応を制御します。実験的に最高の値を手動で見つける必要はありません。

クラスターのインストール時、またはクラスターネットワークのレイテンシーの増加に気付いたときはいつでも、ワーカーレイテンシープロファイルを設定できます。

クラスターのインストール時、またはクラスターネットワークのレイテンシーの増加に気付いたときはいつでも、ワーカーレイテンシープロファイルを設定できます。

8.8.1. ワーカーレイテンシープロファイルを理解する

ワーカーレイテンシープロファイルは、慎重に調整されたパラメーターの 4 つの異なるカテゴリーです。この値を実装する 4 つのパラメーターは、node-status-update-frequency、node-monitor-grace-period、default-not-ready-toleration-seconds、および default-unreachable-toleration-seconds です。これらのパラメーターは、値を使用することで、手動メソッドで最適な値を判断しなくても、レイテンシーの問題に対するクラスターの反応を制御できます。

重要

これらのパラメーターを手動で設定することはサポートされていません。パラメーター設定が間違って、クラスターの安定性に悪影響を及ぼします。

すべてのワーカーレイテンシープロファイルは、次のパラメーターを設定します。

node-status-update-frequency
kubelet がノードステータスを API サーバーに投稿する頻度を指定します。
node-monitor-grace-period
Kubernetes Controller Manager Operator が、ノードを異常とマークし、node.kubernetes.io/not-ready または node.kubernetes.io/unreachable taint をノードに追加する前に、kubelet からの更新を待機する時間を秒単位で指定します。
default-not-ready-toleration-seconds
ノードの異常をマークした後、Kube API Server Operator がそのノードから Pod を削除する前に待機する時間を秒単位で指定します。
default-unreachable-toleration-seconds
ノードの到達不能をマークした後、Kube API Server Operator がそのノードから Pod を削除する前に待機する時間を秒単位で指定します。

次の Operator は、ワーカーレイテンシープロファイルの変更を監視し、それに応じて対応します。

  • Machine Config Operator (MCO) は、ワーカーノードの node-status-update-frequency パラメーターを更新します。
  • Kubernetes Controller Manager Operator は、コントロールプレーンノードの node-monitor-grace-period パラメーターを更新します。
  • Kubernetes API Server Operator は、コントロールプレーンノードの default-not-ready-toleration-seconds および default-unreachable-toleration-seconds パラメーターを更新します。

ほとんどの場合、デフォルト設定が機能しますが、OpenShift Container Platform は、ネットワークで通常よりも高いレイテンシーが発生している状況に対して、他に 2 つのワーカーレイテンシープロファイルを提供します。次のセクションでは、3 つのワーカーレイテンシープロファイルについて説明します。

デフォルトのワーカーレイテンシープロファイル

Default プロファイルでは、各 Kubelet は 10 秒ごとにステータスを更新します(node-status-update-frequency)。Kube Controller Manager は、5 秒ごとに Kubelet のステータスを確認します(node-monitor-grace-period)。

Kubernetes Controller Manager は、Kubelet からのステータスが更新されるまで 40 秒待機してから Kubelet に異常があるとみなします。Kubernetes Controller Manager でステータスが利用できるようにします。次に、ノードに node.kubernetes.io/not-ready または node.kubernetes.io/unreachable テイントのマークを付け、そのノードの Pod を削除します。

そのノードの Pod に NoExecute テイントがある場合、Pod は tolerationSeconds に従って実行されます。Pod にテイントがない場合、これは 300 秒(default-not-ready-toleration-seconds および default-unreachable-toleration-seconds )でエビクトされます( Kube API Serverの default-not-ready-toleration-seconds 設定)。

プロファイルコンポーネントパラメーター値

デフォルト

kubelet

node-status-update-frequency

10s

Kubelet コントローラーマネージャー

node-monitor-grace-period

40s

Kubernetes API Server Operator

default-not-ready-toleration-seconds

300s

Kubernetes API Server Operator

default-unreachable-toleration-seconds

300s

中規模のワーカーレイテンシープロファイル

ネットワークレイテンシーが通常の場合、MediumUpdateAverageReaction プロファイルを使用します。

MediumUpdateAverageReaction プロファイルは、kubelet の更新の頻度を 20 秒に減らし、KubernetesControllerManagerOperator がそれらの更新を待機する期間を 2 分に変更します。そのノード上の Pod の Pod 排除期間は 60 秒に短縮されます。Pod に tolerationSeconds パラメーターがある場合、エビクションはそのパラメーターで指定された期間待機します。

Kubernetes Controller Manager Operator は、5 分間待機してノードの正常でないとみなします。別の 1 分間でエビクションプロセスが開始されます。

プロファイルコンポーネントパラメーター値

MediumUpdateAverageReaction

kubelet

node-status-update-frequency

20s

Kubelet コントローラーマネージャー

node-monitor-grace-period

2m

Kubernetes API Server Operator

default-not-ready-toleration-seconds

60s

Kubernetes API Server Operator

default-unreachable-toleration-seconds

60s

ワーカーの低レイテンシープロファイル

ネットワーク遅延が非常に高い場合は、LowUpdateSlowReaction プロファイルを使用します。

LowUpdateSlowReaction プロファイルは kubelet の更新頻度を 1 分に減らし、Kubernetes Controller Manager Operator がそれらの更新が 5 分になるまで待機する期間を変更します。そのノード上の Pod の Pod 排除期間は 60 秒に短縮されます。Pod に tolerationSeconds パラメーターがある場合、エビクションはそのパラメーターで指定された期間待機します。

Kubernetes Controller Manager Operator は、5 分間待機してノードの正常でないとみなします。別の 1 分間でエビクションプロセスが開始されます。

プロファイルコンポーネントパラメーター値

LowUpdateSlowReaction

kubelet

node-status-update-frequency

1m

Kubelet コントローラーマネージャー

node-monitor-grace-period

5m

Kubernetes API Server Operator

default-not-ready-toleration-seconds

60s

Kubernetes API Server Operator

default-unreachable-toleration-seconds

60s

8.8.2. ワーカーレイテンシープロファイルの使用および変更

ワーカーレイテンシープロファイルを実装してネットワークレイテンシーに対応するには、node.config オブジェクトを編集してプロファイルの名前を追加します。レイテンシーが増減すると、プロファイルをいつでも変更できます。

ワーカーレイテンシープロファイルは、一度に 1 つ移動する必要があります。たとえば、Default プロファイルから LowUpdateSlowReaction ワーカーレイテンシープロファイルに直接移動することはできません。最初に default のワーカーレイテンシープロファイルから MediumUpdateAverageReaction プロファイルに移動し、次に LowUpdateSlowReaction に移動する必要があります。同様に、デフォルトプロファイルに戻るときは、最初にロープロファイルからミディアムプロファイルに移動してから、デフォルトに移動する必要があります。

注記

OpenShift Container Platform クラスターのインストール時にワーカーレイテンシープロファイルを設定することもできます。

手順

デフォルトのワーカーレイテンシープロファイルから移動するには、以下を実行します。

  1. 中規模のワーカーのレイテンシープロファイルに移動します。

    1. node.config オブジェクトを編集します。 

      $ oc edit nodes.config/cluster

    2. spec.workerLatencyProfile: MediumUpdateAverageReaction を追加します。

      node.config オブジェクトの例

      apiVersion: config.openshift.io/v1
kind: Node
metadata:
  annotations:
    include.release.openshift.io/ibm-cloud-managed: "true"
    include.release.openshift.io/self-managed-high-availability: "true"
    include.release.openshift.io/single-node-developer: "true"
    release.openshift.io/create-only: "true"
  creationTimestamp: "2022-07-08T16:02:51Z"
  generation: 1
  name: cluster
  ownerReferences:
  - apiVersion: config.openshift.io/v1
    kind: ClusterVersion
    name: version
    uid: 36282574-bf9f-409e-a6cd-3032939293eb
  resourceVersion: "1865"
  uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
spec:
  workerLatencyProfile: MediumUpdateAverageReaction 1

# ...

      1
      中規模のワーカーレイテンシーポリシーを指定します。

      変更が適用されると、各ワーカーノードでのスケジューリングは無効になります。

  2. 必要に応じて、ワーカーのレイテンシーが低いプロファイルに移動します。

    1. node.config オブジェクトを編集します。 

      $ oc edit nodes.config/cluster

    2. spec.workerLatencyProfile の値を LowUpdateSlowReaction に変更します。

      node.config オブジェクトの例

      apiVersion: config.openshift.io/v1
kind: Node
metadata:
  annotations:
    include.release.openshift.io/ibm-cloud-managed: "true"
    include.release.openshift.io/self-managed-high-availability: "true"
    include.release.openshift.io/single-node-developer: "true"
    release.openshift.io/create-only: "true"
  creationTimestamp: "2022-07-08T16:02:51Z"
  generation: 1
  name: cluster
  ownerReferences:
  - apiVersion: config.openshift.io/v1
    kind: ClusterVersion
    name: version
    uid: 36282574-bf9f-409e-a6cd-3032939293eb
  resourceVersion: "1865"
  uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
spec:
  workerLatencyProfile: LowUpdateSlowReaction 1

# ...

      1
      ワーカーの低レイテンシーポリシーの使用を指定します。

変更が適用されると、各ワーカーノードでのスケジューリングは無効になります。

検証

  • 全ノードが Ready 状態に戻ると、以下のコマンドを使用して Kubernetes Controller Manager を確認し、これが適用されていることを確認できます。 

    $ oc get KubeControllerManager -o yaml | grep -i workerlatency -A 5 -B 5

    出力例

    # ...
    - lastTransitionTime: "2022-07-11T19:47:10Z"
      reason: ProfileUpdated
      status: "False"
      type: WorkerLatencyProfileProgressing
    - lastTransitionTime: "2022-07-11T19:47:10Z" 1
      message: all static pod revision(s) have updated latency profile
      reason: ProfileUpdated
      status: "True"
      type: WorkerLatencyProfileComplete
    - lastTransitionTime: "2022-07-11T19:20:11Z"
      reason: AsExpected
      status: "False"
      type: WorkerLatencyProfileDegraded
    - lastTransitionTime: "2022-07-11T19:20:36Z"
      status: "False"
# ...

    1
    プロファイルが適用され、アクティブであることを指定します。

ミディアムプロファイルからデフォルト、またはデフォルトからミディアムに変更する場合、node.config オブジェクトを編集し、spec.workerLatencyProfile パラメーターを適切な値に設定します。