Documentación de Oracle Cloud Infrastructure

Comparación de nodos virtuales con nodos gestionados

Descubra las diferencias entre los nodos virtuales y los nodos gestionados que puede crear mediante Container Engine for Kubernetes (OKE).

Al crear un pool de nodos con Container Engine for Kubernetes, especifique el tipo de nodos de trabajador que se va a crear en el pool de nodos como uno u otro de los siguientes:

Solo puede crear nodos virtuales en clusters mejorados. Puede crear nodos gestionados tanto en clusters básicos como en clusters mejorados.

Todas las referencias a 'nodos' y 'nodos de trabajador' en la documentación de Container Engine for Kubernetes hacen referencia a nodos virtuales y nodos gestionados, a menos que se indique explícitamente lo contrario.

Nodos virtuales y pools de nodos virtuales

Los nodos virtuales se ejecutan en el arrendamiento de Container Engine for Kubernetes. Puede crear nodos virtuales mediante la creación de un pool de nodos virtuales. Oracle gestiona completamente los nodos virtuales y los pools de nodos virtuales.

Los nodos virtuales proporcionan una experiencia de Kubernetes "sin servidor", lo que le permite ejecutar aplicaciones en contenedores a escala sin la sobrecarga operativa que supone actualizar la infraestructura del plano de datos y gestionar la capacidad de los clusters.

Solo puede crear nodos virtuales y pools de nodos en clusters mejorados.

Funciones notables soportadas de forma diferente por los nodos virtuales

Algunas funciones se soportan de forma diferente cuando se utilizan nodos virtuales en lugar de nodos gestionados:

  • Asignación de recursos: la asignación de recursos está en el nivel del pod, en lugar de en el nivel del nodo de trabajador. Por lo tanto, debe especificar los requisitos de recursos de CPU y memoria (como solicitudes y límites) en la especificación de pod, en lugar de los nodos de trabajador de un pool de nodos. Consulte Recursos asignados a pods aprovisionados por nodos virtuales.

  • Equilibrio de carga: el equilibrio de carga se encuentra entre pods, en lugar de entre nodos de trabajador (como es el caso de los nodos gestionados). En los clusters con nodos virtuales, la gestión de listas de seguridad del equilibrador de carga nunca está activada y siempre se tienen que configurar manualmente las reglas de seguridad. Los equilibrios de carga distribuyen el tráfico entre las direcciones IP de los pods y un puerto de nodo asignado. Al conectarse a pods que se ejecutan en nodos virtuales, utilice la sintaxis <pod-ip>:<nodeport>, en lugar de <node-ip>:<nodeport>. Si utiliza diferentes subredes para pods y nodos, configure la entrada de puerto de nodo en la subred de pod.
  • Red de pod: solo se admiten las redes de pod nativos de VCN (no se admite el plugin CNI de canal). Además, el soporte es ligeramente diferente cuando se utilizan nodos virtuales:
    • Solo hay una VNIC conectada a cada nodo virtual.
    • Las direcciones IP no se asignan previamente antes de crear los pods.
    • El plugin CNI de red de pod nativo de VCN no se muestra como en ejecución en el espacio de nombres kube-system.
    • Dado que solo están soportadas las redes de pod nativos de VCN, la tabla de rutas de subred de pod debe tener reglas de ruta definidas para un gateway de NAT (no un gateway de Internet) y un gateway de servicio.
  • Escala automática: los nodos virtuales se escalan automáticamente para soportar 500 pods. Dado que Oracle gestiona los recursos subyacentes para los nodos virtuales, es más fácil trabajar con la escala automática de pod horizontal de Kubernetes. No es necesario utilizar la escala automática del cluster de Kubernetes (que aún no está soportada con nodos virtuales en ningún caso). La escala automática de pod vertical de Kubernetes no está soportada con nodos virtuales.

Funciones y capacidades notables de Kubernetes no soportadas al utilizar nodos virtuales

Algunas funciones y capacidades de Kubernetes no están soportadas o aún no están disponibles cuando se utilizan nodos virtuales en lugar de nodos gestionados.

Funciones de Kubernetes no soportadas Información adicional
Flannel y otros complementos CNI de terceros no son compatibles. Los nodos virtuales solo soportan el plugin de CNI de red de pods nativos de VCN de OCI.
Los conjuntos de daemons de Kubernetes no están soportados.

Por ejemplo, no se admite lo siguiente:

apiVersion: apps/v1
kind: DaemonSet
No se admiten las reclamaciones de volumen persistentes (PVC). Sin información adicional.
Los proveedores de red que admiten recursos NetworkPolicy junto con el plugin CNI utilizado en el cluster (como Calico y Cilium) no son compatibles. Sin información adicional.
Las políticas de red (recurso NetworkPolicy de Kubernetes) no están soportadas. Sin información adicional.
Los productos de malla de servicios no están soportados. No están soportados productos como Oracle Cloud Infrastructure Service Mesh e Istio Service Mesh.

Están soportados los sondeos de disponibilidad y actividad de tipo HTTP .

Los sondeos HTTPS, gRPC y exec no se admiten.

Los sondeos de inicio no se admiten.

probe.terminationGracePeriodSeconds no está soportado.

 Por ejemplo, se admite lo siguiente:
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 3
Sin embargo, lo siguiente no se admite:
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

El comando kubectl logs se admite.

El comando kubectl logs -f no se admite.

 Por ejemplo, no se admite lo siguiente:
kubectl logs -f workload1-589578899f-lwzm9
No se admiten contenedores efímeros. Sin información adicional.
No se admiten contenedores de inicialización. Sin información adicional.

Están soportados los siguientes tipos de volúmenes:

  • emptyDir
  • ConfigMap
  • Secreto

  • ProjectedVolume de los siguientes tipos:

    • ServiceAccount
    • ConfigMap
    • Secreto

Los siguientes tipos de volúmenes no están soportados:

  • hostPath
  • persistentVolumeClaim
  • locales
  • NFS
  • iscsi
  • cefalea

Por ejemplo, no se admite lo siguiente:

volumes:
- name: test-volume
  hostPath:
    path: /data
Actualmente se puede definir un máximo de 1 volumen de tipo emptyDir en la especificación de pod. Sin información adicional.

Los siguientes campos de pod no están soportados:

  • hostIPC
  • hostNetwork
  • hostPid
  • hostName
  • podOS
  • Sobrecarga
  • setHostNameAsFqdn
  • shareProcessNamespace
 Por ejemplo, no se admite lo siguiente:
spec:
  hostIPC: true
  hostNetwork: true
  hostPID: false
  setHostnameAsFQDN : true
  shareProcessNamespace : true

Los siguientes contextos de seguridad de pod están soportados:

  • runAsNonRoot
  • runAsUser
  • runAsGroup

Los siguientes contextos de seguridad de pod no están soportados:

  • fsGroup
  • fsGroupChangePolicy
  • supplementalGroups
  • seLinuxOptions
  • sistema
  • seccompProfile
 Por ejemplo, no se admite lo siguiente:
spec:
  securityContext:
    seLinuxOptions:
      type: dummy_container.proces

Se admiten los siguientes contextos de seguridad de contenedor:

  • readOnlyRootFilesystem
  • allowPrivilegeEscalation:false

Los siguientes contextos de seguridad de contenedor no están soportados:

  • allowPrivilegeEscalation:true
  • con privilegios
  • procMount
  • capacidades
 Por ejemplo, no se admite lo siguiente:
containers:
  - name: openssh-1
    securityContext:
      capabilities:
        add:
        - CAP_NET_ADMIN

Container.Port

  • IP del Host
  • Puerto del Host
 Por ejemplo, no se admite lo siguiente:
ports:
  - name: test
    containerPort: 81
    hostPort: 80

