ノード

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. OpenShift Container Platform コンソールで 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. Pod 仕様を作成するか、既存の Pod を編集して system-cluster-critical 優先順位クラスを含めます。

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-pdb
   spec:
     template:
       metadata:
         name: critical-pod
       priorityClassName: system-cluster-critical 1

   1

   ノードからエビクトすべきではない Pod のデフォルトの優先順位クラス。

   または、クラスターにとって重要だが、必要に応じて削除できる Pod に system-node-critical を指定することもできます。

2. Pod を作成します。

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

1. Topology ビューで、ノードをクリックしてサイドペインを表示します。

2. Actions ドロップダウンリストから、Add HorizontalPodAutoscaler を選択して Add HorizontalPodAutoscaler フォームを開きます。

   図2.2 Horizontal Pod Autoscaler の追加

   

3. Add HorizontalPodAutoscaler フォームから、名前、最小および最大の Pod 制限、CPU およびメモリーの使用状況を定義し、Save をクリックします。

   注記

   CPU およびメモリー使用量の値のいずれかが見つからない場合は、警告が表示されます。

1. Topology ビューで、ノードをクリックしてサイドペインを表示します。
2. Actions ドロップダウンリストから、Edit HorizontalPodAutoscaler を選択し、 Horizontal Pod Autoscaler フォームを開きます。
3. Edit Horizontal Pod Autoscaler フォームから、最小および最大の Pod 制限および CPU およびメモリー使用量を編集し、Save をクリックします。

1. Topology ビューで、ノードをクリックし、サイドパネルを表示します。
2. Actions ドロップダウンリストから、Remove HorizontalPodAutoscaler を選択します。
3. 確認のポップアップウィンドウで、Remove をクリックして HPA を削除します。

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

   • CPU 使用率のパーセントに基づいてスケーリングするには、既存のオブジェクトとして HorizontalPodAutoscaler オブジェクトを作成します。

     $ oc autoscale <object_type>/<name> \1
       --min <number> \2
       --max <number> \3
       --cpu-percent=<percent> 4

     1

     自動スケーリングするオブジェクトのタイプと名前を指定します。オブジェクトが存在し、 Deployment、DeploymentConfig/dc、ReplicaSet/rs、ReplicationController/rc 、または StatefulSet である必要があります。

     2

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

     3

     スケールアップ時のレプリカの最大数を指定します。

     4

     要求された CPU のパーセントで表示された、すべての Pod に対する目標の平均 CPU 使用率を指定します。指定しない場合または負の値の場合、デフォルトの自動スケーリングポリシーが使用されます。

     たとえば、以下のコマンドは image-registry Deployment オブジェクトの自動スケーリングを示しています。最初のデプロイメントでは 3 つの Pod が必要です。HPA オブジェクトは、最小値を 5 に増やします。Pod の CPU 使用率が 75% に達すると、Pod は 7 まで増加します。

     $ oc autoscale deployment/image-registry --min=5 --max=7 --cpu-percent=75

   • 特定の CPU 値に合わせてスケーリングするには、既存のオブジェクトに対して次のような YAML ファイルを作成します。

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

        apiVersion: autoscaling/v2 1
        kind: HorizontalPodAutoscaler
        metadata:
          name: cpu-autoscale 2
          namespace: default
        spec:
          scaleTargetRef:
            apiVersion: apps/v1 3
            kind: Deployment 4
            name: example 5
          minReplicas: 1 6
          maxReplicas: 10 7
          metrics: 8
          - type: Resource
            resource:
              name: cpu 9
              target:
                type: AverageValue 10
                averageValue: 500m 11

        1

        autoscaling/v2 API を使用します。

        2

        この Horizontal Pod Autoscaler オブジェクトの名前を指定します。

        3

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

        • Deployment、ReplicaSet、Statefulset オブジェクトの場合は、apps/v1 を使用します。
        • ReplicationController の場合は、 v1 を使用します。
        • DeploymentConfig の場合は、 apps.openshift.io/v1 を使用します。

        4

        オブジェクトのタイプを指定します。オブジェクトは、 Deployment、DeploymentConfig/dc、ReplicaSet/rs、ReplicationController/rc 、または StatefulSet である必要があります。

        5

        スケーリングするオブジェクトの名前を指定します。オブジェクトが存在する必要があります。

        6

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

        7

        スケールアップ時のレプリカの最大数を指定します。

        8

        メモリー使用率に metrics パラメーターを使用します。

        9

        CPU 使用率に cpu を指定します。

        10

        AverageValue に設定します。

        11

        ターゲットに設定された CPU 値で averageValue に設定します。

     2. Horizontal Pod Autoscaler を作成します。

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

2. Horizontal Pod Autoscaler が作成されていることを確認します。

   $ oc get hpa cpu-autoscale

   出力例

   NAME            REFERENCE            TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
   cpu-autoscale   Deployment/example   173m/500m       1         10        1          20m

