Comparaison entre les noeuds virtuels et les noeuds gérés

Découvrez les différences entre les noeuds virtuels et les noeuds gérés que vous pouvez créer à l'aide de Kubernetes Engine (OKE).

Lorsque vous créez un pool de noeuds avec Kubernetes Engine, vous indiquez le type de noeud de processus actif à créer dans le pool de noeuds comme l'un ou l'autre des types suivants :

Noeuds virtuels : les noeuds virtuels sont entièrement gérés par Oracle. Reportez-vous à la section Virtual Nodes and Virtual Node Pools.
Noeuds gérés : les noeuds gérés sont exécutés sur des instances de calcul (bare metal ou machine virtuelle) dans votre location et sont au moins partiellement gérés par vous. Reportez-vous à Noeuds gérés et pools de noeuds gérés.

Vous pouvez uniquement créer des noeuds virtuels dans des clusters améliorés. Vous pouvez créer des noeuds gérés dans des clusters de base et des clusters améliorés.

Toutes les références aux "noeuds" et aux "noeuds de travail" dans la documentation du moteur Kubernetes font référence aux noeuds virtuels et aux noeuds gérés, sauf indication contraire explicite.

Noeuds virtuels et pools de noeuds virtuels

Les noeuds virtuels sont exécutés dans la location Kubernetes Engine. Vous créez des noeuds virtuels en créant un pool de noeuds virtuels. Les noeuds virtuels et les pools de noeuds virtuels sont entièrement gérés par Oracle.

Les noeuds virtuels offrent une expérience Kubernetes "sans serveur", ce qui vous permet d'exécuter des applications en conteneur à grande échelle sans frais opérationnels liés à la mise à niveau de l'infrastructure de plan de données et à la gestion de la capacité des clusters.

Vous pouvez uniquement créer des noeuds virtuels et des pools de noeuds dans des clusters améliorés.

Fonctionnalités notables prises en charge différemment par les noeuds virtuels

Certaines fonctionnalités sont prises en charge différemment lorsque vous utilisez des noeuds virtuels plutôt que des noeuds gérés :

