※ 本記事は、Mickey Boxellによる”Introducing On Demand Node Cycling for Oracle Container Engine for Kubernetes“を翻訳したものです。

2023年5月11日

Oracle Container Engine for Kubernetes (OKE)のオンデマンド・ノードの循環のリリースを発表しました。この機能により、OKEクラスタの管理対象ワーカー・ノードの更新プロセスが簡略化されます。以前は時間がかかっていたこのタスクでは、ノードを手動でローテーションしたり、独自のソリューションを開発する必要がありました。現在は、KubernetesおよびホストOSのバージョンを更新することでノード・アップグレードを簡単に実行できるだけでなく、SSHキー、ブート・ボリューム・サイズ、カスタムのcloud-initスクリプトなどの他のノード・プール・プロパティも更新できるようになりました。

ノード・プール

Kubernetes環境内で、作業はワーカー・ノードにスケジュールされます。ワーカー・ノードは、コンテナの実行に必要なリソースを含む物理または仮想マシンです。ノード・プールと呼ばれるノードのグループには、プールで実行されているワーカー・ノードによって継承される一連の標準プロパティがあります。これらのプロパティーには、次の例が含まれます。:

  • Kubernetesバージョン

  • ホスト・イメージ

  • コンピュート・シェイプ

  • ノード・メタデータ(カスタムのcloud-initスクリプトおよび公開SSHキーを含む)

ノード・プールのプロパティの詳細は、「ノード・プールおよびワーカー・ノードのプロパティの変更」を参照してください。

クラスタには、異なる要件のワークロードをサポートするために、それぞれに独自のプロパティ・セットを持つ複数のノード・プールを含めることができます。たとえば、高パフォーマンス・コンピューティング(HPC)のユース・ケースをサポートするためにGPUシェイプを使用するノードのプールを1つ作成し、価格パフォーマンスを向上させるためにArmベースのシェイプを使用する別のプールを作成できます。

ノード・プールのKubernetesバージョンおよびホスト・イメージ・バージョン・プロパティを変更すると、クラスタをアップグレードできます。新しいバージョンがリリースされるたびにこれら2つのプロパティを最新の状態に保つことは、コンプライアンスを維持し、最新の機能アップデートを受け取る上で重要です。

更新の課題

ノード・プールのプロパティの更新は簡単ですが、ノード・プールのプロパティに加えた変更は、新しいワーカー・ノードにのみ適用されます。つまり、既存のノードは更新されません。ノードのフリートを手動で更新するか、独自のスクリプトを作成して、通常の操作用トイレに寄与する必要があります。プール内のノードのプロパティーを更新する手間は理論上は少ないように見えますが、実際にはそうでないことを多くのユーザーが共有しています。

パッチが適用され、準拠した新しいホストOSイメージが毎月、またはそれ以上定期的に提供されるとします。また、セキュリティ・チームは、この新しいイメージですべてのノードを更新することを期待しています。複数のノード・プールに何百ものノードがあり、各ノードにはすでにワークロードが実行されています。最初に、クラスタ・コントロール・プレーンが新しい作業をスケジュールしないように、これらのノードをコード化する必要があります。次に、アプリケーションの可用性を維持するために実装したポッド・ディスラプションの予算やその他のKubernetesの概念を尊重して、これらのノードから既存のワークロードを排出する必要があります。その間、クラスタ内のノード数を一時的にスケール・アップするか、同時に使用不可にするノード数を制限することによって、クラスタ内の他のノードに、これらのワークロードを再スケジュールするための十分な領域があることを確認する必要があります。ワークロードが1つのノードから排出され、新しいノードにスケジュールされたら、既存のノードを削除して、新しいOSバージョンを実行しているノードに置き換えることができます。毎月、各リージョンのすべてのクラスタのすべてのノードに対してこれを実行することを想像してください。このアクティビティを簡素化することは、プラットフォーム・チームとクラスタ・オペレータの生活に大きな影響を与えます。オンデマンド・ノード・サイクルの導入により、この更新プロセスは簡単になります。

オンデマンド・ノードの循環

オンデマンド・ノードの循環機能のリリースにより、ノード・プール内のすべての既存ノードの置換を、更新されたプロパティを実行するノードとともにトリガーできるようになりました。ノード・プールのプロパティは常に同じ方法で変更し、ノード・プール内のノードを循環させます。ノード・プールの更新およびサイクリング操作は相互に切り離され、ノード・プール内のノードに更新を適用するための独自のアプローチを引き続き使用できるオプションが提供されます。

ノード・プールのサイクルを選択した後、OKEは、プール内の既存のワーカー・ノードを自動的にコード化、ドレインおよび削除し、ノード・プールに指定されたコードンおよびドレイン・オプションに従って、またアプリケーションの可用性を維持するために作成したPodDisruptionBudgetsまたはその他のKubernetesのベスト・プラクティスも考慮します。

これにより、更新操作中に一時的に許可する追加ノードの数(maxSurge)と、更新操作中に使用できないようにするノードの数(maxUnavailable)を指定できるため、ワークロードをシフトできるクラスタ内の空き領域が確保されます。maxSurgeは、サービスの中断を回避するために十分な使用可能なノードを確保することで、アップグレード中の停止時間を防止するために役立ちます。maxUnavailableは、プールにノードを一時的に追加する必要性を回避することで、コストを低く保つために役立ちます。

