Oracle Container Engine for Kubernetes(OKE)クラスタの仮想ノードを試してみた

ブログ

Oracle Cloud

2023.04.24

皆さま、こんにちは！y.takanashiです。

先日、Oracle Container Engine for Kubernetes(OKE)に新しいオプションが追加され、仮想ノードタイプが選択できるようになりました。

そこで、今回は実際に仮想ノードを使用したクラスタの作成をしてみたいと思います。

1 仮想ノードとは？
2 管理対象ノードとの違い
3 価格
4 仮想ノードを使用したクラスタの作成
5 アドオンについて
6 まとめ

仮想ノードとは？

仮想ノードとは、2023年3月にリリースされたOracle Container Engine for Kubernetes(OKE)の新しいオプションで、コンテナ化されたアプリケーションのノード・インフラストラクチャを、オーバーヘッドなしで管理・アップグレード・トラブルシューティングなどを行うことができます。

仮想ノードの大きな特徴は、従量課金制による柔軟な料金体系を提供していることです。

従来の管理対象ノードでは、消費するリソースは関係なくデプロイしたワーカー・ノード(コンピュート・インスタンス)のOCPUやメモリに対して課金が発生しましたが、仮想ノードではコンテナ・アプリケーションが消費したリソース(OCPU/メモリ)分のみ課金が発生します。

そのため、運用コストを抑えたいケースでは、仮想ノードを使用したクラスタの作成が有用となります。

管理対象ノードとの違い

従来の管理対象ノードと仮想ノードの違いについて、両ノードを使用したクラスタ作成画面を例に挙げながらご紹介します。

以下が管理対象ノードを使用したクラスタの作成画面です。

続いて、以下が仮想ノードを使用したクラスタの作成画面です。

管理対象ノードを使用したクラスタを作成する際、仮想ノードと比較して以下の内容を指定できます。

ワーカーノード・サブネット
ノードシェイプやOCPU / メモリ数
※仮想ノードはE3,E4のノード・シェイプのみ使用可能でしたが、管理対象ノードはノード・シェイプやOCPU数、メモリ容量を柔軟に指定できます。
ブート・ボリューム
削除を実行してから処理までの時間(削除猶予期間)
Cloud-initスクリプト
SSHキー

したがって、以下のユースケースでは仮想ノードは使用できませんのでご注意ください。

ワーカー・ノードにSSHログインする必要がある場合
Cloud-initファイルを使用したい場合
AMD以外のコンピュート・インスタンスを使用したい場合
ストレージを使用したい場合

また、現時点(2023年4月)では未実装ですが、今後サポートされる機能は以下の通りです。

自動スケーリング
仮想ノードと管理対象ノードを混合したクラスタ
ストレージの使用
E3 / E4以外のポッド・シェイプのサポート
仮想ノードに対する予約容量

上記に挙げた実装予定の機能の中で、個人的には自動スケーリングが早く実装されることを願っています。

価格

以下が仮想ノードの主なリソースの1時間あたりの価格です。

※ロード・バランサ等のIaaSサービス利用分は、別途課金となります。

クラスタ(1クラスタあたり)：¥14 / 1 hour
仮想ノード(1ノードあたり)：¥2.1 / 1 hour
※ポッド・シェイプのOCPU/メモリはOCI側で算出

その他仮想ノードに関する詳細情報については、以下の資料をご覧ください。

OCI公式ドキュメント - 仮想ノードの操作

Speaker Deck - Oracle Container Engine for Kubernetes (OKE) のご紹介

仮想ノードを使用したクラスタの作成

ここでは仮想ノードを使用したOKEクラスタの作成を行います。

手順は、既存の管理対象ノードを使用したクラスタの作成方法と同様となっています。

事前準備

ポリシーの作成

実際にクラスタを作成する前に、まず下記のOCI公式ドキュメントを参考にして、事前準備を行います。

OCI公式ドキュメント - 仮想ノードの操作

以下のポリシーを作成することで、グループに対して仮想ノードや仮想ノードプールを含むクラスタを作成するための必要な権限を付与することができます。

