ノード

1. プロジェクトに切り替えます。

   $ oc project <project-name>

2. 以下のコマンドを実行します。

   $ oc get pods

   以下に例を示します。

   $ oc get pods

   出力例

   NAME                       READY   STATUS    RESTARTS   AGE
   console-698d866b78-bnshf   1/1     Running   2          165m
   console-698d866b78-m87pm   1/1     Running   2          165m

   -o wide フラグを追加して、Pod の IP アドレスと Pod があるノードを表示します。

   $ oc get pods -o wide

   出力例

   NAME                       READY   STATUS    RESTARTS   AGE    IP            NODE                           NOMINATED NODE
   console-698d866b78-bnshf   1/1     Running   2          166m   10.128.0.24   ip-10-0-152-71.ec2.internal    <none>
   console-698d866b78-m87pm   1/1     Running   2          166m   10.129.0.23   ip-10-0-173-237.ec2.internal   <none>

1. 以下のコマンドを実行します。

   $ oc adm top pods

   以下に例を示します。

   $ oc adm top pods -n openshift-console

   出力例

   NAME                         CPU(cores)   MEMORY(bytes)
   console-7f58c69899-q8c8k     0m           22Mi
   console-7f58c69899-xhbgg     0m           25Mi
   downloads-594fcccf94-bcxk8   3m           18Mi
   downloads-594fcccf94-kv4p6   2m           15Mi

2. ラベルを持つ Pod の使用状況の統計を表示するには、以下のコマンドを実行します。

   $ oc adm top pod --selector=''

   フィルターに使用するセレクター (ラベルクエリー) を選択する必要があります。=、==、および != をサポートします。

   以下に例を示します。

   $ oc adm top pod --selector='name=my-pod'

手順 (UI)

1. Red Hat OpenShift Service on AWS コンソールで Workloads → Pods に移動するか、調査するリソースから Pod に移動します。

   注記

   ビルドなどの一部のリソースには、直接クエリーする Pod がありません。このような場合は、リソースの Details ページで Logs リンクを特定できます。

2. ドロップダウンメニューからプロジェクトを選択します。
3. 調査する Pod の名前をクリックします。
4. Logs をクリックします。

1. オブジェクト定義 JSON ファイルを作成し、kubernetes.io/ingress-bandwidth および kubernetes.io/egress-bandwidth アノテーションを使用してデータトラフィックの速度を指定します。たとえば、Pod の egress および ingress の両方の帯域幅を 10M/s に制限するには、以下を実行します。

   制限が設定された Pod オブジェクト定義

   {
       "kind": "Pod",
       "spec": {
           "containers": [
               {
                   "image": "openshift/hello-openshift",
                   "name": "hello-openshift"
               }
           ]
       },
       "apiVersion": "v1",
       "metadata": {
           "name": "iperf-slow",
           "annotations": {
               "kubernetes.io/ingress-bandwidth": "10M",
               "kubernetes.io/egress-bandwidth": "10M"
           }
       }
   }

2. オブジェクト定義を使用して Pod を作成します。

   $ oc create -f <file_or_dir_path>

1. 次のような YAML ファイルを作成して、優先順位クラスの名前を含む Pod 仕様を定義します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx
     labels:
       env: test
   spec:
     containers:
     - name: nginx
       image: nginx
       imagePullPolicy: IfNotPresent
     priorityClassName: system-cluster-critical 1

   1

   この Pod で使用する優先順位クラスを指定します。

2. Pod を作成します。

   $ oc create -f <file-name>.yaml

   優先順位の名前は Pod 設定または Pod テンプレートに直接追加できます。

手順

1. Red Hat OpenShift Service on AWS Web コンソールで、Operator → OperatorHub をクリックします。
2. 使用可能な Operator のリストから Custom Metrics Autoscaler を選択し、Install をクリックします。
3. Install Operator ページで、Installation Mode に A specific namespace on the cluster オプションが選択されていることを確認します。
4. Installed Namespace で、Select a namespace をクリックします。

5. Select Project をクリックします。

   • keda namespace が存在する場合は、リストから keda を選択します。

   • keda namespace が存在しない場合は、以下を実行します。

     1. Create Project を選択して、Create Project ウィンドウを開きます。
     2. Name フィールドに keda と入力します。
     3. Display Name フィールドに、keda などのわかりやすい名前を入力します。
     4. オプション: Display Name フィールドに、namespace の説明を追加します。
     5. Create をクリックします。
6. Install をクリックします。

7. Custom Metrics Autoscaler Operator コンポーネントをリスト表示して、インストールを確認します。

   1. Workloads → Pods に移動します。
   2. ドロップダウンメニューから keda プロジェクトを選択し、custom-metrics-autoscaler-operator-* Pod が実行されていることを確認します。
   3. Workloads → Deployments に移動して、custom-metrics-autoscaler-operator デプロイメントが実行されていることを確認します。

8. オプション: 次のコマンドを使用して、OpenShift CLI でインストールを確認します。

   $ oc get all -n keda

   以下のような出力が表示されます。

   出力例

   NAME                                                      READY   STATUS    RESTARTS   AGE
   pod/custom-metrics-autoscaler-operator-5fd8d9ffd8-xt4xp   1/1     Running   0          18m
   
   NAME                                                 READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/custom-metrics-autoscaler-operator   1/1     1            1           18m
   
   NAME                                                            DESIRED   CURRENT   READY   AGE
   replicaset.apps/custom-metrics-autoscaler-operator-5fd8d9ffd8   1         1         1       18m