1. 以下のいずれか 1 つを含む YAML ファイルを作成します。

   • 特定のメモリー値についてスケーリングするには、既存のオブジェクトについて以下のような HorizontalPodAutoscaler オブジェクトを作成します。

     apiVersion: autoscaling/v2 1
     kind: HorizontalPodAutoscaler
     metadata:
       name: hpa-resource-metrics-memory 2
       namespace: default
     spec:
       scaleTargetRef:
         apiVersion: apps/v1 3
         kind: Deployment 4
         name: example 5
       minReplicas: 1 6
       maxReplicas: 10 7
       metrics: 8
       - type: Resource
         resource:
           name: memory 9
           target:
             type: AverageValue 10
             averageValue: 500Mi 11
       behavior: 12
         scaleDown:
           stabilizationWindowSeconds: 300
           policies:
           - type: Pods
             value: 4
             periodSeconds: 60
           - type: Percent
             value: 10
             periodSeconds: 60
           selectPolicy: Max

     1

     autoscaling/v2 API を使用します。

     2

     この Horizontal Pod Autoscaler オブジェクトの名前を指定します。

     3

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

     • Deployment、ReplicaSet、または Statefulset オブジェクトの場合は、apps/v1 を使用します。
     • ReplicationController の場合は、 v1 を使用します。
     • DeploymentConfig の場合は、 apps.openshift.io/v1 を使用します。

     4

     オブジェクトのタイプを指定します。オブジェクトは、Deployment、DeploymentConfig、ReplicaSet、ReplicationController、またはStatefulSet である必要があります。

     5

     スケーリングするオブジェクトの名前を指定します。オブジェクトが存在する必要があります。

     6

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

     7

     スケールアップ時のレプリカの最大数を指定します。

     8

     メモリー使用率に metrics パラメーターを使用します。

     9

     メモリー使用率の memory を指定します。

     10

     タイプを AverageValue に設定します。

     11

     averageValue および特定のメモリー値を指定します。

     12

     オプション: スケールアップまたはスケールダウンのレートを制御するスケーリングポリシーを指定します。

   • パーセンテージでスケーリングするには、既存のオブジェクトに対して、次のような HorizontalPodAutoscaler オブジェクトを作成します。

     apiVersion: autoscaling/v2 1
     kind: HorizontalPodAutoscaler
     metadata:
       name: memory-autoscale 2
       namespace: default
     spec:
       scaleTargetRef:
         apiVersion: apps/v1 3
         kind: Deployment 4
         name: example 5
       minReplicas: 1 6
       maxReplicas: 10 7
       metrics: 8
       - type: Resource
         resource:
           name: memory 9
           target:
             type: Utilization 10
             averageUtilization: 50 11
       behavior: 12
         scaleUp:
           stabilizationWindowSeconds: 180
           policies:
           - type: Pods
             value: 6
             periodSeconds: 120
           - type: Percent
             value: 10
             periodSeconds: 120
           selectPolicy: Max

     1

     autoscaling/v2 API を使用します。

     2

     この Horizontal Pod Autoscaler オブジェクトの名前を指定します。

     3

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

     • ReplicationController の場合は、v1 を使用します。
     • DeploymentConfig については、apps.openshift.io/v1 を使用します。
     • Deployment、ReplicaSet、Statefulset オブジェクトの場合は、apps/v1 を使用します。

     4

     オブジェクトのタイプを指定します。オブジェクトは、Deployment、DeploymentConfig、ReplicaSet、ReplicationController、またはStatefulSet である必要があります。

     5

     スケーリングするオブジェクトの名前を指定します。オブジェクトが存在する必要があります。

     6

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

     7

     スケールアップ時のレプリカの最大数を指定します。

     8

     メモリー使用率に metrics パラメーターを使用します。

     9

     メモリー使用率の memory を指定します。

     10

     Utilization に設定します。

     11

     averageUtilization および ターゲットに設定する平均メモリー使用率をすべての Pod に対して指定します (要求されるメモリーのパーセントで表す)。ターゲット Pod にはメモリー要求が設定されている必要があります。

     12

     オプション: スケールアップまたはスケールダウンのレートを制御するスケーリングポリシーを指定します。

2. Horizontal Pod Autoscaler を作成します。

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

   以下に例を示します。

   $ oc create -f hpa.yaml

   出力例

   horizontalpodautoscaler.autoscaling/hpa-resource-metrics-memory created

3. Horizontal Pod Autoscaler が作成されていることを確認します。

   $ oc get hpa hpa-resource-metrics-memory

   出力例

   NAME                          REFERENCE            TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
   hpa-resource-metrics-memory   Deployment/example   2441216/500Mi   1         10        1          20m

   $ oc describe hpa hpa-resource-metrics-memory

   出力例

   Name:                        hpa-resource-metrics-memory
   Namespace:                   default
   Labels:                      <none>
   Annotations:                 <none>
   CreationTimestamp:           Wed, 04 Mar 2020 16:31:37 +0530
   Reference:                   Deployment/example
   Metrics:                     ( current / target )
     resource memory on pods:   2441216 / 500Mi
   Min replicas:                1
   Max replicas:                10
   ReplicationController pods:  1 current / 1 desired
   Conditions:
     Type            Status  Reason              Message
     ----            ------  ------              -------
     AbleToScale     True    ReadyForNewScale    recommended size matches current size
     ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
     ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
   Events:
     Type     Reason                   Age                 From                       Message
     ----     ------                   ----                ----                       -------
     Normal   SuccessfulRescale        6m34s               horizontal-pod-autoscaler  New size: 1; reason: All metrics below target