allow group <任意のグループ名> to manage cluster-virtualnode-pools in compartment <任意のコンパートメント名>
allow group <任意のグループ名> to read virtual-network-family in compartment <任意のコンパートメント名>
allow group <任意のグループ名> to manage vnics in compartment <任意のコンパートメント名>

ネットワーク・リソースの構成

続いて、以下を例にネットワーク・リソースを作成します。

リソース名やCIDRブロック等は必要に応じて適宜変更をしておきましょう。

リソース名	例
VCN	・名前：vnode-vcn ・CIDRブロック：10.0.0.0/16 ・DNS解決：選択済
インターネット・ゲートウェイ	・名前：internet-gateway
NATゲートウェイ	・名前：nat-gateway
サービスゲートウェイ	・名前：service-gateway ・サービス: All NRT Services In Oracle Services Network
DHCPオプション	・DNSタイプインターネットおよびVCNリゾルバに設定

VCN、ネットワーク・リソース

リソース用途	例
Kubernetes APIエンドポイント用サブネット	・名前：sub-kubeapi ・タイプ：リージョナル・CIDRブロック： 10.0.0.0/28 ・ルート表:：routetable-kubeapi ・サブネット・アクセス：パブリック・DNS解決：選択済・DHCPオプション：デフォルト・セキュリティ・リスト： seclist-kubeapi
仮想ノードおよびポッド用サブネット	・名前：sub-nodepods ・タイプ: リージョナル・CIDRブロック: 10.0.10.0/24 ・ルート表: routetable-nodespods ・サブネット・アクセス: プライベート・DNS解決: 選択済・DHCPオプション: デフォルト・セキュリティ・リスト: seclist-nodespods
ロード・バランサ用サブネット	・名前：sub-loadbalancer ・タイプ: リージョナル・CIDRブロック: 10.0.20.0/24 ・ルート表: routetable-loadbalancer ・サブネット・アクセス: パブリック・DNS解決: 選択済・DHCPオプション: デフォルト・セキュリティ・リスト: seclist-loadbalancer

サブネット

リソース名	例
routetable-kubeapi	・インターネットへのトラフィック用のルール　・宛先CIDRブロック：0.0.0.0/0 　・ターゲット・タイプ：インターネット・ゲートウェイ　・ターゲット：internet-gateway
routetable-nodespods	・インターネットへのトラフィック用のルール　・宛先CIDRブロック：0.0.0.0/0 　・ターゲット・タイプ：NATゲートウェイ　・ターゲット：nat-gateway ・OCIサービスへのトラフィック用のルール　・宛先：All NRT Services In Oracle Services Network 　・ターゲット・タイプ：サービス・ゲートウェイ　・ターゲット：service-gateway
routetable-loadbalancer	・インターネットへのトラフィック用のルール　・宛先CIDRブロック：0.0.0.0/0 　・ターゲット・タイプ：インターネット・ゲートウェイ　・ターゲット：internet-gateway

ルート表

セキュリティ・リストの構成

同様に、以下を例にセキュリティ・リストも構成します。

方向	状態	ソースCIDR	プロトコル/宛先ポート	説明
イングレス	ステートフル	0.0.0.0/0	TCP/6443	Kubernetes APIエンドポイントへの外部アクセス。
イングレス	ステートフル	10.0.10.0/24	TCP/6443	仮想ノードからKubernetes APIエンドポイントへの通信。
イングレス	ステートフル	10.0.10.0/24	TCP/12250	コントロール・プレーンへの仮想ノード通信。
イングレス	ステートフル	10.0.10.0/24	ICMP 3,4	パス検出。
エグレス	ステートフル	Oracle Services NetworkのすべてのOCIサービス	TCP/443	Kubernetes APIエンドポイントがリージョンOCIサービス・エンドポイントと通信できるようにします。
エグレス	ステートフル	10.0.10.0/24	TCP/すべて	Kubernetes APIエンドポイントが仮想ノードと通信できるようにします。
エグレス	ステートフル	10.0.10.0/24	ICMP 3,4	パス検出。

seclist-kubeapi

