Documentazione di Oracle Cloud Infrastructure

Confronto dei nodi virtuali con i nodi gestiti

Scopri le differenze tra i nodi virtuali e i nodi gestiti che puoi creare utilizzando Kubernetes Engine (OKE).

Quando si crea un pool di nodi con Kubernetes Engine, è necessario specificare il tipo di nodi di lavoro da creare nel pool di nodi come uno o più dei seguenti:

È possibile creare solo nodi virtuali nei cluster avanzati. È possibile creare nodi gestiti sia nei cluster di base che nei cluster avanzati.

Tutti i riferimenti a 'nodi' e 'nodi di lavoro' nella documentazione di Kubernetes Engine fanno riferimento sia ai nodi virtuali che ai nodi gestiti, a meno che non sia esplicitamente indicato diversamente.

Nodi virtuali e pool di nodi virtuali

I nodi virtuali vengono eseguiti nella tenancy del motore Kubernetes. È possibile creare nodi virtuali creando un pool di nodi virtuali. I nodi virtuali e i pool di nodi virtuali sono completamente gestiti da Oracle.

I nodi virtuali offrono un'esperienza Kubernetes 'serverless', che ti consente di eseguire applicazioni containerizzate su larga scala senza il sovraccarico operativo derivante dall'upgrade dell'infrastruttura del piano dati e dalla gestione della capacità dei cluster.

È possibile creare solo nodi virtuali e pool di nodi nei cluster avanzati.

Funzioni notevoli supportate in modo diverso dai nodi virtuali

Alcune funzioni sono supportate in modo diverso quando si utilizzano i nodi virtuali anziché i nodi gestiti.

  • Allocazione risorse: l'allocazione delle risorse si trova a livello di pod anziché a livello di nodo di lavoro. Di conseguenza, è possibile specificare i requisiti delle risorse di CPU e memoria (come richieste e limiti) nella specifica pod, anziché per i nodi di lavoro in un pool di nodi. Vedere Risorse allocate ai pod con provisioning eseguito dai nodi virtuali.

  • Bilanciamento del carico: il bilanciamento del carico è tra i pod, piuttosto che tra i nodi di lavoro (come nel caso dei nodi gestiti). Nei cluster con nodi virtuali, la gestione delle liste di sicurezza del load balancer non è mai abilitata e devi sempre configurare manualmente le regole di sicurezza. I load balancer distribuiscono il traffico tra gli indirizzi IP dei pod e una porta nodo assegnata. Quando ci si connette a pod in esecuzione su nodi virtuali, utilizzare la sintassi <pod-ip>:<nodeport> anziché <node-ip>:<nodeport>. Se utilizzi subnet diverse per pod e nodi, configura l'ingresso delle porte dei nodi nella subnet pod.
  • Pod Networking: è supportata solo la rete di pod VCN nativa (il plugin CNI flannel non è supportato). Inoltre, il supporto è leggermente diverso quando si utilizzano nodi virtuali:
    • A ogni nodo virtuale è collegata una sola VNIC.
    • Gli indirizzi IP non vengono preallocati prima della creazione dei pod.
    • Il plugin CNI di networking pod VCN nativo non viene mostrato come in esecuzione nello spazio di nomi kube-system.
    • Poiché è supportato solo il networking pod nativo VCN, la tabella di instradamento della subnet pod deve disporre di regole di instradamento definite per un gateway NAT (non un gateway Internet) e un gateway di servizio.
  • Ridimensionamento automatico: i nodi virtuali vengono ridimensionati automaticamente per supportare 500 pod. Poiché Oracle gestisce le risorse di base per i nodi virtuali, è più facile lavorare con Kubernetes Horizontal Pod Autoscaler. Non è necessario utilizzare l'Autoscaler del cluster Kubernetes (che in ogni caso non è ancora supportato con i nodi virtuali). Kubernetes Vertical Pod Autoscaler non è supportato con i nodi virtuali.