手順

1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. 利用可能な Operator のリストから VerticalPodAutoscaler を選択し、Install をクリックします。
3. Install Operator ページで、Operator recommended namespace オプションが選択されていることを確認します。これにより、Operator が必須の openshift-vertical-pod-autoscaler namespace にインストールされます。この namespace は存在しない場合は、自動的に作成されます。
4. Install をクリックします。

5. VPA Operator コンポーネントをリスト表示して、インストールを確認します。

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

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

   $ oc get all -n openshift-vertical-pod-autoscaler

   出力には、4 つの Pod と 4 つのデプロイメントが表示されます。

   出力例

   NAME                                                    READY   STATUS    RESTARTS   AGE
   pod/vertical-pod-autoscaler-operator-85b4569c47-2gmhc   1/1     Running   0          3m13s
   pod/vpa-admission-plugin-default-67644fc87f-xq7k9       1/1     Running   0          2m56s
   pod/vpa-recommender-default-7c54764b59-8gckt            1/1     Running   0          2m56s
   pod/vpa-updater-default-7f6cc87858-47vw9                1/1     Running   0          2m56s
   
   NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
   service/vpa-webhook   ClusterIP   172.30.53.206   <none>        443/TCP   2m56s
   
   NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/vertical-pod-autoscaler-operator   1/1     1            1           3m13s
   deployment.apps/vpa-admission-plugin-default       1/1     1            1           2m56s
   deployment.apps/vpa-recommender-default            1/1     1            1           2m56s
   deployment.apps/vpa-updater-default                1/1     1            1           2m56s
   
   NAME                                                          DESIRED   CURRENT   READY   AGE
   replicaset.apps/vertical-pod-autoscaler-operator-85b4569c47   1         1         1       3m13s
   replicaset.apps/vpa-admission-plugin-default-67644fc87f       1         1         1       2m56s
   replicaset.apps/vpa-recommender-default-7c54764b59            1         1         1       2m56s
   replicaset.apps/vpa-updater-default-7f6cc87858                1         1         1       2m56s

1. スケーリングするワークロードオブジェクトがあるプロジェクトに切り替えます。

   1. VPA CR YAML ファイルを作成します。

      apiVersion: autoscaling.k8s.io/v1
      kind: VerticalPodAutoscaler
      metadata:
        name: vpa-recommender
      spec:
        targetRef:
          apiVersion: "apps/v1"
          kind:       Deployment 1
          name:       frontend 2
        updatePolicy:
          updateMode: "Auto" 3
        resourcePolicy: 4
          containerPolicies:
          - containerName: my-opt-sidecar
            mode: "Off"

      1

      この VPA が管理するワークロードオブジェクトのタイプ (Deployment、StatefulSet、Job、DaemonSet、ReplicaSet、または ReplicationController) を指定します。

      2

      この VPA が管理する既存のワークロードオブジェクトの名前を指定します。

      3

      VPA モードを指定します。

      • auto は、コントローラーに関連付けられた Pod に推奨リソースを自動的に適用します。VPA は既存の Pod を終了し、推奨されるリソース制限および要求で新規 Pod を作成します。
      • recreate は、ワークロードオブジェクトに関連付けられた Pod に推奨リソースを自動的に適用します。VPA は既存の Pod を終了し、推奨されるリソース制限および要求で新規 Pod を作成します。recreate モードはほとんど使用されることはありません。リソース要求が変更される際に Pod が再起動されていることを確認する必要がある場合にのみ使用します。
      • initial は、ワークロードオブジェクトに関連付けられた Pod が作成される際に、推奨リソースを自動的に適用します。VPA は、新しい推奨リソースを確認する際に Pod を更新しません。
      • off は、ワークロードオブジェクトに関連付けられた Pod の推奨リソースのみを生成します。VPA は、新しい推奨リソースを確認する際に Pod を更新しません。また、新規 Pod に推奨事項を適用しません。

      4

      オプション:オプトアウトするコンテナーを指定し、モードを Off に設定します。

   2. VPA CR を作成します。

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

      しばらくすると、VPA はワークロードオブジェクトに関連付けられた Pod 内のコンテナーのリソース使用状況を確認します。

      以下のコマンドを実行して、VPA の推奨事項を表示できます。

      $ oc get vpa <vpa-name> --output yaml

      出力には、以下のような CPU およびメモリー要求の推奨事項が表示されます。

      出力例

      ...
      status:
      
      ...
      
        recommendation:
          containerRecommendations:
          - containerName: frontend
            lowerBound: 1
              cpu: 25m
              memory: 262144k
            target: 2
              cpu: 25m
              memory: 262144k
            uncappedTarget: 3
              cpu: 25m
              memory: 262144k
            upperBound: 4
              cpu: 262m
              memory: "274357142"
          - containerName: backend
            lowerBound:
              cpu: 12m
              memory: 131072k
            target:
              cpu: 12m
              memory: 131072k
            uncappedTarget:
              cpu: 12m
              memory: 131072k
            upperBound:
              cpu: 476m
              memory: "498558823"
      
      ...

      1

      lowerBound は、推奨リソースの最小レベルです。

      2

      target は、推奨リソースのレベルです。

      3

      upperBound は、推奨リソースの最大レベルです。

      4

      uncappedTarget は最新の推奨リソースです。

