この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。

ノードメンテナンスおよびKubernetesアップグレードガイド

計画されたノードメンテナンスの処理およびクラスターのKubernetesバージョンのアップグレードに関する指示に従ってください。

ノードOSまたはコンテナランタイムの更新

  1. ノードをコルドンします。Kubernetesノードがコルドンされると、Longhornは自動的にノードスケジューリングを無効にします。

  2. ノードをドレインして、ワークロードを他の場所に移動します。

    ノードをドレインするには`--ignore-daemonsets`を使用する必要があります。--ignore-daemonsets`が必要です。なぜなら、Longhornは`Longhorn managerLonghorn CSI plugin、`engine image`などのいくつかのデーモンセットをデプロイしたからです。

    ドレインが進行している間、ノード上のエンジンプロセスはワークロードポッドと共に他のノードに移行されます。

    ノード上でCSIフローを介して接続されていないボリューム(例えば、UIを使用して手動で接続されたもの)は、ドレイン中にKubernetesによって新しいノードに自動的に接続されません。したがって、Longhornはノードがドレイン操作を完了するのを防ぎます。ユーザーは、ドレインを解除するためにこれらのボリュームを手動で切り離す必要があります。

    ドレインが進行している間、ノード上のレプリカプロセスは、ノードドレインポリシーに基づいて実行を続けるか、最終的に追い出されて停止します。

    デフォルトでは、ノード上のボリュームに対して最後の健康なレプリカが1つある場合、Longhornはノードがドレイン操作を完了するのを防ぎ、最後のレプリカを保護し、ワークロードの中断を防ぎます。この動作は、設定ノードドレインポリシーまたはドレイン前にレプリカを他のノードに追い出すで制御できます。ポリシーを選択する際の考慮事項については、ノードドレインポリシー推奨事項を参照してください。

    ドレインが完了した後、ノード上でエンジンまたはレプリカプロセスが実行されているべきではありません。なぜなら、それらを実行していたインスタンスマネージャーポッドが停止されるからです。ノードドレインポリシーに応じて、ノードにスケジュールされたレプリカは`Failed`として表示されるか、置き換えのために削除されます。Longhornボリュームを使用しているワークロードは期待通りに機能し、ポリシーの要件を満たすために他の場所で十分なレプリカが実行されます。

    通常、他のノードに健康なレプリカがある限り、ドレイン操作の前にレプリカを追い出す必要はありません。ノードが再びオンラインになり、コルドンが解除されると、レプリカは後で再利用できます。詳細なガイダンスについては、ノードドレインポリシーを参照してください。
  3. ノードをシャットダウンまたは再起動するなど、必要なメンテナンスを実施してください。

  4. ノードのコルドンを解除します。Longhornは自動的にノードスケジューリングを再有効化します。ノードに既存のレプリカがある場合、Longhornはそれらのレプリカを使用して再構築プロセスを加速する可能性があります。Longhornが再利用可能なレプリカが利用可能になるまでの待機時間をカスタマイズするには、レプリカ補充待機間隔設定を設定できます。

ディスクの削除

ディスクを削除するには:

  1. ディスクスケジューリングを無効にします。

  2. ディスク上のすべてのレプリカを追い出します。

  3. ディスクを削除します。

ノード名の再利用

これらの手順は、同じノード名を使用してノードを置き換えた場合にも適用されます。新しいノードが起動すると、Longhornはディスクが異なることを認識します。以前のノードと同じ名前を使用する場合、最初に元のディスクを削除し、新しいノードに追加する必要があります。

ノードの削除

ノードを削除するには:

  1. ディスクスケジューリングを無効にします。

  2. ノード上のすべてのレプリカを追い出します。

  3. ノード上のすべてのボリュームをデタッチします。

    ノードがドレインされている場合、すべてのワークロードはすでに別のノードに移行されているはずです。

    他に接続されたままのボリュームがある場合は、続行する前にそれらをデタッチしてください。

  4. Longhornからノードを削除するには、`Delete`タブ内の`Node`を使用してください。

    または、次のコマンドを使用してKubernetesからノードを削除します:

    kubectl delete node

  5. Longhornは自動的にクラスタからノードを削除します。