Funzioni e funzionalità Kubernetes notevoli non supportate quando si utilizzano i nodi virtuali

Alcune funzioni e funzionalità Kubernetes non sono supportate o non sono ancora disponibili quando si utilizzano nodi virtuali anziché nodi gestiti.

Funzioni Kubernetes non supportate Informazioni aggiuntive
Flannel e altri plugin CNI di terze parti non sono supportati. I nodi virtuali supportano solo il plugin CNI Networking pod VCN nativo OCI.
I daemonset Kubernetes non sono supportati.

Ad esempio, quanto segue non è supportato:

apiVersion: apps/v1
kind: DaemonSet
Le richieste di volume persistenti (PVC) non sono supportate. Nessuna ulteriore informazione.
I provider di rete che supportano le risorse NetworkPolicy insieme al plugin CNI utilizzato nel cluster (ad esempio Calico e Cilium) non sono supportati. Nessuna ulteriore informazione.
I criteri di rete (la risorsa NetworkPolicy Kubernetes) non sono supportati. Nessuna ulteriore informazione.
I prodotti mesh di servizio non sono supportati. Prodotti come Oracle Cloud Infrastructure Service Mesh e Istio Service Mesh non sono supportati.

Le sonde di tipo HTTP sono supportate.

Sono supportate sonde HTTPS ed exec.

Le sonde di avvio sono supportate.

Le sonde gRPC non sono supportate.

probe.terminationGracePeriodSeconds non è supportato.

 Sono supportati, ad esempio:
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 3
livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
    scheme: "HTTPS"
startupProbe:
  httpGet:
    path: /healthz
    port:8080
Tuttavia, quanto segue non è supportato:
livenessProbe:
  grpc:
     port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

Il comando kubectl logs è supportato.

Il comando kubectl logs -p è supportato.

Il comando kubectl logs -f non è supportato.

 Sono supportati, ad esempio:
kubectl logs workload1-589578899f-lwzm9
kubectl logs workload1-589578899f-lwzm9 -p
Tuttavia, quanto segue non è supportato:
kubectl logs workload1-589578899f-lwzm9 -f
I contenitori effimeri non sono supportati. Nessuna ulteriore informazione.
Contenitori di inizializzazione non supportati. Nessuna ulteriore informazione.

Sono supportati i seguenti tipi di volume:

  • emptyDir
  • ConfigMap
  • Segreto

  • ProjectedVolume dei seguenti tipi:

    • ServiceAccount
    • ConfigMap
    • Segreto

I seguenti tipi di volume non sono supportati:

  • hostPath
  • persistentVolumeClaim
  • locale
  • nfs
  • iscsi
  • cefali

Ad esempio, quanto segue non è supportato:

volumes:
- name: test-volume
  hostPath:
    path: /data
Nella specifica pod è attualmente possibile definire un massimo di 1 volume di tipo emptyDir. Nessuna ulteriore informazione.

I seguenti campi Pod non sono supportati:

  • hostIPC
  • hostNetwork
  • hostPid
  • hostName
  • podOS
  • Sovraccarico
  • setHostNameAsFqdn
  • shareProcessNamespace
 Ad esempio, quanto segue non è supportato:
spec:
  hostIPC: true
  hostNetwork: true
  hostPID: false
  setHostnameAsFQDN : true
  shareProcessNamespace : true

Sono supportati i seguenti contesti di sicurezza pod sono:

  • runAsNonRoot
  • runAsUser
  • runAsGroup

I seguenti contesti di sicurezza pod non sono supportati:

  • fsGroup
  • fsGroupChangePolicy
  • supplementalGroups
  • seLinuxOptions
  • sysctls
  • seccompProfile
 Ad esempio, quanto segue non è supportato:
spec:
  securityContext:
    seLinuxOptions:
      type: dummy_container.proces

Sono supportati i seguenti contesti di sicurezza del contenitore:

  • readOnlyRootFilesystem
  • allowPrivilegeEscalation:false
  • capacità

