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

6.6. BMC 認証情報のない失敗したベアメタルコントロールプレーンノードの交換

ベアメタルクラスター上のコントロールプレーンノードに障害が発生し、復元できない場合、ベースボード管理コントローラー(BMC)認証情報を提供せずにクラスターをインストールした場合は、障害が発生したノードを新しいノードに置き換えるために追加の手順を実行する必要があります。

6.6.1. 前提条件
リンクのコピー

  • 正常でないベアメタル etcd メンバーを特定している。
  • マシンが実行されていないか、ノードが準備状態にないことを確認している。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • 問題が発生した場合には、etcd バックアップ を作成している。
  • coreos-installer CLI をダウンロードし、インストールしている。

  • クラスターにはコントロールプレーン マシンセット がありません。次のコマンドを実行 して、machineset を確認できます。 

    $ oc get machinesets,controlplanemachinesets -n openshift-machine-api
    重要

    ワーカー用に 1 つ以上の マシンセット のみが必要です。コントロールプレーン のコントロールプレーンマシンセット が存在する場合は、この手順を使用しないでください。

6.6.2. 正常でない etcd メンバーの削除
リンクのコピー

正常でない etcd メンバーを削除して、失敗したコントロールプレーンノードの削除を開始します。

手順

  1. 以下のコマンドを実行して etcd Pod を一覧表示し、影響を受けるノード上にない Pod をメモします。 

    $ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide

    出力例

    etcd-openshift-control-plane-0   5/5   Running   11   3h56m   192.168.10.9    openshift-control-plane-0  <none>           <none>
etcd-openshift-control-plane-1   5/5   Running   0    3h54m   192.168.10.10   openshift-control-plane-1   <none>           <none>
etcd-openshift-control-plane-2   5/5   Running   0    3h58m   192.168.10.11   openshift-control-plane-2   <none>           <none>

  2. 以下のコマンドを実行して、実行中の etcd コンテナーに接続します。 

    $ oc rsh -n openshift-etcd <etcd_pod>

    &lt ;etcd_pod&gt; を正常なノードの 1 つに関連付けられた etcd Pod の名前に置き換えます。

    コマンドの例

    $ oc rsh -n openshift-etcd etcd-openshift-control-plane-0

  3. 以下のコマンドを実行して etcd メンバー一覧を表示します。これらの値は後で必要になるため、ID および正常でない etcd メンバーの名前を書き留めておきます。 

    sh-4.2# etcdctl member list -w table

    出力例

    +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 6fc1e7c9db35841d | started | openshift-control-plane-2    | https://10.0.131.183:2380 | https://10.0.131.183:2379 |
| 757b6793e2408b6c | started | openshift-control-plane-1    | https://10.0.164.97:2380  | https://10.0.164.97:2379  |
| ca8c2990a0aa29d1 | started | openshift-control-plane-0    | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+

    重要

    etcdctl endpoint health コマンドは、置き換えが完了し、新規メンバーが追加されるまで、削除されたメンバーを一覧表示します。

  4. 次のコマンドを実行して、正常でない etcd メンバーを削除します。 

    sh-4.2# etcdctl member remove <unhealthy_member_id>

    & lt;unhealthy_member_id&gt; を正常でないノードの etcd メンバーの ID に置き換えます。

    コマンドの例

    sh-4.2# etcdctl member remove 6fc1e7c9db35841d

    出力例

    Member 6fc1e7c9db35841d removed from cluster b23536c33f2cdd1b

  5. 次のコマンドを実行してメンバーリストを再度表示し、メンバーが削除されたことを確認します。 

    sh-4.2# etcdctl member list -w table

    出力例

    +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 757b6793e2408b6c | started | openshift-control-plane-1    | https://10.0.164.97:2380  | https://10.0.164.97:2379  |
| ca8c2990a0aa29d1 | started | openshift-control-plane-0    | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+

    重要

    メンバーを削除した後、残りの etcd インスタンスが再起動している間、クラスターに短時間アクセスできない場合があります。

  6. 次のコマンドを実行して、rsh セッションを etcd Pod を終了します。 

    sh-4.2# exit

  7. 以下のコマンドを実行して、etcd クォーラムガードをオフにします。 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    このコマンドにより、シークレットを正常に再作成し、静的 Pod をロールアウトできるようになります。

  8. 次のコマンドを実行して、削除された正常でない etcd メンバーのシークレットを一覧表示します。 

    $ oc get secrets -n openshift-etcd | grep <node_name>

    &lt ;node_name> を、etcd メンバーが削除した障害のあるノードの名前に置き換えます。

    コマンドの例

    $ oc get secrets -n openshift-etcd | grep openshift-control-plane-2

    出力例

    etcd-peer-openshift-control-plane-2             kubernetes.io/tls   2   134m
