6.3. ノードの管理

OpenShift Container Platform は、KubeletConfig カスタムリソース (CR) を使用してノードの設定を管理します。KubeletConfig オブジェクトのインスタンスを作成すると、マネージドのマシン設定がノードの設定を上書きするために作成されます。

注記

リモートマシンにログインして設定を変更する方法はサポートされていません。

6.3.1. ノードの変更

クラスターまたはマシンプールの設定を変更するには、カスタムリソース定義 (CRD) または kubeletConfig オブジェクトを作成する必要があります。OpenShift Container Platform は、Machine Config Controller を使用して、変更をクラスターに適用するために CRD を使用して導入された変更を監視します。

注記

kubeletConfig オブジェクトのフィールドは、アップストリームの Kubernetes から kubelet に直接渡されるため、これらのフィールドの検証は kubelet 自体によって直接処理されます。これらのフィールドの有効な値については、関連する Kubernetes のドキュメントを参照してください。kubeletConfig オブジェクトの値が無効な場合、クラスターノードが使用できなくなる可能性があります。

手順

  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

ほとんどの Kubelet 設定オプション はユーザーが設定できます。以下のオプションは上書きが許可されていません。

  • CgroupDriver
  • ClusterDNS
  • ClusterDomain
  • StaticPodPath
注記

単一ノードに 50 を超えるイメージが含まれている場合、Pod のスケジューリングがノード間で不均衡になる可能性があります。これは、ノード上のイメージのリストがデフォルトで 50 に短縮されているためです。KubeletConfig オブジェクトを編集し、nodeStatusMaxImages の値を -1 に設定して、イメージの制限を無効にすることができます。

6.3.2. スケジュール対象としてのコントロールプレーンノードの設定

コントロールプレーンノードをスケジュール可能に設定できます。つまり、新しい Pod をマスターノードに配置できます。デフォルトでは、コントロールプレーンノードはスケジュール対象ではありません。

マスターをスケジュール対象 (Schedulable) に設定できますが、ワーカーノードを保持する必要があります。

注記

ワーカーノードのない OpenShift Container Platform をベアメタルクラスターにデプロイできます。この場合、コントロールプレーンノードはデフォルトでスケジュール対象としてマークされます。

mastersSchedulable フィールドを設定することで、コントロールプレーンノードをスケジュール対象として許可または禁止できます。

重要

コントロールプレーンノードをデフォルトのスケジュール不可からスケジュール可に設定するには、追加のサブスクリプションが必要です。これは、コントロールプレーンノードがワーカーノードになるためです。

手順

  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
    status: {}
    #...
    1
    コントロールプレーンノードがスケジュール対象 (Schedulable) になることを許可する場合は true に設定し、コントロールプレーンノードがスケジュール対象になることを拒否する場合は、false に設定します。
  3. 変更を適用するためにファイルを保存します。

6.3.3. SELinux ブール値の設定

OpenShift Container Platform を使用すると、Red Hat Enterprise Linux CoreOS(RHCOS) ノードで SELinux ブール値を有効または無効にできます。次の手順では、Machine Config Operator(MCO) を使用してノード上の SELinux ブール値を変更する方法について説明します。この手順では、ブール値の例として container_manage_cgroup を使用します。この値は、必要なブール値に変更できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次の例に示すように、MachineConfig オブジェクトを使用して新しい YAML ファイルを作成します。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 99-worker-setsebool
    spec:
      config:
        ignition:
          version: 3.2.0
        systemd:
          units:
          - contents: |
              [Unit]
              Description=Set SELinux booleans
              Before=kubelet.service
    
              [Service]
              Type=oneshot
              ExecStart=/sbin/setsebool container_manage_cgroup=on
              RemainAfterExit=true
    
              [Install]
              WantedBy=multi-user.target graphical.target
            enabled: true
            name: setsebool.service
    #...
  2. 次のコマンドを実行して、新しい MachineConfig オブジェクトを作成します。

    $ oc create -f 99-worker-setsebool.yaml
注記

MachineConfig オブジェクトに変更を適用すると、変更が適用された後、影響を受けるすべてのノードが正常に再起動します。

6.3.4. カーネル引数のノードへの追加

特殊なケースとして、クラスターのノードセットにカーネル引数を追加する必要がある場合があります。これは十分に注意して実行する必要があり、設定する引数による影響を十分に理解している必要があります。

警告

