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

   $ oc project <project-name>

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

   $ oc get pods

   以下に例を示します。

   $ oc get pods -n openshift-console

   出力例

   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=''

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

手順 (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 優先順位クラスを含めます。

   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: Deployment
         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 のリストから 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 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. スケーリングするオブジェクトを含むプロジェクトに変更します。

   $ oc project my-project

2. クラスターにサービスアカウントがない場合は、次のコマンドを使用してサービスアカウントを作成します。

   $ oc create serviceaccount <service_account>

   ここでは、以下のようになります。

   <service_account>

   サービスアカウントの名前を指定します。

3. 次のコマンドを使用して、サービスアカウントに割り当てられたトークンを見つけます。

   $ oc describe serviceaccount <service_account>

   ここでは、以下のようになります。

   <service_account>

   サービスアカウントの名前を指定します。

   出力例

   Name:                thanos
   Namespace:           my-project
   Labels:              <none>
   Annotations:         <none>
   Image pull secrets:  thanos-dockercfg-nnwgj
   Mountable secrets:   thanos-dockercfg-nnwgj
   Tokens:              thanos-token-9g4n5 1
   Events:              <none>

   1

   トリガー認証でこのトークンを使用します。

4. サービスアカウントトークンを使用してトリガー認証を作成します。

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

      apiVersion: keda.sh/v1alpha1
      kind: TriggerAuthentication
      metadata:
        name: keda-trigger-auth-prometheus
      spec:
        secretTargetRef: 1
        - parameter: bearerToken 2
          name: thanos-token-9g4n5 3
          key: token 4
        - parameter: ca
          name: thanos-token-9g4n5
          key: ca.crt

      1

      このオブジェクトが承認にシークレットを使用することを指定します。

      2

      トークンを使用して提供する認証パラメーターを指定します。

      3

      使用するトークンの名前を指定します。

      4

      指定されたパラメーターで使用するトークン内のキーを指定します。

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

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

5. Thanos メトリクスを読み取るためのロールを作成します。

   1. 次のパラメーターを使用して YAML ファイルを作成します。

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: thanos-metrics-reader
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        verbs:
        - get
      - apiGroups:
        - metrics.k8s.io
        resources:
        - pods
        - nodes
        verbs:
        - get
        - list
        - watch

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

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

6. Thanos メトリクスを読み取るためのロールバインディングを作成します。

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

      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: thanos-metrics-reader 1
        namespace: my-project 2
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: Role
        name: thanos-metrics-reader
      subjects:
      - kind: ServiceAccount
        name: thanos 3
        namespace: my-project 4

      1

      作成したロールの名前を指定します。

      2

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

      3

      ロールにバインドするサービスアカウントの名前を指定します。

      4

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

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

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

手順

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. 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. 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. 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"
        recommenders: 5
          - name: my-recommender

      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 に設定します。

      5

      オプション:レコメンダーの推奨者を指定します。

   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: dmFsdWUtMQ0K
     password: dmFsdWUtMQ0KDQo=
   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

   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. 優先順位の名前および値を指定します。
   2. 優先順位クラスおよび説明に globalDefault フィールドをオプションで指定します。

2. Pod 仕様を作成するか、または既存の Pod を編集して、以下のように優先順位クラスの名前を含めます。

   優先順位クラス名を持つ Pod 仕様サンプル

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

   1

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

3. 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: <machineset>
          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: <node_name>
          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.25.0

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

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

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

     kind: ReplicaSet
     
     ....
     
     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
     
     ....
     
     spec:
       nodeSelector:
         region: east
         type: user-node

     注記

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

手順

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

   $ oc edit scheduler cluster

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

   apiVersion: config.openshift.io/v1
   kind: Scheduler
   metadata:
     ...
     name: cluster
     resourceVersion: "601"
     selfLink: /apis/config.openshift.io/v1/schedulers/cluster
     uid: b351d6d0-d06f-4a99-a26b-87af62e79f59
   spec:
     mastersSchedulable: false
     profile: HighNodeUtilization 1

   1

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

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

手順

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

   $ cat team4.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 の作成時に、以下のように Pod 仕様を編集します。

   1. podAffinity スタンザを使用して、requiredDuringSchedulingIgnoredDuringExecution パラメーターまたは preferredDuringSchedulingIgnoredDuringExecution パラメーターを設定します。

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

          podAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                - key: security
                  operator: In
                  values:
                  - S1
              topologyKey: failure-domain.beta.kubernetes.io/zone

   3. operator を指定します。演算子は In、NotIn、Exists、または DoesNotExist にすることができます。たとえば、演算子 In を使用してラベルをノードで必要になるようにします。
   4. topologyKey を指定します。これは、システムがトポロジードメインを表すために使用する事前にデータが設定された Kubernetes ラベル です。

3. Pod を作成します。

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

手順

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

   $ cat team4.yaml
   apiVersion: v1
   kind: Pod
   metadata:
     name: security-s2
     labels:
       security: S2
   spec:
     containers:
     - name: security-s2
       image: docker.io/ocpqe/hello-pod

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

3. podAntiAffinity スタンザを使用して、requiredDuringSchedulingIgnoredDuringExecution パラメーターまたは preferredDuringSchedulingIgnoredDuringExecution パラメーターを設定します。

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

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

          podAntiAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                  - key: security
                    operator: In
                    values:
                    - S2
                topologyKey: kubernetes.io/hostname

   3. preferred (優先) ルールの場合、重みを 1-100 で指定します。
   4. operator を指定します。演算子は In、NotIn、Exists、または DoesNotExist にすることができます。たとえば、演算子 In を使用してラベルをノードで必要になるようにします。
4. topologyKey を指定します。これは、システムがトポロジードメインを表すために使用する事前にデータが設定された Kubernetes ラベル です。

5. Pod を作成します。

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

1. 通常どおり Operator をインストールします。
2. 必要に応じて、ノードがアフィニティーに適切に応答するようにラベル付けされていることを確認してください。

3. Operator Subscription オブジェクトを編集してアフィニティーを追加します。

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: openshift-custom-metrics-autoscaler-operator
     namespace: openshift-keda
   spec:
     name: my-package
     source: my-operators
     sourceNamespace: operator-registries
     config:
       affinity:
         podAntiAffinity: 1
           requiredDuringSchedulingIgnoredDuringExecution:
             podAffinityTerm:
               labelSelector:
                 matchExpressions:
                 - key: kubernetes.io/hostname
                   operator: In
                   values:
                   - ip-10-0-185-229.ec2.internal
               topologyKey: topology.kubernetes.io/zone
    ...

   1

   podAffinity または podAntiAffinity を追加します。

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 仕様では、nodeAffinity スタンザを使用して requiredDuringSchedulingIgnoredDuringExecution パラメーターを設定します。

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

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

      出力例

      spec:
        affinity:
          nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
              - matchExpressions:
                - key: e2e-az-name
                  operator: In
                  values:
                  - e2e-az1
                  - e2e-az2

3. Pod を作成します。

   $ oc create -f e2e-az2.yaml

1. oc label node コマンドを使ってラベルをノードに追加します。

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

2. Pod 仕様では、 nodeAffinity スタンザを使用して preferredDuringSchedulingIgnoredDuringExecution パラメーターを設定します。

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

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

      spec:
        affinity:
          nodeAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 1
              preference:
                matchExpressions:
                - key: e2e-az-name
                  operator: In
                  values:
                  - e2e-az3

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

3. Pod を作成します。

   $ oc create -f e2e-az3.yaml

1. 通常どおり Operator をインストールします。
2. 必要に応じて、ノードがアフィニティーに適切に応答するようにラベル付けされていることを確認してください。

3. Operator Subscription オブジェクトを編集してアフィニティーを追加します。

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: openshift-custom-metrics-autoscaler-operator
     namespace: openshift-keda
   spec:
     name: my-package
     source: my-operators
     sourceNamespace: operator-registries
     config:
       affinity: 1
         nodeAffinity:
           requiredDuringSchedulingIgnoredDuringExecution:
             nodeSelectorTerms:
             - matchExpressions:
               - key: kubernetes.io/hostname
                 operator: In
                 values:
                 - ip-10-0-185-229.ec2.internal
    ...

   1

   nodeAffinity を追加します。

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
   ...
   spec:
     taints:
     - effect: NoSchedule
       key: node-role.kubernetes.io/master
   ...

手順

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

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

   spec:
     tolerations:
     - key: "key1" 1
       value: "value1"
       operator: "Equal"
       effect: "NoExecute"
       tolerationSeconds: 3600 2

   1

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

   2

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

   以下に例を示します。

   Exists 演算子を含む 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
   ...
   spec:
     taints:
     - effect: NoSchedule
       key: node-role.kubernetes.io/master
   ...

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