ノード

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.1 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-registryDeploymentConfig オブジェクトの自動スケーリング。最初のデプロイメントでは 3 つの Pod が必要です。HPA オブジェクトは最小で 5 まで増加され、Pod 上の CPU 使用率が 75% に達すると、Pod を最大 7 まで増やします。

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

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

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

        apiVersion: autoscaling/v2beta2 1
        kind: HorizontalPodAutoscaler
        metadata:
          name: cpu-autoscale 2
          namespace: default
        spec:
          scaleTargetRef:
            apiVersion: apps/v1 3
            kind: ReplicaSet 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/v2beta2 API を使用します。

        2

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

        3

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

        • ReplicationController の場合は、 v1 を使用します。
        • DeploymentConfig の場合は、 apps.openshift.io/v1 を使用します。
        • Deployment、ReplicaSet、Statefulset オブジェクトの場合は、apps/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   ReplicationController/example   173m/500m       1         10        1          20m

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

   • 特定のメモリー値に合わせてスケーリングするには、既存の ReplicationController オブジェクトまたはレプリケーションコントローラーに対して、次のような HorizontalPodAutoscaler オブジェクトを作成します。

     出力例

     apiVersion: autoscaling/v2beta2 1
     kind: HorizontalPodAutoscaler
     metadata:
       name: hpa-resource-metrics-memory 2
       namespace: default
     spec:
       scaleTargetRef:
         apiVersion: v1 3
         kind: ReplicationController 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/v2beta2 API を使用します。

     2

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

     3

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

     • レプリケーションコントローラーについては、v1 を使用します。
     • DeploymentConfig オブジェクトについては、apps.openshift.io/v1 を使用します。

     4

     スケーリングするオブジェクトの種類 (ReplicationController または DeploymentConfig のいずれか) を指定します。

     5

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

     6

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

     7

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

     8

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

     9

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

     10

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

     11

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

     12

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

   • パーセンテージについてスケーリングするには、以下のように HorizontalPodAutoscaler オブジェクトを作成します。

     出力例

     apiVersion: autoscaling/v2beta2 1
     kind: HorizontalPodAutoscaler
     metadata:
       name: memory-autoscale 2
       namespace: default
     spec:
       scaleTargetRef:
         apiVersion: apps.openshift.io/v1 3
         kind: DeploymentConfig 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/v2beta2 API を使用します。

     2

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

     3

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

     • レプリケーションコントローラーについては、v1 を使用します。
     • DeploymentConfig オブジェクトについては、apps.openshift.io/v1 を使用します。

     4

     スケーリングするオブジェクトの種類 (ReplicationController または DeploymentConfig のいずれか) を指定します。

     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   ReplicationController/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:                   ReplicationController/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. ダイアログボックスで、Uninstall をクリックします。