手順

1. OpenShift Container Platform Web コンソールで、Operators → Installed Operators をクリックします。
2. openshift-vertical-pod-autoscaler プロジェクトに切り替えます。
3. VerticalPodAutoscaler Operator の場合は、Options メニュー をクリックし、Uninstall Operator を選択します。
4. オプション: 演算子に関連付けられているすべてのオペランドを削除するには、ダイアログボックスで、Delete all operand instances for this operatorチェックボックスをオンにします。
5. Uninstall をクリックします。

6. オプション: OpenShift CLI を使用して VPA コンポーネントを削除します。

   1. VPA namespace を削除します。

      $ oc delete namespace openshift-vertical-pod-autoscaler

   2. VPA カスタムリソース定義 (CRD) オブジェクトを削除します。

      $ oc delete crd verticalpodautoscalercheckpoints.autoscaling.k8s.io

      $ oc delete crd verticalpodautoscalercontrollers.autoscaling.openshift.io

      $ oc delete crd verticalpodautoscalers.autoscaling.k8s.io

      CRD を削除すると、関連付けられたロール、クラスターロール、およびロールバインディングが削除されます。

      注記

      この操作により、ユーザーが作成したすべての VPA CR がクラスターから削除されます。VPA を再インストールする場合は、これらのオブジェクトを再度作成する必要があります。

   3. VPA Operator を削除します。

      $ oc delete operator/vertical-pod-autoscaler.openshift-vertical-pod-autoscaler

1. 秘密にしておきたいデータを含む秘密オブジェクトを作成します。各シークレットタイプに必要な特定のデータは、以下のセクションで非表示になります。

   不透明なシークレットを作成する YAML オブジェクトの例

   apiVersion: v1
   kind: Secret
   metadata:
     name: test-secret
   type: Opaque 1
   data: 2
     username: <username>
     password: <password>
   stringData: 3
     hostname: myapp.mydomain.com
     secret.properties: |
       property1=valueA
       property2=valueB

   1

   シークレットのタイプを指定します。

   2

   エンコードされた文字列およびデータを指定します。

   3

   デコードされた文字列およびデータを指定します。

   data フィールドまたは stringdata フィールドの両方ではなく、いずれかを使用してください。

2. Pod のサービスアカウントをシークレットを参照するように更新します。

   シークレットを使用するサービスアカウントの YAML

   apiVersion: v1
   kind: ServiceAccount
    ...
   secrets:
   - name: test-secret

3. シークレットを環境変数またはファイルとして使用する Pod を作成します (secret ボリュームを使用)。

   シークレットデータと共にボリュームのファイルが設定された Pod の YAML

   apiVersion: v1
   kind: Pod
   metadata:
     name: secret-example-pod
   spec:
     containers:
       - name: secret-test-container
         image: busybox
         command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
         volumeMounts: 1
             - name: secret-volume
               mountPath: /etc/secret-volume 2
               readOnly: true 3
     volumes:
       - name: secret-volume
         secret:
           secretName: test-secret 4
     restartPolicy: Never

   1

   シークレットが必要な各コンテナーに volumeMounts フィールドを追加します。

   2

   シークレットが表示される未使用のディレクトリー名を指定します。シークレットデータマップの各キーは mountPath の下にあるファイル名になります。

   3

   true に設定します。true の場合、ドライバーに読み取り専用ボリュームを提供するように指示します。

   4

   シークレットの名前を指定します。

   シークレットデータと共に環境変数が設定された Pod の YAML

   apiVersion: v1
   kind: Pod
   metadata:
     name: secret-example-pod
   spec:
     containers:
       - name: secret-test-container
         image: busybox
         command: [ "/bin/sh", "-c", "export" ]
         env:
           - name: TEST_SECRET_USERNAME_ENV_VAR
             valueFrom:
               secretKeyRef: 1
                 name: test-secret
                 key: username
     restartPolicy: Never

   1

   シークレットキーを使用する環境変数を指定します。

   シークレットデータと環境変数が設定されたビルド設定の YAML

   apiVersion: build.openshift.io/v1
   kind: BuildConfig
   metadata:
     name: secret-example-bc
   spec:
     strategy:
       sourceStrategy:
         env:
         - name: TEST_SECRET_USERNAME_ENV_VAR
           valueFrom:
             secretKeyRef: 1
               name: test-secret
               key: username
         from:
           kind: ImageStreamTag
           namespace: openshift
           name: 'cli:latest'

   1

   シークレットキーを使用する環境変数を指定します。

手順

