第16章 ホストされたコントロールプレーンの更新

OpenShift Container Platform のホストされたコントロールプレーンでは、更新はコントロールプレーンとノード間で切り離されます。クラスターコントロールプレーンをホストするユーザーであるサービスクラスタープロバイダーは、必要に応じて更新を管理できます。ホストされたクラスターはコントロールプレーンの更新を処理し、ノードプールはノードのアップグレードを処理します。

16.1. ホストされたコントロールプレーンの更新

ホストされたコントロールプレーンの更新には、ホストされたクラスターとノードプールの更新が含まれます。更新プロセス中にクラスターが完全に動作し続けるためには、コントロールプレーンとノードの更新を完了する際に、Kubernetes バージョンスキューポリシー の要件を満たす必要があります。

16.1.1. ホストされたクラスターの更新

spec.release 値は、コントロールプレーンのバージョンを決定します。HostedCluster オブジェクトは、意図した spec.release 値を HostedControlPlane.spec.release 値に送信し、適切なコントロールプレーン Operator バージョンを実行します。

ホストされたコントロールプレーンは、新しいバージョンの Cluster Version Operator (CVO) を通じて、OpenShift Container Platform コンポーネントとともにコントロールプレーンコンポーネントの新しいバージョンのロールアウトを管理します。

16.1.2. ノードプールの更新

ノードプールを使用すると、spec.release および spec.config の値を公開することで、ノードで実行されているソフトウェアを設定できます。次の方法でノードプールのローリング更新を開始できます。

  • spec.release または spec.config の値を変更します。
  • AWS インスタンスタイプなどのプラットフォーム固有のフィールドを変更します。結果は、新しいタイプの新規インスタンスのセットになります。
  • クラスター設定を変更します (変更がノードに伝播される場合)。

ノードプールは、置換更新とインプレース更新をサポートします。nodepool.spec.release 値は、特定のノードプールのバージョンを決定します。NodePool オブジェクトは、.spec.management.upgradeType 値に従って、置換またはインプレースローリング更新を完了します。

ノードプールを作成した後は、更新タイプは変更できません。更新タイプを変更する場合は、ノードプールを作成し、他のノードプールを削除する必要があります。

16.1.2.1. ノードプールの置き換え更新

置き換え 更新では、以前のバージョンから古いインスタンスが削除され、新しいバージョンでインスタンスが作成されます。この更新タイプは、このレベルの不変性がコスト効率に優れているクラウド環境で効果的です。

置き換え更新では、ノードが完全に再プロビジョニングされるため、手動による変更は一切保持されません。

16.1.2.2. ノードプールのインプレース更新

インプレース 更新では、インスタンスのオペレーティングシステムが直接更新されます。このタイプは、ベアメタルなど、インフラストラクチャーの制約が高い環境に適しています。

インプレース更新では手動による変更を保存できますが、kubelet 証明書など、クラスターが直接管理するファイルシステムまたはオペレーティングシステムの設定に手動で変更を加えると、エラーが報告されます。