9. 必要な CRD を作成する KedaController カスタムリソースをインストールします。

   1. Red Hat OpenShift Service on AWS Web コンソールで、Operators → Installed Operators をクリックします。
   2. Custom Metrics Autoscaler をクリックします。
   3. Operator Details ページで、KedaController タブをクリックします。

   4. KedaController タブで、Create KedaController をクリックしてファイルを編集します。

      kind: KedaController
      apiVersion: keda.sh/v1alpha1
      metadata:
        name: keda
        namespace: keda
      spec:
        watchNamespace: '' 1
        operator:
          logLevel: info 2
          logEncoder: console 3
          caConfigMaps: 4
          - thanos-cert
          - kafka-cert
        metricsServer:
          logLevel: '0' 5
          auditConfig: 6
            logFormat: "json"
            logOutputVolumeClaim: "persistentVolumeClaimName"
            policy:
              rules:
              - level: Metadata
              omitStages: ["RequestReceived"]
              omitManagedFields: false
            lifetime:
              maxAge: "2"
              maxBackup: "1"
              maxSize: "50"
        serviceAccount: {}

      1

      Custom Metrics Autoscaler Operator がアプリケーションをスケーリングする単一の namespace を指定します。空白のままにするか、または空にして、すべての namespace でアプリケーションをスケーリングします。このフィールドは、namespace があるか、空である必要があります。デフォルト値は空です。

      2

      Custom Metrics Autoscaler Operator ログメッセージの詳細レベルを指定します。許可される値は debug、info、error です。デフォルトは info です。

      3

      Custom Metrics Autoscaler Operator ログメッセージのログ形式を指定します。許可される値は console または json です。デフォルトは コンソール です。

      4

      オプション: CA 証明書を持つ 1 つ以上の config map を指定します。Custom Metrics Autoscaler Operator はこれを使用して、TLS 対応のメトリクスソースに安全に接続できます。

      5

      Custom Metrics Autoscaler Metrics Server のログレベルを指定します。使用可能な値は、info の場合は 0、debug の場合は 4 です。デフォルトは 0 です。

      6

      Custom Metrics Autoscaler Operator の監査ログをアクティブにして、使用する監査ポリシーを指定します (「監査ログの設定」セクションを参照)。

   5. Create をクリックして KEDA コントローラーを作成します。

手順

1. TriggerAuthentication または ClusterTriggerAuthentication オブジェクトを作成します。

   1. オブジェクトを定義する YAML ファイルを作成します。

      シークレットを使用したトリガー認証の例

      kind: TriggerAuthentication
      apiVersion: keda.sh/v1alpha1
      metadata:
        name: prom-triggerauthentication
        namespace: my-namespace
      spec:
        secretTargetRef:
        - parameter: user-name
          name: my-secret
          key: USER_NAME
        - parameter: password
          name: my-secret
          key: USER_PASSWORD

   2. TriggerAuthentication オブジェクトを作成します。

      $ oc create -f <filename>.yaml

2. トリガー認証を使用する ScaledObject YAML ファイルを作成または編集します。

   1. 次のコマンドを実行して、オブジェクトを定義する YAML ファイルを作成します。

      トリガー認証を使用したスケーリングされたオブジェクトの例

      apiVersion: keda.sh/v1alpha1
      kind: ScaledObject
      metadata:
        name: scaledobject
        namespace: my-namespace
      spec:
        scaleTargetRef:
          name: example-deployment
        maxReplicaCount: 100
        minReplicaCount: 0
        pollingInterval: 30
        triggers:
        - type: prometheus
          metadata:
            serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
            namespace: kedatest # replace <NAMESPACE>
            metricName: http_requests_total
            threshold: '5'
            query: sum(rate(http_requests_total{job="test-app"}[1m]))
            authModes: "basic"
          authenticationRef:
            name: prom-triggerauthentication 1
            kind: TriggerAuthentication 2

      1

      トリガー認証オブジェクトの名前を指定します。

      2

      TriggerAuthentication を指定します。TriggerAuthentication がデフォルトです。

      クラスタートリガー認証を使用したスケーリングされたオブジェクトの例

      apiVersion: keda.sh/v1alpha1
      kind: ScaledObject
      metadata:
        name: scaledobject
        namespace: my-namespace
      spec:
        scaleTargetRef:
          name: example-deployment
        maxReplicaCount: 100
        minReplicaCount: 0
        pollingInterval: 30
        triggers:
        - type: prometheus
          metadata:
            serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
            namespace: kedatest # replace <NAMESPACE>
            metricName: http_requests_total
            threshold: '5'
            query: sum(rate(http_requests_total{job="test-app"}[1m]))
            authModes: "basic"
          authenticationRef:
            name: prom-cluster-triggerauthentication 1
            kind: ClusterTriggerAuthentication 2

      1

      トリガー認証オブジェクトの名前を指定します。

      2

      ClusterTriggerAuthentication を指定します。

   2. 次のコマンドを実行して、スケーリングされたオブジェクトを作成します。

      $ oc apply -f <filename>

手順

1. 次のコマンドを使用して、ワークロードの ScaledObject CR を編集します。

   $ oc edit ScaledObject scaledobject

2. autoscaling.keda.sh/paused-replicas アノテーションに任意の値を追加します。

   apiVersion: keda.sh/v1alpha1
   kind: ScaledObject
   metadata:
     annotations:
       autoscaling.keda.sh/paused-replicas: "4" 1
     creationTimestamp: "2023-02-08T14:41:01Z"
     generation: 1
     name: scaledobject
     namespace: my-project
     resourceVersion: '65729'
     uid: f5aec682-acdf-4232-a783-58b5b82f5dd0

   1

   Custom Metrics Autoscaler Operator がレプリカを指定された値にスケーリングし、自動スケーリングを停止するよう指定します。

手順

1. 次のコマンドを使用して、ワークロードの ScaledObject CR を編集します。

   $ oc edit ScaledObject scaledobject