既存のノード・プールで新しいワーカー・ノードが起動されると、指定した更新済プロパティを持つことになります。更新操作の終了時に、ノード・プール内のノードの数は、コンソールに表示されるノード・プールのノード数プロパティで指定された数に戻ります。

ノード・プールの循環動作

この例では、クラスタのノード・プールの詳細ページには、Kubernetesバージョン・プロパティが1.24.1に設定されたノード・プールが表示されています。これは、ノード・プールをサポートされている最新のKubernetesバージョンにアップグレードする必要があることを示します。

A screenshot of the Node pool details page in the Oracle Cloud Console.

このページには、ノード・プール内のノードのリストと、すべてのノードがKubernetes 1.24.1を実行していることも表示されます。

A screenshot of the Node pool details page showing the available nodes and their version number.

ページ上部の「編集」をクリックしてパネルを開き、ノード・プールのプロパティを構成します。Kubernetesバージョン・プロパティを、使用可能な最新のKubernetesバージョン1.25.4に更新します。Kubernetesバージョンの更新を保存するには、「変更の保存」をクリックします。

A screenshot of the Edit node pool with the menu for Version number expanded.

ノード・プールのプロパティは、更新されたKubernetesバージョンでリフレッシュされます。操作が完了すると、更新されたプロパティがノード・プールの詳細に表示されます。同じページで、「ノードを循環」をクリックしてダイアログを開き、循環操作を開始します。

A screenshot of the Node pool details page showing the updated node pool properties.

「循環ノード」ダイアログで、循環操作中にプールに追加するノードの最大数(maxSurge)または同時使用不可(maxUnavailable)に整数値またはパーセンテージ値を指定できます。両方の値を空白のままにすると、maxSurgeは1に設定され、maxUnavailableは0に設定されます。「循環ノード」をクリックして操作を開始します。

A screenshot of the Cycle nodes window.

循環をトリガーすると、ノード・プールのステータスが「UPDATING」に変わります。ページの下部に移動してNODEPOOL_CYCLING操作をクリックすると、作業リクエストのステータスをトラッキングできます。Kubernetesバージョン・プロパティを更新するために以前に作成されたNODEPOOL_UPDATE操作も表示されます。NODEPOOL_CYCLING作業リクエストをクリックすると、ログによって進行状況を追跡するために使用できる操作の詳細ビューが開きます。

A screenshot of the Work request details page showing the in-progress work request.

ノード・プール自体を監視して、新しいKubernetesバージョンを実行しているノードに置換された既存のノードを確認することもできます。

A screenshot of the Nodes section in the Console showing the in-progress nodes.

作業リクエストが完了し、既存のすべてのノードが置換されると、タスクは「成功」とマークされます。

A screenshot of the Work request details page showing a successful work request.

すべてのノードの準備ができ、更新されたKubernetesバージョンを実行できるようになりました。

A screenshot of the Nodes section showing the updated and active nodes.

ノードのサイクルはいつですか?

次の理由から、ノード・プールのプロパティを更新し、それらのプロパティをプール内のノードに適用できます。:

  • 新しいノード・シェイプ: チームは、アプリケーション要件が変更されたことを検出し、そのワークロードのパフォーマンス目標を達成するために、より大きなシェイプが必要になりました。クラスタ管理者は、ノード・プールのシェイプを更新し、オンデマンドのノード・サイクルを使用して更新をロールアウトします。

  • 新しいKubernetesバージョン: Kubernetesは、新しいマイナー・バージョンを年に3回リリースし、毎月パッチ・バージョンをリリースします。マイナー・バージョンで提供されている新機能を利用したり、パッチ・バージョンで提供されているパッチを適用したいお客様は、それらの更新をノードのフリートに適用するメカニズムが必要です。

  • 一般的な脆弱性およびエクスポージャ(CVE)の修正: クラスタ管理者は、ワーカー・ノードのイメージを更新して、既存のホストOSイメージで見つかったCVEに対処したいと考えています。イメージ・プロパティの更新後、更新をトリガーして、新しいイメージを実行している新しいインスタンスを作成できます。

  • キー・ローテーション: アプリケーションは通常、キー・ローテーションの要件によって管理されます。クラスタ内のワーカー・ノードのSSHキーを更新する必要があるクラスタ管理者は、新しいSSHキーを使用してノード・プールのプロパティを更新できます。プロパティの更新後、各ノードに新しい公開キーが存在するインスタンスを作成する更新をトリガーできます。

まとめ

オンデマンド・ノードの循環機能を使用すると、ノード・プール内の既存のノードを、更新されたプロパティを実行している新しいノードに簡単に置き換えることができるため、ノードを最新の状態に保ち、セキュアに保つことができます。この機能により、ノード・フリートの更新プロセスが自動化されます。以前は、独自のソリューションの開発に必要な時間のかかるタスクでした。SSHキー、ブート・ボリューム・サイズ、カスタムcloud-initスクリプトなど、別のノード・プール・プロパティを更新する場合は、目標を達成するための柔軟性が付属しています。

詳細は、次の資料を参照してください。: