ノード

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. 以下のいずれかの手順を実行します。

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

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

     1

     DeploymentConfig オブジェクトの名前を指定します。オブジェクトが存在する必要があります。

     2

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

     3

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

     4

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

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

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

     1

     レプリケーションコントローラーの名前を指定します。オブジェクトが存在する必要があります。

     2

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

     3

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

     4

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

   • 特定の CPU 値についてスケーリングするには、既存の DeploymentConfig オブジェクトまたはレプリケーションコントローラーについて以下のような YAML ファイルを作成します。

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

        apiVersion: autoscaling/v2beta2 1
        kind: HorizontalPodAutoscaler
        metadata:
          name: cpu-autoscale 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: cpu 9
              target:
                type: AverageValue 10
                averageValue: 500m 11

        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

        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. image-registry デプロイメントの現在の状態を表示します。

   $ oc get dc image-registry

   出力例

   NAME             REVISION   DESIRED   CURRENT   TRIGGERED BY
   image-registry   1          3         3         config

2. image-registry DeploymentConfig オブジェクトの自動スケーリングを実行します。

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

   出力例

   horizontalpodautoscaler.autoscaling/image-registry autoscaled

3. デプロイメントの新しい状態を表示します。

   $ oc get dc image-registry

   デプロイメントには 5 つの Pod があります。

   出力例

   NAME             REVISION   DESIRED   CURRENT   TRIGGERED BY
   image-registry   1          5         5         config

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

   • 特定のメモリー値についてスケーリングするには、既存の DeploymentConfig オブジェクトまたはレプリケーションコントローラーについて以下のような 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 をクリックします。

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

   $ oc delete secret <secret_name>

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

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

   $ oc annotate service <service_name> service.alpha.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

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

手順

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:
             beta.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. 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:
   ....
     template:
   ....
       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:
             beta.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. プロジェクトを作成するか、または既存プロジェクトを編集して openshift.io/node-selector パラメーターを追加します。

   $ oc edit project <name>

   apiVersion: project.openshift.io/v1
   kind: Project
   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 label MachineSet abc612-msrtw-worker-us-east-1c type=user-node region=east

        以下に例を示します。

        $ 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 <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. カスタムスケジューラーのデプロイメントリソースを含むファイルを作成します。

   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: apps/v1
   kind: Deployment
   metadata:
     labels:
       component: scheduler
       tier: control-plane
     name: custom-scheduler
     namespace: kube-system 3
   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 4
           image: "<namespace>/<image_name>:<tag>" 5
           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

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

   4

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

   5

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

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. 必要に応じて設定を編集し、Create をクリックします。

手順

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

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

2. spec.strategies セクションで 1 つ以上のストラテジーを指定します。

   apiVersion: operator.openshift.io/v1beta1
   kind: KubeDescheduler
   metadata:
     name: cluster
     namespace: openshift-kube-descheduler-operator
   spec:
     deschedulingIntervalSeconds: 3600
     strategies:
       - name: "LowNodeUtilization" 1
         params:
          - name: "CPUThreshold"
            value: "10"
          - name: "MemoryThreshold"
            value: "20"
          - name: "PodsThreshold"
            value: "30"
          - name: "MemoryTargetThreshold"
            value: "40"
          - name: "CPUTargetThreshold"
            value: "50"
          - name: "PodsTargetThreshold"
            value: "60"
          - name: "NumberOfNodes"
            value: "3"
       - name: "RemoveDuplicates" 2
       - name: "RemovePodsHavingTooManyRestarts" 3
         params:
          - name: "PodRestartThreshold"
            value: "10"
          - name: "IncludingInitContainers"
            value: "false"

   1

   LowNodeUtilization ストラテジーは、オプションで設定可能な CPUThreshold および MemoryThreshold などの追加のパラメーターを提供します。

   2

   RemoveDuplicates、RemovePodsViolatingInterPodAntiAffinity、RemovePodsViolatingNodeAffinity、および RemovePodsViolatingNodeTaints ストラテジーには、設定する追加のパラメーターがありません。

   3

   RemovePodsHavingTooManyRestarts ストラテジーでは、PodRestartThreshold パラメーターを設定する必要があります。また、オプションの IncludingInitContainers パラメーターを指定します。

   複数のストラテジーを有効にすることができ、ストラテジーを指定する順番は重要ではありません。

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

