ノード

読み取り操作により、管理者または開発者は OpenShift Dedicated クラスター内のノードに関する情報を取得できます。

OpenShift Dedicated で可能なことは、ノードへのアクセスと管理だけではありません。管理者は、ノードで次のタスクを実行して、クラスターをより効率的でアプリケーションに適したものにし、開発者により良い環境を提供できます。

管理者は、次のタスクを通じてプロジェクト内の Pod に関する情報を取得できます。

次のタスクのリストは、管理者が OpenShift Dedicated で Pod を管理する方法の概要を示しています。

OpenShift Dedicated で利用可能なさまざまなツールと機能を使用して、Pod をより簡単かつ効率的に操作できます。次の操作では、これらのツールと機能を使用して Pod をより適切に管理します。

OpenShift Dedicated でアプリケーションコンテナーを実行および管理するには、Pod を使用する必要があります。Pod を使用すると、複数のコンテナーが単一のホスト上で同じネットワークおよびストレージリソースを共有できます。

Pod はコンテナーに対するマシンインスタンス (物理または仮想) とほぼ同等のものです。各 Pod は独自の内部 IP アドレスで割り当てられるため、そのポートスペース全体を所有し、Pod 内のコンテナーはそれらのローカルストレージおよびネットワークを共有できます。

Pod にはライフサイクルがあります。それらは定義された後にノードで実行されるために割り当てられ、コンテナーが終了するまで実行されるか、その他の理由でコンテナーが削除されるまで実行されます。ポリシーおよび終了コードによっては、Pod は終了後に削除されるか、コンテナーのログへのアクセスを有効にするために保持される可能性があります。

OpenShift Dedicated は Pod をほとんどがイミュータブルなものとして処理します。Pod が実行中の場合は Pod に変更を加えることができません。OpenShift Dedicated は既存 Pod を終了し、これを変更された設定、ベースイメージのいずれかまたはその両方で再作成して変更を実装します。Pod は拡張可能なものとして処理されますが、再作成時に状態を維持しません。そのため、Pod はユーザーが直接管理するのではなく、通常は上位レベルのコントローラーによって管理される必要があります。

OpenShift Dedicated は、Pod の Kubernetes の概念を活用しています。これはホスト上に共にデプロイされる 1 つ以上のコンテナーであり、定義され、デプロイされ、管理される最小のコンピュート単位です。

以下は Pod の定義例です。これは数多くの Pod の機能を示していますが、それらのほとんどは他のトピックで説明されるため、ここではこれらを簡単に説明します。

kind: Pod
apiVersion: v1
metadata:
  name: example
  labels:
    environment: production
    app: abc
spec:
  restartPolicy: Always
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: abc
      args:
      - sleep
      - "1000000"
      volumeMounts:
       - name: cache-volume
         mountPath: /cache
      image: registry.access.redhat.com/ubi7/ubi-init:latest
      securityContext:
        allowPrivilegeEscalation: false
        runAsNonRoot: true
        capabilities:
          drop: ["ALL"]
      resources:
        limits:
          memory: "100Mi"
          cpu: "1"
        requests:
          memory: "100Mi"
          cpu: "1"
  volumes:
  - name: cache-volume
    emptyDir:
      sizeLimit: 500Mi

各項目の説明:

アプリケーションがコンピュートリソースをどのように消費するかを管理するには、Pod の仕様で CPU とメモリーの要求および制限を定義できます。リクエストはスケジューリングに必要な最小限のリソース量を確保し、制限によってコンテナーが過剰なリソースを消費してノード上の他の Pod に影響を与えることを防ぎます。

CPU およびメモリーの 要求 は、Pod の実行に必要なリソースの最小量を指定するものです。これは、OpenShift Dedicated が十分なリソースを持つノードに Pod をスケジュールするのに役立ちます。

CPU とメモリーの 制限 は、Pod が消費できるリソースの最大量を定義するものです。これは、Pod がリソースを過剰に消費して同じノード上の他の Pod に影響を与える可能性を防ぎます。

CPU およびメモリーの要求と制限は、次の原則に従って処理されます。