Kubernetesのアップグレード

インプレースアップグレード

インプレースアップグレードするとは、ノードがクラスタから削除されることなくアップグレードされる方法です。このアップグレード方法を使用するいくつかの例のソリューションは、 SUSE® Rancher Prime: K3s自動アップグレードSUSE Rancher PrimeのKubernetesアップグレードガイドKubeadmアップグレードなどです…​。

ノードとディスクが削除/除去されないことを前提とした場合、推奨されるアップグレードガイドは次のとおりです:

  1. Kubernetesコンポーネントをアップグレードする前に、ノードをコルドンし、ドレインします。ドレイン手順は、ノードOSまたはコンテナランタイムの更新の手順に似ています。

  2. ドレイン`--timeout`は、健全なノードでのレプリカ再構築がノードのアップグレード間に完了するのに十分な長さである必要があります。ドレイン中のノードにLonghornレプリカが多いほど、他の健全なノードでLonghornレプリカが再構築されるのにかかる時間が長くなります。十分な値をテストして選択するか、0(つまりタイムアウトしない)に設定することをお勧めします。

  3. 同時にアップグレードするノードの数は、各ボリュームのLonghornレプリカの数よりも少なくする必要があります。 これは、実行中のLonghornボリュームが常に少なくとも1つの健全なレプリカを持つことを保証するためです。

  4. デタッチされたボリュームの最後の健全なレプリカによってドレインがブロックされないように、設定ノードドレインポリシーを`allow-if-replica-is-stopped`に設定することを検討してください。ポリシーを選択する際の考慮事項については、ノードドレインポリシーの推奨事項を参照してください。

ノードドレインポリシーの推奨事項

現在、選択可能なノードドレインポリシーは5つあります。それぞれに利点と短所があります。このセクションでは、それぞれの一般的なガイダンスを提供し、どのような状況で使用されるべきかを提案します。

重要注意事項

ノードドレインポリシーは、ノードがアクティブにドレインされているときのLonghornの動作を管理することを目的としています。ただし、Longhornはノードのコルドンとドレインの違いを判断する方法がないため、ポリシーに応じて、ノードがコルドンされるたびにLonghornがアクションを取る可能性があります。

ノードドレインポリシーは、特定の条件が満たされるまで、ドレイン中にインスタンスマネージャーポッドの追放を防ぐために機能します。インスタンスマネージャーポッドが追放できない場合、ドレインは完了できません。これにより、ユーザー(または自動化されたプロセス)が安全でない場合にノードをシャットダウンまたは再起動し続けることが制限されます。ドレインのエラーを無視して、メンテナンス操作を続けることは魅力的かもしれませんが、これはLonghornのデータ保護能力を制限します。常にイベントやログを確認して、ドレインが進行しない理由を特定し、根本的な問題を修正するためのアクションを取ってください。

最後のレプリカを含む場合はブロック

これはデフォルトのポリシーです。利便性とデータ保護の良いバランスを提供することを目的としています。このポリシーが有効な間、Longhornは、ボリュームの最後の健全なレプリカを含むコーデンされたノードでインスタンスマネージャーポッドの退去(およびドレインの完了)を防ぎます。

利点:

  • 他のノードで利用可能な各ボリュームの健全なレプリカが利用可能になるまで、ドレイン操作の完了を防ぐことによってデータを保護します。

短所:

  • ボリュームにレプリカが1つしかない場合、または他のレプリカが不健全な場合、ユーザーは手動で(UIを通じて)ディスクまたはノードからレプリカの追放を要求する必要があります。

  • ドレインが完了した後、ボリュームが劣化する可能性があります。ノードが再起動されると、冗長性はノードが再稼働するまで低下します。ノードが削除されると、冗長性は別のレプリカが再構築されるまで低下します。

最後のレプリカが停止している場合を許可します。

このポリシーは`Block If Contains Last Replica`に似ています。本質的に安全性は低下しますが、ドレインをより迅速に完了させることができます。これは、最後の稼働中の健全なレプリカを含むノードで、インスタンスマネージャーポッドの退去(およびドレインの完了)を防ぎます。