2. autoscaling.keda.sh/paused-replicas アノテーションを削除します。

   apiVersion: keda.sh/v1alpha1
   kind: ScaledObject
   metadata:
     annotations:
       autoscaling.keda.sh/paused-replicas: "4" 1
     creationTimestamp: "2023-02-08T14:41:01Z"
     generation: 1
     name: scaledobject
     namespace: my-project
     resourceVersion: '65729'
     uid: f5aec682-acdf-4232-a783-58b5b82f5dd0

   1

   このアノテーションを削除して、一時停止されたカスタムメトリクスオートスケーラーを再開します。

手順

1. KedaController カスタムリソースを編集して、auditConfig スタンザを追加します。

   kind: KedaController
   apiVersion: keda.sh/v1alpha1
   metadata:
     name: keda
     namespace: keda
   spec:
   # ...
     metricsServer:
   # ...
       auditConfig:
         logFormat: "json" 1
         logOutputVolumeClaim: "pvc-audit-log" 2
         policy:
           rules: 3
           - level: Metadata
           omitStages: "RequestReceived" 4
           omitManagedFields: false 5
         lifetime: 6
           maxAge: "2"
           maxBackup: "1"
           maxSize: "50"

   1

   監査ログの出力形式を legacy または json のいずれかで指定します。

   2

   ログデータを格納するための既存の永続ボリューム要求を指定します。API サーバーに送信されるすべてのリクエストは、この永続ボリューム要求に記録されます。このフィールドを空のままにすると、ログデータは stdout に送信されます。

   3

   どのイベントを記録し、どのデータを含めるかを指定します。

   • None: イベントをログに記録しません。
   • Metadata: ユーザー、タイムスタンプなど、リクエストのメタデータのみをログに記録します。リクエストテキストと応答テキストはログに記録しないでください。これはデフォルトになります。
   • Request: メタデータと要求テキストのみをログに記録しますが、応答テキストはログに記録しません。このオプションは、リソース以外の要求には適用されません。
   • RequestResponse: イベントのメタデータ、要求テキスト、および応答テキストをログに記録します。このオプションは、リソース以外の要求には適用されません。

   4

   イベントを作成しないステージを指定します。

   5

   リクエストおよび応答本文のマネージドフィールドが API 監査ログに書き込まれないようにするかどうかを指定します。フィールドを省略する場合は true、フィールドを含める場合は false を指定します。

   6

   監査ログのサイズと有効期間を指定します。

   • maxAge: ファイル名にエンコードされたタイムスタンプに基づく、監査ログファイルを保持する最大日数。
   • maxBackup: 保持する監査ログファイルの最大数。すべての監査ログファイルを保持するには、0 に設定します。
   • maxSize: ローテーションされる前の監査ログファイルの最大サイズ (メガバイト単位)。

検証

1. 監査ログファイルを直接表示します。

   1. keda-metrics-apiserver-* Pod の名前を取得します。

      oc get pod -n keda

      出力例

      NAME                                                  READY   STATUS    RESTARTS   AGE
      custom-metrics-autoscaler-operator-5cb44cd75d-9v4lv   1/1     Running   0          8m20s
      keda-metrics-apiserver-65c7cc44fd-rrl4r               1/1     Running   0          2m55s
      keda-operator-776cbb6768-zpj5b                        1/1     Running   0          2m55s

   2. 次のようなコマンドを使用して、ログデータを表示します。

      $ oc logs keda-metrics-apiserver-<hash>|grep -i metadata 1

      1

      オプション: grep コマンドを使用して、表示するログレベル (Metadata、Request、RequestResponse) を指定できます。

      以下に例を示します。

      $ oc logs keda-metrics-apiserver-65c7cc44fd-rrl4r|grep -i metadata

      出力例

       ...
      {"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"4c81d41b-3dab-4675-90ce-20b87ce24013","stage":"ResponseComplete","requestURI":"/healthz","verb":"get","user":{"username":"system:anonymous","groups":["system:unauthenticated"]},"sourceIPs":["10.131.0.1"],"userAgent":"kube-probe/1.28","responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2023-02-16T13:00:03.554567Z","stageTimestamp":"2023-02-16T13:00:03.555032Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}}
       ...

2. または、特定のログを表示できます。

   1. 次のようなコマンドを使用して、keda-metrics-apiserver-* Pod にログインします。

      $ oc rsh pod/keda-metrics-apiserver-<hash> -n keda

      以下に例を示します。

      $ oc rsh pod/keda-metrics-apiserver-65c7cc44fd-rrl4r -n keda

   2. /var/audit-policy/ ディレクトリーに移動します。

      sh-4.4$ cd /var/audit-policy/

   3. 利用可能なログを一覧表示します。

      sh-4.4$ ls

      出力例

      log-2023.02.17-14:50  policy.yaml

   4. 必要に応じてログを表示します。

      sh-4.4$ cat <log_name>/<pvc_name>|grep -i <log_level> 1

      1

      オプション: grep コマンドを使用して、表示するログレベル (Metadata、Request、RequestResponse) を指定できます。

      以下に例を示します。

      sh-4.4$ cat log-2023.02.17-14:50/pvc-audit-log|grep -i Request

      出力例

       ...
      {"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Request","auditID":"63e7f68c-04ec-4f4d-8749-bf1656572a41","stage":"ResponseComplete","requestURI":"/openapi/v2","verb":"get","user":{"username":"system:aggregator","groups":["system:authenticated"]},"sourceIPs":["10.128.0.1"],"responseStatus":{"metadata":{},"code":304},"requestReceivedTimestamp":"2023-02-17T13:12:55.035478Z","stageTimestamp":"2023-02-17T13:12:55.038346Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"system:discovery\" of ClusterRole \"system:discovery\" to Group \"system:authenticated\""}}
       ...

手順

1. must-gather データを保存するディレクトリーに移動します。

