はじめに
先日以下の機能がリリースされました。
この機能は、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クラスタを有効活用していきましょう！
参考資料