Pod が実行されているノードに十分なリソースがある場合、コンテナーは要求よりも多くの CPU またはメモリーリソースを使用する可能性があります。ただし、コンテナーは対応する制限を超えることはできません。たとえば、コンテナーのメモリー要求を 256 MiB に設定し、そのコンテナーが 8GiB のメモリーを持つノードにスケジュールされた Pod 内にあり、そのノードに他の Pod がない場合、コンテナーは要求された 256 MiB より多くのメモリーを使用しようとする可能性があります。

この動作は CPU およびメモリーの制限には適用されません。CPU およびメモリーの制限は、kubelet とコンテナーランタイムによって適用され、カーネルによって強制されます。Linux ノードでは、カーネルが cgroups を使用して制限を適用します。

CPU、メモリー、ストレージ消費量などの Pod の使用状況に関する統計情報を表示して、コンテナーのランタイム環境を監視し、効率的なリソース使用を確保できます。

OpenShift Dedicated で Pod の問題をトラブルシューティングしたり、Pod の詳細情報を表示したりするには、oc describe pod コマンドを使用して Pod の説明を表示できます。出力の イベント セクションには、Pod とその内部にあるコンテナーに関する詳細情報が表示されます。

CPU、メモリー、ストレージの使用量など、Pod の使用状況に関する統計情報を表示できます。Pod の使用レベルを監視することで、リソースの効率的な利用を確保できます。

OpenShift CLI (oc) または Web コンソールでリソースのログを表示できます。リソースのログを表示することで、問題のトラブルシューティングやリソースの動作監視を行うことができます。

デフォルトでは、ログは最後 (または末尾) から表示されます。

Pod の再起動ポリシーを設定することで、その Pod 内のコンテナーが終了したときに OpenShift Dedicated がどのように応答するかを決定できます。適切な再起動ポリシーを設定することで、クラスターを効率的に稼働させ続けることができます。

このポリシーは Pod のすべてのコンテナーに適用されます。

以下の値を使用できます。

いったんノードにバインドされた Pod は別のノードにはバインドされなくなります。これは、Pod がノードの失敗後も存続するにはコントローラーが必要であることを示しています。

Pod のコンテナーが失敗し、再起動ポリシーが OnFailure に設定される場合、Pod はノード上に留まり、コンテナーが再起動します。コンテナーを再起動させない場合には、再起動ポリシーの Never を使用します。

Pod 全体で障害が発生した場合、OpenShift Dedicated は新しい Pod を起動します。開発者は、アプリケーションが新規 Pod で再起動される可能性に対応しなくてはなりません。とくに、アプリケーションは、一時的なファイル、ロック、以前の実行で生じた未完成の出力などを処理する必要があります。

OpenShift Dedicated が障害が発生したコンテナーに対して再起動ポリシーをどのように使用するかの詳細は、Kubernetes ドキュメントの状態の例を参照してください。

Quality-of-Service (QoS) トラフィックシェーピングを Pod に適用し、その利用可能な帯域幅を効果的に制限することができます。

(Pod からの) Egress トラフィックは、設定したレートを超えるパケットを単純にドロップするポリシングによって処理されます。(Pod への) Ingress トラフィックは、データを効果的に処理できるようシェーピングでパケットをキューに入れて処理されます。Pod に設定する制限は、他の Pod の帯域幅には影響を与えません。

以下の手順は、Pod の帯域幅を制限するものです。

ノードのメンテナンスやクラスターの更新など、意図的な中断時にも Pod の可用性を確保するには、Pod Disruption Budget を使用してアプリケーションの安全制約を定義できます。

PodDisruptionBudget は、同時に稼働していなければならないレプリカの最小数または割合を指定する API オブジェクトです。これらをプロジェクトに設定することは、ノードのメンテナンス (クラスターのスケールダウンまたはクラスターのアップグレードなどの実行) 時に役立ち、この設定は (ノードの障害時ではなく) 自発的な退避の場合にのみ許可されます。

PodDisruptionBudget オブジェクトの設定は、次の主要な部分で構成されます。