2. 以下のいずれかを実行します。

   • Custom Metrics Autoscaler Operator の must-gather データのみを取得するには、以下のコマンドを使用します。

     $ oc adm must-gather --image="$(oc get packagemanifests openshift-custom-metrics-autoscaler-operator \
     -n openshift-marketplace \
     -o jsonpath='{.status.channels[?(@.name=="stable")].currentCSVDesc.annotations.containerImage}')"

     must-gather コマンドのカスタムイメージは、Operator パッケージマニフェストから直接プルされます。そうすることで、Custom Metric Autoscaler Operator が利用可能なクラスター上で機能します。

   • Custom Metric Autoscaler Operator 情報に加えてデフォルトの must-gather データを収集するには、以下を実行します。

     1. 以下のコマンドを使用して Custom Metrics Autoscaler Operator イメージを取得し、これを環境変数として設定します。

        $ IMAGE="$(oc get packagemanifests openshift-custom-metrics-autoscaler-operator \
          -n openshift-marketplace \
          -o jsonpath='{.status.channels[?(@.name=="stable")].currentCSVDesc.annotations.containerImage}')"

     2. Custom Metrics Autoscaler Operator イメージで oc adm must-gather を使用するには、以下を実行します。

        $ oc adm must-gather --image-stream=openshift/must-gather --image=${IMAGE}

   例3.1 Custom Metric Autoscaler の must-gather 出力の例

   └── keda
       ├── apps
       │   ├── daemonsets.yaml
       │   ├── deployments.yaml
       │   ├── replicasets.yaml
       │   └── statefulsets.yaml
       ├── apps.openshift.io
       │   └── deploymentconfigs.yaml
       ├── autoscaling
       │   └── horizontalpodautoscalers.yaml
       ├── batch
       │   ├── cronjobs.yaml
       │   └── jobs.yaml
       ├── build.openshift.io
       │   ├── buildconfigs.yaml
       │   └── builds.yaml
       ├── core
       │   ├── configmaps.yaml
       │   ├── endpoints.yaml
       │   ├── events.yaml
       │   ├── persistentvolumeclaims.yaml
       │   ├── pods.yaml
       │   ├── replicationcontrollers.yaml
       │   ├── secrets.yaml
       │   └── services.yaml
       ├── discovery.k8s.io
       │   └── endpointslices.yaml
       ├── image.openshift.io
       │   └── imagestreams.yaml
       ├── k8s.ovn.org
       │   ├── egressfirewalls.yaml
       │   └── egressqoses.yaml
       ├── keda.sh
       │   ├── kedacontrollers
       │   │   └── keda.yaml
       │   ├── scaledobjects
       │   │   └── example-scaledobject.yaml
       │   └── triggerauthentications
       │       └── example-triggerauthentication.yaml
       ├── monitoring.coreos.com
       │   └── servicemonitors.yaml
       ├── networking.k8s.io
       │   └── networkpolicies.yaml
       ├── keda.yaml
       ├── pods
       │   ├── custom-metrics-autoscaler-operator-58bd9f458-ptgwx
       │   │   ├── custom-metrics-autoscaler-operator
       │   │   │   └── custom-metrics-autoscaler-operator
       │   │   │       └── logs
       │   │   │           ├── current.log
       │   │   │           ├── previous.insecure.log
       │   │   │           └── previous.log
       │   │   └── custom-metrics-autoscaler-operator-58bd9f458-ptgwx.yaml
       │   ├── custom-metrics-autoscaler-operator-58bd9f458-thbsh
       │   │   └── custom-metrics-autoscaler-operator
       │   │       └── custom-metrics-autoscaler-operator
       │   │           └── logs
       │   ├── keda-metrics-apiserver-65c7cc44fd-6wq4g
       │   │   ├── keda-metrics-apiserver
       │   │   │   └── keda-metrics-apiserver
       │   │   │       └── logs
       │   │   │           ├── current.log
       │   │   │           ├── previous.insecure.log
       │   │   │           └── previous.log
       │   │   └── keda-metrics-apiserver-65c7cc44fd-6wq4g.yaml
       │   └── keda-operator-776cbb6768-fb6m5
       │       ├── keda-operator
       │       │   └── keda-operator
       │       │       └── logs
       │       │           ├── current.log
       │       │           ├── previous.insecure.log
       │       │           └── previous.log
       │       └── keda-operator-776cbb6768-fb6m5.yaml
       ├── policy
       │   └── poddisruptionbudgets.yaml
       └── route.openshift.io
           └── routes.yaml

3. 作業ディレクトリーに作成された must-gather ディレクトリーから圧縮ファイルを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

   $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1

   1

   must-gather-local.5421342344627712289/ を実際のディレクトリー名に置き換えます。

4. 圧縮ファイルを Red Hat カスタマーポータル で作成したサポートケースに添付します。

手順

1. Red Hat OpenShift Service on AWS Web コンソールで Administrator パースペクティブを選択します。
2. Observe → Metrics の順に選択します。
3. カスタムクエリーを作成するには、PromQL クエリーを Expression フィールドに追加します。
4. 複数のクエリーを追加するには、Add Query を選択します。

手順