Contenedor

  • TerminationMessagePolicy
  • TerminationMessagePath
  • VolumeDevices
  • VolumeMount.MountPropagation
  • Expresión VolumeMount.Subpath
 Tenga en cuenta que Kubernetes agrega TerminationMessagePolicy y TerminationMessagePath por defecto.
El rango de puertos de contenedor (1, 65535) no puede entrar en conflicto con el rango NodePort (30000-32767). Por ejemplo, no se admite lo siguiente:
containers:
  - name: my-nginx
    image: nginx
    ports:
    - containerPort: 30002
Pod.Volumes.EmptyDirVolumeOrigen:Límite de tamaño Por ejemplo, no se admite lo siguiente:
emptyDir:
  sizeLimit: 500Mi
Pod.Volumes.EmptyDirVolumeSource:Medium - solo puede ser "" o "Memoria" Por ejemplo, no se admite lo siguiente:
emptyDir:
  medium: "Memory1"

Pod:Volumes - El modo se debe especificar como 0644 para lo siguiente:

  • ConfigMapVolumeSource:KeyToPath:Modo
  • SecretVolumeSource:KeyToPath:Mode
  • ProjectedVolumeSource:SecretProjection:KeyToPath:Modo
  • ProjectedVolumeSource:ConfigMapProjection:KeyToPath:Modo
 Por ejemplo, no se admite lo siguiente:
- name: myconfigmap
  configMap:
    name: kube-root-ca.crt
    items:
    - key: ca.crt
      path: abc
      mode: 0400

Pod:Volumes: si se especifica DefaultMode para lo siguiente, DefaultMode debe ser 0644:

  • ConfigMapVolumeSource:Modo predeterminado
  • ProjectedVolumeSource:modo predeterminado
  • SecretVolumeSource: modo predeterminado
 Por ejemplo, no se admite lo siguiente:
- name: workload-volume
    configMap:
      name: myconfigmap
      defaultMode: 0400
Resources.Requests no puede ser diferente de Resources.Limits Por ejemplo, no se admite lo siguiente:
resources:
  requests:
    cpu: 50m
    memory: 200Mi
  limits:
    cpu: 100m
    memory: 400Mi
Volúmenes:DownwardAPI:ResourceFieldRef Por ejemplo, no se admite lo siguiente:
resourceFieldRef:
  containerName: openssh
  resource: limits.cpu
TerminationGracePeriodSeconds Por ejemplo, no se admite lo siguiente:
terminationGracePeriodSeconds: 30
DeletionGracePeriodSeconds Por ejemplo, no se admite lo siguiente:
metadata:
  DeletionGracePeriodSeconds: 30
Contenedor de ejecución Por ejemplo, no se admite lo siguiente:
kubectl exec workload1-589578899f-lwzm9 -- sh
Comando port-forward de Kubectl Utilice kubectl proxy en su lugar (consulte Solución de problemas de pod y servicio en nodos virtuales mediante proxy de kubectl en lugar de kubectl port-forward).
Solicitudes UpdatePod con mutaciones en pod.spec.containers[].image Sin información adicional.
Propagación a pods de actualizaciones a configmaps y secretos montados Sin información adicional.
Métricas de nivel de contenedor en punto final de métricas de kubelet virtual Sin información adicional.
Contenedor:Subnúcleo de ResourceRequirements Sin información adicional.
Contenedor stdin/stdinOnce, tty Sin información adicional.
Conservar direcciones IP de cliente cuando externalTrafficPolicy: local Sin información adicional.
Tipos ImagePullSecret distintos de config y configJson Sin información adicional.
ProjectedVolumeSource:ServiceAccountTokenProjection:ExpirationSeconds Sin información adicional.
El comando kubectl attach para interactuar con un proceso que ya se está ejecutando dentro de un contenedor existente. Sin información adicional.

Funciones y capacidades notables de Container Engine for Kubernetes no soportadas al utilizar nodos virtuales

Algunas funciones y capacidades de Container Engine for Kubernetes no están disponibles, o aún no lo están, al utilizar nodos virtuales en lugar de nodos gestionados.