etcd-serving-metrics-openshift-control-plane-2  kubernetes.io/tls   2   134m
etcd-serving-openshift-control-plane-2          kubernetes.io/tls   2   134m

  9. 削除された影響を受けるノードに関連付けられたシークレットを削除します。

    1. 次のコマンドを実行して、ピアシークレットを削除します。 

      $ oc delete secret -n openshift-etcd etcd-peer-<node_name>

      &lt ;node_name> を影響を受けるノードの名前に置き換えます。

    2. 次のコマンドを実行して、サービングシークレットを削除します。 

      $ oc delete secret -n openshift-etcd etcd-serving-<node_name>

      &lt ;node_name> を影響を受けるノードの名前に置き換えます。

    3. 次のコマンドを実行して、メトリクスシークレットを削除します。 

      $ oc delete secret -n openshift-etcd etcd-serving-metrics-<node_name>
      1

      &lt ;node_name> を影響を受けるノードの名前に置き換えます。

6.6.3. 正常でない etcd メンバーのマシンの削除
リンクのコピー

正常でない etcd メンバーのマシンを削除して、失敗したコントロールプレーンノードの削除を終了します。

手順

  1. 以下のコマンドを実行して、Bare Metal Operator が利用可能であることを確認します。 

    $ oc get clusteroperator baremetal

    出力例

    NAME        VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
baremetal   4.20.0    True        False         False      3d15h

  2. 次のコマンドを実行して、影響を受けるノードの BareMetalHost オブジェクトをファイルに保存します。 

    $ oc get -n openshift-machine-api bmh <node_name> -o yaml > bmh_affected.yaml

    &lt ;node_name> を影響を受けるノードの名前に置き換えます。これは通常、関連する BareMetalHost 名と一致します。

  3. 次のコマンドを実行して、保存された BareMetalHost オブジェクトの YAML ファイルを表示し、コンテンツが正しいことを確認します。 

    $ cat bmh_affected.yaml

  4. 次のコマンドを実行して、影響を受ける BareMetalHost オブジェクトを削除します。 

    $ oc delete -n openshift-machine-api bmh <node_name>

    &lt ;node_name> を影響を受けるノードの名前に置き換えます。

  5. 以下のコマンドを実行してすべてのマシンを一覧表示し、影響を受けるノードに関連付けられたマシンを特定します。 

    $ oc get machines -n openshift-machine-api -o wide

    出力例

    NAME                            PHASE    TYPE  REGION  ZONE  AGE    NODE                       PROVIDERID                                                                                             STATE
examplecluster-control-plane-0  Running                      3h11m  openshift-control-plane-0  baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e  externally provisioned
examplecluster-control-plane-1  Running                      3h11m  openshift-control-plane-1  baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1  externally provisioned
examplecluster-control-plane-2  Running                      3h11m  openshift-control-plane-2  baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135  externally provisioned
examplecluster-compute-0        Running                      165m   openshift-compute-0        baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f        provisioned
examplecluster-compute-1        Running                      165m   openshift-compute-1        baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9        provisioned

  6. 次のコマンドを実行して、異常なメンバーのマシンを削除します。 

    $ oc delete machine -n openshift-machine-api <machine_name>

    &lt ;machine_name> を影響を受けるノードに関連付けられたマシン名に置き換えます。

    コマンドの例

    $ oc delete machine -n openshift-machine-api examplecluster-control-plane-2

    注記

    BareMetalHost オブジェクトと Machine オブジェクトを削除すると、マシンコントローラーは Node オブジェクトを自動的に削除します。

  7. 何らかの理由でマシンの削除が遅れたり、コマンドが妨げられて遅れたりする場合は、マシンオブジェクトのファイナライザーフィールドを削除して強制的に削除します。

    警告

    Ctrl+c を押してマシンの削除を中断しないでください。コマンドが完了するまで続行できるようにする必要があります。新しいターミナルウィンドウを開き、ファイナライザーフィールドを編集して削除します。

    1. 新しいターミナルウィンドウで、次のコマンドを実行してマシン設定を編集します。 

      $ oc edit machine -n openshift-machine-api examplecluster-control-plane-2

    2. Machine カスタムリソースの次のフィールドを削除し、更新されたファイルを保存します。 

      finalizers:
- machine.machine.openshift.io

      出力例

      machine.machine.openshift.io/examplecluster-control-plane-2 edited

6.6.4. 障害が発生したノードが削除されたことの確認
リンクのコピー