以下を実行して、Pod の Disruption Budget をすべてのプロジェクトで確認することができます。

$ oc get poddisruptionbudget --all-namespaces

NAMESPACE                              NAME                                    MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
openshift-apiserver                    openshift-apiserver-pdb                 N/A             1                 1                     121m
openshift-cloud-controller-manager     aws-cloud-controller-manager            1               N/A               1                     125m
openshift-cloud-credential-operator    pod-identity-webhook                    1               N/A               1                     117m
openshift-cluster-csi-drivers          aws-ebs-csi-driver-controller-pdb       N/A             1                 1                     121m
openshift-cluster-storage-operator     csi-snapshot-controller-pdb             N/A             1                 1                     122m
openshift-cluster-storage-operator     csi-snapshot-webhook-pdb                N/A             1                 1                     122m
openshift-console                      console                                 N/A             1                 1                     116m
#...

PodDisruptionBudget は、最低でも minAvailable Pod がシステムで実行されている場合は正常であるとみなされます。この制限を超えるすべての Pod は退避の対象となります。

ボリュームプラグインを使用することで、シークレットをコンテナーにマウントできます。また、システムがシークレットを使用して、Pod に代わってアクションを実行することもできます。

Secret オブジェクトタイプはパスワード、OpenShift Dedicated クライアント設定ファイル、プライベートソースリポジトリーの認証情報などの機密情報を保持するメカニズムを提供します。シークレットは機密内容を Pod から切り離します。

キーのプロパティーには以下が含まれます。

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque
data:
  username: <username>
  password: <password>
stringData:
  hostname: myapp.mydomain.com

各項目の説明:

シークレットに依存する Pod を作成する前に、シークレットを作成する必要があります。

シークレットの作成時に以下を実行します。

管理者は、開発者がシークレットに依存する Pod を作成できるよう事前にシークレットを作成しておく必要があります。

シークレットを使用するには、Pod がシークレットを参照できる必要があります。シークレットは、以下の 3 つの方法で Pod で使用されます。

ボリュームタイプのシークレットは、ボリュームメカニズムを使用してデータをファイルとしてコンテナーに書き込みます。イメージプルシークレットは、シークレットを namespace のすべての Pod に自動的に注入するためにサービスアカウントを使用します。

テンプレートにシークレット定義が含まれる場合、テンプレートで指定のシークレットを使用できるようにするには、シークレットのボリュームソースを検証し、指定されるオブジェクト参照が Secret オブジェクトを実際に参照していることを確認できる必要があります。そのため、シークレットはこれに依存する Pod の作成前に作成されている必要があります。最も効果的な方法として、サービスアカウントを使用してシークレットを自動的に注入することができます。

シークレット API オブジェクトは namespace にあります。それらは同じ namespace の Pod によってのみ参照されます。

個々のシークレットは 1MB のサイズに制限されます。これにより、apiserver および kubelet メモリーを使い切るような大規模なシークレットの作成を防ぐことができます。しかし、複数の小さな秘密を作成すると、メモリーを枯渇させる可能性もある。

シークレット内の値を更新するには、そのシークレットを使用している Pod を再作成する必要があります。実行中の Pod はシークレットデータの変更を自動的に検出しないため、Pod を再起動することで、更新された設定が確実に反映されます。

シークレットの更新は、新規コンテナーイメージのデプロイと同じワークフローで実行されます。kubectl rolling-update コマンドを使用できます。

シークレットの resourceVersion 値は参照時に指定されません。したがって、シークレットが Pod の起動と同じタイミングで更新される場合、Pod に使用されるシークレットのバージョンは定義されません。

管理者として、サービスアカウントトークンシークレットを作成し、API への認証が必要なアプリケーションに配布することができます。

サービスの通信を保護するため、プロジェクト内のシークレットに追加可能な、署名されたサービス証明書/キーペアを生成するように OpenShift Dedicated を設定することができます。

サービス提供証明書のシークレット は、追加設定なしの証明書を必要とする複雑なミドルウェアアプリケーションをサポートするように設計されています。これにはノードおよびマスターの管理者ツールで生成されるサーバー証明書と同じ設定が含まれます。