1. 以下のような YAML ファイルを作成します。名前 <2>、オブジェクト名 <4>、およびオブジェクトの種類 <5> のみが必要です。

   スケーリングされたオブジェクトの例

   apiVersion: keda.sh/v1alpha1
   kind: ScaledObject
   metadata:
     annotations:
       autoscaling.keda.sh/paused-replicas: "0" 1
     name: scaledobject 2
     namespace: my-namespace
   spec:
     scaleTargetRef:
       apiVersion: apps/v1 3
       name: example-deployment 4
       kind: Deployment 5
       envSourceContainerName: .spec.template.spec.containers[0] 6
     cooldownPeriod:  200 7
     maxReplicaCount: 100 8
     minReplicaCount: 0 9
     metricsServer: 10
       auditConfig:
         logFormat: "json"
         logOutputVolumeClaim: "persistentVolumeClaimName"
         policy:
           rules:
           - level: Metadata
           omitStages: "RequestReceived"
           omitManagedFields: false
         lifetime:
           maxAge: "2"
           maxBackup: "1"
           maxSize: "50"
     fallback: 11
       failureThreshold: 3
       replicas: 6
     pollingInterval: 30 12
     advanced:
       restoreToOriginalReplicaCount: false 13
       horizontalPodAutoscalerConfig:
         name: keda-hpa-scale-down 14
         behavior: 15
           scaleDown:
             stabilizationWindowSeconds: 300
             policies:
             - type: Percent
               value: 100
               periodSeconds: 15
     triggers:
     - type: prometheus 16
       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
       authenticationRef: 17
         name: prom-triggerauthentication
         kind: TriggerAuthentication

   1

   オプション: 「ワークロードのカスタムメトリクスオートスケーラーの一時停止」セクションで説明されているように、Custom Metrics Autoscaler Operator がレプリカを指定された値にスケーリングし、自動スケーリングを停止するよう指定します。

   2

   このカスタムメトリクスオートスケーラーの名前を指定します。

   3

   オプション: ターゲットリソースの API バージョンを指定します。デフォルトは apps/v1 です。

   4

   スケーリングするオブジェクトの名前を指定します。

   5

   kind を Deployment、StatefulSet または CustomResource として指定します。

   6

   オプション: カスタムメトリクスオートスケーラーがシークレットなどを保持する環境変数を取得する、ターゲットリソース内のコンテナーの名前を指定します。デフォルトは .spec.template.spec.containers[0] です。

   7

   オプション: minReplicaCount が 0 に設定されている場合、最後のトリガーが報告されてからデプロイメントを 0 にスケールバックするまでの待機時間を秒単位で指定します。デフォルトは 300 です。

   8

   オプション: スケールアップ時のレプリカの最大数を指定します。デフォルトは 100 です。

   9

   オプション: スケールダウン時のレプリカの最小数を指定します。

   10

   オプション: 「監査ログの設定」セクションで説明されているように、監査ログのパラメーターを指定します。

   11

   オプション: failureThreshold パラメーターで定義された回数だけスケーラーがソースからメトリクスを取得できなかった場合に、フォールバックするレプリカの数を指定します。フォールバック動作の詳細は、KEDA のドキュメント を参照してください。

   12

   オプション: 各トリガーをチェックする間隔を秒単位で指定します。デフォルトは 30 です。

   13

   オプション: スケーリングされたオブジェクトが削除された後に、ターゲットリソースを元のレプリカ数にスケールバックするかどうかを指定します。デフォルトは false で、スケーリングされたオブジェクトが削除されたときのレプリカ数をそのまま保持します。

   14

   オプション: Horizontal Pod Autoscaler の名前を指定します。デフォルトは keda-hpa-{scaled-object-name} です。

   15

   オプション: 「スケーリングポリシー」セクションで説明されているように、Pod をスケールアップまたはスケールダウンするレートを制御するために使用するスケーリングポリシーを指定します。

   16

   「カスタムメトリクスオートスケーラートリガーについて」セクションで説明されているように、スケーリングの基準として使用するトリガーを指定します。この例では、Red Hat OpenShift Service on AWS モニタリングを使用します。

   17

   オプション: トリガー認証またはクラスタートリガー認証を指定します。詳細は、関連情報 セクションの カスタムメトリクスオートスケーラー認証について を参照してください。

   • トリガー認証を使用するには、TriggerAuthentication と入力します。これはデフォルトになります。
   • クラスタートリガー認証を使用するには、ClusterTriggerAuthentication と入力します。

2. 次のコマンドを実行して、カスタムメトリクスオートスケーラーを作成します。

   $ oc create -f <filename>.yaml

手順

1. Red Hat OpenShift Service on AWS Web コンソールで、Operators → Installed Operators をクリックします。
2. keda プロジェクトに切り替えます。

3. KedaController カスタムリソースを削除します。

   1. CustomMetricsAutoscaler Operator を見つけて、KedaController タブをクリックします。
   2. カスタムリソースを見つけてから、Delete KedaController をクリックします。
   3. Uninstall をクリックします。

4. Custom Metrics Autoscaler Operator を削除します。

   1. Operators → Installed Operators をクリックします。
   2. CustomMetricsAutoscaler Operator を見つけて Options メニュー をクリックし、Uninstall Operator を選択します。
   3. Uninstall をクリックします。

5. オプション: OpenShift CLI を使用して、カスタムメトリクスオートスケーラーのコンポーネントを削除します。

   1. カスタムメトリクスオートスケーラーの CRD を削除します。

      • clustertriggerauthentications.keda.sh
      • kedacontrollers.keda.sh
      • scaledjobs.keda.sh
      • scaledobjects.keda.sh
      • triggerauthentications.keda.sh

      $ oc delete crd clustertriggerauthentications.keda.sh kedacontrollers.keda.sh scaledjobs.keda.sh scaledobjects.keda.sh triggerauthentications.keda.sh

      CRD を削除すると、関連付けられたロール、クラスターロール、およびロールバインディングが削除されます。ただし、手動で削除する必要のあるクラスターロールがいくつかあります。

   2. カスタムメトリクスオートスケーラークラスターのロールをリスト表示します。

      $ oc get clusterrole | grep keda.sh

   3. リスト表示されているカスタムメトリクスオートスケーラークラスターのロールを削除します。以下に例を示します。

      $ oc delete clusterrole.keda.sh-v1alpha1-admin

   4. カスタムメトリクスオートスケーラークラスターのロールバインディングをリスト表示します。

      $ oc get clusterrolebinding | grep keda.sh

   5. リスト表示されているカスタムメトリクスオートスケーラークラスターのロールバインディングを削除します。以下に例を示します。

      $ oc delete clusterrolebinding.keda.sh-v1alpha1-admin