方向	状態	ソースCIDR	プロトコル/宛先ポート	説明
イングレス	ステートフル	10.0.10.0/24	すべて/すべて	ポッド間通信。
イングレス	ステートフル	10.0.10.0/24	TCP/6443	external-traffic-policy=localのロード・バランサからポッドおよびヘルス・チェック・ノードのポート・トラフィックへのトラフィック。
イングレス	ステートフル	10.0.10.0/24	TCP/12250	external-traffic-policy=clusterのロード・バランサからヘルス・チェック・ポートへのトラフィック
イングレス	ステートフル	10.0.0.0/28	ICMP 3,4	APIサーバーからのパス検出。
イングレス	ステートフル	10.0.0.0/28	TCP/すべて	APIサーバーから仮想ノードへの通信。
エグレス	ステートフル	10.0.10.0/24	すべて/すべて	ポッド間通信。
エグレス	ステートフル	10.0.0.0/28	TCP/6443	仮想ノード/ポッドからAPIサーバーへの通信。
エグレス	ステートフル	10.0.0.0/28	TCP/12250	仮想ノード/ポッドからAPIサーバーへの通信。
エグレス	ステートフル	0.0.0.0/0	ICMP 3,4	仮想ノード/ポッドからKubernetesコントロール・プレーンへのアクセス。

seclist-nodespods

方向	状態	ソースCIDR	プロトコル/宛先ポート	説明
イングレス	ステートフル	0.0.0.0/0	TCP / 443/80	リスナー・ポートが80/443と仮定したロード・バランサへの受信トラフィック
エグレス	ステートフル	10.0.10.0/24	すべて/ 30000-32767	external-traffic-policy=localのポッドおよびヘルス・チェック・ノード・ポート・トラフィックへのトラフィック
エグレス	ステートフル	10.0.10.0/24	TCP/UDP/10256	external-traffic-policy=clusterのヘルス・チェック・ポートへのトラフィック

seclist-loadbalancer

クラスタの作成

事前準備の完了後、仮想ノードを使用したクラスタの作成を行います。

OCIコンソール画面左上のハンバーガーメニューから「開発者サービス」→「Kubernetesクラスタ(OKE)」を選択します。

「クラスタの作成」→「カスタム作成」→「送信」を順に選択します。

ここでは以下の項目を入力して「クラスタの作成」を選択します。

リソース名やスペック等は必要に応じて適宜変更をしておきましょう。

※仮想ノードでクラスタを作成する場合は、ノード・タイプを「仮想」にしておきましょう。

名前：cluster1
Kubernetesバージョン：1.25.4
ネットワーク・タイプ：VCNネイティブ・ポッド・ネットワーク
VCN：vnode-vcn
KubernetesサービスLBサブネット：sub-loadbalancer
Kubernetes APIエンドポイント・サブネット：sub-kubeapi
ノードプール
- 名前：pool1
- ノード・タイプ：仮想
仮想ノード数およびポッド・シェイプ
- ノード数：1
- ポッド・シェイプ：Pod.Standard.E4.Flex
- ※現時点で選択可能なポッド・シェイプはE3、E4のみ
ポッド通信用のサブネット：sub-nodepods
仮想ノード通信用のサブネット：sub-nodepods

作成後、15分程度でクラスタのプロビジョニングは完了します。

作成したクラスタへのアクセス

プロビジョニング完了後、作成したクラスタへのアクセスを行います。

クラスタへのアクセス方法はCloud Shellとローカルからの2つがありますが、今回はCloud Shellからアクセスを行います。

作成したクラスタの詳細画面から「クラスタへのアクセス」→「Cloud Shellアクセス」をそれぞれ選択します。

Cloud Shellの起動後、記載のコマンドをペーストしてkubeconfigファイルを作成します。

oci ce cluster create-kubeconfig --cluster-id ocid1.cluster.oc1.ap-tokyo-1.xxx --file $HOME/.kube/config --region ap-tokyo-1 --token-version 2.0.0  --kube-endpoint PUBLIC_ENDPOINT

kubeconfigファイルの作成後、以下のコマンドで実行中のノード数を確認します。