仮想ノードと管理対象ノードの比較

Container Engine for Kubernetes (OKE)を使用して作成できる仮想ノードと管理対象ノードの違いを確認します。

Container Engine for Kubernetesを使用してノード・プールを作成する場合は、ノード・プールに作成するワーカー・ノードのタイプを次のいずれかまたは別のものとして指定します:

仮想ノードは拡張クラスタでのみ作成できます。管理対象ノードは、基本クラスタと拡張クラスタの両方に作成できます。

Container Engine for Kubernetesドキュメント内の'ノード'および'ワーカー・ノード'へのすべての参照は、特に明記されていないかぎり、仮想ノードと管理対象ノードの両方を参照します。

仮想ノードおよび仮想ノード・プール

仮想ノードは、Container Engine for Kubernetesテナンシで実行されます。仮想ノードを作成するには、仮想ノード・プールを作成します。仮想ノードおよび仮想ノード・プールは、Oracleによって完全に管理されます。

仮想ノードは「サーバーレス」なKubernetesエクスペリエンスを提供し、データ・プレーン・インフラストラクチャのアップグレードおよびクラスタの容量の管理の運用オーバーヘッドなしで、コンテナ化されたアプリケーションを大規模に実行できます。

仮想ノードおよびノード・プールは、拡張クラスタでのみ作成できます。

仮想ノードによって異なる機能をサポート

管理対象ノードではなく仮想ノードを使用する場合、一部の機能は異なる方法でサポートされます。

  • リソース割当:リソース割当は、ワーカー・ノード・レベルではなくポッド・レベルです。したがって、ノード・プールのワーカー・ノードではなく、ポッド仕様でCPUおよびメモリー・リソース要件(リクエストおよび制限として)を指定します。「仮想ノードによってプロビジョニングされたポッドに割り当てられたリソース」を参照してください。

  • ロード・バランシング:ロード・バランシングは、ワーカー・ノード間ではなくポッド間です(管理対象ノードの場合と同様)。仮想ノードを持つクラスタでは、ロード・バランサのセキュリティ・リスト管理は決して有効にならないため、常にセキュリティ・ルールを手動で構成する必要があります。ロード・バランサは、ポッドのIPアドレスと割り当てられたノード・ポート間でトラフィックを分散します。仮想ノードで実行されているポッドに接続する場合は、<node-ip>:<nodeport>ではなく構文<pod-ip>:<nodeport>を使用します。ポッドおよびノードに異なるサブネットを使用する場合は、ポッド・サブネットでノード・ポート・イングレスを構成します。
  • ポッド・ネットワーク: VCNネイティブ・ポッド・ネットワークのみがサポートされています(チャネルCNIプラグインはサポートされていません)。さらに、仮想ノードを使用する場合のサポートは若干異なります。
    • 各仮想ノードにアタッチされるVNICは1つのみです。
    • ポッドが作成される前に、IPアドレスが事前に割り当てられることはありません。
    • VCNネイティブ・ポッド・ネットワーキングCNIプラグインは、kube-systemネームスペースで実行中として表示されません。
    • VCNネイティブ・ポッド・ネットワーキングのみがサポートされているため、ポッド・サブネット・ルート表には、(インターネット・ゲートウェイではなく) NATゲートウェイおよびサービス・ゲートウェイに対して定義されたルート・ルールが必要です。
  • 自動スケーリング:仮想ノードは、500ポッドをサポートするように自動的にスケーリングされます。Oracleは仮想ノードの基礎となるリソースを管理するため、Kubernetes Horizontal Pod Autoscalerの操作が容易です。Kubernetes Cluster Autoscalerを使用する必要はありません(仮想ノードではまだサポートされていません)。Kubernetes Vertical Pod Autoscalerは仮想ノードではサポートされていません。

仮想ノードの使用時にサポートされない注目に値するKubernetesの機能