6. カスタムメトリクスオートスケーラーのプロジェクトを削除します。

   $ oc delete project keda

7. Cluster Metric Autoscaler Operator を削除します。

   $ oc delete operator/openshift-custom-metrics-autoscaler-operator.keda

手順

1. Pod 仕様の特定のラベルの付いた Pod を作成します。

   1. 以下の内容を含む YAML ファイルを作成します。

      apiVersion: v1
      kind: Pod
      metadata:
        name: security-s1
        labels:
          security: S1
      spec:
        securityContext:
          runAsNonRoot: true
          seccompProfile:
            type: RuntimeDefault
        containers:
        - name: security-s1
          image: docker.io/ocpqe/hello-pod
          securityContext:
            runAsNonRoot: true
            seccompProfile:
              type: RuntimeDefault

   2. Pod を作成します。

      $ oc create -f <pod-spec>.yaml

2. 他の Pod の作成時に、以下のパラメーターを設定してアフィニティーを追加します。

   1. 以下の内容を含む YAML ファイルを作成します。

      apiVersion: v1
      kind: Pod
      metadata:
        name: security-s1-east
      # ...
      spec:
        affinity: 1
          podAffinity:
            requiredDuringSchedulingIgnoredDuringExecution: 2
            - labelSelector:
                matchExpressions:
                - key: security 3
                  values:
                  - S1
                  operator: In 4
              topologyKey: topology.kubernetes.io/zone 5
      # ...

      1

      Pod のアフィニティーを追加します。

      2

      requiredDuringSchedulingIgnoredDuringExecution パラメーターまたは preferredDuringSchedulingIgnoredDuringExecution パラメーターを設定します。

      3

      満たす必要のある key および values を指定します。新規 Pod を他の Pod と共にスケジュールする必要がある場合、最初の Pod のラベルと同じ key および values パラメーターを使用します。

      4

      Operator を指定します。演算子は In、NotIn、Exists、または DoesNotExist にすることができます。たとえば、演算子 In を使用してラベルをノードで必要になるようにします。

      5

      topologyKey を指定します。これは、システムがトポロジードメインを表すために使用する事前にデータが設定された Kubernetes ラベル です。

   2. Pod を作成します。

      $ oc create -f <pod-spec>.yaml

手順

1. Pod 仕様の特定のラベルの付いた Pod を作成します。

   1. 以下の内容を含む YAML ファイルを作成します。

      apiVersion: v1
      kind: Pod
      metadata:
        name: security-s1
        labels:
          security: S1
      spec:
        securityContext:
          runAsNonRoot: true
          seccompProfile:
            type: RuntimeDefault
        containers:
        - name: security-s1
          image: docker.io/ocpqe/hello-pod
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: [ALL]

   2. Pod を作成します。

      $ oc create -f <pod-spec>.yaml

2. 他の Pod の作成時に、以下のパラメーターを設定します。

   1. 以下の内容を含む YAML ファイルを作成します。

      apiVersion: v1
      kind: Pod
      metadata:
        name: security-s2-east
      # ...
      spec:
      # ...
        affinity: 1
          podAntiAffinity:
            preferredDuringSchedulingIgnoredDuringExecution: 2
            - weight: 100 3
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                  - key: security 4
                    values:
                    - S1
                    operator: In 5
                topologyKey: kubernetes.io/hostname 6
      # ...

      1

      Pod の非アフィニティーを追加します。

      2

      requiredDuringSchedulingIgnoredDuringExecution パラメーターまたは preferredDuringSchedulingIgnoredDuringExecution パラメーターを設定します。

      3

      優先ルールの場合、ノードの重みを 1 ~ 100 で指定します。最も高い重みを持つノードが優先されます。

      4

      満たす必要のある key および values を指定します。新規 Pod を他の Pod と共にスケジュールされないようにする必要がある場合、最初の Pod のラベルと同じ key および values パラメーターを使用します。

      5

      Operator を指定します。演算子は In、NotIn、Exists、または DoesNotExist にすることができます。たとえば、演算子 In を使用してラベルをノードで必要になるようにします。

      6

      topologyKey を指定します。これは、システムがトポロジードメインを表すために使用する事前にデータが設定された Kubernetes ラベル です。

   2. Pod を作成します。

      $ oc create -f <pod-spec>.yaml

1. Pod 仕様の特定のラベルの付いた Pod を作成します。

   1. 以下の内容を含む YAML ファイルを作成します。

      注記

      アフィニティーをスケジュールされた Pod に直接追加することはできません。

      出力例

      apiVersion: v1
      kind: Pod
      metadata:
        name: s1
      spec:
        affinity: 1
          nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution: 2
              nodeSelectorTerms:
              - matchExpressions:
                - key: e2e-az-name 3
                  values:
                  - e2e-az1
                  - e2e-az2
                  operator: In 4
      #...

      1

      Pod のアフィニティーを追加します。

      2

      requiredDuringSchedulingIgnoredDuringExecution パラメーターを設定します。

      3

      満たす必要のある key および values を指定します。新規 Pod を編集したノードにスケジュールする必要がある場合、ノードのラベルと同じ key および values パラメーターを使用します。

      4

      Operator を指定します。演算子は In、NotIn、Exists、または DoesNotExist にすることができます。たとえば、演算子 In を使用してラベルをノードで必要になるようにします。

   2. Pod を作成します。

      $ oc create -f <file-name>.yaml