手順

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

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

2. 必要に応じて追加の設定を行います。

   apiVersion: operator.openshift.io/v1beta1
   kind: KubeDescheduler
   metadata:
     name: cluster
     namespace: openshift-kube-descheduler-operator
   spec:
     deschedulingIntervalSeconds: 3600 1
     flags:
     - --dry-run 2
     image: quay.io/openshift/origin-descheduler:4.5 3
   ...

   1

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

   2

   Descheduler Pod に追加する 1 つ以上のフラグを設定します。このフラグは、バイナリーに渡すことのできる形式である必要があります。

   3

   デプロイする 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 1

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

   2 2 2

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

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

   3 3 3

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

   4 4 4

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

   5 5 5

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

   6 6 6

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

   7

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

   8

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

   9

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

   注記

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

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

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

手順

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

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

      $ oc adm cordon <node1>

      出力例

      node/<node1> cordoned

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

      $ oc get node <node1>

      出力例

      NAME        STATUS                        ROLES     AGE       VERSION
      <node1>     NotReady,SchedulingDisabled   worker    1d        v1.18.3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   $ oc adm uncordon <node1>

手順

1. schedulers.config.openshift.io リソースを編集します。

   $ oc edit schedulers.config.openshift.io cluster

2. mastersSchedulable フィールドを設定します。

   apiVersion: config.openshift.io/v1
   kind: Scheduler
   metadata:
     creationTimestamp: "2019-09-10T03:04:05Z"
     generation: 1
     name: cluster
     resourceVersion: "433"
     selfLink: /apis/config.openshift.io/v1/schedulers/cluster
     uid: a636d30a-d377-11e9-88d4-0a60097bee62
   spec:
     mastersSchedulable: false 1
     policy:
       name: ""
   status: {}

   1

   マスターノードがスケジュール対象 (Schedulable) になるのを許可する場合は true に設定し、マスターノードがスケジュール対象となるのを拒否するは、false に設定します。

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

手順

1. OpenShift Container Platform クラスターの既存の MachineConfig を一覧表示し、マシン設定にラベルを付ける方法を判別します。

   $ oc get MachineConfig

   出力例

   NAME                                                        GENERATEDBYCONTROLLER                      IGNITIONVERSION   CREATED
   00-master                                                   577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m
   00-worker                                                   577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m
   01-master-container-runtime                                 577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m
   01-master-kubelet                                           577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m
   01-worker-container-runtime                                 577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m
   01-worker-kubelet                                           577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m
   99-master-1131169f-dae9-11e9-b5dd-12a845e8ffd8-registries   577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m
   99-master-ssh                                                                                          2.2.0             30m
   99-worker-114e8ac7-dae9-11e9-b5dd-12a845e8ffd8-registries   577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m
   99-worker-ssh                                                                                          2.2.0             30m
   rendered-master-b3729e5f6124ca3678188071343115d0            577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m
   rendered-worker-18ff9506c718be1e8bd0a066850065b7            577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             30m

2. カーネル引数を識別する MachineConfig オブジェクトファイルを作成します (例: 05-worker-kernelarg-selinuxpermissive.yaml)。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker1
     name: 05-worker-kernelarg-selinuxpermissive2
   spec:
     config:
       ignition:
         version: 2.2.0
     kernelArguments:
       - enforcing=03

   1

   新しいカーネル引数をワーカーノードのみに適用します。

   2

   マシン設定 (05) 内の適切な場所を特定するための名前が指定されます (SELinux permissive モードを設定するためにカーネル引数を追加します)。

   3

   正確なカーネル引数を enforcing=0 として特定します。

