PowerFlex 4.x：MVMノードでRKE2証明書をローテーションする方法

概要: RKE2証明書は自動的に更新されるはずですが、まれにこの更新が行われないことがあります。 この手順では、MVMノードでRKE2証明書をローテーションする方法について説明します。

この記事は次に適用されます： この記事は次には適用されません： この記事は、特定の製品に関連付けられていません。 すべての製品パージョンがこの記事に記載されているわけではありません。
他のリソースを確認する

手順

注：この手順を実行するときは注意してください。PowerFlex Manager Platform (PFMP)機能を維持するには、2つの管理仮想マシン(MVM)ノードが稼働している必要があります。
注：Kubectlコマンドは、「Ready」ステータス以外のノードでは機能しません。
注：この手順では、MVMの/var/lib/rancher/rke2/server/tls/にある証明書を更新します。
注：この手順では、Kubernetesシークレットまたは証明書によって管理されている証明書は更新されません。

手順：
 

1.任意のMVMノードにSSHで接続します。

2.すべてのノードが「Ready」ステータスであることを確認します。

kubectl get node
注：kubectlコマンドは、「Ready」ステータス以外のノードでは機能しません。このような場合は、別のノードからコマンドを実行します。

3.すべてのPostgresデータベース インスタンスを一覧表示し、リーダー ロールを持つポッド名を特定します。

kubectl exec -n powerflex -c database $(kubectl get pods -n powerflex -l='postgres-operator.crunchydata.com/role=master, postgres-operator.crunchydata.com/instance-set' | grep Running | cut -d' ' -f1) -- sh -c 'patronictl list'

出力例:

+ Cluster: postgres-ha-ha +------------------------------------------+--------------+-----------+----+-----------+
| Member                  | Host                                     | Role         | State     | TL | Lag in MB |
+-------------------------+------------------------------------------+--------------+-----------+----+-----------+
| postgres-ha-cmo1-58bs-0 | postgres-ha-cmo1-58bs-0.postgres-ha-pods | Sync Standby | streaming |  7 |         0 |
| postgres-ha-cmo1-lvkz-0 | postgres-ha-cmo1-lvkz-0.postgres-ha-pods | Sync Standby | streaming |  7 |         0 |
| postgres-ha-cmo1-v7zg-0 | postgres-ha-cmo1-v7zg-0.postgres-ha-pods | Leader       | running   |  7 |           | ← This is the Leader pod
+-------------------------+------------------------------------------+--------------+-----------+----+-----------+

4.PostgreSQLリーダー ポッドを実行しているMVMを特定します。

for x in `kubectl get pods -n powerflex | grep "postgres-ha-cmo" | awk '{print $1}'`; do echo $x; kubectl get pods -n powerflex $x -o json | grep '"nodeName"' | cut -d ':' -f2; echo " "; done

出力例:

postgres-ha-cmo1-58bs-0
 "pfmp-mvm3-c",
postgres-ha-cmo1-lvkz-0
 "pfmp-mvm2-c",
postgres-ha-cmo1-v7zg-0
 "pfmp-mvm1-c", ← This is the MVM running the Leader pod

5.ターゲットMVMにSSHで接続します。

注：手順1から4までの情報を使用して適切な更新シーケンスを決定し、ターゲットMVMにSSHで接続します。
  ・現在NotReady状態のノードを最初に更新する必要があります。
  ・ PostgreSQLリーダー ポッドが稼働しているMVMを最後に更新する必要があります。
  ・他のノードは任意の順序で更新できます。

6.rootユーザーに切り替えます。

sudo -s

7.メンテナンス対象のMVMにラベルを付けます。

kubectl label node <Target-MVM> cmo.maintenance.mode=true
注：Target-MVMを編集します。
注：このコマンドは、NotReadyステータスのノードをスキップします。

成功時の出力例：

node/pfmp-mvm2-c labeled

エラー時の出力例：

error: 'cmo.maintenance.mode' already has a value (false), and --overwrite is false

次のコマンドを使用して、メンテナンス ラベルがtrueに設定されているかどうかを確認できます。

kubectl describe nodes <Target-MVM> | grep cmo.maintenance.mode

注：Target-MVMを編集します。

出力例:

                    cmo.maintenance.mode=true
注：値がfalseの場合は、次のコマンドを実行して再試行してください。 
kubectl label node <Target-MVM> cmo.maintenance.mode-

8.ターゲットMVMからポッドをドレインします。

kubectl drain <Target-MVM> --ignore-daemonsets --delete-emptydir-data
注：Target-MVMを編集します。
注：このコマンドは、NotReadyステータスのノードをスキップします。

出力例:

node/pfmp-mvm2-c cordoned
Warning: ignoring DaemonSet-managed Pods: calico-system/calico-node-6b28t, kube-system/rke2-ingress-nginx-controller-nzdw4, kube-system/rke2-multus-ds-7qj7z, powerflex/logging-fluent-bit-hg4jx, powerflex/metallb-speaker-dgsm7, powerflex/powerflex-status-service-r2phw, powerflex/powerflex-status-ui-vb4f5
evicting pod powerflex/vault-2
evicting pod powerflex/block-legacy-gateway-0
...
node/<Node Name> drained ← This message confirms successful draining

