Documentation sur Oracle Cloud Infrastructure

Comparaison des noeuds virtuels et des 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).

Lors de la création d'un groupe de noeuds avec le moteur Kubernetes, vous spécifiez le type de noeuds de travail à créer dans le groupe de noeuds comme l'un ou l'autre des suivants :

Vous ne pouvez créer des noeuds virtuels que dans des grappes améliorées. Vous pouvez créer des noeuds gérés dans des grappes de base et des grappes améliorées.

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

Noeuds virtuels et groupes de noeuds virtuels

Les noeuds virtuels s'exécutent dans la location du moteur Kubernetes. Vous créez des noeuds virtuels en créant un groupe de noeuds virtuels. Les noeuds virtuels et les groupes 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 conteneurisées à grande échelle sans les frais d'exploitation liés à la mise à niveau de l'infrastructure de plan de données et à la gestion de la capacité des grappes.

Vous ne pouvez créer des noeuds virtuels et des groupes de noeuds que dans des grappes améliorées.

Fonctions notables prises en charge différemment par les noeuds virtuels

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

  • Affectation de ressources : L'affectation de ressources se fait au niveau du pod, plutôt qu'au niveau du noeud de travail. Par conséquent, vous spécifiez les besoins en ressources d'UC et de mémoire (en tant que demandes et limites) dans la spécification du pod, plutôt que pour les noeuds de travail d'un groupe de noeuds. Voir Ressources affectées aux pods provisionnés par des noeuds virtuels.

  • Équilibrage de charge : L'équilibrage de charge est entre les pods, plutôt qu'entre les noeuds de travail (comme c'est le cas pour les noeuds gérés). Dans les grappes 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 des 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 aux pods exécutés sur des noeuds virtuels, utilisez la syntaxe <pod-ip>:<nodeport>, plutôt que <node-ip>:<nodeport>. Si vous utilisez des sous-réseaux différents pour les pods et les noeuds, configurez le trafic entrant de port de noeud sur le sous-réseau de pod.
  • Réseau de pods : Seul le réseau de pods natif du VCN est pris en charge (le plugiciel CNI flannel n'est pas pris en charge). De plus, le support est légèrement différent lors de l'utilisation de nœuds virtuels :
    • Une seule carte VNIC est attachée à chaque noeud virtuel.
    • Les adresses IP ne sont pas pré-allouées avant la création des pods.
    • Le plugiciel CNI de réseau de pods natif de VCN n'est pas affiché comme s'exécutant dans l'espace de noms kube-system.
    • Comme seul le service de réseau de pods natif de VCN est pris 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 une passerelle Internet) et une passerelle de service.
  • Ajustement automatique : Les noeuds virtuels sont ajustés automatiquement pour prendre en charge 500 pods. Comme Oracle gère les ressources sous-jacentes des noeuds virtuels, il est plus facile d'utiliser le HPA de Kubernetes. Il n'est pas nécessaire d'utiliser le composant d'ajustement automatique de grappe de Kubernetes (qui n'est pas encore pris en charge avec les noeuds virtuels en tout cas). Le VPA de Kubernetes n'est pas pris en charge avec les noeuds virtuels.

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

Certaines fonctions et capacité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 de Kubernetes non prises en charge Informations supplémentaires
Flannel et autres plugiciels CNI tiers ne sont pas pris en charge. Les noeuds virtuels prennent uniquement en charge le plugiciel CNI de réseau de pods natif du VCN OCI.
Les jeux 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 revendications de volume persistantes (PVC) ne sont pas prises en charge. Aucune information supplémentaire.
Les fournisseurs de réseau qui prennent en charge les ressources NetworkPolicy avec le plugiciel CNI utilisé dans la grappe (comme Calico et Cilium) ne sont pas pris en charge. Aucune information supplémentaire.
Les politiques de réseau (ressource Kubernetes NetworkPolicy) ne sont pas prises en charge. Aucune information supplémentaire.
Les produits de maillage de services ne sont pas pris en charge. Les produits tels que le maillage de services Istio ne sont pas pris en charge.

Les sondes de disponibilité et de disponibilité de type HTTP sont prises 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
Cependant, ce qui suit n'est 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
Cependant, ce qui suit n'est pas pris en charge :
kubectl logs workload1-589578899f-lwzm9 -f
Les contenants é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
  • local
  • nfs
  • iscsi
  • Cephes

Par exemple, ce qui suit n'est pas pris en charge :

volumes:
- name: test-volume
  hostPath:
    path: /data
Un maximum de 1 volume de type emptyDir peut actuellement être défini dans la spécification de pod. Aucune information supplémentaire.

Les champs de pod suivants ne sont pas pris en charge :

  • hostIPC
  • hostNetwork
  • hostPid
  • hostName
  • podOS
  • Frais généraux généraux
  • 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
  • sysctres
  • 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 : Faux
  • capacités

Les contextes de sécurité de conteneur suivants ne sont pas pris en charge :

  • allowPrivilegeEscalation : Vrai
  • privilégiés
  • procMount
 Par exemple :
containers:
  - name: openssh-1
    securityContext:
      capabilities:
        add:
        - CAP_NET_ADMIN
Cependant, ce qui suit n'est pas pris en charge :
containers:
  - name: openssh-1
    securityContext:
      procMount: Unmasked

Container.Port

  • Adresse IP de l'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
 Notez que Kubernetes ajoute TerminationMessagePolicy et TerminationMessagePath par défaut.
L'intervalle de ports de conteneur (1, 65535) ne peut pas entrer en conflit avec l'intervalle 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 : Limite de taille Par exemple, ce qui suit n'est pas pris en charge :
emptyDir:
  sizeLimit: 500Mi
Pod.Volumes.EmptyDirVolumeSource:Medium - peut seulement être "" ou "Mémoire" Par exemple, ce qui suit n'est pas pris en charge :
emptyDir:
  medium: "Memory1"

Pod:Volumes - Le mode doit être spécifié comme 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 ce qui suit, DefaultMode doit être 0644 :

  • ConfigMapVolumeSource : Mode par défaut
  • ProjectedVolumeSource : Mode par défaut
  • SecretVolumeSource : Mode par défaut
 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
Exécuter le conteneur Par exemple, ce qui suit n'est pas pris en charge :
kubectl exec workload1-589578899f-lwzm9 -- sh
Commande port-forward de Kubectl Utilisez plutôt kubectl proxy (voir Dépannage des problèmes de pod et de service sur les noeuds virtuels à l'aide d'un mandataire kubectl plutôt que de kubectl port-forward).
Demandes UpdatePod avec mutations dans pod.spec.containers[].image Aucune information supplémentaire.
Propagation aux pods de mises à jour des configmaps et des secrets montés Aucune information supplémentaire.

Les mesures de niveau conteneur suivantes du point d'extrémité des mesures de kubelet virtuel sont prises en charge :

  • container_cpu_usage_seconds_total
  • container_memory_working_set_bytes
Les autres mesures au niveau du conteneur dans le point d'extrémité des mesures de kubelet virtuel ne sont pas prises en charge.		 Aucune information supplémentaire.
Conteneur : Sous-cœur Ressources requises Aucune information supplémentaire.
Conteneur stdin/stdinOnce, tty Aucune information supplémentaire.
Conserver les adresses IP du client lorsque externalTrafficPolicy : Local Aucune information supplémentaire.
Types ImagePullSecret autres que config et configJson Aucune information supplémentaire.
ProjectedVolumeSource : ServiceAccountTokenProjection : Secondes d'expiration Aucune information supplémentaire.
Commande kubectl attach pour interagir avec un processus qui est déjà en cours d'exécution dans un conteneur existant. Aucune information supplémentaire.

Fonctions et capacités notables de Kubernetes Engine (OKE) non prises en charge lors de l'utilisation de noeuds virtuels

Certaines fonctions et capacités de Kubernetes Engine ne sont pas disponibles, ou pas encore, lors de l'utilisation de noeuds virtuels plutôt que de noeuds gérés.

Fonctionnalités de Kubernetes Engine non prises en charge Informations supplémentaires
Connexions SSH aux noeuds de travail (y compris au moyen d'un hôte 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 la grappe exécute au moins Kubernetes version 1.25.
Grappes mixtes, contenant à la fois des noeuds virtuels et des noeuds gérés. Pas encore disponible.
Ajuster automatiquement le nombre de noeuds virtuels. Pas encore disponible.
Réservations de capacité pour provisionner des noeuds virtuels. Pas encore disponible.
Pods avec des formes Intel et GPU. Pas encore disponible.

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

Les déploiements communs 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 Notes
kube-proxy dans l'espace de noms kube-system, et le module complémentaire 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 de trafic entrant Nginx Déployer différemment lors de l'utilisation de noeuds virtuels (voir Configuration de l'exemple de contrôleur de trafic entrant).
Ajustement automatique de grappe Kubernetes Non pris en charge lors de l'utilisation de noeuds virtuels.
VPA Non pris en charge lors de l'utilisation de noeuds virtuels.
Serveur de mesures Kubernetes Déployer différemment lors de l'utilisation de noeuds virtuels (voir Déploiement du serveur de mesures Kubernetes sur une grappe).

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

Les noeuds gérés s'exécutent sur des instances de calcul (sans système d'exploitation ou sur machine virtuelle) de votre location. Vous créez des noeuds gérés en créant un groupe de noeuds gérés. Les noeuds gérés et les groupes de noeuds gérés sont gérés par vous.

Comme vous êtes 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é de la grappe.

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

Vous pouvez créer des noeuds gérés et des groupes de noeuds dans des grappes de base et des grappes améliorées.

Pour plus d'informations, voir Comparaison des noeuds gérés avec des noeuds virtuels