管理対象ノードではなく仮想ノードを使用する場合、一部のKubernetes機能がサポートされていないか、まだ使用できません。

サポートされていないKubernetes機能 追加情報
Flannelおよびその他のサード・パーティのCNIプラグインはサポートされていません。 仮想ノードは、OCI VCNネイティブ・ポッド・ネットワークCNIプラグインのみをサポートします。
Kubernetesデーモンセットはサポートされていません。

たとえば、次の例はサポートされていません。

apiVersion: apps/v1
kind: DaemonSet
永続ボリューム要求(PVC)はサポートされていません。 追加情報がありません。
クラスタで使用されるCNIプラグイン(CalicoやCiliumなど)とともにNetworkPolicyリソースをサポートするネットワーク・プロバイダはサポートされていません。 追加情報がありません。
ネットワーク・ポリシー(Kubernetes NetworkPolicyリソース)はサポートされていません。 追加情報がありません。
サービス メッシュ プロダクトはサポートされていません。 Oracle Cloud Infrastructure Service MeshやIstio Service Meshなどの製品は、サポートされていません。

HTTPタイプの有効性および準備期間プローブはサポートされます

HTTPS、gRPC、およびexecプローブはサポートされません

起動プローブはサポートされません

probe.terminationGracePeriodSecondsはサポートされません

たとえば、次がサポートされています。
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 3
ただし、次はサポートされていません:
livenessProbe:
  grpc:
     port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
    scheme: "HTTPS"
startupProbe:
  httpGet:
    path: /healthz
    port:8080

kubectl logsコマンドがサポートされます

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

たとえば、次の例はサポートされていません。
kubectl logs -f workload1-589578899f-lwzm9
エフェメラル・コンテナはサポートされていません。 追加情報がありません。
初期コンテナはサポートされていません。 追加情報がありません。

次のボリュームタイプがサポートされています

  • emptyDir
  • ConfigMap
  • シークレット
  • 次のタイプのProjectedVolume:

    • ServiceAccount
    • ConfigMap
    • シークレット

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

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

たとえば、次の例はサポートされていません。

volumes:
- name: test-volume
  hostPath:
    path: /data
ポッド仕様では、現在、タイプemptyDirの最大ボリュームを1つ定義できます。 追加情報がありません。

次のポッド・フィールドはサポートされていません:

  • hostIPC
  • hostNetwork
  • hostPid
  • hostName
  • podOS
  • オーバーヘッド
  • setHostNameAsFqdn
  • shareProcessNamespace
たとえば、次の例はサポートされていません。
spec:
  hostIPC: true
  hostNetwork: true
  hostPID: false
  setHostnameAsFQDN : true
  shareProcessNamespace : true

次のポッド・セキュリティ・コンテキストがサポートされます:

  • runAsNonRoot
  • runAsUser
  • runAsGroup

次のポッド・セキュリティ・コンテキストはサポートされていません。

  • fsGroup
  • fsGroupChangePolicy
  • supplementalGroups
  • seLinuxOptions
  • sysctls
  • seccompProfile
たとえば、次の例はサポートされていません。
spec:
  securityContext:
    seLinuxOptions:
      type: dummy_container.proces

次のコンテナ・セキュリティ・コンテキストがサポートされます:

  • readOnlyRootFilesystem
  • allowPrivilegeエスカレーション:false

次のコンテナ・セキュリティ・コンテキストはサポートされていません。

  • allowPrivilegeエスカレーション:true
  • 特権付き
  • procMount
  • 機能
たとえば、次の例はサポートされていません。
containers:
  - name: openssh-1
    securityContext:
      capabilities:
        add:
        - CAP_NET_ADMIN

Container.Port

  • ホストIP
  • ホスト・ポート
たとえば、次の例はサポートされていません。
ports:
  - name: test
    containerPort: 81
    hostPort: 80