代替のコントロールプレーンノードの作成に進む前に、障害が発生したノードが正常に削除されたことを確認してください。

手順

  1. 以下のコマンドを実行して、マシンが削除されていることを確認します。 

    $ oc get machines -n openshift-machine-api -o wide

    出力例

    NAME                              PHASE     TYPE   REGION   ZONE   AGE     NODE                                 PROVIDERID                                                                                       STATE
examplecluster-control-plane-0    Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned
examplecluster-control-plane-1    Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
examplecluster-compute-0          Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
examplecluster-compute-1          Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned

  2. 次のコマンドを実行して、ノードが削除されたことを確認します。 

    $ oc get nodes

    出力例

    NAME                     STATUS ROLES   AGE   VERSION
openshift-control-plane-0 Ready master 3h24m v1.33.4
openshift-control-plane-1 Ready master 3h24m v1.33.4
openshift-compute-0       Ready worker 176m v1.33.4
openshift-compute-1       Ready worker 176m v1.33.4

  3. すべてのクラスター Operator がロールアウトの変更を完了するまで待ちます。次のコマンドを実行して、進捗を監視します。 

    $ watch oc get co

6.6.5. 新規コントロールプレーンノードの作成
リンクのコピー

BareMetalHost オブジェクトとノードを作成して、新しいコントロールプレーンノードの作成を開始します。

手順

  1. 以前に保存した bmh_affected.yaml ファイルを編集します。

    1. 以下のメタデータをファイルから削除します。

      • creationTimestamp
      • generation
      • resourceVersion
      • uid
    2. ファイルの status セクションを削除します。

    結果のファイルは以下の例のようになります。

    bmh_affected.yaml ファイルの例

    apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  labels:
    installer.openshift.io/role: control-plane
  name: openshift-control-plane-2
  namespace: openshift-machine-api
spec:
  automatedCleaningMode: disabled
  bmc:
    address:
    credentialsName:
    disableCertificateVerification: true
  bootMACAddress: ab:cd:ef:ab:cd:ef
  bootMode: UEFI
  externallyProvisioned: true
  online: true
  rootDeviceHints:
    deviceName: /dev/disk/by-path/pci-0000:04:00.0-nvme-1
  userData:
    name: master-user-data-managed
    namespace: openshift-machine-api

  2. 次のコマンドを実行して、bmh_affected.yaml ファイルを使用して BareMetalHost オブジェクトを作成します。 

    $ oc create -f bmh_affected.yaml

    BareMetalHost オブジェクトの作成時に、次の警告が期待されます。 

    Warning: metadata.finalizers: "baremetalhost.metal3.io": prefer a domain-qualified finalizer name to avoid accidental conflicts with other finalizer writers

  3. 次のコマンドを実行して、コントロールプレーンの Ignition シークレットを抽出します。 

    $ oc extract secret/master-user-data-managed \
    -n openshift-machine-api \
    --keys=userData \
    --to=- \
    | sed '/^userData/d' > new_controlplane.ign

    このコマンドは、ignition シークレットの開始 userData 行も削除します。

  4. 次の参照例を使用して、新しいノードのネットワーク設定用の new_controlplane_nmstate.yaml という名前の Nmstate YAML ファイルを作成します。

    Nmstate YAML ファイルの例

    interfaces:
  - name: eno1
    type: ethernet
    state: up
    mac-address: "ab:cd:ef:01:02:03"
    ipv4:
      enabled: true
      address:
        - ip: 192.168.20.11
          prefix-length: 24
      dhcp: false
    ipv6:
      enabled: false
dns-resolver:
  config:
    search:
      - iso.sterling.home
    server:
      - 192.168.20.8
routes:
  config:
  - destination: 0.0.0.0/0
    metric: 100
    next-hop-address: 192.168.20.1
    next-hop-interface: eno1
    table-id: 254

    注記

    エージェント ベースのインストーラーを使用してクラスターをインストールした場合は、元のクラスターデプロイメントから失敗したノードの networkConfig セクションを、新しいコントロールプレーンノードの Nmstate ファイルの開始点として使用できます。たとえば、以下のコマンドは、最初のコントロールプレーンノードの networkConfig セクションを抽出します。 

    $ cat agent-config-iso.yaml | yq .hosts[0].networkConfig > new_controlplane_nmstate.yaml

  5. 次のコマンドを実行して、カスタマイズされた Red Hat Enterprise Linux CoreOS (RHCOS)ライブ ISO を作成します。 

    $ coreos-installer iso customize rhcos-live.86_64.iso \
    --dest-ignition new_controlplane.ign \
    --network-nmstate new_controlplane_nmstate.yaml \
    --dest-device /dev/disk/by-path/<device_path> \
    -f

    & lt;device_path& gt; を、ISO が生成されるターゲットデバイスへのパスに置き換えます。

  6. カスタマイズされた RHCOS ライブ ISO で新しいコントロールプレーンノードを起動します。
  7. 証明書署名要求(CSR)を承認すると、新しいノードがクラスターに参加します。