1. 特定のラベルの付いた Pod を作成します。

   1. 以下の内容を含む YAML ファイルを作成します。

      注記

      アフィニティーをスケジュールされた Pod に直接追加することはできません。

      apiVersion: v1
      kind: Pod
      metadata:
        name: s1
      spec:
        affinity: 1
          nodeAffinity:
            preferredDuringSchedulingIgnoredDuringExecution: 2
            - weight: 3
              preference:
                matchExpressions:
                - key: e2e-az-name 4
                  values:
                  - e2e-az3
                  operator: In 5
      #...

      1

      Pod のアフィニティーを追加します。

      2

      preferredDuringSchedulingIgnoredDuringExecution パラメーターを設定します。

      3

      ノードの重みを数字の 1-100 で指定します。最も高い重みを持つノードが優先されます。

      4

      満たす必要のある key および values を指定します。新規 Pod を編集したノードにスケジュールする必要がある場合、ノードのラベルと同じ key および values パラメーターを使用します。

      5

      Operator を指定します。演算子は In、NotIn、Exists、または DoesNotExist にすることができます。たとえば、演算子 In を使用してラベルをノードで必要になるようにします。

   2. Pod を作成します。

      $ oc create -f <file-name>.yaml

1. デーモンセット yaml ファイルを定義します。

   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
     name: hello-daemonset
   spec:
     selector:
         matchLabels:
           name: hello-daemonset 1
     template:
       metadata:
         labels:
           name: hello-daemonset 2
       spec:
         nodeSelector: 3
           role: worker
         containers:
         - image: openshift/hello-openshift
           imagePullPolicy: Always
           name: registry
           ports:
           - containerPort: 80
             protocol: TCP
           resources: {}
           terminationMessagePath: /dev/termination-log
         serviceAccount: default
         terminationGracePeriodSeconds: 10
   #...

   1

   デーモンセットに属する Pod を判別するラベルセレクターです。

   2

   Pod テンプレートのラベルセレクターです。上記のラベルセレクターに一致している必要があります。

   3

   Pod レプリカをデプロイする必要があるノードを判別するノードセレクターです。一致するラベルがこのノードに存在する必要があります。

2. デーモンセットオブジェクトを作成します。

   $ oc create -f daemonset.yaml

3. Pod が作成されていることを確認し、各 Pod に Pod レプリカがあることを確認するには、以下を実行します。

   1. daemonset Pod を検索します。

      $ oc get pods

      出力例

      hello-daemonset-cx6md   1/1       Running   0          2m
      hello-daemonset-e3md9   1/1       Running   0          2m

   2. Pod がノードに配置されていることを確認するために Pod を表示します。

      $ oc describe pod/hello-daemonset-cx6md|grep Node

      出力例

      Node:        openshift-node01.hostname.com/10.14.20.134

      $ oc describe pod/hello-daemonset-e3md9|grep Node

      出力例

      Node:        openshift-node02.hostname.com/10.14.20.137

1. 以下のような YAML ファイルを作成します。

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: pi
   spec:
     parallelism: 1    1
     completions: 1    2
     activeDeadlineSeconds: 1800 3
     backoffLimit: 6   4
     template:         5
       metadata:
         name: pi
       spec:
         containers:
         - name: pi
           image: perl
           command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
         restartPolicy: OnFailure    6
   #...

   1

   オプション: ジョブを並行して実行する Pod レプリカの数を指定します。デフォルトは 1 です。

   • 非並列ジョブの場合は、未設定のままにします。未設定の場合は、デフォルトの 1 に設定されます。

   2

   オプション: ジョブの完了をマークするために必要な Pod の正常な完了の数を指定します。

   • 非並列ジョブの場合は、未設定のままにします。未設定の場合は、デフォルトの 1 に設定されます。
   • 固定の完了数を持つ並列ジョブの場合、完了の数を指定します。
   • ワークキューのある並列ジョブでは、未設定のままにします。未設定の場合、デフォルトは parallelism 値に設定されます。

   3

   オプション: ジョブを実行できる最大期間を指定します。

   4

   オプション: ジョブの再試行回数を指定します。このフィールドは、デフォルトでは 6 に設定されています。

   5

   コントローラーが作成する Pod のテンプレートを指定します。

   6

   Pod の再起動ポリシーを指定します。

   • Never.ジョブを再起動しません。
   • OnFailure.ジョブが失敗した場合にのみ再起動します。

   • Alwaysジョブを常に再起動します。

     Red Hat OpenShift Service on AWS が失敗したコンテナーに再起動ポリシーを使用する方法の詳細は、Kubernetes ドキュメントの Example States を参照してください。

2. ジョブを作成します。

   $ oc create -f <file-name>.yaml

1. 以下のような YAML ファイルを作成します。

   apiVersion: batch/v1
   kind: CronJob
   metadata:
     name: pi
   spec:
     schedule: "*/1 * * * *"          1
     concurrencyPolicy: "Replace"     2
     startingDeadlineSeconds: 200     3
     suspend: true                    4
     successfulJobsHistoryLimit: 3    5
     failedJobsHistoryLimit: 1        6
     jobTemplate:                     7
       spec:
         template:
           metadata:
             labels:                  8
               parent: "cronjobpi"
           spec:
             containers:
             - name: pi
               image: perl
               command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
             restartPolicy: OnFailure 9

   1

   cron 形式 で指定されたジョブのスケジュール。この例では、ジョブは毎分実行されます。

   2

   オプションの同時実行ポリシー。cron ジョブ内での同時実行ジョブを処理する方法を指定します。以下の同時実行ポリシーの 1 つのみを指定できます。これが指定されない場合、同時実行を許可するようにデフォルト設定されます。

   • Allow: cron ジョブを同時に実行できます。
   • Forbid: 同時実行を禁止し、直前の実行が終了していない場合は次の実行を省略します。
   • Replace: 同時に実行されているジョブを取り消し、これを新規ジョブに置き換えます。

   3

   ジョブを開始するためのオプションの期限 (秒単位)(何らかの理由によりスケジュールされた時間が経過する場合)。ジョブの実行が行われない場合、ジョブの失敗としてカウントされます。これが指定されない場合は期間が設定されません。

   4

   cron ジョブの停止を許可するオプションのフラグ。これが true に設定されている場合、後続のすべての実行が停止されます。

   5

   保持する成功した終了済みジョブの数 (デフォルトは 3 に設定)。

   6

   保持する失敗した終了済みジョブの数 (デフォルトは 1 に設定)。

   7

   ジョブテンプレート。これはジョブの例と同様です。

   8

   この cron ジョブで生成されるジョブのラベルを設定します。

   9

   Pod の再起動ポリシー。ジョブコントローラーには適用されません。

   注記

   .spec.successfulJobsHistoryLimit と .spec.failedJobsHistoryLimit のフィールドはオプションです。これらのフィールドでは、完了したジョブと失敗したジョブのそれぞれを保存する数を指定します。デフォルトで、これらのジョブの保存数はそれぞれ 3 と 1 に設定されます。制限に 0 を設定すると、終了後に対応する種類のジョブのいずれも保持しません。

