コントロール・プレーン・ホストの更新前の考慮事項

Satellite ロケーション・コントロール・プレーンのホストを更新する前に、以下の考慮事項を確認してください。

バージョンアップが利用可能かどうかはどうやって確認すればよいですか？

Red Hat OpenShift on IBM Cloud チームがワーカー・ノード用の新規バージョンをパッケージ化すると、ホスト用のバージョン更新が利用可能になります。 通常、ワーカー・ノードのバージョン更新は 2 週間ごとにリリースされます。

月次や隔月など、必要なセキュリティ更新サイクルに合わせて、バージョンの更新がないか確認してください。 使用可能なバージョン更新を確認するには、Red Hat OpenShift on IBM Cloud のバージョン変更ログを参照してください。

また、コマンドラインインターフェース（CLI）を使用することで、どのコントロールプレーンホストを更新する必要があるかを素早く特定することもできます。 ibmcloud sat location ls、 ibmcloud sat location get、 ibmcloud sat hosts、または ibmcloud sat host get を実行する際は、 「Status」 または 「State」 列に、古くなったホストを示す記号がないか確認してください。 詳細については、「 更新が必要なコントロールプレーンホストの特定 」を参照してください。

hosts ファイルの更新は、 Satellite のロケーション制御プレーンで実行されているクラスタマスターに影響を与えますか？

はい。 クラスター・マスターは Satellite ロケーション・コントロール・プレーンで実行されるため、ホストを更新する前に、コントロール・プレーンに十分な追加ホストがあることを確認してください。 追加のホストを接続するには、Attaching capacity to your Satellite location control plane を参照してください。

Satellite が有効になっている IBM Cloud サービスのホストは、 Satellite のロケーション・コントロールプレーンと同じバージョンを実行している必要がありますか？

いいえ、 Satellite のロケーションのコントロールプレーンに割り当てられているホストは、そのロケーション内で実行されている Satellite が有効な IBM Cloud サービスに割り当てられているホストと同じバージョンを実行している必要はありません。 ただし、そのロケーション内のすべてのホストでは、サポートされているバージョンを実行する必要があります。

ホストで実行できるサポート対象の Red Hat OpenShift バージョンを確認するには、Red Hat OpenShift on IBM Cloud の資料を参照するか、コマンド・ラインで ibmcloud ks versions を実行します。

ホストを更新しても、 Satellite のロケーション制御プレーンのサブドメインには引き続きアクセスできますか？

ロケーション・サブドメインが自動的に作成された場合は、更新時などで、サブドメインに登録されているホスト IP アドレスが自動的に管理されます。

Satellite ロケーション・コントロール・プレーンの作成時に、ibmcloud sat location dns register コマンドを使用して、ホスト IP アドレスをロケーション・サブドメインに手動で登録した場合は、開始する前にコントロール・プレーンに 3 つのホストを必ず接続して、これらのホスト IP をサブドメインに手動で登録してください。 これで、これらの新しいホストはロケーションに対する要求を処理します。 その後、以前にサブドメインに使用されていたホストを更新できます。

コントロールプレーンのバージョンを確認する方法は？

ibmcloud sat location get --location <locationID> --json を実行し、 masterKubeVersion フィールドを確認する。

コントロールプレーンのノードを置き換える際に適用されるバージョンは？

新しいノードのマイナーバージョンは、コントロールプレーンのマイナーバージョンと一致する。 パッチバージョンは、最新の脆弱性修正を含む最新のワーカーパッチバージョンです。

コントロールプレーンのバージョンはクラスタのバージョンと一致する必要がありますか？

いいえ コントロールプレーンで使用される Satellite のロケーションバージョンは、クラスタホストで使用されているバージョンと必ずしも一致するとは限りません。 コントロール・プレーンは自分で更新するが、利用可能な最新のコントロール・プレーンのバージョンは IBM によって決定される。 クラスタホストは、コントロールプレーンよりも新しいバージョンを使用できます。

コントロール・プレーンを更新する際のダウンタイムを回避するには？

更新プロセスに従うことで、すべてのコントロールプレーンコンポーネントがノード上で実行できるようになり、障害が発生しないことが保証されます。 一度に1つのワーカーだけを更新し、ノードが完全に機能するのに十分な時間を置いてから次のワーカーを開始するようにしてください。

コントロールプレーンのホストはどれくらいの頻度でアップデートすべきでしょうか？

新しいワーカーノード修正パックが利用可能になったら、コントロールプレーンホストを更新して、最近の脆弱性の修正をすべて取り込むことをお勧めします。

更新が必要なコントロールプレーンホストの特定

CLIおよびコンソールには、古いバージョンを実行しているコントロールプレーンホストを素早く特定できる視覚的なインジケーターが用意されており、問題が深刻化する前に更新を優先的に行うことができます。

コントロール・プレーン・ホストの更新

バージョン更新を適用するには、ホストを分離して再読み込みし、再度接続してから、コントロールプレーンまたは別のロケーションリソースに再割り当てしてください。

コントロール・プレーン・ホストを更新する場合は、同時に複数のホストを割り当てたり削除したりしないでください。そうするとコントロール・プレーンが壊れる可能性があります。 あるホストの割り当てまたは削除が完了するまで待ってから、別のホストの割り当てまたは削除を行う必要があります。

