OKEの基本クラスタでも問題ないケース

はじめに

こんにちは、技術部の内藤です。

OKEのクラスタは、基本クラスタと拡張クラスタの2種類があります。拡張クラスタの方が機能が豊富で魅力ですが、すべてのケースで拡張クラスタが必要というわけではありません。

今回は、基本クラスタでも問題ないケースについて説明します。

基本クラスタと拡張クラスタの違い

料金面

2025年7月時点で以下です。

  • 基本クラスタは無料
  • 拡張クラスタは月に約11,500円（日に372円）かかる

詳細は以下をご覧ください。

Container Servicesの価格設定 | オラクル | Oracle 日本

機能面

いろいろと違いはありますが、私が影響が大きいものと考えるのは以下です。

  • アドオンの利用可否
  • Workload Identityの利用可否

詳細は、以下の公式ドキュメントや資料をご確認ください。

基本クラスタでも問題ないケース

以下の条件にすべて当てはまる場合は、基本クラスタで十分です。

要約すると、シンプルかつ非機能要件がゆるいアプリケーションです。
※ならKubernetesじゃないほうがいいのでは？と思われるかもしれませんが、慣れているなら、インスタンスの面倒を見る必要がなく、かんたんにノードやポッドを作り直せるKubernetesは非常に便利です

OCI Native Ingress ControllerでIngressを使わない

基本クラスタはアドオンが使えないため、OCI Native Ingress Controllerが使えません。そのため、Ingressを使用しない、またはNGINX Ingress Controllerなど他のIngress Controllerを使用する場合は、基本クラスタでも問題ありません。

OCI Native Ingress Controllerについての詳細は、以下の公式ドキュメントをご覧ください。

KubernetesクラスタでのOCIネイティブ・イングレス・コントローラの設定

オートスケーリングしない

基本クラスタはアドオンが使えないため、Kubernetes Cluster Autoscalerアドオンが使えません。そのため、クラスタの自動スケーリングができません。ワークロードが安定しており、手動でのスケーリングで十分な場合は基本クラスタで対応可能です。

Kubernetes Cluster Autoscalerについての詳細は、以下の公式ドキュメントをご覧ください。

アクセス制御を厳格にしない

基本クラスタではWorkload Identityが使えないため、ポッドからOCIサービスへのアクセス制御が制限されます。厳格なアクセス制御が不要な環境や、インスタンスプリンシパルで十分な場合は基本クラスタでも対応可能です。

ノード数が多くない（1桁レベル）

基本クラスタではサイクルノードが使えません。ノード数が少なく、手動でのノード管理で十分な場合は基本クラスタで問題ありません。

ノード数が多いと、Kubernetesのアップデート時などに、ノードの更新が大変になります。が、それもスクリプトを作成すれば可能だとは思います。

財務的なSLAが不要

基本クラスタには、サービス・レベル目標(SLO)が付属していますが、財務的に支援されるサービス・レベル合意(SLA)は付属していません。
拡張クラスタには、財務的に支えられたサービス・レベル合意(SLA)が付属しています。

拡張クラスタと基本クラスタの比較には、上記があります。つまり、財務的なSLAが不要なら、基本クラスタで問題ありません。

おわりに

基本クラスタは機能が限定的ですが、シンプルな構成なら基本クラスタで十分です。

OCIは無料枠が豊富で、ノードの料金もインスタンスの無料枠として計算されるため、基本クラスタなら無料枠だけでKubernetesを運用することも十分にできます。

OKE
Kubernetes

OKEの仮想ノードだと厳しい部分

はじめに

OKEでは、ノードは管理対象ノードと仮想ノードの2種類が存在します。

以下の資料などを読むと、運用は仮想ノードがよさげに思えます。が、個人的にはまだ時期尚早だと思うので、私が仮想ノードで辛いと感じる部分を一部抜粋します。

Oracle Container Engine for Kubernetes (OKE) 概要 - Speaker Deck
https://oracle-japan.github.io/ocidocs/services/developers/oke-overview/

仮想ノードとは？

かんたんにいうと、AWSのFargateです。管理しなくていいです。

仮想ノードだと辛い部分

仮想ノードと管理対象ノードの比較で詳細があります。

Kubernetesデーモンセットはサポートされていません。

うーん、辛い。OSSだったり監視ツールだったりは、だいたいDaemonSetですからね。

永続ボリューム要求(PVC)はサポートされていません。

アプリケーションによっては厳しい。

gRPCプローブはサポートされていません。

アプリケーションによっては以下略

初期コンテナはサポートされていません。

initContainers です。

アプリケーションによっては以下略

kubectl logs -fコマンドはサポートされていません。

本番運用開始したらいいと思いますが、開発中は辛いです。

