Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

11.6. 正常でないクラスターのコントロールプレーンノードの置き換え

3 - 5 個のコントロールプレーンノードを持つ OpenShift Container Platform クラスター内の正常ではないコントロールプレーン (マスター) ノードを置き換えることができます。

正常なクラスター内のコントロールプレーンノードを置き換える方法の詳細は、正常なクラスター内のコントロールプレーンノードの置き換え を参照してください。

11.6.1. 正常でないコントロールプレーンノードの削除
リンクのコピー

正常でないコントロールプレーンノードをクラスターから削除します。これは、以下の例では node-0 です。

前提条件

  • 少なくとも 3 つのコントロールプレーンノードを持つクラスターをインストールした。
  • コントロールプレーンノードの少なくとも 1 つが準備状態ではない。

手順

  1. ノードのステータスをチェックして、コントロールプレーンノードが準備状態にないことを確認します。 

    $ oc get nodes

    出力例

    NAME      STATUS      ROLES    AGE   VERSION
node-0    NotReady    master   20h   v1.24.0+3882f8f
node-1    Ready       master   20h   v1.24.0+3882f8f
node-2    Ready       master   20h   v1.24.0+3882f8f
node-3    Ready       worker   20h   v1.24.0+3882f8f
node-4    Ready       worker   20h   v1.24.0+3882f8f

  2. etcd-Operator ログでクラスターが正常でないことを確認します。 

    $ oc logs -n openshift-etcd-operator etcd-operator deployment/etcd-operator

    出力例

    E0927 08:24:23.983733       1 base_controller.go:272] DefragController reconciliation failed: cluster is unhealthy: 2 of 3 members are available, node-0 is unhealthy

  3. 次のコマンドを実行して、etcd メンバーを確認します。

    1. コントロールプレーンノードへのリモートシェルセッションを開きます。 

      $ oc rsh -n openshift-etcd node-1

    2. etcdctl メンバーをリスト表示します。 

      # etcdctl member list -w table

      出力例

      +--------+---------+--------+--------------+--------------+---------+
|   ID   | STATUS  |  NAME  |  PEER ADDRS  | CLIENT ADDRS | LEARNER |
+--------+---------+--------+--------------+--------------+---------+
|61e2a860| started | node-0 |192.168.111.25|192.168.111.25|  false  |
|2c18942f| started | node-1 |192.168.111.26|192.168.111.26|  false  |
|ead4f280| started | node-2 |192.168.111.28|192.168.111.28|  false  |
+--------+---------+--------+--------------+--------------+---------+

  4. etcdctl エンドポイントのヘルスレポートでクラスターの異常なメンバーが報告されていることを確認します。 

    # etcdctl endpoint health

    出力例

    {"level":"warn","ts":"2022-09-27T08:25:35.953Z","logger":"client","caller":"v3/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"etcd-endpoints://0xc000680380/192.168.111.25","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = latest balancer error: last connection error: connection error: desc = \"transport: Error while dialing dial tcp 192.168.111.25: connect: no route to host\""}
192.168.111.28 is healthy: committed proposal: took = 12.465641ms
192.168.111.26 is healthy: committed proposal: took = 12.297059ms
192.168.111.25 is unhealthy: failed to commit proposal: context deadline exceeded
Error: unhealthy cluster

  5. Machine カスタムリソース (CR) を削除して、異常なコントロールプレーンを削除します。 

    $ oc delete machine -n openshift-machine-api node-0
    注記

    Machine CR と Node CR はファイナライザーによって保護されているため、削除されない可能性があります。これが発生した場合は、すべてのファイナライザーを削除して Machine CR を手動で削除する必要があります。

  6. etcd-operator ログで、異常なマシンが削除されたかどうかを確認します。 

    $ oc logs -n openshift-etcd-operator etcd-operator deployment/ettcd-operator

    出力例

    I0927 08:58:41.249222       1 machinedeletionhooks.go:135] skip removing the deletion hook from machine node-0 since its member is still present with any of: [{InternalIP } {InternalIP 192.168.111.25}]

  7. 上記のログの例のように、削除がスキップされたことがわかった場合は、異常な etcdctl メンバーを手動で削除します。

    1. コントロールプレーンノードへのリモートシェルセッションを開きます。 

      $ oc rsh -n openshift-etcd node-1

    2. etcdctl メンバーをリスト表示します。 

      # etcdctl member list -w table

      出力例

      +--------+---------+--------+--------------+--------------+---------+