3. 新規のマシン設定を作成します。

   $ oc create -f 05-worker-kernelarg-selinuxpermissive.yaml

4. マシン設定で新規の追加内容を確認します。

   $ oc get MachineConfig

   出力例

   NAME                                                        GENERATEDBYCONTROLLER                      IGNITIONVERSION   CREATED
   00-master                                                   577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m
   00-worker                                                   577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m
   01-master-container-runtime                                 577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m
   01-master-kubelet                                           577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m
   01-worker-container-runtime                                 577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m
   01-worker-kubelet                                           577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m
   
   05-worker-kernelarg-selinuxpermissive                                                                  3.1.0             105s
   
   99-master-1131169f-dae9-11e9-b5dd-12a845e8ffd8-registries   577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m
   99-master-ssh                                                                                          2.2.0             30m
   99-worker-114e8ac7-dae9-11e9-b5dd-12a845e8ffd8-registries   577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m
   99-worker-ssh                                                                                          2.2.0             31m
   rendered-master-b3729e5f6124ca3678188071343115d0            577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m
   rendered-worker-18ff9506c718be1e8bd0a066850065b7            577c2d527b09cd7a481a162c50592139caa15e20   2.2.0             31m

5. ノードを確認します。

   $ oc get nodes

   出力例

   NAME                           STATUS                     ROLES    AGE   VERSION
   ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.18.3
   ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.18.3
   ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.18.3
   ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.18.3
   ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.18.3
   ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.18.3

   変更が適用されているため、各ワーカーノードのスケジューリングが無効にされていることを確認できます。

6. ワーカーノードのいずれかに移動し、カーネルコマンドライン引数 (ホストの /proc/cmdline 内) を一覧表示して、カーネル引数が機能することを確認します。

   $ oc debug node/ip-10-0-141-105.ec2.internal

   出力例

   Starting pod/ip-10-0-141-105ec2internal-debug ...
   To use host binaries, run `chroot /host`
   
   sh-4.2# cat /host/proc/cmdline
   BOOT_IMAGE=/ostree/rhcos-... console=tty0 console=ttyS0,115200n8
   rootflags=defaults,prjquota rw root=UUID=fd0... ostree=/ostree/boot.0/rhcos/16...
   coreos.oem.id=qemu coreos.oem.id=ec2 ignition.platform.id=ec2 enforcing=0
   
   sh-4.2# exit

   enforcing=0 引数が他のカーネル引数に追加されていることを確認できるはずです。

手順

1. 設定する必要のあるノードタイプの静的な CRD、Machine Config Pool に関連付けられたラベルを取得します。以下のいずれかの手順を実行します。

   1. 必要なマシン設定プールの現在のラベルをチェックします。

      以下に例を示します。

      $  oc get machineconfigpool  --show-labels

      出力例

      NAME      CONFIG                                             UPDATED   UPDATING   DEGRADED   LABELS
      master    rendered-master-e05b81f5ca4db1d249a1bf32f9ec24fd   True      False      False      operator.machineconfiguration.openshift.io/required-for-upgrade=
      worker    rendered-worker-f50e78e1bc06d8e82327763145bfcf62   True      False      False

   2. 必要なマシン設定プールにカスタムラベルを追加します。

      以下に例を示します。

      $ oc label machineconfigpool worker custom-kubelet=enabled

2. 設定の変更用に kubeletconfig カスタムリソース (CR) を作成します。

   以下に例を示します。

   custom-config CR の設定例

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: custom-config 1
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: enabled 2
     kubeletConfig: 3
       podsPerCore: 10
       maxPods: 250
       systemReserved:
         cpu: 2000m
         memory: 1Gi

   1

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

   2

   設定変更を適用するラベルを指定します。これは、マシン設定プールに追加するラベルになります。

   3

   変更する必要のある新しい値を指定します。

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

   $ oc create -f <file-name>

   以下は例になります。

   $ oc create -f master-kube-config.yaml