6.6.6. ノード、ベアメタルホスト、およびマシンのリンク
リンクのコピー

マシンを作成し、それを新しい BareMetalHost オブジェクトおよびノードにリンクすることにより、新しいコントロールプレーンノードの作成を続行します。

手順

  1. 次のコマンドを実行して、コントロールプレーンノードの providerID を取得します。 

    $ oc get -n openshift-machine-api baremetalhost -l installer.openshift.io/role=control-plane -ojson | jq -r '.items[] | "baremetalhost:///openshift-machine-api/" + .metadata.name + "/" + .metadata.uid'

    出力例

    baremetalhost:///openshift-machine-api/master-00/6214c5cf-c798-4168-8c78-1ff1a3cd2cb4
baremetalhost:///openshift-machine-api/master-01/58fb60bd-b2a6-4ff3-a88d-208c33abf954
baremetalhost:///openshift-machine-api/master-02/dc5a94f3-625b-43f6-ab5a-7cc4fc79f105

  2. 次のコマンドを実行して、ラベルのクラスター情報を取得します。 

    $ oc get machine -n openshift-machine-api \
    -l machine.openshift.io/cluster-api-machine-role=master \
    -L machine.openshift.io/cluster-api-cluster

    出力例

    NAME                           PHASE   TYPE  REGION  ZONE  AGE  CLUSTER-API-CLUSTER
ci-op-jcp3s7wx-ng5sd-master-0  Running                     10h  ci-op-jcp3s7wx-ng5sd
ci-op-jcp3s7wx-ng5sd-master-1  Running                     10h  ci-op-jcp3s7wx-ng5sd
ci-op-jcp3s7wx-ng5sd-master-2  Running                     10h  ci-op-jcp3s7wx-ng5sd

  3. 次のような yaml ファイルを作成して、新規コントロールプレーンノードの Machine オブジェクトを作成します。 

    apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  annotations:
    metal3.io/BareMetalHost: openshift-machine-api/<new_control_plane_machine>
    1 
    
  finalizers:
    - machine.machine.openshift.io
  labels:
    machine.openshift.io/cluster-api-cluster: <cluster_api_cluster>
    2 
    
    machine.openshift.io/cluster-api-machine-role: master
    machine.openshift.io/cluster-api-machine-type: master
  name: <new_control_plane_machine>
    3 
    
  namespace: openshift-machine-api