apiVersion: v1
kind: Service
metadata:
  name: registry
  annotations:
    service.beta.openshift.io/serving-cert-secret-name: registry-cert
# ...

registry-cert を 証明書の名前に置き換えてください。

他の Pod は Pod に自動的にマウントされる /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt ファイルの CA バンドルを使用して、クラスターで作成される証明書 (内部 DNS 名の場合にのみ署名される) を信頼できます。

この機能の署名アルゴリズムは x509.SHA256WithRSA です。ローテーションを手動で実行するには、生成されたシークレットを削除します。新規の証明書が作成されます。

シークレットを扱う際のトラブルシューティングのヒントについては、以下の情報を確認してください。

サービス証明書の生成は以下を出して失敗します (サービスの service.beta.openshift.io/serving-cert-generation-error アノテーションには以下が含まれます)。

secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60

証明書を生成したサービスがすでに存在しないか、サービスに異なる serviceUID があります。古いシークレットを削除し、サービスのアノテーション (service.beta.openshift.io/serving-cert-generation-error、service.beta.openshift.io/serving-cert-generation-error-num) をクリアして証明書の再生成を強制的に実行する必要があります。

以下のセクションを参照すると、config map を使用して、アプリケーションコードとは別に設定値を Pod に提供する方法を確認できます。

数多くのアプリケーションには、設定ファイル、コマンドライン引数、および環境変数の組み合わせを使用した設定が必要です。OpenShift Dedicated では、これらの設定アーティファクトは、コンテナー化されたアプリケーションを移植可能な状態に保つためにイメージコンテンツから切り離されます。

ConfigMap オブジェクトは、コンテナーを OpenShift Dedicated に依存させないようにする一方で、コンテナーに設定データを挿入するメカニズムを提供します。設定マップは、個々のプロパティーなどの粒度の細かい情報や、設定ファイル全体または JSON Blob などの粒度の荒い情報を保存するために使用できます。

ConfigMap オブジェクトは、Pod で使用したり、コントローラーなどのシステムコンポーネントの設定データを保存するために使用できる設定データのキーと値のペアを保持します。以下に例を示します。

kind: ConfigMap
apiVersion: v1
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: example-config
  namespace: my-namespace
data:
  example.property.1: hello
  example.property.2: world
  example.property.file: |-
    property.1=value-1
    property.2=value-2
    property.3=value-3
binaryData:
  bar: L3Jvb3QvMTAw

各項目の説明:

設定データはさまざまな方法で Pod 内で使用できます。設定マップは以下を実行するために使用できます。

ユーザーとシステムコンポーネントの両方が設定データを設定マップに保存できます。

設定マップはシークレットに似ていますが、機密情報を含まない文字列の使用をより効果的にサポートするように設計されています。

Pod に設定データを提供するには、OpenShift Dedicated Web コンソールを使用して config map を作成できます。config map を使用すると、アプリケーションの情報を含むキーと値のペアを定義できます。

Pod に設定データを提供するには、OpenShift CLI (oc) を使用して、ディレクトリー、特定のファイル、またはリテラル値から config map を作成できます。

$ oc create configmap game-config --from-file=example-files/

$ oc describe configmaps game-config

Name:           game-config
Namespace:      default
Labels:         <none>
Annotations:    <none>

Data

game.properties:        158 bytes
ui.properties:          83 bytes

$ oc create configmap game-config-3 --from-file=game-special-key=example-files/game.properties

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config
  namespace: default
data:
  log_level: INFO

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

Pod の優先順位およびプリエンプション機能を使用する場合、スケジューラーは優先順位に基づいて保留中の Pod を順序付け、保留中の Pod はスケジューリングのキューで優先順位のより低い他の保留中の Pod よりも前に置かれます。その結果、より優先順位の高い Pod は、スケジューリングの要件を満たす場合に優先順位の低い Pod よりも早くスケジュールされる可能性があります。Pod をスケジュールできない場合、スケジューラーは引き続き他の優先順位の低い Pod をスケジュールします。

$ oc get priorityclasses