5. オプション: 演算子に関連付けられているすべてのオペランドを削除するには、ダイアログボックスで、Delete all operand instances for this operatorチェックボックスをオンにします。
6. Uninstall をクリックします。

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

   1. VPA の変更用 Webhook 設定を削除します。

      $ oc delete mutatingwebhookconfigurations/vpa-webhook-config

   2. VPA カスタムリソースを一覧表示します。

      $ oc get verticalpodautoscalercheckpoints.autoscaling.k8s.io,verticalpodautoscalercontrollers.autoscaling.openshift.io,verticalpodautoscalers.autoscaling.k8s.io -o wide --all-namespaces

      出力例

      NAMESPACE      NAME                                                                       AGE
      my-project     verticalpodautoscalercheckpoint.autoscaling.k8s.io/vpa-recommender-httpd   5m46s
      
      NAMESPACE                           NAME                                                               AGE
      openshift-vertical-pod-autoscaler   verticalpodautoscalercontroller.autoscaling.openshift.io/default   11m
      
      NAMESPACE      NAME                                                       MODE   CPU   MEM       PROVIDED   AGE
      my-project     verticalpodautoscaler.autoscaling.k8s.io/vpa-recommender   Auto   93m   262144k   True       9m15s

   3. 一覧表示された VPA カスタムリソースを削除します。以下に例を示します。

      $ oc delete verticalpodautoscalercheckpoint.autoscaling.k8s.io/vpa-recommender-httpd -n my-project

      $ oc delete verticalpodautoscalercontroller.autoscaling.openshift.io/default -n openshift-vertical-pod-autoscaler

      $ oc delete verticalpodautoscaler.autoscaling.k8s.io/vpa-recommender -n my-project

   4. VPA カスタムリソース定義 (CRD) を一覧表示します。

      $ oc get crd

      出力例

      NAME                                                              CREATED AT
       ...
      verticalpodautoscalercheckpoints.autoscaling.k8s.io               2022-02-07T14:09:20Z
      verticalpodautoscalercontrollers.autoscaling.openshift.io         2022-02-07T14:09:20Z
      verticalpodautoscalers.autoscaling.k8s.io                         2022-02-07T14:09:20Z
       ...

   5. 一覧表示された VPA CRD を削除します。

      $ oc delete crd verticalpodautoscalercheckpoints.autoscaling.k8s.io verticalpodautoscalercontrollers.autoscaling.openshift.io verticalpodautoscalers.autoscaling.k8s.io

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

   6. VPA クラスターロールを一覧表示します。

      $ oc get clusterrole | grep openshift-vertical-pod-autoscaler

      出力例

      openshift-vertical-pod-autoscaler-6896f-admin        2022-02-02T15:29:55Z
      openshift-vertical-pod-autoscaler-6896f-edit         2022-02-02T15:29:55Z
      openshift-vertical-pod-autoscaler-6896f-view         2022-02-02T15:29:55Z

   7. 一覧表示された VPA クラスターロールを削除します。以下に例を示します。

      $ oc delete clusterrole openshift-vertical-pod-autoscaler-6896f-admin openshift-vertical-pod-autoscaler-6896f-edit openshift-vertical-pod-autoscaler-6896f-view

   8. 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. シークレットを削除します。

   $ 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

     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

     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.18.3+002a51f

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. 必要な述語と優先順位を使って policy.cfg という名前の JSON ファイルを作成します。

   スケジューラー JSON ファイルのサンプル

   {
   "kind" : "Policy",
   "apiVersion" : "v1",
   "predicates" : [ 1
           {"name" : "MaxGCEPDVolumeCount"},
           {"name" : "GeneralPredicates"},
           {"name" : "MaxAzureDiskVolumeCount"},
           {"name" : "MaxCSIVolumeCountPred"},
           {"name" : "CheckVolumeBinding"},
           {"name" : "MaxEBSVolumeCount"},
           {"name" : "MatchInterPodAffinity"},
           {"name" : "CheckNodeUnschedulable"},
           {"name" : "NoDiskConflict"},
           {"name" : "NoVolumeZoneConflict"},
           {"name" : "PodToleratesNodeTaints"}
           ],
   "priorities" : [ 2
           {"name" : "LeastRequestedPriority", "weight" : 1},
           {"name" : "BalancedResourceAllocation", "weight" : 1},
           {"name" : "ServiceSpreadingPriority", "weight" : 1},
           {"name" : "NodePreferAvoidPodsPriority", "weight" : 1},
           {"name" : "NodeAffinityPriority", "weight" : 1},
           {"name" : "TaintTolerationPriority", "weight" : 1},
           {"name" : "ImageLocalityPriority", "weight" : 1},
           {"name" : "SelectorSpreadPriority", "weight" : 1},
           {"name" : "InterPodAffinityPriority", "weight" : 1},
           {"name" : "EqualPriority", "weight" : 1}
           ]
   }

   1

   必要に応じて述語を追加します。

   2

   必要に応じて優先順位を追加します。