spec:
  metadata: {}
  providerID: <provider_id>
    4 
    
  providerSpec:
    value:
      apiVersion: baremetal.cluster.k8s.io/v1alpha1
      hostSelector: {}
      image:
        checksum: ""
        url: ""
      kind: BareMetalMachineProviderSpec
      userData:
        name: master-user-data-managed

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

    <new_control_plane_machine>
    新しいマシンの名前を指定します。これは以前に削除されたマシン名と同じになります。
    <cluster_api_cluster>
    直前の手順の出力に示されるように、他のコントロールプレーンマシンの CLUSTER-API-CLUSTER 値を指定します。
    <provider_id>
    前の手順の出力に示されている、新しいベアメタルホストの providerID 値を指定します。

    次の警告が期待されます。 

    Warning: metadata.finalizers: "machine.machine.openshift.io": prefer a domain-qualified finalizer name to avoid accidental conflicts with other finalizer writers

  4. 単一の bash シェルセッションで次の手順を実行して、新しいコントロールプレーンノードと Machine オブジェクトを BareMetalHost オブジェクトにリンクします。

    1. 以下のコマンドを実行して NEW_NODE_NAME 変数を定義します。 

      $ NEW_NODE_NAME=<new_node_name>

      & lt;new_node_name&gt; を新しいコントロールプレーンノードの名前に置き換えます。

    2. 以下のコマンドを実行して NEW_MACHINE_NAME 変数を定義します。 

      $ NEW_MACHINE_NAME=<new_machine_name>

      & lt;new_machine_name&gt; を新しいマシンの名前に置き換えます。

    3. 次のコマンドを実行して、新しいノードの BareMetalHost オブジェクトから抽出して、BMH_UID を定義します。 

      $ BMH_UID=$(oc get -n openshift-machine-api bmh $NEW_NODE_NAME -ojson | jq -r .metadata.uid)
       
      $ echo $BMH_UID

    4. 以下のコマンドを実行して、consumerRef オブジェクトをベアメタルホストにパッチを適用します。 

      $ oc patch -n openshift-machine-api bmh $NEW_NODE_NAME --type merge --patch '{"spec":{"consumerRef":{"apiVersion":"machine.openshift.io/v1beta1","kind":"Machine","name":"'$NEW_MACHINE_NAME'","namespace":"openshift-machine-api"}}}'

    5. 次のコマンドを実行して、providerID 値を新しいノードにパッチを適用します。 

      $ oc patch node $NEW_NODE_NAME --type merge --patch '{"spec":{"providerID":"baremetalhost:///openshift-machine-api/'$NEW_NODE_NAME'/'$BMH_UID'"}}'

    6. 次のコマンドを実行して、providerID の値を確認します。 

      $ oc get node -l node-role.kubernetes.io/control-plane -ojson | jq -r '.items[] | .metadata.name + "  " + .spec.providerID'

  5. 次のコマンドを実行して、BareMetalHost オブジェクトの poweredOn ステータスを true に設定します。 

    $ oc patch -n openshift-machine-api bmh $NEW_NODE_NAME --subresource status --type json -p '[{"op":"replace","path":"/status/poweredOn","value":true}]'

  6. 次のコマンドを実行して、BareMetalHost オブジェクトの poweredOn ステータスを確認します。 

    $ oc get bmh -n openshift-machine-api -ojson | jq -r '.items[] | .metadata.name + "   PoweredOn:" +  (.status.poweredOn | tostring)'

  7. 次のコマンドを実行して、BareMetalHost オブジェクトのプロビジョニング状態を確認します。 

    $ oc get bmh -n openshift-machine-api -ojson | jq -r '.items[] | .metadata.name + "   ProvisioningState:" +  .status.provisioning.state'
    重要

    プロビジョニング状態が 管理対象外 ではない場合は、以下のコマンドを実行してプロビジョニング状態を変更します。 

    $ oc patch -n openshift-machine-api bmh $NEW_NODE_NAME --subresource status --type json -p '[{"op":"replace","path":"/status/provisioning/state","value":"unmanaged"}]'

  8. 次のコマンドを実行して、マシンの状態を Provisioned に設定します。 

    $ oc patch -n openshift-machine-api machines $NEW_MACHINE_NAME -n openshift-machine-api --subresource status --type json -p '[{"op":"replace","path":"/status/phase","value":"Provisioned"}]'

6.6.7. 新規 etcd メンバーの追加
リンクのコピー

新しい etcd メンバーをクラスターに追加して、新しいコントロールプレーンノードの追加を終了します。

手順

  1. 単一の bash シェルセッションで以下の手順を実行して、新規 etcd メンバーをクラスターに追加します。

    1. 次のコマンドを実行して、新しいコントロールプレーンノードの IP を見つけます。 

      $ oc get nodes -owide -l node-role.kubernetes.io/control-plane

      後で使用できるようにノードの IP アドレスを書き留めておきます。

    2. 以下のコマンドを実行して、etcd Pod を一覧表示します。 

      $ oc get -n openshift-etcd pods -l k8s-app=etcd -o wide

    3. 次のコマンドを実行して、実行中の etcd Pod のいずれかに接続します。新しいノード上の etcd Pod は CrashLoopBackOff 状態である必要があります。 

      $ oc rsh -n openshift-etcd <running_pod>

      &lt ;running_pod> を直前の手順で表示される実行中の Pod の名前に置き換えます。

    4. 以下のコマンドを実行して etcd メンバー一覧を表示します。 

      sh-4.2# etcdctl member list -w table

    5. 次のコマンドを実行して、新しいコントロールプレーンの etcd メンバーを追加します。 

      sh-4.2# etcdctl member add <new_node> --peer-urls="https://<ip_address>:2380"

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

      <new_node>
      新しいコントロールプレーンノードの名前を指定します。
      <ip_address>
      新しいノードの IP アドレスを指定します。

    6. 次のコマンドを実行して rsh シェルを終了します。 

      sh-4.2# exit

  2. 以下のコマンドを実行して etcd の再デプロイメントを強制的に実行します。 

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "single-master-recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

  3. 次のコマンドを実行して、etcd クォーラムガードをオンに戻します。 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'

  4. 次のコマンドを実行して、クラスター Operator のロールアウトをモニターします。 

    $ watch oc get co
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

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

Legal Notice

Theme

© 2026 Red Hatトップに戻る