次のボリューム・タイプはサポートされません。

多い。

  • hostPath
  • persistentVolumeClaim
  • ローカル
  • nfs
  • iscsi
  • cephfs

ポッド仕様では、現在、タイプemptyDirの最大ボリュームを1つ定義できます。

一つだけ？ 未確認です。

Resources.RequestsはResources.Limitsと異なる値にできません

厳しいような、、、

ワーカー・ノードへのSSH接続(要塞経由を含む)

ノードの詳細なトラブルシューティングは諦めましょう。作り直せばいいのでしょうが。

カスタムcloud-initスクリプトの使用

例えば、OCIのOKEでFSSの転送中暗号化を有効にするで紹介した oci-fss-utils のインストールは、cloud-init以外で行う必要があります。

Kubernetesクラスタ・自動スケーリング

厳しい。

おわりに

上記は抜粋なので、制限はもっとあります。

仮想ノードで運用が楽になると思ったら、実は構築も運用も非常に辛いこともありえるので、事前に調査しておきましょう！

OKE
Kubernetes

OCIのOKEのポッドのNSGはOCI CLIだと変更できる

はじめに

こんにちは、技術部の内藤です。

タイトルそのままですが、OKEでは、記事執筆の2025年6月30日時点で、作成したノードプールのポッドのNSGを変更することはできませんが、CLIだと変更できます。コマンドの引数が複雑かつドキュメント見てもよくわからないので、詳細を説明します。

なぜか変更できないポッドのNSG

画像のように、少なくとも私の環境だとグレーアウトされており、ポッドのNSGを確認・変更ができません。

NSGがグレーアウトされている

サブネットにはなにも出ない、、、

サブネットにはなにも出てこない

私が初めてOKEを使った2024年の10月からこうなっており、普通にバグな気がするのですが、なかなか直してくれませんね、、、
それとも、仕様なのでしょうか？

NSGの変更方法1 - ノードプールを作り直す

変更方法と言っていいかあやしいですが、ノードプール作成時には問題なくNSGを設定できるので、ノードプールを作り直すことでNSGを変更可能です。

これはいまいちなので、まともな方法を紹介します。

NSGの変更方法2 - OCI CLIを使う

OCI CLIを使うと、ノードプールを作り直すことなく、ポッドのNSGを変更できます。

まず、現在のサブネットとNSGのIDを確認してみましょう。

oci ce node-pool get --node-pool-id xxx

出力結果の例