2. スケジューラー JSON ファイルに基づいて設定マップを作成します。

   $ oc create configmap -n openshift-config --from-file=policy.cfg <configmap-name> 1

   1

   設定マップの名前を入力します。

   以下に例を示します。

   $ oc create configmap -n openshift-config --from-file=policy.cfg scheduler-policy

   出力例

   configmap/scheduler-policy created

3. スケジューラー Operator カスタムリソースを編集して設定マップを追加します。

   $ oc patch Scheduler cluster --type='merge' -p '{"spec":{"policy":{"name":"<configmap-name>"}}}' --type=merge 1

   1

   設定マップの名前を指定します。

   以下に例を示します。

   $ oc patch Scheduler cluster --type='merge' -p '{"spec":{"policy":{"name":"scheduler-policy"}}}' --type=merge

   Scheduler 設定リソースに変更を加えた後に、openshift-kube-apiserver Pod の再デプロイを待機します。これには数分の時間がかかる場合があります。Pod が再デプロイされるまで、新規スケジューラーは有効になりません。

4. openshift-kube-scheduler namespace のスケジューラー Pod のログを表示して、スケジューラーポリシーが設定されていることを確認します。以下のコマンドは、スケジューラーによって登録される述語と優先順位をチェックします。

   $ oc logs <scheduler-pod> | grep predicates

   以下に例を示します。

   $ oc logs openshift-kube-scheduler-ip-10-0-141-29.ec2.internal | grep predicates

   出力例

   Creating scheduler with fit predicates 'map[MaxGCEPDVolumeCount:{} MaxAzureDiskVolumeCount:{} CheckNodeUnschedulable:{} NoDiskConflict:{} NoVolumeZoneConflict:{} GeneralPredicates:{} MaxCSIVolumeCountPred:{} CheckVolumeBinding:{} MaxEBSVolumeCount:{} MatchInterPodAffinity:{} PodToleratesNodeTaints:{}]' and priority functions 'map[InterPodAffinityPriority:{} LeastRequestedPriority:{} ServiceSpreadingPriority:{} ImageLocalityPriority:{} SelectorSpreadPriority:{} EqualPriority:{} BalancedResourceAllocation:{} NodePreferAvoidPodsPriority:{} NodeAffinityPriority:{} TaintTolerationPriority:{}]'

手順

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

   $ oc label node node1 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. Pod 仕様を tolerations スタンザを含めるように編集して、容認を Pod に追加します。

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

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

   1

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

   2

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

   以下に例を示します。

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

   spec:
   ....
     template:
   ....
       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 にスケジュールできます。

1. ノードからテイントを削除するには、以下を実行します。

   $ oc adm taint nodes <node-name> <key>-

   以下に例を示します。

   $ oc adm taint nodes ip-10-0-132-248.ec2.internal key1-

   出力例

   node/ip-10-0-132-248.ec2.internal untainted

2. Pod から容認を削除するには、容認を削除するための Pod 仕様を編集します。

   spec:
     tolerations:
     - key: "key2"
       operator: "Exists"
       effect: "NoExecute"
       tolerationSeconds: 3600

手順

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

     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

     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.18.3+002a51f

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. スケジューラー Operator CR を編集して、デフォルトのクラスタースコープのノードクラスターを追加します。

   $ oc edit scheduler cluster

   ノードセレクターを含むスケジューラー Operator CR のサンプル

   apiVersion: config.openshift.io/v1
   kind: Scheduler
   metadata:
     name: cluster
   ...
   
   spec:
     defaultNodeSelector: type=user-node,region=east 1
     mastersSchedulable: false
     policy:
       name: ""

   1

   適切な <key>:<value> ペアが設定されたノードセレクターを追加します。

   この変更を加えた後に、openshift-kube-apiserver プロジェクトの Pod の再デプロイを待機します。これには数分の時間がかかる場合があります。デフォルトのクラスター全体のノードセレクターは、Pod の再起動まで有効になりません。

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

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

     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 1

        1

        それぞれのラベルに <key> /<value> ペアを追加します。

        以下に例を示します。

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

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

        以下に例を示します。

        $ oc edit MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

        出力例

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

     3. 0 にスケールダウンし、ノードをスケールアップして、そのマシンセットに関連付けられたノードを再デプロイします。

        以下に例を示します。

        $ oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

        $ oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

     4. ノードの準備ができ、利用可能な状態になったら、oc get コマンドを使用してラベルがノードに追加されていることを確認します。

        $ oc get nodes -l <key>=<value>

        以下に例を示します。

        $ oc get nodes -l type=user-node

        出力例

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp   Ready    worker   61s   v1.18.3+002a51f

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

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

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

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

        $ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 type=user-node region=east

     2. oc get コマンドを使用して、ラベルがノードに追加されていることを確認します。

        $ oc get nodes -l <key>=<value>,<key>=<value>

        以下に例を示します。

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

        出力例

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49   Ready    worker   17m   v1.18.3+002a51f