カーネル引数を正しく使用しないと、システムが起動不可能になる可能性があります。

設定可能なカーネル引数の例には、以下が含まれます。

  • enforcing=0: SELinux (Security Enhanced Linux) を Permissive モードで実行するように設定します。Permissive モードでは、システムは、SELinux が読み込んだセキュリティーポリシーを実行しているかのように動作します。これには、オブジェクトのラベル付けや、アクセスを拒否したエントリーをログに出力するなどの動作が含まれますが、いずれの操作も拒否される訳ではありません。Permissive モードは、実稼働システムでの使用はサポートされませんが、デバッグには役に立ちます。
  • nosmt: カーネルの対称マルチスレッド (SMT) を無効にします。マルチスレッドは、各 CPU の複数の論理スレッドを許可します。潜在的なクロススレッド攻撃に関連するリスクを減らすために、マルチテナント環境での nosmt の使用を検討できます。SMT を無効にすることは、基本的にパフォーマンスよりもセキュリティーを重視する選択をしていることになります。
  • systemd.unified_cgroup_hierarchy : Linux コントロールグループバージョン 2 (cgroup v2) を有効にします。cgroup v2 は、カーネル コントロールグループ の次のバージョンであり、複数の改善を提供します。

    重要

    OpenShift Container Platform cgroups バージョン 2 機能は Developer プレビューとして提供されており、現時点では Red Hat ではサポートされていません。

カーネル引数の一覧と説明については、Kernel.org カーネルパラメーター を参照してください。

次の手順では、以下を特定する MachineConfig オブジェクトを作成します。

  • カーネル引数を追加する一連のマシン。この場合、ワーカーロールを持つマシン。
  • 既存のカーネル引数の最後に追加されるカーネル引数。
  • マシン設定のリストで変更が適用される場所を示すラベル。

前提条件

  • 作業用の OpenShift Container Platform クラスターに対する管理者権限が必要です。

手順

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

    $ oc get MachineConfig

    出力例

    NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
    00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-master-ssh                                                                                 3.2.0             40m
    99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-worker-ssh                                                                                 3.2.0             40m
    rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

  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:
      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   AGE
    00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    05-worker-kernelarg-selinuxpermissive                                                         3.2.0             105s
    99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-master-ssh                                                                                 3.2.0             40m
    99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-worker-ssh                                                                                 3.2.0             40m
    rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

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

    $ oc get nodes

    出力例

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

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

  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 引数が他のカーネル引数に追加されていることを確認できるはずです。

6.3.5. ノードでのスワップメモリー使用の有効化

重要

ノードでスワップメモリーの使用を有効にできるのは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

ノードごとに OpenShift Container Platform ワークロードの swap メモリー使用量を有効にすることができます。

警告

スワップメモリーを有効にすると、ワークロードのパフォーマンスとリソース不足の処理に悪影響を与える可能性があります。コントロールプレーンノードでスワップメモリーを有効化しないでください。

スワップメモリーを有効にするには、kubeletconfig カスタムリソース (CR) を作成して、swapbehavior パラメーターを設定します。制限付きまたは無制限のスワップメモリーを設定できます。

  • 制限付き: Limited Swap 値を使用して、使用できるスワップメモリーワークロード量を制限します。Open Shift Container Platform によって管理されていないノード上のワークロードは、引き続きスワップメモリーを使用できます。Limited Swap の動作は、ノードが Linux コントロールグループの バージョン 1 (cgroups v1)バージョン 2 (cgroups v2) のどちらで実行されているかによって異なります。

    • cgroups v1: Open Shift Container Platform ワークロードは、設定されている場合、Pod のメモリー制限まで、メモリーとスワップの任意の組み合わせを使用できます。
    • cgroups v2: Open Shift Container Platform ワークロードはスワップメモリーを使用できません。
  • Unlimited: Unlimited Swap値を使用して、ワークロードがシステム制限まで、要求したスワップメモリーを使用できるようにします。

この設定がないと、スワップメモリーが存在する場合は kubelet が開始されないため、ノードでスワップメモリーを有効にする前に、OpenShift Container Platform でスワップメモリーを有効にする必要があります。ノードにスワップメモリーが存在しない場合、Open Shift Container Platform でスワップメモリーを有効にしても効果はありません。

