Red Hat OpenShift 証明書の回転

Red Hat OpenShift for VMware は kubelet クライアント証明書を使用します。この証明書はセキュリティーのために定期的にローテーションする必要があります。Red Hat OpenShift が主にローテーション・プロセスを自動で行いますが、それには、証明書署名要求 (CSR) の手動による承認が必要です。したがって、証明書の有効期限切れを回避するために、Red Hat OpenShift 証明書ローテーションのスケジュールを把握しておくことが重要です。

インストール時に作成された初期証明書は、作成後 24 時間で有効期限が切れます。Red Hat OpenShift をインストールする IBM の自動化プロセスが、この最初のローテーションの CSR の承認を処理します。承認処理は、最初の 30 時間の間、bastion でスクリプトを実行することによって行われます。このスクリプトの名前は /root/approve-csr.sh、そのログ・ファイルの名前は /root/approve-csr.log です。

スクリプトを正常に実行するには、最初の証明書ローテーションが完了するまで、kubeadmin 資格情報が最初と同じままである必要があります。最初の 24 時間は kubeadmin 資格情報を変更しないでください。資格情報が変更されている場合は、最初の証明書ローテーションの間 CSR をモニターして承認する必要があります。詳細については、 マシンのCSRを承認するを参照してください。

最初の証明書ローテーションが完了するまでは、 Red Hat OpenShift クラスター仮想マシン (VM) または bastion VM を再始動しないでください。

最初の証明書ローテーションの後、証明書は 30 日ごとに更新されます。証明書ローテーションごとに CSR を承認するプロセスを確立する必要があります。Red Hat® によれば、CSR はその有効期限の 80% (CSR の有効期間開始の約 25 日後) に達したときに承認することができます。

CSR を時間内に承認せず、証明書の有効期限が切れた場合でも、有効期限切れのコントロール・プレーン証明書からリカバリーして、Red Hat OpenShift クラスターを再び作動可能にすることができます。 詳細については 、「期限切れの制御プレーン証明書の復旧 」を参照してください。

Red Hat OpenShift VMのサイズ変更

1. SSH を使用して、bastion VM にログインします。
2. root ユーザーになります。sudo -i
3. ターゲット VM をシャットダウンします。ssh core@<vm-ip> sudo shutdown -h 0
4. VM をパワーオフした後に、vCenter Server 内で VM をサイズ変更します。
5. VM をパワーオンします。
6. Red Hat OpenShift コンソールで、 **「コンピュート (Compute)」>「ノード (Nodes)」**に移動し、再始動された VM が 「作動可能 (Ready)」 状態に戻るのを待ちます。
7. すべての VM について前述の手順を実行します。

Red Hat OpenShift、SSHキーを変更する。 VM

インストール時に生成される SSH 鍵ペアは、 Red Hat OpenShift bastion VM 上にあります。SSH 鍵ペアの場所は、Red Hat OpenShift サービスの詳細ページに示されています。 この SSH 鍵はすべてのクラスター VM にインストールされているので、パスワードを必要とせずに bastion からの SSH ログインが可能です。

新しい SSH 鍵ペアを生成し、これを使用して既存の鍵を置き換えることをお勧めします。新しい SSH キー ペアを生成する方法の詳細については、 Red Hat OpenShift でのインストール後に SSH キーを更新する方法」を参照してください。 コマンドは bastion VM から実行する必要があります。 bastion へのログインについて詳しくは、Bastion の詳細を参照してください。

Red Hat OpenShift クラスターをより多くのワーカーで拡大する

ワーカー VM を追加して Red Hat OpenShift クラスターを拡張するには、以下のステップを実行します。

1. RHCOREOS テンプレートからワーカー VM を作成します：

   1. VM を他の Red Hat OpenShift ワーカー VM と同じネットワークに接続しておきます。
   2. さらに設定手順が必要なので、この VM の電源はまだ入れないでください。