1. namespace を作成するか、既存の namespace を編集して openshift.io/node-selector パラメーターを追加します。

   $ oc edit namespace <name>

   出力例

   apiVersion: v1
   kind: Namespace
   metadata:
     annotations:
       openshift.io/node-selector: "type=user-node,region=east" 1
       openshift.io/description: ""
       openshift.io/display-name: ""
       openshift.io/requester: kube:admin
       openshift.io/sa.scc.mcs: s0:c30,c5
       openshift.io/sa.scc.supplemental-groups: 1000880000/10000
       openshift.io/sa.scc.uid-range: 1000880000/10000
     creationTimestamp: "2021-05-10T12:35:04Z"
     labels:
       kubernetes.io/metadata.name: demo
     name: demo
     resourceVersion: "145537"
     uid: 3f8786e3-1fcb-42e3-a0e3-e2ac54d15001
   spec:
     finalizers:
     - kubernetes

   1

   適切な <key>:<value> ペアを持つ openshift.io/node-selector を追加します。

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

   • 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 ci-ln-l8nry52-f76d1-hl7m7-worker-c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

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

        以下に例を示します。

        $ oc edit MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

        出力例

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

     3. そのマシンセットに関連付けられたノードを再デプロイします。

        以下に例を示します。

        $ oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

        $ oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

     4. ノードの準備ができ、利用可能な状態になったら、oc get コマンドを使用してラベルがノードに追加されていることを確認します。

        $ oc get nodes -l <key>=<value>

        以下に例を示します。

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

        出力例

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp   Ready    worker   61s   v1.18.3+002a51f

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

     1. Node オブジェクトを編集してラベルを追加します。

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

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

        $ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-c-tgq49 type=user-node region=east

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

        $ oc get nodes -l <key>=<value>

        以下に例を示します。

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

        出力例

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49   Ready    worker   17m   v1.18.3+002a51f

手順

1. Pod 仕様を作成し、Pod トポロジーの分散制約を指定します。

   pod-spec.yaml ファイルの例

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-pod
     labels:
       foo: bar
   spec:
     topologySpreadConstraints:
     - maxSkew: 1 1
       topologyKey: topology.kubernetes.io/zone 2
       whenUnsatisfiable: DoNotSchedule 3
       labelSelector: 4
         matchLabels:
           foo: bar 5
     containers:
     - image: "docker.io/ocpqe/hello-pod"
       name: hello-pod

   1

   任意の 2 つのトポロジードメイン間の Pod 数の最大差。デフォルトは 1 で、0 の値を指定することはできません。

   2

   ノードラベルのキー。このキーと同じ値を持つノードは同じトポロジーにあると見なされます。

   3

   分散制約を満たさない場合に Pod を処理する方法です。デフォルトは DoNotSchedule であり、これはスケジューラーに Pod をスケジュールしないように指示します。ScheduleAnyway に設定して Pod を依然としてスケジュールできますが、スケジューラーはクラスターがさらに不均衡な状態になるのを防ぐためにスキューの適用を優先します。

   4

   制約を満たすために、分散される際に、このラベルセレクターに一致する Pod はグループとしてカウントされ、認識されます。ラベルセレクターを指定してください。指定しないと、Pod が一致しません。

   5

   今後適切にカウントされるようにするには、この Pod 仕様がこのラベルセレクターに一致するようにラベルを設定していることも確認してください。