利点:

  • ノードが再びオンラインになることが期待される状況(データは失われません)で、ノードのディスクに保存されているレプリカが積極的に使用されていない場合、ドレイン操作を進めることができます。

短所:

  • `Block If Contains Last Replica`に類似した欠点があります。

  • 何らかの理由でノードが再び稼働しない場合、データは失われます。

常に許可

このポリシーはデータを保護することはありませんが、排出を即座に完了させることができます。インスタンスマネージャーポッドの退去(およびドレインの完了)を決して防ぎません。本番環境では使用しないでください。

利点:

  • ドレイン操作は、Longhornが干渉することなく迅速に完了します。

短所:

  • Longhornがデータを保護する機会はありません。

退去のためにブロックします。

このポリシーは最大限のデータ保護を提供しますが、長いドレイン時間や不必要なデータ移動を引き起こす可能性があります。ノードにレプリカが残っている限り、インスタンスマネージャーポッドの退去(およびドレインの完了)を防ぎます。さらに、ノードからレプリカを自動的に退去させるためのアクションを取ります。

通常の使用時にこのポリシーを有効にしておくことは推奨されません。ノードがコーデンされるたびにレプリカの退去がトリガーされます。計画的なメンテナンス中のみ有効にしてください。

このポリシーの主な使用ケースは、冗長性のないボリュームを持つクラスターを自動的にアップグレードする場合です。 (numberOfReplicas == 1)他のポリシーは、レプリカが手動で追い出されるまでドレインを防ぎますが、これは自動化には不便です。

利点:

  • すべてのレプリカが移動されるまで、ドレイン操作の完了を防ぐことによってデータを保護します。

  • ユーザーが手動で行う必要がないように、レプリカを自動的に追い出します(UIを通じて)。

  • 常にレプリカの冗長性を維持します。

短所:

  • ドレイン操作は、他の動作に比べて著しく遅くなります。すべてのレプリカは、完了する前に別のノードで再構築されなければなりません。再構築中に移動するデータの量に応じて、ドレインタイムアウトを適切に調整する必要があります。

  • ドレイン操作はデータ集約型であり、特にレプリカ自動バランスが有効な場合、退去されたレプリカがドレインされたノードに戻される可能性があります。

  • これらのポリシーのすべてと同様に、ドレインではなくコーデン時にトリガーされます。ユーザーがノードをドレインせずに定期的にコーデンする場合、レプリカは無駄に再構築されます。

最後のレプリカを含む場合は退去のためにブロックする

このポリシーは、デフォルトの Block If Contains Last Replica のデータ保護を提供し、自動退去の便利さを追加します。発効中は、Longhornはボリュームの最後の健全なレプリカを含むコーデンされたノードで、インスタンスマネージャーポッドの退去(およびドレインの完了)を防ぎます。さらに、この条件を満たすレプリカはノードから自動的に追い出されます。

通常の使用下ではこのポリシーを有効にしておくことは推奨されません。ノードがコーデンされるたびにレプリカの退去がトリガーされる可能性があるためです。計画的なメンテナンス中のみ有効にしてください。

このポリシーの主な使用ケースは、冗長性のないボリュームを持つクラスターを自動的にアップグレードする場合です。 (numberOfReplicas == 1)他のポリシーは、レプリカが手動で追い出されるまでドレインを防ぎますが、これは自動化には不便です。

利点:

  • 他のノードで利用可能な各ボリュームの健全なレプリカが利用可能になるまで、ドレイン操作の完了を防ぐことによってデータを保護します。

  • ユーザーが手動で行う必要がないように、レプリカを自動的に追い出します(UIを通じて)。

  • ドレイン操作は、データを保護するために必要な遅さとデータ集約性だけです。

短所:

  • ドレインが完了した後、ボリュームが劣化する可能性があります。ノードが再起動されると、冗長性はノードが再稼働するまで低下します。ノードが削除されると、冗長性は別のレプリカが再構築されるまで低下します。

  • これらのポリシーのすべてと同様に、ドレインではなくコーデン時にトリガーされます。ユーザーがノードをドレインせずに定期的にコーデンする場合、レプリカは無駄に再構築されます。