1. 以下のコマンドを実行して namespace にサービスアカウントを作成します。

   $ oc create sa <service_account_name> -n <your_namespace>

2. 以下の YAML の例は service-account-token-secret.yaml という名前のファイルに保存します。この例には、サービスアカウントトークンの生成に使用可能な Secret オブジェクト設定が含まれています。

   apiVersion: v1
   kind: Secret
   metadata:
     name: <secret_name> 1
     annotations:
       kubernetes.io/service-account.name: "sa-name" 2
   type: kubernetes.io/service-account-token 3

   1

   <secret_name> は、サービストークンシークレットの名前に置き換えます。

   2

   既存のサービスアカウント名を指定します。ServiceAccount と Secret オブジェクトの両方を作成する場合は、ServiceAccount オブジェクトを最初に作成します。

   3

   サービスアカウントトークンシークレットタイプを指定します。

3. ファイルを適用してサービスアカウントトークンを生成します。

   $ oc apply -f service-account-token-secret.yaml

4. 以下のコマンドを実行して、シークレットからサービスアカウントトークンを取得します。

   $ oc get secret <sa_token_secret> -o jsonpath='{.data.token}' | base64 --decode) 1

   出力例

   ayJhbGciOiJSUzI1NiIsImtpZCI6IklOb2dtck1qZ3hCSWpoNnh5YnZhSE9QMkk3YnRZMVZoclFfQTZfRFp1YlUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkZXItdG9rZW4tdHZrbnIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiYnVpbGRlciIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjNmZGU2MGZmLTA1NGYtNDkyZi04YzhjLTNlZjE0NDk3MmFmNyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmJ1aWxkZXIifQ.OmqFTDuMHC_lYvvEUrjr1x453hlEEHYcxS9VKSzmRkP1SiVZWPNPkTWlfNRp6bIUZD3U6aN3N7dMSN0eI5hu36xPgpKTdvuckKLTCnelMx6cxOdAbrcw1mCmOClNscwjS1KO1kzMtYnnq8rXHiMJELsNlhnRyyIXRTtNBsy4t64T3283s3SLsancyx0gy0ujx-Ch3uKAKdZi5iT-I8jnnQ-ds5THDs2h65RJhgglQEmSxpHrLGZFmyHAQI-_SjvmHZPXEc482x3SkaQHNLqpmrpJorNqh1M8ZHKzlujhZgVooMvJmWPXTb2vnvi3DGn2XI-hZxl1yD2yGH1RBpYUHA

   1

   <sa_token_secret> は、サービストークンシークレットの名前に置き換えます。

5. サービスアカウントトークンを使用して、クラスターの API で認証します。

   $ curl -X GET <openshift_cluster_api> --header "Authorization: Bearer <token>" 1 2

   1

   <openshift_cluster_api> は OpenShift クラスター API に置き換えます。

   2

   <token> は、直前のコマンドで出力されるサービスアカウントトークンに置き換えます。

1. シークレットを削除します。

   $ oc delete secret <secret_name>

2. アノテーションをクリアします。

   $ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-

   $ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-

1. 次のコマンドを入力して、設定するノードタイプの静的な MachineConfigPool CRD に関連付けられたラベルを取得します。以下のいずれかの手順を実行します。

   1. マシン設定を表示します。

      # oc describe machineconfig <name>

      以下に例を示します。

      # oc describe machineconfig 00-worker

      出力例

      Name:         00-worker
      Namespace:
      Labels:       machineconfiguration.openshift.io/role=worker 1

      1

      デバイスマネージャーに必要なラベル。

手順

1. 設定変更のためのカスタムリソース (CR) を作成します。

   Device Manager CR の設定例

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: devicemgr 1
   spec:
     machineConfigPoolSelector:
       matchLabels:
          machineconfiguration.openshift.io: devicemgr 2
     kubeletConfig:
       feature-gates:
         - DevicePlugins=true 3

   1

   CR に名前を割り当てます。

   2

   Machine Config Pool からラベルを入力します。

   3

   DevicePlugins を 'true` に設定します。

2. デバイスマネージャーを作成します。

   $ oc create -f devicemgr.yaml

   出力例

   kubeletconfig.machineconfiguration.openshift.io/devicemgr created

3. デバイスマネージャーが実際に有効にされるように、/var/lib/kubelet/device-plugins/kubelet.sock がノードで作成されていることを確認します。これは、デバイスマネージャーの gRPC サーバーが新規プラグインの登録がないかどうかリッスンする UNIX ドメインソケットです。このソケットファイルは、デバイスマネージャーが有効にされている場合にのみ Kubelet の起動時に作成されます。