Las funciones de Container Engine for Kubernetes no están soportadas Información adicional
Conexiones SSH a nodos de trabajador (incluso a través de un bastión) No disponible.
Uso de scripts personalizados de cloud-init No disponible.
Script de Node Doctor No disponible.
Soporte para versiones de Kubernetes anteriores a la versión 1.25 Los nodos virtuales requieren que el cluster ejecute al menos la versión 1.25 de Kubernetes.
Clusters mixtos que contienen nodos virtuales y nodos gestionados. Aún no está disponible.
Escala automática del número de nodos virtuales. Aún no está disponible.
Reservas de capacidad para aprovisionar nodos virtuales. Aún no está disponible.
Pods con unidades Intel y GPU. Aún no está disponible.
Rotación de credenciales, como se describe en Rotación de credenciales de cluster Aún no está disponible.

Despliegues comunes no soportados y soportados de forma diferente al utilizar nodos virtuales

Los siguientes despliegues comunes no están soportados cuando se utilizan nodos virtuales en lugar de nodos gestionados, o están soportados de forma diferente:

Despliegue Notas:
kube-proxy en el espacio de nombres kube-system y el complemento de cluster kube-proxy kube-proxy se ejecuta en pods programados en nodos virtuales, pero no se despliega en el espacio de nombres kube-system.
Panel de control de Kubernetes No se admite cuando se utilizan nodos virtuales.
Controlador de entrada de Nginx Despliegue de forma diferente al utilizar nodos virtuales (consulte Configuración del controlador de entrada de ejemplo).
Escala automática del cluster de Kubernetes No se admite cuando se utilizan nodos virtuales.
Escala automática de pod vertical No se admite cuando se utilizan nodos virtuales.
Servidor de métricas de Kubernetes Despliegue de forma diferente al utilizar nodos virtuales (consulte Despliegue del servidor de métricas de Kubernetes en un cluster).

Nodos gestionados y pools de nodos gestionados

Los nodos gestionados se ejecutan en las instancias de Compute (tanto con hardware dedicado como en máquina virtual) de su arrendamiento. Puede crear nodos gestionados mediante la creación de un pool de nodos gestionados. Los nodos gestionados y los pools de nodos gestionados son gestionados por usted.

Como responsable de gestionar los nodos gestionados, tiene la posibilidad de configurarlos para cumplir sus requisitos específicos. Usted se encargará de cambiar la versión de Kubernetes en nodos gestionados y de gestionar la capacidad del cluster.

Al utilizar nodos gestionados, paga por las instancias de Compute que ejecutan aplicaciones.

Puede crear nodos gestionados y pools de nodos tanto en clusters básicos como en clusters mejorados.

Funciones notables soportadas de forma diferente por los nodos gestionados

Algunas funciones se soportan de forma diferente cuando se utilizan nodos gestionados en lugar de nodos virtuales:

  • Asignación de recursos: la asignación de recursos está en el nivel del nodo de trabajador, en lugar de en el nivel del pod. Por lo tanto, debe especificar los requisitos de recursos de CPU y memoria para los nodos de trabajador en un pool de nodos, en lugar de en la especificación de pod.
  • Equilibrio de carga: el equilibrio de carga se encuentra entre nodos de trabajador, en lugar de entre pods (como es el caso de los nodos virtuales). Por lo tanto, no puede utilizar puertas de preparación de pod para enrutar el tráfico a juegos de backends de equilibrador de carga en clusters con nodos gestionados.
  • Red de pod: se admiten tanto el plugin CNI de red de pod nativo de VCN como el plugin CNI de canal.
  • Escala automática: está soportado el uso de la escala automática del cluster de Kubernetes y la escala automática de pod vertical.

Funciones notables no soportadas o aún no disponibles al utilizar nodos gestionados

Algunas funciones aún no están disponibles cuando se utilizan nodos gestionados en lugar de nodos virtuales, como:
  • Marcados de Kubernetes