はじめに
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クラスタ・自動スケーリング
厳しい。
おわりに
上記は抜粋なので、制限はもっとあります。
仮想ノードで運用が楽になると思ったら、実は構築も運用も非常に辛いこともありえるので、事前に調査しておきましょう！