NAME                      VALUE        GLOBAL-DEFAULT   AGE
system-node-critical      2000001000   false            72m
system-cluster-critical   2000000000   false            72m
openshift-user-critical   1000000000   false            3d13h
cluster-logging           1000000      false            29s

開発者が Pod を作成する場合、Pod はキューに入れられます。開発者が Pod の優先順位またはプリエンプションを設定している場合、スケジューラーはキューから Pod を選択し、Pod をノードにスケジュールしようとします。スケジューラーが Pod に指定されたすべての要件を満たす適切なノードに領域を見つけられない場合、プリエンプションロジックが保留中の Pod にトリガーされます。

スケジューラーがノードで 1 つ以上の Pod のプリエンプションを実行する場合、優先順位の高い Pod 仕様の nominatedNodeName フィールドは、nodename フィールドと共にノードの名前に設定されます。スケジューラーは nominatedNodeName フィールドを使用して Pod の予約されたリソースを追跡し、またクラスターのプリエンプションに関する情報をユーザーに提供します。

スケジューラーが優先順位の低い Pod のプリエンプションを実行した後に、スケジューラーは Pod のグレースフルな終了期間を許可します。スケジューラーが優先順位の低い Pod の終了を待機する間に別のノードが利用可能になると、スケジューラーはそのノードに優先順位の高い Pod をスケジュールできます。その結果、Pod 仕様の nominatedNodeName フィールドおよび nodeName フィールドが異なる可能性があります。

さらに、スケジューラーがノード上で Pod のプリエンプションを実行し、終了を待機している場合で、保留中の Pod よりも優先順位の高い Pod をスケジュールする必要がある場合、スケジューラーは代わりに優先順位の高い Pod をスケジュールできます。その場合、スケジューラーは保留中の Pod の nominatedNodeName をクリアし、その Pod を他のノードの対象とすることができます。

プリエンプションは、ノードから優先順位の低いすべての Pod を削除する訳ではありません。スケジューラーは、優先順位の低い Pod の一部を削除して保留中の Pod をスケジュールできます。

スケジューラーは、保留中の Pod をノードにスケジュールできる場合にのみ、Pod のプリエンプションを実行するノードを考慮します。

Pod 仕様で priorityClassName を使用して優先順位クラスオブジェクトを作成し、Pod を優先順位に関連付けることで、Pod の優先度およびプリエンプションを適用できます。

Pod でノードセレクターを使用し、ノードでラベルを使用して、Pod がスケジュールされる場所を制御できます。ノードセレクターを使用すると、OpenShift Dedicated は一致するラベルが含まれるノード上に Pod をスケジュールします。

ラベルをノード、コンピュートマシンセット、またはマシン設定に追加します。コンピュートマシンセットにラベルを追加すると、ノードまたはマシンが停止した場合に、新規ノードにそのラベルが追加されます。ノードまたはマシン設定に追加されるラベルは、ノードまたはマシンが停止すると維持されません。

ノードセレクターを既存 Pod に追加するには、ノードセレクターを ReplicaSet オブジェクト、DaemonSet オブジェクト、StatefulSet オブジェクト、Deployment オブジェクト、または DeploymentConfig オブジェクトなどの Pod の制御オブジェクトに追加します。制御オブジェクト下の既存 Pod は、一致するラベルを持つノードで再作成されます。新規 Pod を作成する場合、ノードセレクターを Pod 仕様に直接追加できます。Pod に制御オブジェクトがない場合は、Pod を削除し、Pod 仕様を編集して、Pod を再作成する必要があります。

$ oc describe pod router-default-66d5cf9464-7pwkc

出力は次の例のようになります。

kind: Pod
apiVersion: v1
metadata:
# ...
Name:               router-default-66d5cf9464-7pwkc
Namespace:          openshift-ingress
# ...
Controlled By:      ReplicaSet/router-default-66d5cf9464
# ...

Web コンソールでは、Pod YAML の ownerReferences に制御オブジェクトをリスト表示します。

apiVersion: v1
kind: Pod
metadata:
  name: router-default-66d5cf9464-7pwkc