1. 1 つ以上の優先順位クラスを作成します。

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

      apiVersion: scheduling.k8s.io/v1
      kind: PriorityClass
      metadata:
        name: high-priority 1
      value: 1000000 2
      preemptionPolicy: PreemptLowerPriority 3
      globalDefault: false 4
      description: "This priority class should be used for XYZ service pods only." 5

      1

      優先順位クラスオブジェクトの名前です。

      2

      オブジェクトの優先順位の値です。

      3

      オプション: この優先クラスがプリエンプティングであるか非プリエンプティングであるかを指定します。プリエンプションポリシーは、デフォルトで PreemptLowerPriority に設定されます。これにより、その優先順位クラスの Pod はそれよりも優先順位の低い Pod のプリエンプションを実行できます。プリエンプションポリシーが Never に設定される場合、その優先順位クラスの Pod はプリエンプションを実行しません。

      4

      オプション: 優先クラス名が指定されていない Pod にこの優先クラスを使用するかどうかを指定します。このフィールドはデフォルトで false です。globalDefault が true に設定される 1 つの優先順位クラスのみがクラスター内に存在できます。globalDefault:true が設定された優先順位クラスがない場合、優先順位クラス名が設定されていない Pod の優先順位はゼロになります。globalDefault:true が設定された優先順位クラスを追加すると、優先順位クラスが追加された後に作成された Pod のみがその影響を受け、これによって既存 Pod の優先順位は変更されません。

      5

      オプション: 開発者がこの優先クラスで使用する必要がある Pod について説明します。任意の文字列を入力します。

   2. 優先クラスを作成します。

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

2. 優先クラスの名前を含む Pod 仕様を作成します。

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

      apiVersion: v1
      kind: Pod
      metadata:
        name: nginx
        labels:
          env: test
      spec:
        containers:
        - name: nginx
          image: nginx
          imagePullPolicy: IfNotPresent
        priorityClassName: high-priority 1

      1

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

   2. Pod を作成します。

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

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

手順

1. マシンセットを使用するか、ノードを直接編集してラベルをノードに追加します。

   • MachineSet オブジェクトを使用して、ノードの作成時にマシンセットによって管理されるノードにラベルを追加します。

     1. 以下のコマンドを実行してラベルを MachineSet オブジェクトに追加します。

        $ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api

        以下に例を示します。

        $ oc patch MachineSet abc612-msrtw-worker-us-east-1c  --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

        ヒント

        あるいは、以下の YAML を適用してマシンセットにラベルを追加することもできます。

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
        metadata:
          name: xf2bd-infra-us-east-2a
          namespace: openshift-machine-api
        spec:
          template:
            spec:
              metadata:
                labels:
                  region: "east"
                  type: "user-node"
        #...

     2. oc edit コマンドを使用して、ラベルが MachineSet オブジェクトに追加されていることを確認します。

        以下に例を示します。

        $ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api

        MachineSet オブジェクトの例

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
        
        # ...
        
        spec:
        # ...
          template:
            metadata:
        # ...
            spec:
              metadata:
                labels:
                  region: east
                  type: user-node
        # ...

   • ラベルをノードに直接追加します。

     1. ノードの Node オブジェクトを編集します。

        $ oc label nodes <name> <key>=<value>

        たとえば、ノードにラベルを付けるには、以下を実行します。

        $ oc label nodes ip-10-0-142-25.ec2.internal type=user-node region=east

        ヒント

        あるいは、以下の YAML を適用してノードにラベルを追加することもできます。

        kind: Node
        apiVersion: v1
        metadata:
          name: hello-node-6fbccf8d9
          labels:
            type: "user-node"
            region: "east"
        #...

     2. ラベルがノードに追加されていることを確認します。

        $ oc get nodes -l type=user-node,region=east

        出力例

        NAME                          STATUS   ROLES    AGE   VERSION
        ip-10-0-142-25.ec2.internal   Ready    worker   17m   v1.23.0

2. 一致するノードセレクターを Pod に追加します。

   • ノードセレクターを既存 Pod および新規 Pod に追加するには、ノードセレクターを Pod の制御オブジェクトに追加します。

     ラベルを含む ReplicaSet オブジェクトのサンプル

     kind: ReplicaSet
     apiVersion: apps/v1
     metadata:
       name: hello-node-6fbccf8d9
     # ...
     spec:
     # ...
       template:
         metadata:
           creationTimestamp: null
           labels:
             ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
             pod-template-hash: 66d5cf9464
         spec:
           nodeSelector:
             kubernetes.io/os: linux
             node-role.kubernetes.io/worker: ''
             type: user-node 1
     #...

     1

     ノードセレクターを追加します。

   • ノードセレクターを特定の新規 Pod に追加するには、セレクターを Pod オブジェクトに直接追加します。

     ノードセレクターを持つ Pod オブジェクトの例

     apiVersion: v1
     kind: Pod
     metadata:
       name: hello-node-6fbccf8d9
     #...
     spec:
       nodeSelector:
         region: east
         type: user-node
     #...

     注記

     ノードセレクターを既存のスケジュールされている Pod に直接追加することはできません。

手順