コンテナ

  • TerminationMessagePolicy
  • TerminationMessagePath
  • VolumeDevices
  • VolumeMount.MountPropagation
  • VolumeMount.Subpath式
Kubernetesでは、デフォルトでTerminationMessagePolicyおよびTerminationMessagePathが追加されます。
コンテナ・ポート範囲(1、65535)は、NodePort範囲(30000-32767)と競合できません。 たとえば、次の例はサポートされていません。
containers:
  - name: my-nginx
    image: nginx
    ports:
    - containerPort: 30002
ポッド.ボリューム.空ディレクトリボリュームソース: サイズ制限 たとえば、次の例はサポートされていません。
emptyDir:
  sizeLimit: 500Mi
Pod.Volumes.EmptyDirVolumeSource:Medium - ""または"Memory"のみを指定できます たとえば、次の例はサポートされていません。
emptyDir:
  medium: "Memory1"

Pod:Volumes - Modeは0644と指定する必要があります。

  • ConfigMapVolumeSource:KeyToPath: モード
  • SecretVolumeSource:KeyToPath: モード
  • ProjectedVolumeSource:SecretProjection:KeyToPath: モード
  • ProjectedVolumeSource:ConfigMapProjection:KeyToPath: モード
たとえば、次の例はサポートされていません。
- name: myconfigmap
  configMap:
    name: kube-root-ca.crt
    items:
    - key: ca.crt
      path: abc
      mode: 0400

ポッド: ボリューム- DefaultModeが次のように指定されている場合、DefaultModeは0644である必要があります:

  • ConfigMapVolumeSource: デフォルトモード
  • 予測ボリューム・ソース: デフォルト・モード
  • SecretVolumeSource: デフォルトモード
たとえば、次の例はサポートされていません。
- name: workload-volume
    configMap:
      name: myconfigmap
      defaultMode: 0400
Resources.RequestsはResources.Limitsと異なる値にできません たとえば、次の例はサポートされていません。
resources:
  requests:
    cpu: 50m
    memory: 200Mi
  limits:
    cpu: 100m
    memory: 400Mi
ボリューム: 下方API:ResourceFieldRef たとえば、次の例はサポートされていません。
resourceFieldRef:
  containerName: openssh
  resource: limits.cpu
TerminationGracePeriodSeconds たとえば、次の例はサポートされていません。
terminationGracePeriodSeconds: 30
DeletionGracePeriodSeconds たとえば、次の例はサポートされていません。
metadata:
  DeletionGracePeriodSeconds: 30
実行コンテナ たとえば、次の例はサポートされていません。
kubectl exec workload1-589578899f-lwzm9 -- sh
Kubectl port-forwardコマンド かわりにkubectl proxyを使用します(「kubectlポートフォワードではなくkubectlプロキシを使用した仮想ノードでのポッドおよびサービス問題のトラブルシューティング」を参照)。
pod.spec.containers[].imageへの突然変異を含むUpdatePodリクエスト 追加情報がありません。
マウントされた構成マップおよびシークレットへの更新のポッドへの伝播 追加情報がありません。
仮想kubeletメトリック・エンドポイントのコンテナ・レベルのメトリック 追加情報がありません。
コンテナ: 生産資源所要量サブコア 追加情報がありません。
コンテナ標準入力/stdinOnce、tty 追加情報がありません。
externalTrafficPolicy: ローカル時のクライアントIPアドレスの保持 追加情報がありません。
configおよびconfigJson以外のImagePullSecretタイプ 追加情報がありません。
予測ボリューム・ソース: サービス・アカウント・トークン予測: 失効秒 追加情報がありません。
既存のコンテナ内ですでに実行されているプロセスと対話するためのkubectl attachコマンド。 追加情報がありません。

仮想ノードの使用時にサポートされない注目に値するContainer Engine for Kubernetesの機能

管理対象ノードではなく仮想ノードを使用する場合、一部のContainer Engine for Kubernetesの機能が使用できないか、まだ使用できません。