1. オプション: 既存のホストの更新中に計算容量を処理するため、Satellite ロケーション・コントロール・プレーンに追加のホストを接続し、割り当てます。
2. 更新するホストを Satellite ロケーションから削除します。
3. インフラストラクチャー・プロバイダーからの指針に従って、ホストのオペレーティング・システムを再ロードします。
4. Satellite ロケーションにホストを接続します。
5. Satellite ロケーション・コントロール・プレーンにホストを割り当てます。

ブートストラップ・プロセスの一部として、クラスター・マスターに一致する最新のイメージと Red Hat OpenShift のバージョンがホストで更新され、ホストへの SSH アクセスが削除されます。

Kubernetes APIサーバーの更新

Kubernetes API を更新しても、コントロールプレーンのホストは更新されません。

Kubernetes API サーバーを更新するには、 cluster master update コマンドを実行します。

ホスト鍵のリセット

Satellite ロケーション内のすべてのホストと通信するためにコントロール・プレーンが使用するキーをリセットします。

ロケーションを作成すると、APIキーが生成されます。このAPIキーは、 Satellite APIサーバーが、ホストをそのロケーションに関連付け、コントロールプレーンまたは Satellite 対応の IBM Cloud サービス にホストを割り当てる際に使用されます。 生成された API キーは、機密情報として扱われ、保護される必要があります。 このキーは 365 日ごとに有効期限が切れます。 鍵の有効期限が切れると、 未割り当てホストは unresponsive 状況 になります。 追加のホストを接続するには、そのロケーションから 新規ホスト接続スクリプトをダウンロード し、それを使用してホストを接続する必要があります。 既存の割り当て済みホストは影響を受けません。

鍵の有効期限が切れる前に、既存のホスト鍵をリセットすることができます。 Satellite のロケーションのホスト・キーをリセットするには、 --reset-key オプションを指定して ibmcloud sat host attach コマンドを実行します。

ibmcloud sat host attach --location LOCATION_NAME --reset-key

Satellite のロケーションでTerraformを使用している場合、ホストキーの有効期限が切れたか、手動でリセットしたかといった理由でホストキーがリセットされると、割り当て済みのホストを含め、すべてのホストを置き換えるよう求められます。 この問題は、Terraform スクリプトを更新することで回避できます。 詳しくは、 ホスト接続スクリプトが Terraform で状態変更をトリガーするのはなぜですか? を参照してください。

コントロールプレーンを新しい Red Hat Enterprise Linux （RHEL）バージョンへ移行する

古いバージョンの RHEL 上でコントロールプレーンのホストを置き換えるには、 まず、使用したい新しいバージョンの RHEL 上でホストを追加する必要があります。 ロケーションに新しいホストをアタッチし、それらをコントロールプレーンに割り当てた後、同じゾーンの古いホストをコントロールプレーンから削除することができます。

RHELの新しいバージョンへ移行する前に、 Red Hat CoreOS （RHCOS）が、 CoreOS が有効になっている地域において、サポート対象のOSとなっていることにご留意ください。 RHCOSは、 Red Hat OpenShift エコシステムと緊密に統合された、最小限かつ安全なOSであり、メジャーバージョンのインプレースアップグレードが可能です。 お使いのロケーションでRHCOSホストを使用するには、まず Red Hat CoreOS を有効にしたロケーションを作成する必要があります。 RHCOS が有効になっているロケーションが既にある場合は、代わりに RHCOS ホストを追加することを検討してください。 Red Hat CoreOS を有効にした Satellite ロケーションを作成するには、「 ロケーションの概要 」を参照してください。

1. 以下のコマンドを実行して、置換するホストと、それらのホストが配置されているゾーンを識別します。 出力ファイルで、 "os" ラベル、または os ラベルのないホストを探します。

   ibmcloud sat hosts --location LOCATION_ID --output json
   

   以下の出力例は、 "os": "RHEL7" ラベルを示しています。 このホストは us-south-1 ゾーンにあります。

   [
       {
           "id": " LOCATION_ID",
           "name": "LOCATION_NAME",
           "labels": {
               ...
               "os": "RHEL7"
               ...
           "state": "assigned",
           "assignment": {
               "zone": "us-south-1",
           },
       },
   ...
   ]
   

2. その場所用のホスト接続スクリプトをダウンロードしてください。

   ibmcloud sat host attach --location LOCATION_ID
   

3. 特定されたゾーンの Satellite の場所に新しい RHEL ホストをプロビジョニングし、そのホスト上でホストアタッチスクリプトを実行する。 このプロセスは、インフラストラクチャーによって異なります。 詳しくは、 ご使用のロケーションへのホストの接続 を参照してください。

4. ホストがロケーションにアタッチされた後、 host assign コマンドを使って、そのホストをロケーションコントロールプレーンに割り当てることができます。

   ibmcloud sat host assign --host HOST_NAME --location LOCATION_ID --cluster infrastructure --zone ZONE
   

5. 新しいホストをコントロールプレーンに割り当てた後、新しいホストが追加された同じゾーンから古いホストを削除することができます。

   ibmcloud sat host rm --location LOCATION_ID --host HOST_NAME
   

すべての古いコントロールプレーンホストが新しいホストに置き換えられ、その場所から削除されるまで、この手順を繰り返します。