2. Pod を作成します。

   $ oc create -f pod-spec.yaml

手順

1. カスタムスケジューラーのデプロイメントリソースを含むファイルを作成します。

   custom-scheduler.yaml ファイルの例

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: custom-scheduler
     namespace: kube-system 1
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: custom-scheduler-as-kube-scheduler
   subjects:
   - kind: ServiceAccount
     name: custom-scheduler
     namespace: kube-system 2
   roleRef:
     kind: ClusterRole
     name: system:kube-scheduler
     apiGroup: rbac.authorization.k8s.io
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: custom-scheduler-as-volume-scheduler
   subjects:
   - kind: ServiceAccount
     name: custom-scheduler
     namespace: kube-system 3
   roleRef:
     kind: ClusterRole
     name: system:volume-scheduler
     apiGroup: rbac.authorization.k8s.io
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     labels:
       component: scheduler
       tier: control-plane
     name: custom-scheduler
     namespace: kube-system 4
   spec:
     selector:
       matchLabels:
         component: scheduler
         tier: control-plane
     replicas: 1
     template:
       metadata:
         labels:
           component: scheduler
           tier: control-plane
           version: second
       spec:
         serviceAccountName: custom-scheduler
         containers:
         - command:
           - /usr/local/bin/kube-scheduler
           - --address=0.0.0.0
           - --leader-elect=false
           - --scheduler-name=custom-scheduler 5
           image: "<namespace>/<image_name>:<tag>" 6
           livenessProbe:
             httpGet:
               path: /healthz
               port: 10251
             initialDelaySeconds: 15
           name: kube-second-scheduler
           readinessProbe:
             httpGet:
               path: /healthz
               port: 10251
           resources:
             requests:
               cpu: '0.1'
           securityContext:
             privileged: false
           volumeMounts: []
         hostNetwork: false
         hostPID: false
         volumes: []

   1 2 3 4

   この手順では、kube-system namespace を使用しますが、お好みの namespace を使用することができます。

   5

   カスタムスケジューラーのコマンドには、異なる引数が必要な場合があります。たとえば、--config 引数を使用して、設定をマウントされたボリュームとして渡すことができます。

   6

   カスタムスケジューラー用に作成したコンテナーイメージを指定します。

2. クラスター内にデプロイメントリソースを作成します。

   $ oc create -f custom-scheduler.yaml

手順

1. クラスターがロールベースアクセス制御 (RBAC) を使用する場合は、カスタムスケジューラー名を system:kube-scheduler クラスターロールに追加します。

   1. system:kube-scheduler クラスターロールを編集します。

      $ oc edit clusterrole system:kube-scheduler

   2. カスタムスケジューラーの名前を、leases および endpoints リソースの resourceNames 一覧に追加します。

      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRole
      metadata:
        annotations:
          rbac.authorization.kubernetes.io/autoupdate: "true"
        creationTimestamp: "2021-07-07T10:19:14Z"
        labels:
          kubernetes.io/bootstrapping: rbac-defaults
        name: system:kube-scheduler
        resourceVersion: "125"
        uid: 53896c70-b332-420a-b2a4-f72c822313f2
      rules:
      ...
      - apiGroups:
        - coordination.k8s.io
        resources:
        - leases
        verbs:
        - create
      - apiGroups:
        - coordination.k8s.io
        resourceNames:
        - kube-scheduler
        - custom-scheduler 1
        resources:
        - leases
        verbs:
        - get
        - update
      - apiGroups:
        - ""
        resources:
        - endpoints
        verbs:
        - create
      - apiGroups:
        - ""
        resourceNames:
        - kube-scheduler
        - custom-scheduler 2
        resources:
        - endpoints
        verbs:
        - get
        - update
      ...

      1 2

      この例では、custom-scheduler をカスタムスケジューラー名として使用します。