1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. 使用可能な Operator のリストから Custom Metrics Autoscaler を選択し、Install をクリックします。
3. Install Operator ページで、Installation Mode に All namespaces on the cluster (default) オプションが選択されていることを確認します。これにより、Operator がすべての namespace にインストールされます。
4. Installed Namespace に openshift-keda namespace が選択されていることを確認します。クラスターに存在しない場合、OpenShift Container Platform は namespace を作成します。
5. Install をクリックします。

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

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

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

   $ oc get all -n openshift-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

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

   1. OpenShift Container Platform 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: openshift-keda
      spec:
        watchNamespace: '' 1
        operator:
          logLevel: info 2
          logEncoder: console 3
        metricsServer:
          logLevel: '0' 4
          auditConfig: 5
            logFormat: "json"
            logOutputVolumeClaim: "persistentVolumeClaimName"
            policy:
              rules:
              - level: Metadata
              omitStages: "RequestReceived"
              omitManagedFields: false
            lifetime:
              maxAge: "2"
              maxBackup: "1"
              maxSize: "50"
        serviceAccount: {}

      1

      カスタムオートスケーラーが監視する namespace を指定します。コンマ区切りのリストに名前を入力します。すべての namespace を監視するには、省略するか空に設定します。デフォルトは空です。

      2

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

      3

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

      4

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

      5

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

   5. Create をクリックして、KEDAController を作成します。

手順

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 <file-name>.yaml

2. ScaledObject 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:
     - authenticationRef:
       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: 1
           name: prom-triggerauthentication
         metadata:
           name: prom-triggerauthentication
         type: object
       - authenticationRef: 2
           name: prom-cluster-triggerauthentication
           kind: ClusterTriggerAuthentication
         metadata:
           name: prom-cluster-triggerauthentication
         type: object

   1

   オプション: トリガー認証を指定します。

   2

   オプション: クラスタートリガー認証を指定します。kind: ClusterTriggerAuthentication パラメーターを含める必要があります。

   注記

   namespace トリガー認証とクラスタートリガー認証の両方を指定する必要はありません。

3. オブジェクトを作成します。以下に例を示します。

   $ oc apply -f <file-name>

手順

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: openshift-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 openshift-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.26","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 openshift-keda

      以下に例を示します。

      $ oc rsh pod/keda-metrics-apiserver-65c7cc44fd-rrl4r -n openshift-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 データを保存するディレクトリーに移動します。

   注記

   クラスターがネットワークが制限された環境を使用している場合、追加の手順を実行する必要があります。ミラーレジストリーに信頼される CA がある場合、まず信頼される CA をクラスターに追加する必要があります。制限されたネットワーク上のすべてのクラスターでは、次のコマンドを実行して、デフォルトの must-gather イメージをイメージストリームとしてインポートする必要があります。

   $ oc import-image is/must-gather -n openshift

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 出力例:

   └── openshift-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
       ├── openshift-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. OpenShift Container Platform 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
       metadata:
         name: prom-triggerauthentication
       type: object
     - authenticationRef: 18
         name: prom-cluster-triggerauthentication
       metadata:
         name: prom-cluster-triggerauthentication
       type: object

   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

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

   17

   オプション: カスタムメトリックオートスケーラートリガー認証の作成のセクションで説明されているように、トリガー認証を指定します。

   18

   オプション: カスタムメトリックオートスケーラートリガー認証の作成のセクションで説明されているように、クラスタートリガー認証を指定します。

   注記

   namespace トリガー認証とクラスタートリガー認証の両方を指定する必要はありません。

2. カスタムメトリックオートスケーラーを作成します。

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

手順

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

   kind: ScaledJob
   apiVersion: keda.sh/v1alpha1
   metadata:
     name: scaledjob
     namespace: my-namespace
   spec:
     failedJobsHistoryLimit: 5
     jobTargetRef:
       activeDeadlineSeconds: 600 1
       backoffLimit: 6 2
       parallelism: 1 3
       completions: 1 4
       template:  5
         metadata:
           name: pi
         spec:
           containers:
           - name: pi
             image: perl
             command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
     maxReplicaCount: 100 6
     pollingInterval: 30 7
     successfulJobsHistoryLimit: 5 8
     failedJobsHistoryLimit: 5 9
     envSourceContainerName: 10
     rolloutStrategy: gradual 11
     scalingStrategy: 12
       strategy: "custom"
       customScalingQueueLengthDeduction: 1
       customScalingRunningJobPercentage: "0.5"
       pendingPodConditions:
         - "Ready"
         - "PodScheduled"
         - "AnyOtherCustomPodCondition"
       multipleScalersCalculation : "max"
     triggers:
     - type: prometheus 13
       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: "bearer"
     - authenticationRef: 14
         name: prom-triggerauthentication
       metadata:
         name: prom-triggerauthentication
        type: object
     - authenticationRef: 15
         name: prom-cluster-triggerauthentication
       metadata:
         name: prom-cluster-triggerauthentication
       type: object

   1

   ジョブを実行できる最大期間を指定します。

   2

   ジョブの再試行回数を指定します。デフォルト値は 6 です。

   3

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

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

   4

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

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

   5

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

   6

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

   7

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

   8

   オプション: 保持する必要がある正常に終了したジョブの数を指定します。デフォルトは 100 です。

   9

   オプション: 保持する必要がある失敗したジョブの数を指定します。デフォルトは 100 です。

   10

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

   11

   オプション: スケーリングされたジョブが更新されるたびに、既存のジョブを終了するかどうかを指定します。

   • default : 関連するスケーリングされたジョブが更新されると、オートスケーラーは既存のジョブを終了します。オートスケーラーは、最新の仕様でジョブを再作成します。
   • gradual : 関連するスケーリングされたジョブが更新された場合、オートスケーラーは既存のジョブを終了しません。オートスケーラーは、最新の仕様で新しいジョブを作成します。

   12

   オプション: スケーリングストラテジーを指定します: default、custom、または accurate。デフォルトは default です。詳細については、以下の関連情報セクションのリンクを参照してください。

   13

   カスタムメトリックオートスケーラートリガーについてのセクションで説明されているように、スケーリングの基礎として使用するトリガーを指定します。

   14

   オプション: カスタムメトリックオートスケーラートリガー認証の作成のセクションで説明されているように、トリガー認証を指定します。

   15

   オプション: カスタムメトリックオートスケーラートリガー認証の作成のセクションで説明されているように、クラスタートリガー認証を指定します。

   注記

   namespace トリガー認証とクラスタートリガー認証の両方を指定する必要はありません。

