Kubernetesバージョンのクラスターを更新する場合、コントロールプレーンを更新してからオフピーク時にノードプールを更新する必要があります。 ノードプールの更新中に、kubeletとコンテナランタイムが更新されます。 Container Service for Kubernetes (ACK) は、ノードプールを更新する前に事前チェックを実行します。 シームレスな更新を確実にするために、事前チェックは更新のリスクを通知します。
使用上の注意
ノードスケーリング
クラスターに対してノードスケーリングが有効になっている場合、クラスターが更新された後、クラスターは自動的にcluster-autoscalerコンポーネントを最新バージョンに更新します。 これにより、自動スケーリング機能が期待どおりに機能します。 クラスターの更新後、cluster-autoscalerのバージョンが最新バージョンに更新されているかどうかを確認します。 詳細については、「ノードの自動スケーリングの有効化」をご参照ください。
クラスターの更新中に、スケーリングモードが迅速モードに設定されているノードは、ノードがシャットダウンしているため、更新に失敗する場合があります。 クラスターの更新後に迅速モードのノードを更新できない場合は、手動でノードを削除することを推奨します。
クラスターのKubernetesバージョンを1.18に更新すると、ACKはリソース予約を自動的に設定します。 リソース予約がクラスターに設定されておらず、ノードのリソース使用率が高い場合、ACKは、クラスターの更新後にノードに追い出されたポッドをスケジュールできない可能性があります。 ノードに十分なリソースを確保します。 CPU使用率は50% を超えず、メモリ使用率は70% を超えないことを推奨します。 詳細については、「リソース予約ポリシー」をご参照ください。
Kubernetes 1.24以前を実行するクラスター内のポッドが起動プローブのみで設定されている場合、kubeletが再起動された後、ポッドは一時的にNotReady状態のままになることがあります。 マルチレプリカ展開戦略を使用して複数のノードにワークロードを分散し、ノードの再起動時にポッドが十分であることを確認することを推奨します。
LoadBalancerサービスによって公開されるServer Load Balancer (SLB) インスタンスのIPアドレスを使用してポッドが同じノード上の別のポッドにアクセスし、サービスのexternalTrafficPolicyがLocalに設定されている場合、ノードの更新後に2つのポッドが同じノードに存在しなくなります。 これにより、ネットワーク障害が発生します。カスタムOSイメージは、ACKによって厳密に検証されません。 ACKは、カスタムOSイメージを使用するクラスターのクラスター更新の成功を保証するものではありません。
クラスターを更新するには、Yumを使用して必要なソフトウェアパッケージをダウンロードする必要があります。 クラスターでカスタムネットワーク設定またはカスタムOSイメージを使用している場合は、Yumが期待どおりに実行できるようにする必要があります。
yum makecacheコマンドを実行して、Yumのステータスを確認できます。クラスターが他のカスタム設定 (スワップパーティション、CLIを使用して変更されたkubelet設定、ランタイム設定など) を使用している場合、クラスターの更新に失敗したり、更新中にカスタム設定が上書きされたりする可能性があります。
システムディスクを交換してノードを更新すると、ACKはノードをドレインし、PodDisruptionBudget (PDB) に基づいてノードから他の使用可能なノードにポッドを追い出します。 高いサービス可用性を確保するために、マルチレプリカ配置戦略を使用して、複数のノードにワークロードを分散することを推奨します。 キーサービスのPDBを構成して、同時に中断されるポッドの数を制御することもできます。
ノードのドレインのデフォルトのタイムアウト時間は30分です。 ポッドの移行がタイムアウト期間内に完了しなかった場合、ACKは更新を終了し、サービスの安定性を確保します。
ノード上のポッドがhostPathボリュームを使用し、hostPathボリュームがシステムディスクを指している場合、システムディスクを置き換えることによってノードが更新された後、ホストパスボリューム内のデータが失われます。
ノードプールの更新中は、ノードプールのみをスケールアウトできます。 スケールインは許可されていません。
ノードがフリーノード (ノードプールで管理されていないワーカーノード) の場合、ノードを移行する必要があります。 詳細については、「ノードプールへの無料ノードの追加」をご参照ください。
説明
ノードプールの更新中に、kubeletとコンテナランタイムが更新されます。
kubelet: ノードプール内のすべてのノードのkubeletを制御プレーンと同じバージョンに更新します。 インプレース更新は、デフォルトでノードプールで実行されます。
コンテナランタイム: 新しいコンテナランタイムのバージョンが利用可能な場合、ノードプール内のノードのコンテナランタイムを新しいバージョンに更新できます。
コンテナランタイムをDockerからcontainerdに変更した場合、変更はノードプール内のノードのシステムディスクを置き換えることによって適用されます。 システムディスク内のすべてのデータがクリアされます。 システムディスクを交換してランタイム更新を実行する場合は、ノードプールを更新する前にシステムディスクの重要なデータをバックアップしてください。 詳細については、「コンテナランタイムをDockerからcontainerdに移行する」をご参照ください。
containerdバージョンを更新すると、デフォルトでノードプールに対してインプレース更新が実行されます。 各ノードの
/etc/containerd/config.tomlファイルは、ACKで提供される新しいバージョンに置き換えられます。説明ランタイム更新中に、ポッドプローブとライフサイクルフックが実行に失敗し、ポッドがインプレース再起動を実行する可能性があります。
手順
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のナビゲーションウィンドウで、 を選択します。
ノードプール ページで、更新するノードプールを見つけ、[操作] 列の [詳細] > [クベレットアップデート] を選択します。
更新オブジェクト (コンテナランタイムおよびkubelet) を表示し、更新するノード (すべてのノードまたは特定のノード) を指定し、更新方法を選択し、バッチ更新ポリシーを設定します。
更新方法
システムディスクを交換することによるノードプールのアップグレード: システムがノードプール内のノードのシステムディスクを交換するとき、システムはノードプール構成を使用してノードコンポーネントパラメーターをレンダリングします。 これにより、ノードコンポーネントとノードプールの構成が同じになります。
この更新方法を選択した場合は、ノードプールを更新する前にデータをバックアップするか、システムディスクに重要なデータを保存しないでください。 データディスクは更新の影響を受けません。
更新前にスナップショットを作成: ノードにシステムディスク上の重要なデータがある場合、[更新前にスナップショットを作成] を選択してノードのデータをバックアップおよび復元できます。 スナップショットの使用に対して課金されます。 詳細については、「スナップショット課金」をご参照ください。 スナップショットの作成の進行状況が動的に変わります。 更新後にスナップショットが不要になった場合は、できるだけ早い機会にスナップショットを削除してください。
一括更新ポリシー
バッチあたりの最大ノード数: バッチ内で同時に更新できるノードの最大数を指定できます。 最大10個のノードを指定できます。 更新プロセスの詳細については、「リファレンス: システムディスクの交換によるインプレース更新と更新」をご参照ください。
自動一時停止ポリシー: 更新中のノードの一時停止ポリシー。
バッチ間の間隔: 自動一時停止ポリシーを設定しない場合、更新バッチ間の間隔を設定するかどうかを指定できます。 バッチ間の間隔は5〜120分に設定できます。
事前チェック をクリックします。 事前チェックが完了したら、ページの指示に従って更新を開始します。
説明クラスターが事前チェックに失敗した場合、または事前チェックの結果に警告が含まれている場合は、クラスターチェック項目とクラスター問題の修正方法に関する提案を参照するか、ページの指示に基づいて事前チェックの詳細を確認して問題のトラブルシューティングを行います。
更新中に、[イベントローテーション] セクションで次の操作を実行できます。
一時停止: クラスターの更新を一時停止した後は操作を実行しません。 さらに、できるだけ早く更新を再開して完了することをお勧めします。 更新が7日を超えて一時停止されると、システムは自動的に更新プロセスを終了します。 更新処理中に生成されたイベントおよびログデータも削除されます。
[一時停止] をクリックした後、kubeletとコンテナーのランタイムを更新後にロールバックできません。
Cancel: 更新をキャンセルします。 [キャンセル] をクリックすると、更新がキャンセルされます。 この操作を実行した後、kubeletとコンテナーランタイムを更新した後にロールバックすることはできません。
更新後、[ノード] ページでノード名をクリックします。 [概要] タブで、ノードのkubeletバージョンとコンテナランタイムバージョンが目的のバージョンに更新されているかどうかを確認します。
リファレンス: インプレース更新と更新によるシステムディスク
システムディスクの交換によるインプレース更新と更新
次のセクションでは、インプレース更新とシステムディスクの交換による更新の手順について説明します。 バッチで同時に更新できるノードの最大数を指定できます。 最大10個のノードを指定できます。 バッチごとに更新されるノードの数は、1、2、4、8… 最大同時実行性に達すると、各バッチで更新されるノードの数は最大同時実行性に等しくなります。 たとえば、最大同時実行性を4に設定した場合、最初のバッチで1つのノードが更新され、2番目のバッチで2つのノードが同時に更新され、3番目以降のバッチで4つのノードが同時に更新されます。
次の図は、最大同時実行数がNの場合のバッチ更新プロセスを示しています。バッチごとに更新されるノードの数は、1、2、4、8、... 、Nの順序でバッチごとに増加します。
インプレース更新をノードで実行する方法
更新の前に事前チェックを実行します。 ttrpc要求処理の失敗やコンテナプロセスが信号に応答しないなど、コンテナに重大な問題がある場合、更新は一時停止されます。
現在のコンテナーとポッドのステータスをtmp一時ディレクトリに保存します。
containerd、crictl、および関連する構成ファイルを、ACKが提供する最新バージョンに更新します。 再起動は実行中のコンテナには影響しません。 ノードで
/etc/containerd/config.tomlファイルを変更した場合、更新によって変更が上書きされます。kubeletが期待どおりに実行され、ノードの準備ができていることを確認します。
システムディスクの交換によるノードの更新方法
ノードはドレインされます。 ノードがドレインされると、スケジュール不可に設定されます。
Elastic Compute Service (ECS) インスタンスが停止しています。
システムディスクが交換され、ディスクIDが変更されます。 システムディスクのカテゴリ、ECSインスタンスのIPアドレス、およびECSインスタンスにバインドされているelastic network Interface (ENI) のMACアドレスは変更されません。
ノードは再初期化される。
ノードが再起動され、準備が整いました。 ノードの準備が整うと、ノードはスケジューリング可能に設定される。
ノードがドレインされる前にノードがスケジュール不可能に設定されている場合、システムディスクを交換してノードが更新された後、ノードは自動的にスケジュール可能に戻りません。
よくある質問
ノードプールを更新した後、ノードプールをロールバックできますか?
kubeletとコンテナーランタイムは、更新後にロールバックできません。 更新後のOSイメージのみをロールバックできます。 使用する元のOSイメージは、ノードプールでサポートされている必要があります。
更新中にアプリケーションは影響を受けますか?
インプレース更新: ポッドは再起動されず、アプリケーションは影響を受けません。
システムディスクを交換して更新する: ノードは更新中にドレインされます。 アプリケーションが複数のノードにまたがる複数のポッドで実行され、そのポッドに対してグレースフルシャットダウンが有効になっている場合、アプリケーションは影響を受けません。 グレースフルシャットダウンの詳細については、「Kubernetesでのグレースフルシャットダウンとゼロダウンタイムのデプロイ」をご参照ください。 同じアプリケーションの複数のレプリカが同じバッチで更新されないようにするには、最大同時実行性をアプリケーションが実行されるポッドの数よりも少ない値に設定することをお勧めします。
バッチでノードを更新するにはどのくらいの時間が必要ですか?
インプレース更新: 5分以内。
システムディスクを交換して更新: スナップショットが作成されていない場合は8分以内。 [更新前にスナップショットを作成] を選択した場合、スナップショットの作成後にACKがノードの更新を開始します。 スナップショット作成のタイムアウト時間は40分です。 スナップショットの作成がタイムアウトすると、ノードの更新が開始されません。 システムディスクにビジネスデータが保存されていない場合は、更新前にスナップショットの作成をクリアすることを推奨します。
ノードの更新時にデータ損失が発生しますか?
システムディスクを交換して実行時の更新を実行する場合は、ノードプールを更新する前にデータをバックアップするか、システムディスクに重要なデータを格納しないでください。 データディスクは更新の影響を受けません。
ノードのシステムディスクが交換された後、ノードのIPアドレスは変更されますか?
システムディスクが交換された後、ディスクIDは変更されますが、システムディスクのカテゴリ、ECSインスタンスのIPアドレス、およびECSインスタンスにバインドされているENIのMACアドレスは変更されません。 詳細については、「インスタンスのオペレーティングシステムの置き換え」をご参照ください。
空きノードを更新する方法?
ノードプールに追加されないノードは、フリーノードと呼ばれます。 フリーノードは、ノードプール機能がリリースされる前に作成されたクラスターに存在します。 空きノードを更新するには、ノードをノードプールに追加し、ノードプールを更新します。 ノードプールに空きノードを追加する方法の詳細については、「ノードプールに空きノードを追加する」をご参照ください。
ノードのコンテナランタイムをDockerからcontainerdに変更した後、Dockerディレクトリがまだ存在し、ディスク領域を占有している場合はどうすればよいですか?
クラスター関連のコンテナー、イメージ、およびログに加えて、作成したファイルパスもDockerディレクトリに含まれます。 Dockerディレクトリのデータが不要になった場合は、手動でディレクトリを削除できます。
スナップショットからデータを復元するにはどうすればよいですか?
ノードプールを更新するときに、ノードプール内のノードのスナップショットを作成できます。 デフォルトでは、スナップショットは30日間保持されます。 スナップショットは、保存期間が終了する前に手動で削除できます。 ノードプールの更新後にデータが失われた場合は、次の方法を使用してデータを復元できます。
一括更新を実行してkubeletのみを更新する場合は、スナップショットを使用してディスクをロールバックできます。 詳細については、「スナップショットを使用したディスクのロールバック」をご参照ください。
ノードプール内のノードのシステムディスクを置き換えることによってオペレーティングシステムまたはコンテナランタイムが更新された場合、スナップショットからディスクを作成できます。 詳細については、「スナップショットからのディスクの作成」をご参照ください。
関連ドキュメント
クラスターの自動更新を有効にして、O&Mの負荷を軽減できます。 詳細については、「クラスターの自動更新」をご参照ください。
containerdのリリースノートの詳細については、「containerdのリリースノート」をご参照ください。
管理対象ノードプールを作成し、ノードプールの自動共通脆弱性および露出 (CVE) パッチ適用機能を有効にすることができます。 詳細については、「自動CVEパッチ適用 (推奨) 」をご参照ください。
Kubernetesは1.24、組み込みコンテナランタイムとしてのDockerのサポートを停止する予定です。 ノードコンテナランタイムをDockerからcontainerdに移行する方法の詳細については、「コンテナランタイムをDockerからcontainerdに移行する」をご参照ください。
Dockerとcontainerdには異なるコマンドラインツールがあります。 詳細については、「Docker Engineとcontainerdが提供する一般的に使用されるコマンドの比較」をご参照ください。
できるだけ早い機会にOSイメージのバージョンを更新することを推奨します。 詳細は、「オペレーティングシステムの変更」をご参照ください。