Allocation des ressources : l'allocation des ressources se fait au niveau du pod, plutôt qu'au niveau du noeud de processus actif. Par conséquent, vous indiquez les besoins en ressources de CPU et de mémoire (en tant que demandes et limites) dans la spécification de pod, plutôt que pour les noeuds de processus actif d'un pool de noeuds. Reportez-vous à Ressources allouées aux pods provisionnés par des noeuds virtuels.
Equilibrage de charge : l'équilibrage de charge est effectué entre les pods, plutôt qu'entre les noeuds de processus actif (comme c'est le cas avec les noeuds gérés). Dans les clusters avec des noeuds virtuels, la gestion des listes de sécurité de l'équilibreur de charge n'est jamais activée et vous devez toujours configurer manuellement les règles de sécurité. Les équilibreurs de charge répartissent le trafic entre les adresses IP des pods et un port de noeud affecté. Lors de la connexion à des pods exécutés sur des noeuds virtuels, utilisez la syntaxe <pod-ip>:<nodeport> plutôt que <node-ip>:<nodeport>. Si vous utilisez différents sous-réseaux pour les pods et les noeuds, configurez l'entrée de port de noeud sur le sous-réseau de pod.
Mise en réseau de pods : seule la mise en réseau de pods native VCN est prise en charge (le plug-in CNI flannel n'est pas pris en charge). En outre, la prise en charge est légèrement différente lors de l'utilisation de noeuds virtuels :
- Une seule carte d'interface réseau virtuelle est attachée à chaque noeud virtuel.
- Les adresses IP ne sont pas préallouées avant la création des pods.
- Le plug-in CNI de mise en réseau de pod natif VCN n'est pas affiché comme étant en cours d'exécution dans l'espace de noms du système kube.
- Etant donné que seule la mise en réseau de pod natif VCN est prise en charge, la table de routage du sous-réseau de pod doit comporter des règles de routage définies pour une passerelle NAT (et non pour une passerelle Internet) et une passerelle de service.
Redimensionnement automatique : les noeuds virtuels évoluent automatiquement pour prendre en charge 500 pods. Etant donné qu'Oracle gère les ressources sous-jacentes pour les noeuds virtuels, il est plus facile d'utiliser l'outil de redimensionnement automatique de pod horizontal Kubernetes. Il n'est pas nécessaire d'utiliser l'outil de redimensionnement automatique de cluster Kubernetes (qui n'est en aucun cas pris en charge avec les noeuds virtuels). L'outil de redimensionnement automatique de pod vertical Kubernetes n'est pas pris en charge avec les noeuds virtuels.

Fonctionnalités et fonctionnalités Kubernetes notables non prises en charge lors de l'utilisation de noeuds virtuels

Certaines fonctionnalités de Kubernetes ne sont pas prises en charge ou ne sont pas encore disponibles lors de l'utilisation de noeuds virtuels plutôt que de noeuds gérés.


Fonctionnalités Kubernetes non prises en charge	Informations supplémentaires
Flannel et les autres plugins CNI tiers ne sont pas pris en charge.	Les noeuds virtuels prennent uniquement en charge le module d'extension CNI OCI VCN-Native Pod Networking.
Les ensembles de démons Kubernetes ne sont pas pris en charge.	Par exemple, ce qui suit n'est pas pris en charge : `apiVersion: apps/v1 kind: DaemonSet`
Les demandes de volume persistant (PVC) ne sont pas prises en charge.	Aucune information supplémentaire.
Les fournisseurs réseau qui prennent en charge les ressources NetworkPolicy avec le module d'extension CNI utilisé dans le cluster (comme Calico et Cilium) ne sont pas pris en charge.	Aucune information supplémentaire.
Les stratégies réseau (ressource NetworkPolicy Kubernetes) ne sont pas prises en charge.	Aucune information supplémentaire.
Les produits de maillage de service ne sont pas pris en charge.	Les produits tels que Istio Service Mesh ne sont pas pris en charge.
Les tests de disponibilité et de préparation de type HTTP sont pris en charge. Les sondes HTTPS et exec sont prises en charge. Les sondes de démarrage sont prises en charge. Les sondes gRPC ne sont pas prises en charge. probe.terminationGracePeriodSeconds n'est pas pris en charge.	Par exemple, les éléments suivants sont pris en charge : `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` Les éléments suivants ne sont toutefois pas pris en charge : `livenessProbe: grpc: port: 8080 initialDelaySeconds: 5 periodSeconds: 5`
La commande `kubectl logs` est prise en charge. La commande `kubectl logs -p` est prise en charge. La commande `kubectl logs -f` n'est pas prise en charge.	Par exemple, les éléments suivants sont pris en charge : `kubectl logs workload1-589578899f-lwzm9` `kubectl logs workload1-589578899f-lwzm9 -p` Les éléments suivants ne sont toutefois pas pris en charge : `kubectl logs workload1-589578899f-lwzm9 -f`
Les conteneurs éphémères ne sont pas pris en charge.	Aucune information supplémentaire.
Les conteneurs d'initialisation ne sont pas pris en charge.	Aucune information supplémentaire.
Les types de volume suivants sont pris en charge : emptyDir ConfigMap Clé secrète ProjectedVolume des types suivants : ServiceAccount ConfigMap Clé secrète Les types de volume suivants ne sont pas pris en charge : hostPath persistentVolumeClaim locale nfs iscsi Céphalées	Par exemple, ce qui suit n'est pas pris en charge : `volumes: - name: test-volume hostPath: path: /data`
1 volume maximum de type emptyDir peut actuellement être défini dans la spécification de pod.	Aucune information supplémentaire.
Les champs Pod suivants ne sont pas pris en charge : hostIPC hostNetwork hostPid hostName podOS Surcharge setHostNameAsFqdn shareProcessNamespace	Par exemple, ce qui suit n'est pas pris en charge : `spec: hostIPC: true hostNetwork: true hostPID: false setHostnameAsFQDN : true shareProcessNamespace : true`
Les contextes de sécurité de pod suivants sont pris en charge : runAsNonRoot runAsUser runAsGroup Les contextes de sécurité de pod suivants ne sont pas pris en charge : fsGroup fsGroupChangePolicy supplementalGroups seLinuxOptions sysctls seccompProfile	Par exemple, ce qui suit n'est pas pris en charge : `spec: securityContext: seLinuxOptions: type: dummy_container.proces`
Les contextes de sécurité de conteneur suivants sont pris en charge : readOnlyRootFilesystem allowPrivilegeEscalation : False capacités Les contextes de sécurité de conteneur suivants ne sont pas pris en charge : allowPrivilegeEscalation : true privilégié procMount	Par exemple, les éléments suivants sont pris en charge : `containers: - name: openssh-1 securityContext: capabilities: add: - CAP_NET_ADMIN` Les éléments suivants ne sont toutefois pas pris en charge : `containers: - name: openssh-1 securityContext: procMount: Unmasked`
Container.Port IP d'hôte Port de l'hôte	Par exemple, ce qui suit n'est pas pris en charge : `ports: - name: test containerPort: 81 hostPort: 80`
Conteneur TerminationMessagePolicy TerminationMessagePath VolumeDevices VolumeMount.MountPropagation Expression VolumeMount.Subpath	Kubernetes ajoute TerminationMessagePolicy et TerminationMessagePath par défaut.
La plage de ports de conteneur (1, 65535) ne peut pas entrer en conflit avec la plage NodePort (30000-32767).	Par exemple, ce qui suit n'est pas pris en charge : `containers: - name: my-nginx image: nginx ports: - containerPort: 30002`
Pod.Volumes.EmptyDirVolumeSource :SizeLimit	Par exemple, ce qui suit n'est pas pris en charge : `emptyDir: sizeLimit: 500Mi`
Pod.Volumes.EmptyDirVolumeSource:Medium - ne peut être que "" ou "Memory"	Par exemple, ce qui suit n'est pas pris en charge : `emptyDir: medium: "Memory1"`
Pod:Volumes - Le mode doit être défini sur 0644 pour les éléments suivants : ConfigMapVolumeSource:KeyToPath:Mode SecretVolumeSource:KeyToPath:Mode ProjectedVolumeSource :SecretProjection:KeyToPath:Mode ProjectedVolumeSource :ConfigMapProjection:KeyToPath:Mode	Par exemple, ce qui suit n'est pas pris en charge : `- name: myconfigmap configMap: name: kube-root-ca.crt items: - key: ca.crt path: abc mode: 0400`
Pod:Volumes : si DefaultMode est spécifié pour les éléments suivants, DefaultMode doit être 0644 : ConfigMapVolumeSource : DefaultMode ProjectedVolumeSource : DefaultMode SecretVolumeSource : DefaultMode	Par exemple, ce qui suit n'est pas pris en charge : `- name: workload-volume configMap: name: myconfigmap defaultMode: 0400`
Resources.Requests ne peut pas être différent de Resources.Limits	Par exemple, ce qui suit n'est pas pris en charge : `resources: requests: cpu: 50m memory: 200Mi limits: cpu: 100m memory: 400Mi`
Volumes:DownwardAPI:ResourceFieldRef	Par exemple, ce qui suit n'est pas pris en charge : `resourceFieldRef: containerName: openssh resource: limits.cpu`
TerminationGracePeriodSeconds	Par exemple, ce qui suit n'est pas pris en charge : `terminationGracePeriodSeconds: 30`
DeletionGracePeriodSeconds	Par exemple, ce qui suit n'est pas pris en charge : `metadata: DeletionGracePeriodSeconds: 30`
Conteneur d'exécution	Par exemple, ce qui suit n'est pas pris en charge : `kubectl exec workload1-589578899f-lwzm9 -- sh`
Commande port-forward de Kubectl	Utilisez `kubectl proxy` à la place (reportez-vous à Dépannage des problèmes de pod et de service sur les noeuds virtuels à l'aide du proxy kubectl plutôt que de la transmission de port kubectl).
Demandes UpdatePod avec des mutations vers pod.spec.containers[].image	Aucune information supplémentaire.
Propagation aux pods des mises à jour des configmaps et des clés secrètes montées	Aucune information supplémentaire.
Les mesures de niveau conteneur suivantes dans l'adresse de mesures de kubelet virtuel sont prises en charge : container_cpu_usage_seconds_total container_memory_working_set_bytes D'autres mesures au niveau du conteneur dans l'adresse de mesures de kubelet virtuel ne sont pas prises en charge.	Aucune information supplémentaire.
Conteneur : Sous-cœur ResourceRequirements	Aucune information supplémentaire.
Conteneur stdin/stdinOnce, tty	Aucune information supplémentaire.
Conserver les adresses IP client lorsque externalTrafficPolicy : local	Aucune information supplémentaire.
Types ImagePullSecret autres que config et configJson	Aucune information supplémentaire.
ProjectedVolumeSource : ServiceAccountTokenProjection : ExpirationSeconds	Aucune information supplémentaire.
Commande `kubectl attach` permettant d'interagir avec un processus déjà en cours d'exécution dans un conteneur existant.	Aucune information supplémentaire.

Fonctionnalités et fonctionnalités importantes de Kubernetes Engine (OKE) non prises en charge lors de l'utilisation de noeuds virtuels

Certaines fonctionnalités du moteur Kubernetes ne sont pas disponibles ou ne sont pas encore disponibles lorsque vous utilisez des noeuds virtuels plutôt que des noeuds gérés.


Fonctionnalités du moteur Kubernetes non prises en charge	Informations supplémentaires
Connexions SSH aux noeuds de processus actif (y compris via un bastion)	Non disponible.
Utilisation de scripts cloud-init personnalisés	Non disponible.
Script Node Doctor	Non disponible.
Prise en charge des versions de Kubernetes antérieures à la version 1.25	Les noeuds virtuels nécessitent que le cluster exécute au moins Kubernetes version 1.25.
Clusters mixtes, contenant à la fois des noeuds virtuels et des noeuds gérés.	Non encore disponible.
Redimensionnement automatique du nombre de noeuds virtuels.	Non encore disponible.
Réservations de capacité pour provisionner des noeuds virtuels.	Non encore disponible.
Pods avec des formes Intel et GPU.	Non encore disponible.

Déploiements courants non pris en charge et pris en charge différemment lors de l'utilisation de noeuds virtuels

Les déploiements courants suivants ne sont pas pris en charge lors de l'utilisation de noeuds virtuels plutôt que de noeuds gérés, ou sont pris en charge différemment :


Déploiement	Remarques
kube-proxy dans l'espace de noms kube-system et l'extension kube-proxy cluster	kube-proxy s'exécute dans des pods programmés sur des noeuds virtuels, mais n'est pas déployé dans l'espace de noms kube-system.
Tableau de bord Kubernetes	Non pris en charge lors de l'utilisation de noeuds virtuels.
Contrôleur d'entrée Nginx	Déployez différemment lors de l'utilisation de noeuds virtuels (reportez-vous à Configuration de l'exemple de contrôleur d'entrée).
Outil de redimensionnement automatique de cluster Kubernetes	Non pris en charge lors de l'utilisation de noeuds virtuels.
Outil de redimensionnement automatique de pod vertical	Non pris en charge lors de l'utilisation de noeuds virtuels.
Serveur de mesures Kubernetes	Déploiement différent lors de l'utilisation de noeuds virtuels (reportez-vous à Déploiement du serveur de mesures Kubernetes sur un cluster).

Noeuds gérés et pools de noeuds gérés

Les noeuds gérés sont exécutés sur des instances de calcul (bare metal ou machine virtuelle) dans votre location. Pour créer des noeuds gérés, créez un pool de noeuds gérés. Vous gérez les noeuds gérés et les pools de noeuds gérés.

En tant que responsable de la gestion des noeuds gérés, vous avez la possibilité de les configurer pour répondre à vos besoins spécifiques. Vous êtes responsable de la mise à niveau de Kubernetes sur les noeuds gérés et de la gestion de la capacité du cluster.

Lorsque vous utilisez des noeuds gérés, vous payez pour les instances de calcul qui exécutent les applications.

Vous pouvez créer des noeuds gérés et des pools de noeuds dans des clusters de base et des clusters améliorés.

Pour plus d'informations, reportez-vous à Comparaison de noeuds gérés avec des noeuds virtuels.