前提条件

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

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

      $ oc describe machineconfigpool <name>

      以下に例を示します。

      $ oc describe machineconfigpool worker

      出力例

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        creationTimestamp: 2019-02-08T14:52:39Z
        generation: 1
        labels:
          custom-kubelet: small-pods 1

      1

      ラベルが追加されると、labels の下に表示されます。

   2. ラベルが存在しない場合は、キー/値のペアを追加します。

      $ oc label machineconfigpool worker custom-kubelet=small-pods

手順

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

   max-pods CR の設定例

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: set-max-pods 1
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: small-pods 2
     kubeletConfig:
       podsPerCore: 10 3
       maxPods: 250 4

   1

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

   2

   設定の変更を適用するラベルを指定します。

   3

   ノードがプロセッサーコアの数に基づいて実行できる Pod の数を指定します。

   4

   ノードのプロパティーにかかわらず、ノードが実行できる Pod 数を固定値に指定します。

   注記

   podsPerCore を 0 に設定すると、この制限が無効になります。

   上記の例では、podsPerCore のデフォルト値は 10 であり、maxPods のデフォルト値は 250 です。つまり、ノードのコア数が 25 以上でない限り、デフォルトにより podsPerCore が制限要素になります。

2. 変更が適用されるかどうかを確認するために、MachineConfigPool CRD を一覧表示します。変更が Machine Config Controller によって取得されると、UPDATING 列で True と報告されます。

   $ oc get machineconfigpools

   出力例

   NAME     CONFIG                        UPDATED   UPDATING   DEGRADED
   master   master-9cc2c72f205e103bb534   False     False      False
   worker   worker-8cecd1236b33ee3f8a5e   False     True       False

   変更が完了すると、UPDATED 列で True と報告されます。

   $ oc get machineconfigpools

   出力例

   NAME     CONFIG                        UPDATED   UPDATING   DEGRADED
   master   master-9cc2c72f205e103bb534   False     True       False
   worker   worker-8cecd1236b33ee3f8a5e   True      False      False

手順

1. 以下を実行します。

   $ oc get Tuned/default -o yaml -n openshift-cluster-node-tuning-operator

1. ノードの仕様を編集して Pod の非アフィニティーを設定します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: with-pod-antiaffinity
   spec:
     affinity:
       podAntiAffinity: 1
         preferredDuringSchedulingIgnoredDuringExecution: 2
         - weight: 100 3
           podAffinityTerm:
             labelSelector:
               matchExpressions:
               - key: registry 4
                 operator: In 5
                 values:
                 - default
             topologyKey: kubernetes.io/hostname

   1

   Pod の非アフィニティーを設定するためのスタンザです。

   2

   preferred (優先) ルールを定義します。

   3

   preferred (優先) ルールの重みを指定します。最も高い重みを持つノードが優先されます。

   4

   非アフィニティールールが適用される時を決定する Pod ラベルの説明です。ラベルのキーおよび値を指定します。

   5

   演算子は、既存 Pod のラベルと新規 Pod の仕様の matchExpression パラメーターの値のセットの間の関係を表します。これには In、NotIn、Exists、または DoesNotExist のいずれかを使用できます。

   この例では、コンテナーイメージレジストリー Pod に registry=default のラベルがあることを想定しています。Pod の非アフィニティーでは任意の Kubernetes の一致式を使用できます。

2. スケジューリングポリシーファイルで、MatchInterPodAffinity スケジューラー述語を有効にします。

1. 1 つ以上の Pod で現在実行されているイメージの一覧
2. ホストで利用可能なイメージの一覧

前提条件

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

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

      $ oc describe machineconfigpool <name>

      以下に例を示します。

      $ oc describe machineconfigpool worker

      出力例

      Name:         worker
      Namespace:
      Labels:       custom-kubelet=small-pods 1

      1

      ラベルが追加されると、Labels の下に表示されます。

   2. ラベルが存在しない場合は、キー/値のペアを追加します。

      $ oc label machineconfigpool worker custom-kubelet=small-pods