2. Pod 設定を作成し、schedulerName パラメーターでカスタムスケジューラーの名前を指定します。

   custom-scheduler-example.yaml ファイルの例

   apiVersion: v1
   kind: Pod
   metadata:
     name: custom-scheduler-example
     labels:
       name: custom-scheduler-example
   spec:
     schedulerName: custom-scheduler 1
     containers:
     - name: pod-with-second-annotation-container
       image: docker.io/ocpqe/hello-pod

   1

   使用するカスタムスケジューラーの名前です。この例では custom-scheduler になります。スケジューラー名が指定されていない場合、Pod はデフォルトのスケジューラーを使用して自動的にスケジュールされます。

3. Pod を作成します。

   $ oc create -f custom-scheduler-example.yaml

検証

1. 以下のコマンドを入力し、Pod が作成されたことを確認します。

   $ oc get pod custom-scheduler-example

   custom-scheduler-example Pod が出力に表示されます。

   NAME                       READY     STATUS    RESTARTS   AGE
   custom-scheduler-example   1/1       Running   0          4m

2. 以下のコマンドを入力し、カスタムスケジューラーが Pod をスケジュールしたことを確認します。

   $ oc describe pod custom-scheduler-example

   以下の切り捨てられた出力に示されるように、スケジューラー custom-scheduler が一覧表示されます。

   Events:
     Type    Reason          Age        From                                               Message
     ----    ------          ----       ----                                               -------
     Normal  Scheduled       <unknown>  custom-scheduler                                   Successfully assigned default/custom-scheduler-example to <node_name>

手順

1. OpenShift Container Platform Web コンソールにログインします。

2. Kube Descheduler Operator に必要な namespace を作成します。

   1. Administration → Namespaces に移動し、Create Namespace をクリックします。
   2. Name フィールドに openshift-kube-descheduler-operator を入力し、Create をクリックします。

3. Kube Descheduler Operator をインストールします。

   1. Operators → OperatorHub に移動します。
   2. Kube Descheduler Operator をフィルターボックスに入力します。
   3. Kube Descheduler Operator を選択し、Install をクリックします。
   4. Install Operator ページで、A specific namespace on the cluster を選択します。ドロップダウンメニューから openshift-kube-descheduler-operator を選択します。
   5. Update Channel および Approval Strategy の値を必要な値に調整します。
   6. Install をクリックします。

4. Descheduler インスタンスを作成します。

   1. Operators → Installed Operators ページから、 Kube Descheduler Operator をクリックします。
   2. Kube Descheduler タブを選択し、Create KubeDescheduler をクリックします。

   3. 必要に応じて設定を編集します。

      1. Profiles セクションを展開し、1 つ以上のプロファイルを選択して有効にします。AffinityAndTaints プロファイルはデフォルトで有効になっています。Add Profile をクリックして、追加のプロファイルを選択します。
      2. オプション: Descheduling Interval Seconds フィールドを使用して、Descheduler の実行間の秒数を変更します。デフォルトは 3600 秒です。
   4. Create をクリックします。

手順

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

   $ oc edit kubedeschedulers.operator.openshift.io cluster -n openshift-kube-descheduler-operator

2. spec.profiles セクションに 1 つ以上のプロファイルを指定します。

   apiVersion: operator.openshift.io/v1beta1
   kind: KubeDescheduler
   metadata:
     name: cluster
     namespace: openshift-kube-descheduler-operator
   spec:
     deschedulingIntervalSeconds: 3600
     logLevel: Normal
     managementState: Managed
     operatorLogLevel: Normal
     profiles:
     - AffinityAndTaints       1
     - TopologyAndDuplicates   2
     - LifecycleAndUtilization 3

   1

   Pod 間の非アフィニティー、ノードアフィニティー、およびノードのテイントに違反する Pod をエビクトする AffinityAndTaints プロファイルを有効にします。

   2

   ノード間で同様の Pod または同じトポロジードメインの Pod を均等に分散できるように Pod をエビクトする TopologyAndDuplicates プロファイルを有効にします。

   3

   長時間実行される Pod をエビクトし、ノード間のリソース使用状況のバランスを取る、LifecycleAndUtilization プロファイルを有効にします。

   複数のプロファイルを有効にすることができますが、プロファイルを指定する順番は重要ではありません。

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