# ...
  ownerReferences:
    - apiVersion: apps/v1
      kind: ReplicaSet
      name: router-default-66d5cf9464
      uid: d81dd094-da26-11e9-a48a-128e7edf0312
      controller: true
      blockOwnerDeletion: true
# ...

Custom Metrics Autoscaler Operator バージョン 2.18.1-2 の変更点については、以下のリリースノートを参照してください。Red Hat OpenShift の Custom Metrics Autoscaler Operator のリリースノートでは、新機能および拡張機能、非推奨となった機能、および既知の問題を説明しています。

Custom Metrics Autoscaler Operator は、Kubernetes ベースの Event Driven Autoscaler (KEDA) を使用し、OpenShift Dedicated の Horizontal Pod Autoscaler (HPA) の上に構築されます。

Custom Metrics Autoscaler Operator の以前のバージョンにおける変更点については、以下のリリースノートを参照してください。

現在のバージョンは、Custom Metrics Autoscaler Operator リリースノート を参照してください。

デフォルトでは、Custom Metrics Autoscaler Operator は、自動的に生成されたサービス CA 証明書を使用して、クラスター上のサービスに接続します。

カスタム CA 証明書を必要とするクラスター外のサービスを使用する場合は、必要な証明書を config map に追加できます。次に、カスタムメトリクスオートスケーラーのインストール の説明に従って、KedaController カスタムリソースに config map を追加します。Operator は起動時にこれらの証明書を読み込み、Operator によって信頼されたものとして登録します。

config map には、1 つ以上の PEM エンコードされた CA 証明書を含む 1 つ以上の証明書ファイルを含めることができます。または、証明書ファイルごとに個別の config map を使用することもできます。

次の手順を使用して、Custom Metrics Autoscaler Operator をインストールできます。

Custom Metrics Autoscaler Operator のインストール中に自動的にインストールされる KedaController カスタムリソース (CR) を変更するには、次の手順に従います。

Prometheus メトリクスに基づいて Pod をスケーリングできます。このメトリクスは、インストール済みの OpenShift Dedicated モニタリングまたは外部 Prometheus サーバーをメトリクスソースとして使用できます。OpenShift Dedicated モニタリングをメトリクスのソースとして使用するために必要な設定については、「OpenShift Dedicated モニタリングを使用するためのカスタムメトリクスオートスケーラーの設定」を参照してください。

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: prom-scaledobject
  namespace: my-namespace
spec:
# ...
  triggers:
  - type: prometheus 

    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092 

      namespace: kedatest 

      metricName: http_requests_total 

      threshold: '5' 

      query: sum(rate(http_requests_total{job="test-app"}[1m])) 

      authModes: basic 

      cortexOrgID: my-org 

      ignoreNullValues: "false" 

      unsafeSsl: "false" 

      timeout: 1000 

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: gpu-scaledobject
  namespace: my-namespace
spec:
  scaleTargetRef:
    kind: Deployment
    name: gpu-deployment
  minReplicaCount: 1 

  maxReplicaCount: 5 

  triggers:
  - type: prometheus
    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
      namespace: my-namespace
      metricName: gpu_utilization
      threshold: '90' 

      query: SUM(DCGM_FI_DEV_GPU_UTIL{instance=~".+", gpu=~".+"}) 

      authModes: bearer
    authenticationRef:
      name: keda-trigger-auth-prometheus

CPU メトリクスに基づいて Pod をスケーリングできます。このトリガーは、クラスターメトリクスをメトリクスのソースとして使用します。

カスタムメトリクスオートスケーラーは、オブジェクトに関連付けられた Pod をスケーリングして、指定された CPU 使用率を維持します。オートスケーラーは、すべての Pod で指定された CPU 使用率を維持するために、最小数と最大数の間でレプリカ数を増減します。メモリートリガーは、Pod 全体のメモリー使用率を考慮します。Pod に複数のコンテナーがある場合、メモリートリガーは Pod 内にあるすべてのコンテナーの合計メモリー使用率を考慮します。

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cpu-scaledobject
  namespace: my-namespace