2. cron ジョブを作成します。

   $ oc create -f <file-name>.yaml

手順

1. Pod の退避を実行する前に、ノードをスケジュール対象外としてマークします。

   1. ノードにスケジュール対象外 (unschedulable) のマークを付けます。

      $ oc adm cordon <node1>

      出力例

      node/<node1> cordoned

   2. ノードのステータスが Ready,SchedulingDisabled であることを確認します。

      $ oc get node <node1>

      出力例

      NAME        STATUS                     ROLES     AGE       VERSION
      <node1>     Ready,SchedulingDisabled   worker    1d        v1.31.3

2. 以下の方法のいずれかを使用して Pod を退避します。

   • 1 つ以上のノードで、すべてまたは選択した Pod を退避します。

     $ oc adm drain <node1> <node2> [--pod-selector=<pod_selector>]

   • --force オプションを使用してベア Pod の削除を強制的に実行します。true に設定されると、Pod がレプリケーションコントローラー、レプリカセット、ジョブ、デーモンセット、またはステートフルセットで管理されていない場合でも削除が続行されます。

     $ oc adm drain <node1> <node2> --force=true

   • --grace-period を使用して、各 Pod を正常に終了するための期間 (秒単位) を設定します。負の値の場合には、Pod に指定されるデフォルト値が使用されます。

     $ oc adm drain <node1> <node2> --grace-period=-1

   • true に設定された --ignore-daemonsets フラグを使用してデーモンセットが管理する Pod を無視します。

     $ oc adm drain <node1> <node2> --ignore-daemonsets=true

   • --timeout を使用して、中止する前の待機期間を設定します。値 0 は無限の時間を設定します。

     $ oc adm drain <node1> <node2> --timeout=5s

   • --delete-emptydir-data フラグを true に設定して、emptyDir ボリュームを使用する Pod がある場合にも Pod を削除します。ローカルデータはノードがドレイン (解放) される場合に削除されます。

     $ oc adm drain <node1> <node2> --delete-emptydir-data=true

   • true に設定された --dry-run オプションを使用して、実際に退避を実行せずに移行するオブジェクトをリスト表示します。

     $ oc adm drain <node1> <node2>  --dry-run=true

     特定のノード名 (例: <node1> <node2>) を指定する代わりに、--selector=<node_selector> オプションを使用し、選択したノードで Pod を退避することができます。

3. 完了したら、ノードにスケジュール対象のマークを付けます。

   $ oc adm uncordon <node1>

手順

1. Init コンテナーの Pod を作成します。

   1. 以下のような YAML ファイルを作成します。

      apiVersion: v1
      kind: Pod
      metadata:
        name: myapp-pod
        labels:
          app: myapp
      spec:
        securityContext:
          runAsNonRoot: true
          seccompProfile:
            type: RuntimeDefault
        containers:
        - name: myapp-container
          image: registry.access.redhat.com/ubi9/ubi:latest
          command: ['sh', '-c', 'echo The app is running! && sleep 3600']
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: [ALL]
        initContainers:
        - name: init-myservice
          image: registry.access.redhat.com/ubi9/ubi:latest
          command: ['sh', '-c', 'until getent hosts myservice; do echo waiting for myservice; sleep 2; done;']
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: [ALL]
        - name: init-mydb
          image: registry.access.redhat.com/ubi9/ubi:latest
          command: ['sh', '-c', 'until getent hosts mydb; do echo waiting for mydb; sleep 2; done;']
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: [ALL]

   2. Pod を作成します。

      $ oc create -f myapp.yaml

   3. Pod のステータスを表示します。

      $ oc get pods

      出力例

      NAME                          READY     STATUS              RESTARTS   AGE
      myapp-pod                     0/1       Init:0/2            0          5s

      Pod のステータス Init:0/2 は、2 つのサービスを待機していることを示します。

2. myservice サービスを作成します。

   1. 以下のような YAML ファイルを作成します。

      kind: Service
      apiVersion: v1
      metadata:
        name: myservice
      spec:
        ports:
        - protocol: TCP
          port: 80
          targetPort: 9376

   2. Pod を作成します。

      $ oc create -f myservice.yaml

   3. Pod のステータスを表示します。

      $ oc get pods

      出力例

      NAME                          READY     STATUS              RESTARTS   AGE
      myapp-pod                     0/1       Init:1/2            0          5s

      Pod のステータス Init:1/2 は、1 つのサービス (この場合は mydb サービス) を待機していることを示します。

3. mydb サービスを作成します。

   1. 以下のような YAML ファイルを作成します。

      kind: Service
      apiVersion: v1
      metadata:
        name: mydb
      spec:
        ports:
        - protocol: TCP
          port: 80
          targetPort: 9377

   2. Pod を作成します。

      $ oc create -f mydb.yaml

   3. Pod のステータスを表示します。

      $ oc get pods

      出力例

      NAME                          READY     STATUS              RESTARTS   AGE
      myapp-pod                     1/1       Running             0          2m

      Pod のステータスは、サービスを待機しておらず、実行中であることを示していました。