クラスタ・ノードの移行
byoプロバイダを使用したKubernetesクラスタ間のノードの移行について説明します。
Kubernetesクラスタのノードは、あるクラスタから別のクラスタに移行できます。
あるクラスタから別のクラスタへのノードの移行は、ホストのプロビジョニングと同時にノードを既存のクラスタに結合するために必要なキー・マテリアルの追加を調整できない場合に最も役立ちます。 このような場合、1つのノード・クラスタを作成し、そのノードをターゲット・クラスタに移動する最も簡単なパスです。 このようにして、複数の小規模なクラスタを1つの大規模なクラスタにまとめることができます。
ノート:
OCKイメージを実行しているホストには、単一ノード・クラスタであっても、常にKubernetesクラスタが含まれます。
クラスタ間でのノードの移行には、2つのユースケースがあります。 ノードを完全に再プロビジョニングする必要なく、短期的な要件に基づいてクラスタ容量を調整するために、ノードを再割当てできます。 または、ノードをプロビジョニングして、後でクラスタに追加することもできます。
クラスタ間でのノードの移行は、システムまたはシステムのセットのプロビジョニング・リクエストが作成されたときと、そのリクエストが履行されたときに、インフラストラクチャ管理スキームにサービス・レベル合意がない場合に役立ちます。 たとえば、クラスタ管理者は8つのノードを必要とし、IT部門は不明なタイム・テーブルでリソースのリクエストを満たし、ノードが使用可能になったあとにアクセス情報を引き渡します。 リソースがプロビジョニングされたり、タイム・テーブルが提供されたりしても、管理者は必ずしも通知されません。 つまり、ノードがクラスタに参加するために必要なすべてのキー・マテリアル(証明書キーおよび結合トークン)が、新しいシステムの初回起動時に有効であることを保証することは困難です。 調整が可能であったとしても、IT部門は、手動のクラスタ・プロビジョニングを実行するのに十分なKubernetesクラスタ管理も理解する必要があります。 これは、一般的な独自の持込み(BYO)クラスタで実行可能なワークフローではありません。
説明されているユースケースを解決するために、意図したパスは、IT部門にいくつかのノードを作成するように依頼することです。 これらの各システムは、単一ノード・クラスタに自動的にブートします。 次に、管理者はこれらのノードを収集し、各ノードを大きなクラスタに移行することによって必要なクラスタ・トポロジを構築します。
2つのKubernetesクラスタが必要です。 任意のメソッドを使用してインストールできますが、目的のユース・ケースは、OCKがインストールされているが未構成であるホストをブートするか、2つのBYOクラスタをマージすることです。
クラスタ間で、同様の構成のノードおよびKubernetesバージョンを移行できます。 ソース・クラスタとターゲット・クラスタ上のKubernetesバージョンは同じである必要はありませんが、「近い」である必要があります。 十分に閉じることは、同じマイナーなKubernetesリリースまたは以前のマイナー・リリースに存在する必要があることを意味します。 たとえば、両方ともKubernetesリリース1.32.xを実行しているか、リリース1.31.xなど、1つ前のマイナー・リリースを実行している必要があります。
ocne cluster joinコマンドは、あるクラスタから別のクラスタにノードを移行するために使用します。 ソースおよびターゲット・クラスタの構成情報(kubeconfigファイル)と、移行するノードの名前を指定します。 ノードの名前は、kubectl get nodesコマンドの使用時に表示される名前と同じである必要があります。 ノードの名前は、移行時に変更されません。 ノード名は同じままです。
ノードは、ocne cluster joinコマンドの--role-control-planeノード・オプションを指定しないかぎり、ワーカー・ノードとして移行されます。
また、ocne cluster joinコマンドを使用してイグニッション情報を生成し、ノードをBYOクラスタに結合することもできます。 たとえば:
ocne cluster join --kubeconfig $HOME/.kube/kubeconfig.mycluster --config byo.yaml > worker.ign重要:
クラスタ内の最後のコントロール・プレーン・ノードを移行すると、そのクラスタが破棄されます。 最初にすべてのワーカー・ノードを移行または削除します。