Container Engine for Kubernetesの機能はサポートされていません 追加情報
ワーカー・ノードへのSSH接続(要塞経由を含む) 使用できません
カスタムcloud-initスクリプトの使用 使用できません
Node Doctorスクリプト 使用できません
バージョン1.25より前のKubernetesバージョンのサポート 仮想ノードでは、クラスタで少なくともKubernetesバージョン1.25が実行されている必要があります。
仮想ノードと管理対象ノードの両方を含む混合クラスタ。 まだ使用可ではない
仮想ノードの数を自動スケールします。 まだ使用可ではない
仮想ノードをプロビジョニングするための容量予約。 まだ使用可ではない
IntelおよびGPUシェイプのポッド。 まだ使用可ではない
資格証明のローテーション(「クラスタ資格証明のローテーション」を参照) まだ使用可ではない

仮想ノードを使用する場合、共通デプロイメントはサポートされず、異なる方法でサポートされます

管理対象ノードではなく仮想ノードを使用する場合、または異なる方法でサポートされている場合は、次の共通デプロイメントはサポートされていません。

デプロイメント ノート
kube-systemネームスペースのkube-proxy、およびkube-proxyクラスタ・アドオン kube-proxyは、仮想ノードでスケジュールされているポッドで実行されますが、kube-systemネームスペースにはデプロイされません。
Kubernetes Dashboard 仮想ノードを使用する場合、サポートされません。
Nginxイングレス・コントローラ 仮想ノードを使用する場合、異なる方法でデプロイします(「サンプル・イングレス・コントローラの設定」を参照)。
Kubernetesクラスタ・自動スケーリング 仮想ノードを使用する場合、サポートされません。
縦型ポッド自動スケーリング 仮想ノードを使用する場合、サポートされません。
Kubernetesメトリック・サーバー 仮想ノードの使用時に異なる方法でデプロイします(クラスタへのKubernetesメトリック・サーバーのデプロイを参照)。

管理対象ノードおよび管理対象ノード・プール

管理対象ノードは、テナンシのコンピュート・インスタンス(ベア・メタルまたは仮想マシン)で実行されます。管理対象ノードを作成するには、管理対象ノード・プールを作成します。管理対象ノードおよび管理対象ノード・プールは、ユーザーが管理します。

管理対象ノードの管理はユーザーが担当しているため、特定の要件を満たすように柔軟に構成できます。管理対象ノードでKubernetesをアップグレードし、クラスタ容量を管理する責任があります。

管理対象ノードを使用する場合、アプリケーションを実行するコンピュート・インスタンスに対して支払います。

管理対象ノードおよびノード・プールは、基本クラスタと拡張クラスタの両方に作成できます。

管理対象ノードによって異なる機能をサポート

仮想ノードではなく管理対象ノードを使用するときは、いくつかの機能が異なります。

  • リソース割当:リソース割当は、ポッド・レベルではなくワーカー・ノード・レベルです。そのため、ポッド仕様ではなく、ノード・プール内のワーカー・ノードのCPUおよびメモリー・リソース要件を指定します。
  • ロード・バランシング:ロード・バランシングは、ポッド間ではなくワーカー・ノード間です(仮想ノードの場合と同様)。そのため、ポッド・レディネス・ゲートを使用して、管理対象ノードがあるクラスタ内のロード・バランサ・バックエンド・セットにトラフィックをルーティングすることはできません。
  • ポッド・ネットワーク: VCNネイティブ・ポッド・ネットワークCNIプラグインとチャネルCNIプラグインの両方がサポートされています。
  • 自動スケーリング: Kubernetes Cluster AutoscalerとVertical Pod Autoscalerの使用がサポートされています。

管理対象ノードの使用時にサポートされていない、またはまだ使用できない重要な機能

仮想ノードではなく管理対象ノードを使用する場合、次のような機能はまだ使用できません。
  • Kubernetes Taint