9.ノードのステータスが「Ready, SchedulingDisabled」になっていることを確認します。

kubectl get node
注：このコマンドは、NotReadyステータスのノードをスキップします。

出力例:

NAME          STATUS                     ROLES                       AGE   VERSION
pfmp-mvm1-c   Ready                      control-plane,etcd,master   93d   v1.25.3+rke2r1
pfmp-mvm2-c   Ready,SchedulingDisabled   control-plane,etcd,master   93d   v1.25.3+rke2r1
pfmp-mvm3-c   Ready                      control-plane,etcd,master   93d   v1.25.3+rke2r1

10.ターゲットMVMでRKE2サービスを停止します。

 ・ホスト名を確認します。

hostname

 ・RKE2サービスを停止します。

systemctl stop rke2-server

11.証明書をローテーションします。

rke2 certificate rotate

出力例:

INFO[0000] Server detected, rotating server certificates 
INFO[0000] Rotating certificates for admin service      
INFO[0000] Rotating certificates for etcd service       
INFO[0000] Rotating certificates for api-server service 
INFO[0000] Rotating certificates for controller-manager service 
INFO[0000] Rotating certificates for cloud-controller service 
INFO[0000] Rotating certificates for scheduler service  
INFO[0000] Rotating certificates for rke2-server service 
INFO[0000] Rotating dynamic listener certificate        
INFO[0000] Rotating certificates for rke2-controller service 
INFO[0000] Rotating certificates for auth-proxy service 
INFO[0000] Rotating certificates for kubelet service    
INFO[0000] Rotating certificates for kube-proxy service 
INFO[0000] Successfully backed up certificates for all services to path /var/lib/rancher/rke2/server/tls-1748242637, please restart rke2 server or agent to rotate certificates

12.RKE2サービスを再起動します。

systemctl start rke2-server
注：この処理には、5分ほどかかる場合があります。

13.プロンプトが表示されたら、メンテナンス ラベルを削除して、ノードをuncordon（スケジュール可能に戻す）します。

kubectl uncordon <Target-MVM> ; kubectl label node <Target-MVM> cmo.maintenance.mode-
注：Target-MVMを編集します。
注：手順7と8をスキップしたノードでは、このコマンドをスキップできます。

14.10〜30分待った後、次の点を確認します。

  14-1. 証明書の有効期限が更新されていること（約1年先）。

openssl x509 -in /var/lib/rancher/rke2/server/tls/etcd/client.crt -noout -dates
openssl x509 -in /var/lib/rancher/rke2/server/tls/etcd/server-client.crt -noout -dates
openssl x509 -in /var/lib/rancher/rke2/server/tls/etcd/peer-server-client.crt -noout -dates

  14-2. すべてのノードが「Ready」ステータスであること。

kubectl get node

  14-3. 異常なステータスのポッドがないこと。

kubectl get pod -A -o wide | egrep -v "Running|Completed"
注：このコマンドでは、「Running」および「Completed」以外のステータスをもつポッドのみを表示します。表示されているポッドがある場合は、それらをチェックします。

15.すべてのチェックに合格した場合は、次のMVMに進んで手順5から始めます。
  次のMVMに進む前に、1つ目のMVMで処理を完了します。
  PostgreSQLリーダー ポッドを実行しているMVMは、最後に更新する必要があります。

3つすべてのMVMで手順を完了したら、手順3のコマンドを実行してPostgresデータベースの正常性を確認します。1つのポッドが「Leader」で、「running」ステータスである必要があります。ラグは0MBであり、両方の「Sync Standby」メンバーの状態が「streaming」である必要があります。

正常なデータベースの例：

+ Cluster: postgres-ha-ha +------------------------------------------+--------------+-----------+----+-----------+
| Member                  | Host                                     | Role         | State     | TL | Lag in MB |
+-------------------------+------------------------------------------+--------------+-----------+----+-----------+
| postgres-ha-cmo1-58bs-0 | postgres-ha-cmo1-58bs-0.postgres-ha-pods | Sync Standby | streaming |  7 |         0 |
| postgres-ha-cmo1-lvkz-0 | postgres-ha-cmo1-lvkz-0.postgres-ha-pods | Sync Standby | streaming |  7 |         0 |
| postgres-ha-cmo1-v7zg-0 | postgres-ha-cmo1-v7zg-0.postgres-ha-pods | Leader       | running   |  7 |           |
+-------------------------+------------------------------------------+--------------+-----------+----+-----------+

対象製品

ScaleIO
文書のプロパティ
文書番号: 000325517
文書の種類: How To
最終更新: 09 6月 2025
バージョン:  2
質問に対する他のDellユーザーからの回答を見つける
サポート サービス
お使いのデバイスがサポート サービスの対象かどうかを確認してください。