はじめに

先日以下の機能がリリースされました。

この機能は、OKEのNodePool(Worker Nodeのグループ)とは別にユーザ管理のWorker NodeをOKEの管理対象として組み込める機能です。

まずは、言葉だけだと何を言っているかわからないと思うので、早速触ってみましょう。

前提条件

Self Managed Nodesを利用するには以下の2つの条件があります。

利用するOKEクラスタはv1.25以上の拡張クラスタであること
OKEクラスタが利用するCNIはflannelであること(VCN Native Pod NetworkingはNG)

また、Worker NodeとするOSイメージは現時点ではOKE Worker Nodeイメージ(Oracle Linux7 or 8)のみです。

今後は様々なOSイメージがサポートされてくると思います。

事前準備

Self Managed Nodesを利用するには以下の2ステップが必要です。

動的グループおよびポリシーの作成
Cloud-initスクリプトの作成

それぞれの手順を行っていきます。なお、今回はOKEクラスタが事前に作成されているものとして進めます。

1.動的グループおよびポリシーの作成

今回はNodeが所属するコンパートメント内の全てのインスタンスを対象としたグループを作成します。
このグループ名をoke-self-managed-nodes-dyn-groupとします。

ALL {instance.compartment.id = '<compartment-ocid>'}

ポリシーは以下のようにします。

Allow dynamic-group oke-self-managed-nodes-dyn-group to {CLUSTER_JOIN} in compartment <compartment-name>

これで動的グループとポリシーの作成は完了です。

2.　Cloud-initスクリプトの作成

ここでは、インスタンス起動時にOKEクラスタに参加するための初期化スクリプトを作成します。

手順は以下のドキュメントにもあります。

ベースとなるのは以下のスクリプトです。

#!/usr/bin/env bash
bash /etc/oke/oke-install.sh \
  --apiserver-endpoint "<cluster-endpoint>" \
  --kubelet-ca-cert "<base64-encoded-certificate>"

"<cluster-endpoint>"と"<base64-encoded-certificate>"の部分を埋めます。

まず、"<cluster-endpoint>"はOKEクラスタのプライベートAPIエンドポイントです。

以下のようにOKEのコンソール画面で確認できます。

ポート番号である6443は除きます。

次に"<base64-encoded-certificate>"は、OKEクラスタのCA証明書です。
例えば、東京リージョンにあるクラスタの場合、以下のコマンドで取得できます。

oci ce cluster create-kubeconfig --cluster-id ocid1.cluster.oc1.ap-tokyo-1.aaaaaaaaj5fsxxxxxxxxxxxwiducguq --region ap-tokyo-1 --file - | grep -oE "LS0t.*"

クラスタOCIDである”ocid1.cluster.oc1.ap-tokyo-1.aaaaaaaaj5fsxxxxxxxxxxxwiducguq”とリージョン識別子である”ap-tokyo-1”はご自身の環境で置き換えてください。

これでCloud-initスクリプトの作成は完了です。

事前準備は以上です。

Nodeの追加

いよいよ、Self Managed Nodesを追加します。

まずは、OCIコンソール画面から通常のComputeインスタンス画面を起動します。

この記事ではOracle-Linux-8.7-2023.05.24-0-OKE-1.26.2-625のイメージを利用します。
OCIDで指定しますが、リージョンによって異なるので、以下のドキュメントでご確認ください。

以下のようになります。シェイプは任意で問題ありません。

本来は、Object Storageなどにエスクポートしたカスタムイメージなどを指定しますが、今回は真っ新なOracle-Linux-8.7-2023.05.24-0-OKE-1.26.2-625イメージを指定しています。

インスタンスで利用するVCNは既存のOKEクラスタで利用しているWorker Nodeサブネットを利用するのがいいと思います。

最後にcloud-initを指定します。

これは事前準備で作成したスクリプトを貼り付けるだけです。例えば以下のようなイメージです。

#!/usr/bin/env bash
bash /etc/oke/oke-install.sh \
  --apiserver-endpoint "10.0.0.5" \
  --kubelet-ca-cert "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURpVENDQW5HZ0F3SUJBZ0lSQU9LaXR0WWlLd0trYzlYWlMrcXBzZm93RFFZxxxxxxxTFZ6aS8zRk1vL0xoRHRXNHJFN0lrcExYemwKSklubW9IL2oyNExiSnE4MGNtOEVWSFhLMWQyUlEzQjUzelROMUpXaTl3SxxxxxxxxxxhXVzEzNWdzNmFzS2ZvczgzV2ZWT3JFZzhmYlllRUI3NXg0N1BCaCtCMmhwdkhFb0Q2djNhRHF0b0V4dgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg=="

これでインスタンスを作成します。

Nodeの状態を確認してみます。

$ kubectl get node
NAME         STATUS     ROLES    AGE   VERSION
10.0.10.22   Ready      node     78d   v1.26.2
10.0.10.4    NotReady   <none>   76s   v1.26.2

ROLESカラムが<none>のNodeが表示されています。これが上記で作成したインスタンスです。

しばらくすると以下のようにSTATUSがREADYになります。

$ kubectl get node
NAME         STATUS   ROLES    AGE     VERSION
10.0.10.22   Ready    node     78d     v1.26.2
10.0.10.4    Ready    <none>   2m46s   v1.26.2

これでSelf Managed Nodeの追加ができました！

Self Managed Nodesのユースケース

ここまでざっと機能だけ見てきましたが、実際にどのようなユースケースがあるのかを考えてみます。

OKEではサポートされていない機能が以下のようにいくつか存在します。

RDMAネットワークを利用するベアメタル・インスタンス(HPC)
最近リリースされたVirtual NodesとVMを同時に使いたいケース(ロードマップにはあるが、まだ未サポート）

特に前者については、昨今のLLM機運の高まりにより、利用されるケースも多くあると思います。

このようなユースケースにSelf Managed Nodesは利用できます。

ただし、Self Managed Nodesでは現在以下の機能がサポートされていないので、注意が必要です。

Kubernetes Cluster Autoscaler
OKEによるdrain/cordonオプションの利用
オンデマンドノードサイクルによるバージョンアップ

まとめ

Self Managed Nodesを利用すると　従来のOKEではサポートされていない機能もカバーすることができます！
この機能を利用して、どんどんOKEクラスタを有効活用していきましょう！

参考資料