前提条件

  • バージョン 4.10 以降を使用する OpenShift Container Platform クラスターが実行中である。
  • 管理者権限を持つユーザーとしてクラスターにログインしている。
  • クラスターで TechPreviewNoUpgrade 機能セットを有効にしている (ノード → クラスターの操作 → 機能ゲートを使用した機能の有効化 を参照)。

    注記

    TechPreviewNoUpgrade 機能セットを有効にすると元に戻すことができなくなり、マイナーバージョンの更新ができなくなります。これらの機能セットは、実稼働クラスターでは推奨されません。

  • ノードで cgroupsv2 が有効になっている場合は、swapaccount = 1 カーネル引数を設定して、ノードでスワップアカウンティングを有効にする必要があります。

手順

  1. スワップメモリーを許可するマシン設定プールにカスタムラベルを適用します。

    $ oc label machineconfigpool worker kubelet-swap=enabled
  2. カスタムリソース (CR) を作成し、スワップ設定を有効にして設定します。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: KubeletConfig
    metadata:
      name: swap-config
    spec:
      machineConfigPoolSelector:
        matchLabels:
          kubelet-swap: enabled
      kubeletConfig:
        failSwapOn: false 1
        memorySwap:
          swapBehavior: LimitedSwap 2
    #...
    1
    false に設定すると、関連付けられたノードでスワップメモリーを使用できるようになります。スワップメモリーの使用を無効にするには、true に設定します。
    2
    スワップメモリーの動作を指定します。指定しない場合、デフォルトは Limited Swap です。
  3. マシンでスワップメモリーを有効にします。

6.3.6. RHOSP ホストから別の RHOSP ホストへのコントロールプレーンノードの移行

コントロールプレーンノードをある Red Hat Open Stack Platform (RHOSP) ノードから別のノードに移動するスクリプトを実行できます。

前提条件

  • 環境変数 OS_CLOUD は、 clouds.yaml ファイルの管理者の認証情報を持つ クラウド エントリーを参照します。
  • 環境変数 KUBECONFIG は、管理用 Open Shift Container Platform 認証情報を含む設定を参照します。

手順

  • コマンドラインから、次のスクリプトを実行します。
#!/usr/bin/env bash

set -Eeuo pipefail

if [ $# -lt 1 ]; then
	echo "Usage: '$0 node_name'"
	exit 64
fi

# Check for admin OpenStack credentials
openstack server list --all-projects >/dev/null || { >&2 echo "The script needs OpenStack admin credentials. Exiting"; exit 77; }

# Check for admin OpenShift credentials
oc adm top node >/dev/null || { >&2 echo "The script needs OpenShift admin credentials. Exiting"; exit 77; }

set -x

declare -r node_name="$1"
declare server_id
server_id="$(openstack server list --all-projects -f value -c ID -c Name | grep "$node_name" | cut -d' ' -f1)"
readonly server_id

# Drain the node
oc adm cordon "$node_name"
oc adm drain "$node_name" --delete-emptydir-data --ignore-daemonsets --force

# Power off the server
oc debug "node/${node_name}" -- chroot /host shutdown -h 1

# Verify the server is shut off
until openstack server show "$server_id" -f value -c status | grep -q 'SHUTOFF'; do sleep 5; done

# Migrate the node
openstack server migrate --wait "$server_id"

# Resize the VM
openstack server resize confirm "$server_id"

# Wait for the resize confirm to finish
until openstack server show "$server_id" -f value -c status | grep -q 'SHUTOFF'; do sleep 5; done

# Restart the VM
openstack server start "$server_id"

# Wait for the node to show up as Ready:
until oc get node "$node_name" | grep -q "^${node_name}[[:space:]]\+Ready"; do sleep 5; done

# Uncordon the node
oc adm uncordon "$node_name"

# Wait for cluster operators to stabilize
until oc get co -o go-template='statuses: {{ range .items }}{{ range .status.conditions }}{{ if eq .type "Degraded" }}{{ if ne .status "False" }}DEGRADED{{ end }}{{ else if eq .type "Progressing"}}{{ if ne .status "False" }}PROGRESSING{{ end }}{{ else if eq .type "Available"}}{{ if ne .status "True" }}NOTAVAILABLE{{ end }}{{ end }}{{ end }}{{ end }}' | grep -qv '\(DEGRADED\|PROGRESSING\|NOTAVAILABLE\)'; do sleep 5; done

スクリプトが完了すると、コントロールプレーンマシンは新しい RHOSP ノードに移行されます。