手順

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

   コンテナーのガベージコレクション CR のサンプル設定:

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: worker-kubeconfig 1
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: small-pods 2
     kubeletConfig:
       evictionSoft: 3
         memory.available: "500Mi" 4
         nodefs.available: "10%"
         nodefs.inodesFree: "5%"
         imagefs.available: "15%"
         imagefs.inodesFree: "10%"
       evictionSoftGracePeriod:  5
         memory.available: "1m30s"
         nodefs.available: "1m30s"
         nodefs.inodesFree: "1m30s"
         imagefs.available: "1m30s"
         imagefs.inodesFree: "1m30s"
       evictionHard:
         memory.available: "200Mi"
         nodefs.available: "5%"
         nodefs.inodesFree: "4%"
         imagefs.available: "10%"
         imagefs.inodesFree: "5%"
       evictionPressureTransitionPeriod: 0s 6
       imageMinimumGCAge: 5m 7
       imageGCHighThresholdPercent: 80 8
       imageGCLowThresholdPercent: 75 9

   1

   オブジェクトの名前。

   2

   セレクターラベル。

   3

   エビクションのタイプ: EvictionSoft および EvictionHard。

   4

   特定のエビクショントリガーシグナルに基づくエビクションのしきい値。

   5

   ソフトエビクションの猶予期間。このパラメーターは、eviction-hard には適用されません。

   6

   エビクションの不足状態から移行するまでの待機時間

   7

   ガベージコレクションによって削除されるまでの未使用のイメージの有効期間。

   8

   イメージのガべージコレクションをトリガーするディスク使用量のパーセント (整数で表される) です。

   9

   イメージのガべージコレクションが解放しようとするディスク使用量のパーセント (整数で表される) です。

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

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

   以下に例を示します。

   $ oc create -f gc-container.yaml

   出力例

   kubeletconfig.machineconfiguration.openshift.io/gc-container created

3. ガベージコレクションがアクティブであることを確認します。カスタムリソースで指定した Machine Config Pool では、変更が完全に実行されるまで UPDATING が 'true` と表示されます。

   $ oc get machineconfigpool

   出力例

   NAME     CONFIG                                   UPDATED   UPDATING
   master   rendered-master-546383f80705bd5aeaba93   True      False
   worker   rendered-worker-b4c51bb33ccaae6fc4a6a5   False     True

前提条件

1. system-reserved 設定の値を判別しやすくするために、ノード要約 API を使用してノードについてのリソースの使用をイントロスペクトできます。ノードについて以下のコマンドを入力します。

   $ oc get --raw /api/v1/nodes/<node>/proxy/stats/summary

   たとえば、cluster.node22 ノードからリソースにアクセスするには、以下の手順を入力できます。

   $ oc get --raw /api/v1/nodes/cluster.node22/proxy/stats/summary

   出力例

   {
       "node": {
           "nodeName": "cluster.node22",
           "systemContainers": [
               {
                   "cpu": {
                       "usageCoreNanoSeconds": 929684480915,
                       "usageNanoCores": 190998084
                   },
                   "memory": {
                       "rssBytes": 176726016,
                       "usageBytes": 1397895168,
                       "workingSetBytes": 1050509312
                   },
                   "name": "kubelet"
               },
               {
                   "cpu": {
                       "usageCoreNanoSeconds": 128521955903,
                       "usageNanoCores": 5928600
                   },
                   "memory": {
                       "rssBytes": 35958784,
                       "usageBytes": 129671168,
                       "workingSetBytes": 102416384
                   },
                   "name": "runtime"
               }
           ]
       }
   }

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

   1. Machine Config Pool を表示します。

      $ oc describe machineconfigpool <name>

      以下に例を示します。

      $ oc describe machineconfigpool worker

      出力例

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        creationTimestamp: 2019-02-08T14:52:39Z
        generation: 1
        labels:
          custom-kubelet: small-pods 1

      1

      ラベルが追加されると、labels の下に表示されます。

   2. ラベルが存在しない場合は、キー/値のペアを追加します。

      $ oc label machineconfigpool worker custom-kubelet=small-pods