|   ID   |  STATUS |  NAME  |  PEER ADDRS  | CLIENT ADDRS | LEARNER |
+--------+---------+--------+--------------+--------------+---------+
|61e2a860| started | node-0 |192.168.111.25|192.168.111.25|  false  |
|2c18942f| started | node-1 |192.168.111.26|192.168.111.26|  false  |
|ead4f280| started | node-2 |192.168.111.28|192.168.111.28|  false  |
+--------+---------+--------+--------------+--------------+---------+

    3. etcdctl エンドポイントのヘルスレポートでクラスターの異常なメンバーが報告されていることを確認します。 

      # etcdctl endpoint health

      出力例

      {"level":"warn","ts":"2022-09-27T10:31:07.227Z","logger":"client","caller":"v3/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"etcd-endpoints://0xc0000d6e00/192.168.111.25","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = latest balancer error: last connection error: connection error: desc = \"transport: Error while dialing dial tcp 192.168.111.25: connect: no route to host\""}
192.168.111.28 is healthy: committed proposal: took = 13.038278ms
192.168.111.26 is healthy: committed proposal: took = 12.950355ms
192.168.111.25 is unhealthy: failed to commit proposal: context deadline exceeded
Error: unhealthy cluster

    4. クラスターから異常な etcdctl メンバーを削除します。 

      # etcdctl member remove 61e2a86084aafa62

      出力例

      Member 61e2a86084aafa62 removed from cluster 6881c977b97990d7

    5. 次のコマンドを実行して、異常な etcdctl メンバーが削除されたことを確認します。 

      # etcdctl member list -w table

      出力例

      +----------+---------+--------+--------------+--------------+-------+
|    ID    | STATUS  |  NAME  |  PEER ADDRS  | CLIENT ADDRS |LEARNER|
+----------+---------+--------+--------------+--------------+-------+
| 2c18942f | started | node-1 |192.168.111.26|192.168.111.26| false |
| ead4f280 | started | node-2 |192.168.111.28|192.168.111.28| false |
+----------+---------+--------+--------------+--------------+-------+

11.6.2. 新しいコントロールプレーンノードの追加
リンクのコピー

削除した異常なノードを置き換えるために、新しいコントロールプレーンノードを追加します。以下の例では、新しいノードは node-5 です。

前提条件

手順

  1. 新しい Day 2 コントロールプレーンノードの保留中の証明書署名要求 (CSR) を取得します。 

    $ oc get csr | grep Pending

    出力例

    csr-5sd59   8m19s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   <none>              Pending
csr-xzqts   10s     kubernetes.io/kubelet-serving                 system:node:node-5                                                   <none>              Pending

  2. 新しいノード (この例では node-5) の保留中の CSR をすべて承認します。 

    $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
    注記

    インストールを完了するには、CSR を承認する必要があります。

  3. コントロールプレーンノードが Ready ステータスであることを確認します。 

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES     AGE     VERSION
node-1    Ready     master    20h     v1.24.0+3882f8f
node-2    Ready     master    20h     v1.24.0+3882f8f
node-3    Ready     worker    20h     v1.24.0+3882f8f
node-4    Ready     worker    20h     v1.24.0+3882f8f
node-5    Ready     master    2m52s   v1.24.0+3882f8f

    クラスターが Machine API を使用して実行される場合、etcd Operator には新しいノードを参照する Machine CR が必要です。クラスターに 3 つのコントロールプレーンノードがある場合、Machine API は自動的にアクティブ化されます。

  4. BareMetalHost および Machine CR を作成し、それらを新しいコントロールプレーンの Node CR にリンクします。

    重要

    Boot-it-yourself では BareMetalHost および Machine CR は作成されないため、これらを作成する必要があります。BareMetalHost および Machine CR の作成に失敗すると、etcd Operator でエラーが発生します。

    1. 一意の .metadata.name の値を使用して BareMetalHost CR を作成します。 

      apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: node-5
  namespace: openshift-machine-api
spec:
  automatedCleaningMode: metadata
  bootMACAddress: 00:00:00:00:00:02
  bootMode: UEFI
  customDeploy:
    method: install_coreos
  externallyProvisioned: true
  online: true
  userData:
    name: master-user-data-managed
    namespace: openshift-machine-api

    2. BareMetalHost CR を適用します。 

      $ oc apply -f <filename>

      &lt ;filename& gt; を BareMetalHost CR の名前に置き換えます。

    3. 一意の .metadata.name 値を使用して Machine CR を作成します。 

      apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  annotations:
    machine.openshift.io/instance-state: externally provisioned
    metal3.io/BareMetalHost: openshift-machine-api/node-5
  finalizers:
  - machine.machine.openshift.io
  labels:
    machine.openshift.io/cluster-api-cluster: test-day2-1-6qv96
    machine.openshift.io/cluster-api-machine-role: master
    machine.openshift.io/cluster-api-machine-type: master
  name: node-5
  namespace: openshift-machine-api
spec:
  metadata: {}
  providerSpec:
    value:
      apiVersion: baremetal.cluster.k8s.io/v1alpha1
      customDeploy:
        method: install_coreos
      hostSelector: {}
      image:
        checksum: ""
        url: ""
      kind: BareMetalMachineProviderSpec
      metadata:
        creationTimestamp: null
      userData:
       name: master-user-data-managed

    4. Machine CR を適用します。 

      $ oc apply -f <filename>

      <filename> は Machine CR の名前に置き換えます。

    5. link-machine-and-node.sh スクリプトを実行して、BareMetalHost、Machine、および Node をリンクします。

      1. 以下の link-machine-and-node.sh スクリプトをローカルマシンにコピーします。 

        #!/bin/bash

# Credit goes to
# https://bugzilla.redhat.com/show_bug.cgi?id=1801238.
# This script will link Machine object
# and Node object. This is needed
# in order to have IP address of
# the Node present in the status of the Machine.

set -e

machine="$1"
node="$2"

if [ -z "$machine" ] || [ -z "$node" ]; then
    echo "Usage: $0 MACHINE NODE"
    exit 1
fi

node_name=$(echo "${node}" | cut -f2 -d':')

oc proxy &
proxy_pid=$!
function kill_proxy {
    kill $proxy_pid
}
trap kill_proxy EXIT SIGINT

HOST_PROXY_API_PATH="http://localhost:8001/apis/metal3.io/v1alpha1/namespaces/openshift-machine-api/baremetalhosts"

function print_nics() {
    local ips
    local eob
    declare -a ips

    readarray -t ips < <(echo "${1}" \
                         | jq '.[] | select(. | .type == "InternalIP") | .address' \
                         | sed 's/"//g')

    eob=','
    for (( i=0; i<${#ips[@]}; i++ )); do
        if [ $((i+1)) -eq ${#ips[@]} ]; then
            eob=""
        fi
        cat <<- EOF
          {
            "ip": "${ips[$i]}",
            "mac": "00:00:00:00:00:00",
            "model": "unknown",
            "speedGbps": 10,
            "vlanId": 0,
            "pxe": true,
            "name": "eth1"
          }${eob}
EOF
    done
}

function wait_for_json() {
    local name
    local url
    local curl_opts
    local timeout

    local start_time
    local curr_time
    local time_diff

    name="$1"
    url="$2"
    timeout="$3"
    shift 3
    curl_opts="$@"
    echo -n "Waiting for $name to respond"
    start_time=$(date +%s)
    until curl -g -X GET "$url" "${curl_opts[@]}" 2> /dev/null | jq '.' 2> /dev/null > /dev/null; do
        echo -n "."
        curr_time=$(date +%s)
        time_diff=$((curr_time - start_time))
        if [[ $time_diff -gt $timeout ]]; then
            printf '\nTimed out waiting for %s' "${name}"
            return 1
        fi
        sleep 5
    done
    echo " Success!"
    return 0
}
wait_for_json oc_proxy "${HOST_PROXY_API_PATH}" 10 -H "Accept: application/json" -H "Content-Type: application/json"

addresses=$(oc get node -n openshift-machine-api "${node_name}" -o json | jq -c '.status.addresses')

machine_data=$(oc get machines.machine.openshift.io -n openshift-machine-api -o json "${machine}")
host=$(echo "$machine_data" | jq '.metadata.annotations["metal3.io/BareMetalHost"]' | cut -f2 -d/ | sed 's/"//g')

if [ -z "$host" ]; then
    echo "Machine $machine is not linked to a host yet." 1>&2
    exit 1
fi

# The address structure on the host doesn't match the node, so extract
# the values we want into separate variables so we can build the patch
# we need.
hostname=$(echo "${addresses}" | jq '.[] | select(. | .type == "Hostname") | .address' | sed 's/"//g')

set +e
read -r -d '' host_patch << EOF
{
  "status": {
    "hardware": {
      "hostname": "${hostname}",
      "nics": [
$(print_nics "${addresses}")
      ],
      "systemVendor": {
        "manufacturer": "Red Hat",
        "productName": "product name",
        "serialNumber": ""
      },
      "firmware": {
        "bios": {
          "date": "04/01/2014",
          "vendor": "SeaBIOS",
          "version": "1.11.0-2.el7"
        }
      },
      "ramMebibytes": 0,
      "storage": [],
      "cpu": {
        "arch": "x86_64",
        "model": "Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz",
        "clockMegahertz": 2199.998,
        "count": 4,
        "flags": []
      }
    }
  }
}
EOF
set -e

echo "PATCHING HOST"
echo "${host_patch}" | jq .

curl -s \
     -X PATCH \
     "${HOST_PROXY_API_PATH}/${host}/status" \
     -H "Content-type: application/merge-patch+json" \
     -d "${host_patch}"

oc get baremetalhost -n openshift-machine-api -o yaml "${host}"

      2. スクリプトを実行可能にします。 

        $ chmod +x link-machine-and-node.sh

      3. スクリプトを実行します。 

        $ bash link-machine-and-node.sh node-5 node-5
        注記

        最初の node-5 インスタンスはマシンを表し、2 番目のインスタンスはノードを表します。

  5. 次のコマンドを実行して、etcd のメンバーを確認します。

    1. コントロールプレーンノードへのリモートシェルセッションを開きます。 

      $ oc rsh -n openshift-etcd node-1

    2. etcdctl メンバーをリスト表示します。 

      # etcdctl member list -w table

      出力例

      +---------+-------+--------+--------------+--------------+-------+
|   ID    | STATUS|  NAME  |   PEER ADDRS | CLIENT ADDRS |LEARNER|
+---------+-------+--------+--------------+--------------+-------+
| 2c18942f|started| node-1 |192.168.111.26|192.168.111.26| false |
| ead4f280|started| node-2 |192.168.111.28|192.168.111.28| false |
| 79153c5a|started| node-5 |192.168.111.29|192.168.111.29| false |
+---------+-------+--------+--------------+--------------+-------+

  6. etcd Operator の設定プロセスが完了するまで監視します。 

    $ oc get clusteroperator etcd

    出力例 (完了時)

    NAME   VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
etcd   4.11.5    True        False         False      22h

  7. 以下のコマンドを実行して etcdctl の健全性を確認します。

    1. コントロールプレーンノードへのリモートシェルセッションを開きます。 

      $ oc rsh -n openshift-etcd node-1

    2. エンドポイントの健全性を確認します。 

      # etcdctl endpoint health

      出力例

      192.168.111.26 is healthy: committed proposal: took = 9.105375ms
192.168.111.28 is healthy: committed proposal: took = 9.15205ms
192.168.111.29 is healthy: committed proposal: took = 10.277577ms

  8. ノードの正常性を確認します。 

    $ oc get Nodes

    出力例

    NAME     STATUS   ROLES    AGE   VERSION
node-1   Ready    master   20h   v1.24.0+3882f8f
node-2   Ready    master   20h   v1.24.0+3882f8f
node-3   Ready    worker   20h   v1.24.0+3882f8f
node-4   Ready    worker   20h   v1.24.0+3882f8f
node-5   Ready    master   40m   v1.24.0+3882f8f

  9. クラスター Operator がすべて利用可能であることを確認します。 

    $ oc get ClusterOperators

    出力例

    NAME                               VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                     4.11.5    True        False         False      150m
baremetal                          4.11.5    True        False         False      22h
cloud-controller-manager           4.11.5    True        False         False      22h
cloud-credential                   4.11.5    True        False         False      22h
cluster-autoscaler                 4.11.5    True        False         False      22h
config-operator                    4.11.5    True        False         False      22h
console                            4.11.5    True        False         False      145m
csi-snapshot-controller            4.11.5    True        False         False      22h
dns                                4.11.5    True        False         False      22h
etcd                               4.11.5    True        False         False      22h
image-registry                     4.11.5    True        False         False      22h
ingress                            4.11.5    True        False         False      22h
insights                           4.11.5    True        False         False      22h
kube-apiserver                     4.11.5    True        False         False      22h
kube-controller-manager            4.11.5    True        False         False      22h
kube-scheduler                     4.11.5    True        False         False      22h
kube-storage-version-migrator      4.11.5    True        False         False      148m
machine-api                        4.11.5    True        False         False      22h
machine-approver                   4.11.5    True        False         False      22h
machine-config                     4.11.5    True        False         False      110m
marketplace                        4.11.5    True        False         False      22h
monitoring                         4.11.5    True        False         False      22h
network                            4.11.5    True        False         False      22h
node-tuning                        4.11.5    True        False         False      22h
openshift-apiserver                4.11.5    True        False         False      163m
openshift-controller-manager       4.11.5    True        False         False      22h
openshift-samples                  4.11.5    True        False         False      22h
operator-lifecycle-manager         4.11.5    True        False         False      22h
operator-lifecycle-manager-catalog 4.11.5    True        False         False      22h
operator-lifecycle-manager-pkgsvr  4.11.5    True        False         False      22h
service-ca                         4.11.5    True        False         False      22h
storage                            4.11.5    True        False         False      22h

  10. クラスターのバージョンが正しいことを確認します。 

    $ oc get ClusterVersion

    出力例

    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.11.5    True        False         22h     Cluster version is 4.11.5

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る