2. 要塞の労働者発火ファイルを準備する：

   1. bastion へのログインについて詳しくは、Bastion の詳細を参照してください。
   2. bastion 上のインストール・ディレクトリーで、worker.ignという名前のワーカー ignition ファイルを見つけます。 コマンド base64 -w0 worker.ign > worker.ign.b64 を使用して、このファイルの base64 バージョンを作成します。 次のステップでは、新しく作成した worker.ign.b64 ファイルの内容を使います。

3. VM アトリビュートを設定する：

   1. 始める前に、 VM の電源を切ってください。 次に、Configuration Parameters ウィンドウで、新しいワーカー VM を選択し、 Actions > Edit Settings をクリックします。
   2. 「設定の編集」ウィンドウで、**「VM オプション」タブをクリックします。 左側の「詳細」をクリックして、ウィンドウ内で「アドバンスト」セクションを展開します。 その後、左側の「構成パラメータ」**にスクロールダウンします。設定の編集をクリックします。
   3. 通常は、「構成パラメータ」ウィンドウに、VM の既存のパラメーターの長いリストが表示されます。 値を追加するには、**「構成パラメータの追加」**をクリックします。 **「名前」と「値」**というラベルが付いた 2 つの空のフィールドが表示されるので、入力します。 以下の3つのステップにこのプロセスを使用する。
   4. guestinfo.ignition.config.data という値を作成し、先に作成した base64-encoded イグニッション設定ファイル worker.ign.b64 の内容に設定する。
   5. guestinfo.ignition.config.data.encoding という値を作成し、文字列 base64 に設定する。
   6. disk.EnableUUID という値を作成し、文字列 TRUE に設定する。
   7. 新しいパラメーターを作成したら、OK を2回クリックして開いたウィンドウを閉じます。

4. ワーカー VM の DHCP バインディングを作成します。

   1. NSX-T™ にログインします。
   2. **「ネットワーキング」>「セグメント」**に移動します。
   3. ocp-internal セグメントを編集します。
   4. **「DHCP 静的バインディング (DHCP Static Bindings)」を展開し、「設定」**をクリックして「静的バインディングの設定 (Set Static Bindings)」ウィンドウを開きます。
   5. 既存のバインディングのリストを確認し、次に使用可能な IP アドレスをメモします。
   6. 既存のワーカー・バインディングの 1 つを調べ、後で必要になる情報を確認します。 ゲートウェイ・アドレスと DHCP オプションをメモします。 DHCP オプションを表示するには、**「DHCP オプション (DHCP Options)」の横の「設定」**をクリックします。 Options］ウィンドウで、 ［Select DHCP Option］ リストから［ Generic Options］を選択します。 設定されているオプションをメモします。
   7. 調べた既存のバインディングを閉じると、「静的バインディングの設定 (Set Static Bindings)」ウィンドウに戻ります。
   8. **「IPV4 静的バインディングの追加 (Add IPV4 Static Binding)」**をクリックします。 先程メモした DHCP オプションを含め、新規ワーカーの詳細を入力します。
   9. 完了したら**「保存」**をクリックして変更をコミットします。

5. ワーカーをロード・バランサー・プールに追加します。

   1. **「ネットワーキング」>「ロード・バランサー」>「サーバー・プール (Server Pools)」**に移動します。
   2. サーバープールの編集 ocp-apps.
   3. 編集ウィンドウのメンバー/グループの下で、青い数値リンクをクリックします。 デフォルトは 3 です。
   4. 「サーバー・プール・メンバーの構成 (Configure Server Pool Members)」ウィンドウが開いたら、**「メンバーの追加」**をクリックします。
   5. 新規ワーカーの名前と IP アドレスを入力します。 ポート番号は空のままにしておきます。
   6. 保存をクリックし、適用をクリックします。

6. 新しいワーカーの DNS レコードを作成する：

   1. VCF for Classic - Automated インスタンスの AD NS サーバーにログインします。
   2. DNS マネージャーを使用して、対応する ocp ゾーンに新しい A レコードを追加します。Aレコードを作成する際、関連するPTRレコードを作成するオプションが選択されていることを確認してください。