手順

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

   $ oc edit kubedeschedulers.operator.openshift.io cluster -n openshift-kube-descheduler-operator

2. deschedulingIntervalSeconds フィールドを必要な値に更新します。

   apiVersion: operator.openshift.io/v1beta1
   kind: KubeDescheduler
   metadata:
     name: cluster
     namespace: openshift-kube-descheduler-operator
   spec:
     deschedulingIntervalSeconds: 3600 1
   ...

   1

   Descheduler の実行間隔を秒単位で設定します。このフィールドの値 0 は Descheduler を一度実行し、終了します。

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

手順

1. OpenShift Container Platform Web コンソールにログインします。

2. Descheduler インスタンスを削除します。

   1. Operators → Installed Operators ページから、Kube Descheduler Operator をクリックします。
   2. Kube Descheduler タブを選択します。
   3. cluster クラスターの横にある Options メニュー をクリックし、 Delete KubeDescheduler を選択します。
   4. 確認ダイアログで Delete をクリックします。

3. Kube Descheduler Operator をアンインストールします。

   1. Operators → Installed Operators に移動します。
   2. Kube Descheduler Operator エントリーの横にある Options メニュー をクリックし、Uninstall Operator を選択します。
   3. 確認ダイアログで、Uninstall をクリックします。

4. openshift-kube-descheduler-operator namespace を削除します。

   1. Administration → Namespaces に移動します。
   2. openshift-kube-descheduler-operator をフィルターボックスに入力します。
   3. openshift-kube-descheduler-operator エントリーの横にある Options メニュー をクリックし、Delete Namespace を選択します。
   4. 確認ダイアログで openshift-kube-descheduler-operator を入力し、Delete をクリックします。

5. KubeDescheduler CRD を削除します。

   1. Administration → Custom Resource Definitions に移動します。
   2. KubeDescheduler をフィルターボックスに入力します。
   3. KubeDescheduler エントリーの横にある Options メニュー をクリックし、Delete CustomResourceDefinition を選択します。
   4. 確認ダイアログで Delete をクリックします。

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

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

   1

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

   2

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

   3

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

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

   $ oc create -f daemonset.yaml

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

   1. daemonset Pod を検索します。

      $ oc get pods

      出力例

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

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

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

      出力例

      Node:        openshift-node01.hostname.com/10.14.20.134

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

      出力例

      Node:        openshift-node02.hostname.com/10.14.20.137

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

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

   1. オプションで、ジョブが並列で実行される Pod のレプリカ数を指定します。デフォルトは 1 に設定されます。

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

   2. オプションで、ジョブを完了 (completed) としてマークするために必要な Pod の正常な完了数を指定します。

      • 非並列ジョブの場合は、未設定のままにします。未設定の場合は、デフォルトの 1 に設定されます。
      • 固定の完了数を持つ並列ジョブの場合、完了の数を指定します。
      • ワークキューのある並列ジョブでは、未設定のままにします。未設定の場合、デフォルトは parallelism 値に設定されます。
   3. オプションで、ジョブを実行できる最長期間を指定します。
   4. オプションで、ジョブの再試行回数を指定します。このフィールドは、デフォルトでは 6 に設定されています。
   5. コントローラーが作成する Pod のテンプレートを指定します。

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

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

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

        OpenShift Container Platform が失敗したコンテナーについて再起動ポリシーを使用する方法の詳細は、Kubernetes ドキュメントの State の例 を参照してください。

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

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

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

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

   1 1

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

   2 2

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

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

   3 3

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

   4 4

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

   5 5

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

   6 6

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

   7

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

   8

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

   9

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

   注記

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

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

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