{
// 省略
    "node-config-details": {
      // 省略
      "node-pool-pod-network-option-details": {
        "cni-type": "OCI_VCN_IP_NATIVE",
        "max-pods-per-node": null,
        "pod-nsg-ids": [
          "value1",
          "value2",
          "value3"
        ],
        "pod-subnet-ids": [
          "value"
        ]
// 省略
}

次に、引数の値を記述したjsonファイルを用意するために、どのようなkey,valueが必要かを、以下のコマンドで確認します。

oci ce node-pool update --generate-full-command-json-input

出力結果の例

{
  // 省略
  "nodePoolId": "string",
  // 省略
  "podNsgIds": [
    "string",
    "string"
  ],
  "podSubnetIds": [
    "string",
    "string"
  ],
  //
}

podSubnetIds も必須なので載せています。

仮にOCIDがvalue1,2,3のNSGがアタッチされているとして、value4のOCIDのNSGをアタッチするとして、以下のjsonファイルを params.json として作成します。
※ファイル名はなんでも構いません

{
  "nodePoolId": "value",
  "podSubnetIds": [
    "value"
  ],
  "podNsgIds": [
    "value1",
    "value2",
    "value3",
    "value4"
  ]
}

最後に、のコマンドでポッドのNSGを更新します。 --from-json で、ファイルを指定できます。確認がある場合は、yを入力してEnterです。

oci --profile old ce node-pool update --from-json params.json
WARNING: Updates to initial-node-labels and subnet-ids and node-config-details and node-metadata and node-source-details and node-shape-config and freeform-tags and defined-tags and node-eviction-node-pool-settings and node-pool-cycling-details will replace any existing values. Are you sure you want to continue? [y/N]: y
{
  "opc-work-request-id": "ocid1.clustersworkrequest.xxxxx"
}

これでもう一度getコマンドで確認すると、ポッドのNSGが追加されています。

oci ce node-pool get --node-pool-id xxx

{
// 省略
    "node-config-details": {
      // 省略
      "node-pool-pod-network-option-details": {
        "cni-type": "OCI_VCN_IP_NATIVE",
        "max-pods-per-node": null,
        "pod-nsg-ids": [
          "value1",
          "value2",
          "value3",
          "value4"
        ],
        "pod-subnet-ids": [
          "value"
        ]
// 省略
}

おわりに

OCIのコンソールでポッドのNSGが変更できないのは不便ですが、OCI CLIを使うことでjsonファイルの作成の手間はありつつも変更できます。

このバグ？仕様？が早く改善されることを願います。

OKE
NSG
CLI

OCIのOKEでFSSの転送中暗号化を有効にする

はじめに

こんにちは、技術部の内藤です。

OCIのOKEでプロビジョニングしたFSSではNSGを使えないという記事で、OKEでFSSをプロビジョニングする場合のNSGやセキュリティルールについて書きました。

今回は、FSSで転送中暗号化を有効にする場合の設定方法について説明します。転送中暗号化を使用することで、クライアントとFSSマウントターゲット間の通信をより安全に行うことができます。

転送中暗号化とは

転送中暗号化は、NFSクライアントとFSSマウントターゲット間の通信をTLSで暗号化する機能です。これにより、ネットワーク上でデータが盗聴されるリスクを軽減できます。

転送中暗号化を使用する場合、通常のNFSポートではなく、専用のポート（2051）を使用します。

ノードプールの設定

ノードに必要なパッケージのインストール

ノードのイメージがOracle Linux 8の場合で説明します。

転送中暗号化を使用するには、ノードに oci-fss-utils パッケージが必要です。OKEのノードプールでは、Cloud-Initスクリプトを使用してこのパッケージをインストールできます。
※正直、Cloud-Initスクリプトを使う方法がベストかは不明ですが、私はこの方法で実現できました

ノードプールに、以下のCloud-Initスクリプトを設定します。

まず、ノードプールの作成・編集画面で「カスタム・クラウド初期化スクリプト・テンプレートのダウンロード」から、テンプレートをダウンロードしてください。

Cloud-Initスクリプト

そして、必要なパッケージをインストールするために、コードを以下のようにして、コンソールに貼り付けます。

#!/bin/bash
# 変更NG https://docs.oracle.com/ja-jp/iaas/Content/ContEng/Tasks/contengusingcustomcloudinitscripts.htm
curl --fail -H "Authorization: Bearer Oracle" -L0 http://169.254.169.254/opc/v2/instance/metadata/oke_init_script | base64 --decode >/var/run/oke-init.sh
bash /var/run/oke-init.sh

# FSSで転送中暗号化を利用するために oci-fss-utils をインストール
# https://docs.oracle.com/ja-jp/iaas/Content/File/Tasks/intransitencryption.htm#upgrade
sudo yum-config-manager --enable ol8_developer
sudo dnf install -y oci-fss-utils
sudo dnf upgrade -y oci-fss-utils

注意点

カスタムのCloud-init初期化スクリプトを使用した管理対象ノードの設定に、以下の記載があります。

Kubernetes Engineは、cloud-initを使用して、管理対象ノードをホストするコンピュート・インスタンスを設定します。Kubernetes Engineは、管理対象ノードをホストする各インスタンスにデフォルトの起動スクリプトをインストールします。インスタンスが初めて起動すると、cloud-initによってデフォルトの起動スクリプトが実行されます。

デフォルトの起動スクリプトをカスタマイズする場合は、Kubernetes Engineによって提供されるロジックを変更しないでください。

私はこれを読まずに、デフォルトのコードを消して、ノードがAPIエンドポイントから認識されず、しばらくハマりました、、、

ブート・ボリュームの転送中暗号化の有効化

ノードプールの作成・編集画面で「転送中暗号化の使用」にチェックを入れます。

ブートボリュームの転送中暗号化

ノードプール作成後に上記変更をした場合

既存のノードを削除して、新しいノードを（自動で）立ち上げてください。ノードプールの変更を反映するには、変更後にノードを立ち上げる必要があります。

セキュリティリストの設定

転送中暗号化を使用する場合、マウントターゲットのサブネットに設定するセキュリティリストでポート2051の通信を許可する必要があります。

「ファイル・ストレージに対するVCNセキュリティ・ルールの構成」のシナリオC: マウント・ターゲットおよびインスタンスでTLS転送中暗号化を使用に従い、ノードが存在するサブネットのCIDRからの2051ポートのインバウンドをステートフルで許可します。

  • TCP
  • 宛先ポート: 2051
  • ソースCIDR: ノードがあるサブネット

ノードのサブネットが 172.22.1.0/24 の場合は、以下のようになります。

セキュリティ

参考

おわりに

OKEでFSSの転送中暗号化を使用する場合は、パッケージのインストールとセキュリティリストの設定が重要です。初めてだと地味にハマると思うので、本記事を参考に設定してみてください！

OKE
FSS
セキュリティリスト

OCIのOKEでプロビジョニングしたFSSではNSGを使えない

はじめに

こんにちは、技術部の内藤です。

OKE（Oracle Kubernetes Engine）でPersistent Volume Claim（PVC）を使用してFile Storage Service（FSS）を動的にプロビジョニングする際、ネットワークセキュリティの設定で注意すべき点があります。

通常、OCIではセキュリティリストよりNetwork Security Group（NSG）を使用して管理することが推奨されていますが、2025年6月時点では、FSSの動的プロビジョニングでは、NSGの設定がおそらくできません。

以下の公式ドキュメントに、それらしい記述は見当たりません。

ファイル・ストレージ・サービスでのPVCのプロビジョニング

そのため、FSSのマウントターゲットが作成されるサブネットに対して、セキュリティリストを使用してアクセス制御を設定する必要があります。今回は、この設定方法を説明します。

FSSでのセキュリティ・ルールについて

インスタンスなりPodなりがFSSにアクセスするには、接続元からFSSのマウントターゲットへの通信を許可する必要があります。

前述の通り、OKEではFSSのNSGの設定ができないため、マウントターゲットが作成されるサブネットに適切なセキュリティリストを設定する必要があります。

許可が必要なポートとプロトコル

FSSを使用するために、以下のポートとプロトコルの通信を許可する必要があります。

以下の例は、異なるサブネットかつ転送中の暗号化をしない場合です。

接続元とFSSで同一サブネットかどうかや転送中暗号化を有効にしているかなどで設定は変わるので、詳細は以下のドキュメントをご覧ください。

ファイル・ストレージに対するVCNセキュリティ・ルールの構成

マウントターゲットのサブネットに設定するセキュリティリスト

以下のルールをすべてIngressのステートフルで許可します。

  • 1つ目
    • TCP
    • 宛先ポート: 111,2048-2050
    • ソースCIDR: ノードがあるサブネット
  • 2つ目
    • UDP
    • 宛先ポート: 111,2048
    • ソースCIDR: ノードがあるサブネット

ノードのサブネットが 172.22.1.0/24 だとしたら、以下の画像のようになります。

セキュリティリストの設定

おわりに

いずれはKubernetesのマニフェストでNSGが設定できるようになることを期待しつつ、FSSを利用する際はしばらくはセキュリティリストで対応しましょう。

OKE
セキュリティリスト
NSG
Security List
FSS

OCI未経験者がOKEを使うためのおすすめのチュートリアル

はじめに

こんにちは、技術部の内藤です。

OCI未経験者が、OKEでKubernetesを使えるようにするためのおすすめのチュートリアルを紹介します。実際に、私が業務でOCIやOKEを使い始める時にやったチュートリアルです。

前提

以下の知識がある人用です。 ※なくても大丈夫かもしれません

  • AWSなど、OCI以外のクラウドサービスの基本がわかる
    • AWSだと、VPC, EC, セキュリティグループあたりはある程度理解している
  • Kubernetesの基本がわかる
    • Pod, Deployment, Service, Ingressあたりはある程度理解している
    • 理解していなくてもいいのですが、知らない場合は、実際にサービスをKubernetesで構築するときに、基本を理解したほうが絶対によいです

おすすめチュートリアル - 基本編

まずは以下の4つをやりましょう。

MySQLではなくOracle DBを利用される場合は、以下のチュートリアルをどうぞ。

101: Oracle Cloud で Oracle Database を使おう(BaseDB) | Oracle Cloud Infrastructure チュートリアル

PostgreSQLなど上記以外のDBは、おそらくOCI公式の日本語チュートリアルはないので、ひとまずMySQLかOracle DBで試してみることをおすすめします。

なお、もちろんドキュメントは存在します。例として、PostgreSQLのドキュメントを記載します。

OCI Database with PostgreSQLの開始

おすすめチュートリアル - OKE編

次に、OKEの基本を学ぶために以下のチュートリアルをやりましょう。

上記で足りなければ

以下のページに、OCI公式の日本語チュートリアルの一覧があります。ここから、必要なものを探してやってみてください。

Oracle Cloud Infrastructure チュートリアル

もちろん、これだけでは実運用のサービスを動かすための知識や経験は足りないので、実際にサービスを構築していくなかで、公式ドキュメントや他のチュートリアルをやっていきましょう。

おわりに

急いでいるときは、意外とチュートリアルなどを飛ばしてしまいがちですが、最初にある程度基本を理解したほうが、最終的にかかる時間は減ると私は思っています。（今まで、焦りから基本の理解をおろそかにして、結局余計に時間がかかったことが多々あります、、、）

ということで、OCIやOKEを使い始める方は、まずはぜひ上記のチュートリアルをやってみてください。

OKE
Kubernetes
初心者向け
OKE