7. bastion からの証明書署名要求 (CSR) を承認します。 新しいワーカーのプロビジョニングの間に、あなたはベースジョンからの CSRを承認しなければならないかもしれない：

   1. root ・ユーザーとしてbastionにログインし、bastionのインストール・ディレクトリに移動する。 詳細は バスティオンの詳細 を参照。

   2. コマンドを実行する前に、 Red Hat OpenShift への認証が必要です：

      • 認証が構成されておらず、デフォルトの kubeadmin アカウントとパスワードを使用している場合は、コマンド export KUBECONFIG=auth/kubeconfig を実行し、コマンド ./oc whoami を実行して認証されていることを確認します。
      • 他のバックエンドまたはユーザーが認証済みである場合は、Red Hat OpenShift の資料で説明されているように、これらのアカウントのいずれかを使用してログインします。例えば、コマンド ./oc login を実行します。

   3. ./oc get nodes を実行して、新規ワーカーが表示されるか確認します。Ready 状態でない場合は、コマンド ./oc get csr を使って保留中のCSRを繰り返しチェックし、コマンド ./oc adm certificate approve <csr_name> を使ってCSRを承認する。コンフィギュレーションが完了し、新しいワーカーがレディ状態になるまでチェックを続けます。

      新規ワーカーが作動可能状態になったら、それを Red Hat OpenShift で使用できるようになります。

8. VM の電源を入れる：

   • VM をパワーオンしたら、VM をモニターして問題があるかどうかを確認できます。VM は IP アドレスを取得し、ignition ファイルを処理してから、ログイン・プロンプトを開きます。

   • ログイン・プロンプトが表示されても、コンソール・ログ・メッセージで覆われてしまう場合があります。必要であれば、コンソールでEnterキーを数回押す。 ログイン・プロンプトが表示されているが、コンソール・ログ・メッセージで覆われている場合は、Enterキーを押してログイン・プロンプトを再度表示する。

   • ログインプロンプトが表示されない場合は、以下の可能性があります：

     • 現在 VM は IP アドレスを取得していない。 VM が接続されているネットワークを確認してください。 また、DHCPバインディング設定も確認してください。
     • worker.ign.64 の base64 の値が正しくない。 いくつかの文字が欠落しているか、余分な文字が含まれている可能性があります。 値を調べて確認してください。

     VM がログイン・プロンプトを表示しなかったために設定を変更する必要がある場合は、VM をパワーオフし、必要な設定を変更してから再度パワーオンしてください。

Red Hat OpenShift を削除する際の注意点 VMware

• Red Hat OpenShift for VMware を削除する前に、VMware 上の ocp ディレクトリーに作成した追加の VM をすべて削除する必要があります。 VMware ソリューションの自動機能では、Red Hat OpenShift の最初のインストール時にデプロイされた項目 (VM、ストレージ、および NSX) のみが削除されます。 インストール後に配置されたノードは削除されません。
• Red Hat OpenShift VMware の初期導入時に作成された VXLAN、DLR、およびエッジゲートウェイは削除されます。 VMware の Red Hat OpenShift を削除すると、VXLAN 上にデプロイした VM は接続性を失います。
• クラスタが NFS ストレージを使用している場合、 Red Hat OpenShift を削除すると、インストール時に追加された NFS データ・ストアが削除されます。
• vSAN データ・ストアを使用している場合は、Red Hat OpenShift をアンインストールする前に、不要になった永続ボリュームがあればそれらを削除してください。削除されないボリュームは、Red Hat OpenShift のアンインストール後も vSAN ストレージに残ります。
• サービスを削除する前に、このサービスとともにデプロイされた個人用VMをストレージから削除する必要があります。 Red Hat OpenShift 個人用VMのみを注文し、それらは vSAN-based。