spec:
# ...
  triggers:
  - type: cpu 

    metricType: Utilization 

    metadata:
      value: '60' 

  minReplicaCount: 1 

メモリーメトリクスに基づいて Pod をスケーリングできます。このトリガーは、クラスターメトリクスをメトリクスのソースとして使用します。

カスタムメトリクスオートスケーラーは、オブジェクトに関連付けられた Pod をスケーリングして、指定されたメモリー使用率を維持します。オートスケーラーは、すべての Pod で指定のメモリー使用率を維持するために、最小数と最大数の間でレプリカ数を増減します。メモリートリガーは、Pod 全体のメモリー使用率を考慮します。Pod に複数のコンテナーがある場合、メモリー使用率はすべてのコンテナーの合計になります。

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: memory-scaledobject
  namespace: my-namespace
spec:
# ...
  triggers:
  - type: memory 

    metricType: Utilization 

    metadata:
      value: '60' 

      containerName: api 

Apache Kafka トピックまたは Kafka プロトコルをサポートするその他のサービスに基づいて Pod をスケーリングできます。カスタムメトリクスオートスケーラーは、スケーリングされるオブジェクトまたはスケーリングされるジョブで allowIdleConsumers パラメーターを true に設定しない限り、Kafka パーティションの数を超えてスケーリングしません。

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-scaledobject
  namespace: my-namespace
spec:
# ...
  triggers:
  - type: kafka 

    metadata:
      topic: my-topic 

      bootstrapServers: my-cluster-kafka-bootstrap.openshift-operators.svc:9092 

      consumerGroup: my-group 

      lagThreshold: '10' 

      activationLagThreshold: '5' 

      offsetResetPolicy: latest 

      allowIdleConsumers: true 

      scaleToZeroOnInvalidOffset: false 

      excludePersistentLag: false 

      version: '1.0.0' 

      partitionLimitation: '1,2,10-20,31' 

      tls: enable 

Pod は時間範囲に基づいてスケーリングできます。

時間範囲の開始時に、カスタムメトリクスオートスケーラーが、オブジェクトに関連する Pod を、設定された最小 Pod 数から指定された必要な Pod 数にスケーリングします。時間範囲の終了時に、Pod は設定された最小値にスケールダウンされます。期間は cron 形式 で設定する必要があります。

次の例では、この scaled object に関連する Pod を、インド標準時の午前 6 時から午後 6 時 30 分まで 0 から 100 にスケーリングします。

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cron-scaledobject
  namespace: default
spec:
  scaleTargetRef:
    name: my-deployment
  minReplicaCount: 0 

  maxReplicaCount: 100 

  cooldownPeriod: 300
  triggers:
  - type: cron 

    metadata:
      timezone: Asia/Kolkata 

      start: "0 6 * * *" 

      end: "30 18 * * *" 

      desiredReplicas: "100" 

特定のラベルセレクターに一致する Pod の数に基づいて Pod をスケーリングできます。

Custom Metrics Autoscaler Operator は、同じ namespace にある特定のラベルが付いた Pod の数を追跡し、ラベル付き Pod の数に基づいて scaled object の Pod との 関係 を計算します。この関係を使用して、Custom Metrics Autoscaler Operator は、ScaledObject または ScaledJob 仕様のスケーリングポリシーに従ってオブジェクトをスケーリングします。

Pod 数には、Succeeded フェーズまたは Failed フェーズの Pod が含まれます。

たとえば、frontend デプロイメントと backend デプロイメントがあるとします。kubernetes-workload トリガーを使用すると、frontend Pod の数に基づいて backend デプロイメントをスケーリングできます。frontend Pod の数が増えると、Operator は指定された比率を維持するために backend Pod をスケーリングします。この例では、app=frontend Pod セレクターを持つ Pod が 10 個ある場合、Operator は、scaled object で設定された 0.5 の比率を維持するために、バックエンド Pod を 5 にスケーリングします。

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: workload-scaledobject
  namespace: my-namespace
spec:
  triggers:
  - type: kubernetes-workload 

    metadata:
      podSelector: 'app=frontend' 

      value: '0.5' 

      activationValue: '3.1'