I seguenti contesti di sicurezza contenitore non sono supportati:

  • allowPrivilegeEscalation:true
  • privilegiata
  • procMount
 Ad esempio:
containers:
  - name: openssh-1
    securityContext:
      capabilities:
        add:
        - CAP_NET_ADMIN
Tuttavia, quanto segue non è supportato:
containers:
  - name: openssh-1
    securityContext:
      procMount: Unmasked

Container.Port

  • IP host
  • Porta host
 Ad esempio, quanto segue non è supportato:
ports:
  - name: test
    containerPort: 81
    hostPort: 80

Container

  • TerminationMessagePolicy
  • TerminationMessagePath
  • VolumeDevices
  • VolumeMount.MountPropagation
  • Espressione VolumeMount.Subpath
 Si noti che Kubernetes aggiunge TerminationMessagePolicy e TerminationMessagePath per impostazione predefinita.
L'intervallo di porte del contenitore (1, 65535) non può essere in conflitto con l'intervallo NodePort (30000-32767). Ad esempio, quanto segue non è supportato:
containers:
  - name: my-nginx
    image: nginx
    ports:
    - containerPort: 30002
Pod.Volumes.EmptyDirVolumeFonte:SizeLimit Ad esempio, quanto segue non è supportato:
emptyDir:
  sizeLimit: 500Mi
Pod.Volumes.EmptyDirVolumeSource:Medium - può essere solo "" o "Memory" Ad esempio, quanto segue non è supportato:
emptyDir:
  medium: "Memory1"

Pod:Volumes - Mode deve essere specificato come 0644 per quanto segue:

  • ConfigMapVolumeSource:KeyToPath:Mode
  • SecretVolumeSource:KeyToPath:Mode
  • ProiettatoFonte:SecretProjection:KeyToPath:Mode
  • ProjectedVolumeSource:ConfigMapProiezione:KeyToPath:Mode
 Ad esempio, quanto segue non è supportato:
- name: myconfigmap
  configMap:
    name: kube-root-ca.crt
    items:
    - key: ca.crt
      path: abc
      mode: 0400

Pod:Volumi - se DefaultMode specificato per quanto segue, DefaultMode deve essere 0644:

  • ConfigMapVolumeSource:DefaultMode
  • Origine volume prevista: DefaultMode
  • SecretVolumeSource: DefaultMode
 Ad esempio, quanto segue non è supportato:
- name: workload-volume
    configMap:
      name: myconfigmap
      defaultMode: 0400
Resources.Requests non può essere diverso da Resources.Limits Ad esempio, quanto segue non è supportato:
resources:
  requests:
    cpu: 50m
    memory: 200Mi
  limits:
    cpu: 100m
    memory: 400Mi
Volumi:DownwardAPI:ResourceFieldRef Ad esempio, quanto segue non è supportato:
resourceFieldRef:
  containerName: openssh
  resource: limits.cpu
TerminationGracePeriodSeconds Ad esempio, quanto segue non è supportato:
terminationGracePeriodSeconds: 30
DeletionGracePeriodSeconds Ad esempio, quanto segue non è supportato:
metadata:
  DeletionGracePeriodSeconds: 30
Esegui contenitore Ad esempio, quanto segue non è supportato:
kubectl exec workload1-589578899f-lwzm9 -- sh
Comando port-forward di Kubectl Utilizzare invece kubectl proxy (vedere Risoluzione dei problemi di pod e servizi sui nodi virtuali utilizzando il proxy kubectl anziché il port-forward kubectl).
richieste UpdatePod con mutazioni a pod.spec.containers[].image Nessuna ulteriore informazione.
Propagazione a pod di aggiornamenti a configmap e segreti montati Nessuna ulteriore informazione.

Sono supportate le metriche a livello di contenitore riportate di seguito nell'endpoint delle metriche kubelet virtuale.

  • container_cpu_usage_seconds_total
  • container_memory_working_set_bytes