2. カスタムメトリックオートスケーラーを作成します。

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

手順

1. OpenShift Container Platform Web コンソールで、Operators → Installed Operators をクリックします。
2. openshift-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 openshift-keda

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

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

手順

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

   $ oc edit scheduler cluster

2. spec.profile フィールドで使用するプロファイルを指定します。

   apiVersion: config.openshift.io/v1
   kind: Scheduler
   metadata:
     name: cluster
   #...
   spec:
     mastersSchedulable: false
     profile: HighNodeUtilization 1
   #...

   1

   LowNodeUtilization、 HighNodeUtilization、または NoScoring に設定されます。

3. 変更を適用するためにファイルを保存します。

手順

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

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

      apiVersion: v1
      kind: Pod
      metadata:
        name: security-s1
        labels:
          security: S1
      spec:
        containers:
        - name: security-s1
          image: docker.io/ocpqe/hello-pod

   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:
        containers:
        - name: security-s1
          image: docker.io/ocpqe/hello-pod

   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. oc label node コマンドを使用してラベルをノードに追加します。

   $ oc label node node1 e2e-az-name=e2e-az1

   ヒント

   あるいは、以下の YAML を適用してラベルを追加できます。

   kind: Node
   apiVersion: v1
   metadata:
     name: <node_name>
     labels:
       e2e-az-name: e2e-az1
   #...

2. 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. oc label node コマンドを使用してラベルをノードに追加します。

   $ oc label node node1 e2e-az-name=e2e-az3

2. 特定のラベルの付いた 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. NoSchedule テイントをコントロールプレーンノードに追加する場合、ノードには、デフォルトで追加される node-role.kubernetes.io/master=:NoSchedule テイントが必要です。

   以下に例を示します。

   apiVersion: v1
   kind: Node
   metadata:
     annotations:
       machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
       machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
     name: my-node
   #...
   spec:
     taints:
     - effect: NoSchedule
       key: node-role.kubernetes.io/master
   #...

手順

1. Pod 仕様を tolerations スタンザを含めるように編集して、容認を Pod に追加します。

   Equal 演算子を含む Pod 設定ファイルのサンプル

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-pod
   #...
   spec:
     tolerations:
     - key: "key1" 1
       value: "value1"
       operator: "Equal"
       effect: "NoExecute"
       tolerationSeconds: 3600 2
   #...

   1

   テイントおよび容認コンポーネント の表で説明されている toleration パラメーターです。

   2

   tolerationSeconds パラメーターは、エビクトする前に Pod をどの程度の期間ノードにバインドさせるかを指定します。

   以下に例を示します。

   Exists 演算子を含む Pod 設定ファイルのサンプル

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-pod
   #...
   spec:
      tolerations:
       - key: "key1"
         operator: "Exists" 1
         effect: "NoExecute"
         tolerationSeconds: 3600
   #...

   1

   Exists Operator は value を取りません。

   この例では、テイントを、キー key1、値 value1、およびテイント effect NoExecute を持つ node1 にテイントを配置します。

2. テイントおよび容認コンポーネント の表で説明されているパラメーターと共に以下のコマンドを使用してテイントをノードに追加します。

   $ oc adm taint nodes <node_name> <key>=<value>:<effect>

   以下に例を示します。

   $ oc adm taint nodes node1 key1=value1:NoExecute

   このコマンドは、キー key1、値 value1、および effect NoExecute を持つテイントを node1 に配置します。

   注記

   NoSchedule テイントをコントロールプレーンノードに追加する場合、ノードには、デフォルトで追加される node-role.kubernetes.io/master=:NoSchedule テイントが必要です。

   以下に例を示します。

   apiVersion: v1
   kind: Node
   metadata:
     annotations:
       machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
       machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
     name: my-node
   #...
   spec:
     taints:
     - effect: NoSchedule
       key: node-role.kubernetes.io/master
   #...

   Pod の容認はノードのテイントに一致します。いずれかの容認のある Pod は node1 にスケジュールできます。