Altre metriche a livello di contenitore nell'endpoint delle metriche del kubelet virtuale non sono supportate.		 Nessuna ulteriore informazione.
Container: Subcore ResourceRequirements Nessuna ulteriore informazione.
Contenitore stdin/stdinOnce, tty Nessuna ulteriore informazione.
Conserva gli indirizzi IP del client quando externalTrafficPolicy: locale Nessuna ulteriore informazione.
Tipi ImagePullSecret diversi da config e configJson Nessuna ulteriore informazione.
ProjectedVolumeSource:ServiceAccountTokenProiezione: ExpirationSeconds Nessuna ulteriore informazione.
Il comando kubectl attach per interagire con un processo già in esecuzione all'interno di un contenitore esistente. Nessuna ulteriore informazione.

Funzioni e funzionalità notevoli di Kubernetes Engine (OKE) non supportate quando si utilizzano i nodi virtuali

Alcune funzioni e funzionalità di Kubernetes Engine non sono disponibili o non sono ancora disponibili quando si utilizzano nodi virtuali anziché nodi gestiti.

Funzioni del motore Kubernetes non supportate Informazioni aggiuntive
Connessioni SSH ai nodi di lavoro (anche tramite un bastion) Non disponibile.
Uso di script cloud-init personalizzati Non disponibile.
Script Node Doctor Non disponibile.
Supporto per le versioni Kubernetes precedenti alla versione 1.25 I nodi virtuali richiedono che il cluster esegua almeno Kubernetes versione 1.25.
Cluster misti, contenenti sia nodi virtuali che nodi gestiti. Non ancora disponibile.
Scalabilità automatica del numero di nodi virtuali. Non ancora disponibile.
Assegnazioni capacità per eseguire il provisioning dei nodi virtuali. Non ancora disponibile.
Pod con forme Intel e GPU. Non ancora disponibile.

Distribuzioni comuni non supportate e supportate in modo diverso quando si utilizzano i nodi virtuali

Le seguenti distribuzioni comuni non sono supportate quando si utilizzano nodi virtuali anziché nodi gestiti o sono supportate in modo diverso:

Sviluppo Note
kube-proxy nello spazio di nomi kube-system e l'add-on cluster kube-proxy kube-proxy viene eseguito in pod pianificati su nodi virtuali, ma non viene distribuito nello spazio di nomi kube-system.
Dashboard Kubernetes Non supportato quando si utilizzano i nodi virtuali.
Controller di ingresso Nginx Distribuire in modo diverso quando si utilizzano i nodi virtuali (vedere Impostazione del controller di entrata di esempio).
Autoscaler del cluster Kubernetes Non supportato quando si utilizzano i nodi virtuali.
Autoscaler pod verticale Non supportato quando si utilizzano i nodi virtuali.
Server metriche Kubernetes Distribuisci in modo diverso quando utilizzi i nodi virtuali (vedere Distribuzione del server delle metriche Kubernetes in un cluster).

Nodi gestiti e pool di nodi gestiti

I nodi gestiti vengono eseguiti sulle istanze di computazione (bare metal o virtual machine) nella tenancy. Per creare nodi gestiti, creare un pool di nodi gestiti. I nodi gestiti e i pool di nodi gestiti sono gestiti dall'utente.

Poiché sei responsabile della gestione dei nodi gestiti, hai la flessibilità di configurarli per soddisfare i tuoi requisiti specifici. Sei responsabile dell'upgrade di Kubernetes sui nodi gestiti e della gestione della capacità del cluster.

Quando si utilizzano i nodi gestiti, si paga per le istanze di computazione che eseguono le applicazioni.

È possibile creare nodi gestiti e pool di nodi sia nei cluster di base che nei cluster avanzati.

Per ulteriori informazioni, vedere Confronto dei nodi gestiti con i nodi virtuali