Oracle Cloud Infrastructure - Dokumentation

Virtuelle Knoten mit verwalteten Knoten vergleichen

Erfahren Sie mehr über die Unterschiede zwischen den virtuellen und verwalteten Knoten, die Sie mit der Kubernetes Engine (OKE) erstellen können.

Beim Erstellen eines Knotenpools mit der Kubernetes-Engine geben Sie den Typ der im Knotenpool zu erstellenden Worker-Knoten wie folgt an:

Sie können nur virtuelle Knoten in erweiterten Clustern erstellen. Sie können verwaltete Knoten sowohl in Basisclustern als auch in erweiterten Clustern erstellen.

Alle Verweise auf "Knoten" und "Arbeitsknoten" in der Kubernetes Engine-Dokumentation beziehen sich sowohl auf virtuelle Knoten als auch auf verwaltete Knoten, sofern nicht ausdrücklich etwas anderes angegeben ist.

Virtuelle Knoten und virtuelle Knotenpools

Virtuelle Knoten werden im Kubernetes Engine-Mandanten ausgeführt. Sie erstellen virtuelle Knoten, indem Sie einen virtuellen Knotenpool erstellen. Virtuelle Knoten und Pools virtueller Knoten werden vollständig von Oracle verwaltet.

Virtuelle Knoten bieten eine "serverlose" Kubernetes-Erfahrung, mit der Sie containerisierte Anwendungen in großem Maßstab ausführen können, ohne den Betriebsaufwand für das Upgrade der Data-Plane-Infrastruktur und die Verwaltung der Clusterkapazität.

Sie können nur virtuelle Knoten und Knotenpools in erweiterten Clustern erstellen.

Wichtige Features, die von virtuellen Knoten unterschiedlich unterstützt werden

Einige Features werden bei der Verwendung virtueller Knoten und nicht verwalteter Knoten unterschiedlich unterstützt:

  • Ressourcenzuteilung: Die Ressourcenzuteilung erfolgt auf Pod-Ebene und nicht auf Mitarbeiterknotenebene. Daher geben Sie CPU- und Speicherressourcenanforderungen (als Anforderungen und Limits) in der Podspezifikation an, nicht für die Worker-Knoten in einem Knotenpool. Siehe Ressourcen, die von virtuellen Knoten bereitgestellten Pods zugewiesen sind.

  • Load Balancing: Das Load Balancing erfolgt zwischen Pods und nicht zwischen Worker-Knoten (wie bei verwalteten Knoten). In Clustern mit virtuellen Knoten ist die Verwaltung von Load-Balancer-Sicherheitslisten nie aktiviert, und Sie müssen Sicherheitsregeln immer manuell konfigurieren. Load Balancer verteilen Traffic auf die IP-Adressen der Pods und einen zugewiesenen Knotenport. Wenn Sie eine Verbindung zu Pods herstellen, die auf virtuellen Knoten ausgeführt werden, verwenden Sie die Syntax <pod-ip>:<nodeport> und nicht <node-ip>:<nodeport>. Wenn Sie verschiedene Subnetze für Pods und Knoten verwenden, konfigurieren Sie den Knotenport-Ingress im Podsubnetz.
  • Podnetzwerk: Nur VCN-natives Podnetzwerk wird unterstützt (das Flannel-CNI-Plug-in wird nicht unterstützt). Außerdem ist die Unterstützung bei der Verwendung virtueller Knoten etwas anders:
    • An jeden virtuellen Knoten ist nur eine VNIC angehängt.
    • IP-Adressen werden nicht vorab zugewiesen, bevor Pods erstellt werden.
    • Das CNI-Plug-in für VCN-natives Podnetworking wird nicht als im Namespace "kube-system" ausgeführt angezeigt.
    • Da nur VCN-natives Podnetzwerk unterstützt wird, müssen für die Routentabelle des Podsubnetzes Routingregeln für ein NAT-Gateway (kein Internetgateway) und ein Servicegateway definiert sein.
  • Autoscaling: Virtuelle Knoten werden automatisch skaliert, um 500 Pods zu unterstützen. Da Oracle die zugrunde liegenden Ressourcen für virtuelle Knoten verwaltet, ist es einfacher, mit Kubernetes Horizontal Pod Autoscaler zu arbeiten. Es ist nicht erforderlich, Kubernetes Cluster Autoscaler zu verwenden (das in jedem Fall noch nicht mit virtuellen Knoten unterstützt wird). Kubernetes Vertical Pod Autoscaler wird mit virtuellen Knoten nicht unterstützt.

Bemerkenswerte Kubernetes-Features und -Funktionen werden bei Verwendung virtueller Knoten nicht unterstützt

Einige Kubernetes-Features und -Funktionen werden bei der Verwendung virtueller Knoten anstelle verwalteter Knoten nicht unterstützt oder sind noch nicht verfügbar.

Kubernetes-Features werden nicht unterstützt Zusätzliche Informationen
Flannel und andere CNI-Plugins von Drittanbietern werden nicht unterstützt. Virtuelle Knoten unterstützen nur das CNI-Plug-in für das OCI-VCN-native Podnetworking.
Kubernetes-Daemonsets werden nicht unterstützt.

Beispiel: Folgendes wird nicht unterstützt:

apiVersion: apps/v1
kind: DaemonSet
Persistente Volume Claims (PVCs) werden nicht unterstützt. Keine zusätzlichen Informationen.
Netzwerkprovider, die NetworkPolicy-Ressourcen neben dem im Cluster verwendeten CNI-Plug-in unterstützen (wie Calico und Cilium), werden nicht unterstützt. Keine zusätzlichen Informationen.
Netzwerk-Policys (die Kubernetes-Ressource NetworkPolicy) werden nicht unterstützt. Keine zusätzlichen Informationen.
Service-Mesh-Produkte werden nicht unterstützt. Produkte wie Istio Service Mesh werden nicht unterstützt.

Liveness- und Readiness-Probes vom Typ HTTP werden unterstützt.

HTTPS- und Exec-Probes werden unterstützt.

Startup-Probes werden unterstützt.

gRPC-Probes werden nicht unterstützt.

probe.terminationGracePeriodSeconds wird nicht unterstützt.

 Beispiel: Folgendes wird unterstützt:
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
Folgendes wird jedoch nicht unterstützt:
livenessProbe:
  grpc:
     port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

Der Befehl kubectl logs wird unterstützt.

Der Befehl kubectl logs -p wird unterstützt.

Der Befehl kubectl logs -f wird nicht unterstützt.

 Beispiel: Folgendes wird unterstützt:
kubectl logs workload1-589578899f-lwzm9
kubectl logs workload1-589578899f-lwzm9 -p
Folgendes wird jedoch nicht unterstützt:
kubectl logs workload1-589578899f-lwzm9 -f
Flüchtige Container werden nicht unterstützt. Keine zusätzlichen Informationen.
Init-Container werden nicht unterstützt. Keine zusätzlichen Informationen.

Die folgenden Volume-Typen werden unterstützt:

  • emptyDir
  • ConfigMap
  • Secret

  • ProjectedVolume der folgenden Typen:

    • ServiceAccount
    • ConfigMap
    • Secret

Die folgenden Volume-Typen werden nicht unterstützt:

  • hostPath
  • persistentVolumeClaim
  • Lokal
  • nfs
  • Iscsi
  • Cephfs

Beispiel: Folgendes wird nicht unterstützt:

volumes:
- name: test-volume
  hostPath:
    path: /data
Maximal 1 Volume des Typs emptyDir kann derzeit in der Podspezifikation definiert werden. Keine zusätzlichen Informationen.

Die folgenden Podfelder werden nicht unterstützt:

  • hostIPC
  • hostNetwork
  • hostPid
  • hostName
  • podOS
  • Overhead
  • setHostNameAsFqdn
  • shareProcessNamespace
 Beispiel: Folgendes wird nicht unterstützt:
spec:
  hostIPC: true
  hostNetwork: true
  hostPID: false
  setHostnameAsFQDN : true
  shareProcessNamespace : true

Die folgenden Podsicherheitskontexte werden unterstützt:

  • runAsNonRoot
  • runAsUser
  • runAsGroup

Die folgenden Podsicherheitskontexte werden nicht unterstützt:

  • fsGroup
  • fsGroupChangePolicy
  • supplementalGroups
  • seLinuxOptions
  • sysctls
  • seccompProfile
 Beispiel: Folgendes wird nicht unterstützt:
spec:
  securityContext:
    seLinuxOptions:
      type: dummy_container.proces

Die folgenden Containersicherheitskontexte werden unterstützt:

  • readOnlyRootFilesystem
  • allowPrivilegeEscalation:false
  • Berechtigungen

Die folgenden Containersicherheitskontexte werden nicht unterstützt:

  • allowPrivilegeEscalation:true
  • privilegiert
  • procMount
 Beispiel: Folgendes wird unterstützt:
containers:
  - name: openssh-1
    securityContext:
      capabilities:
        add:
        - CAP_NET_ADMIN
Folgendes wird jedoch nicht unterstützt:
containers:
  - name: openssh-1
    securityContext:
      procMount: Unmasked

Container.Port

  • Host-IP
  • Hostport
 Beispiel: Folgendes wird nicht unterstützt:
ports:
  - name: test
    containerPort: 81
    hostPort: 80

Container

  • TerminationMessagePolicy
  • TerminationMessagePath
  • VolumeDevices
  • VolumeMount.MountPropagation
  • VolumeMount.Subpath-Ausdruck
 Beachten Sie, dass Kubernetes standardmäßig TerminationMessagePolicy und TerminationMessagePath hinzufügt.
Containerportbereich (1, 65535) darf nicht mit dem NodePort-Bereich (30000-32767) in Konflikt stehen. Beispiel: Folgendes wird nicht unterstützt:
containers:
  - name: my-nginx
    image: nginx
    ports:
    - containerPort: 30002
Pod.Volumes.EmptyDirVolumeQuelle:SizeLimit Beispiel: Folgendes wird nicht unterstützt:
emptyDir:
  sizeLimit: 500Mi
Pod.Volumes.EmptyDirVolumeSource:Medium - kann nur "" oder "Speicher" sein Beispiel: Folgendes wird nicht unterstützt:
emptyDir:
  medium: "Memory1"

Pod:Volumes - Der Modus muss für Folgendes als 0644 angegeben werden:

  • ConfigMapVolumeSource:KeyToPath:Modus
  • SecretVolumeSource:KeyToPath:Modus
  • ProjectedVolumeSource:SecretProjection:KeyToPath:Modus
  • ProjectedVolumeSource:ConfigMapProjection:KeyToPath:Modus
 Beispiel: Folgendes wird nicht unterstützt:
- name: myconfigmap
  configMap:
    name: kube-root-ca.crt
    items:
    - key: ca.crt
      path: abc
      mode: 0400

Pod:Volumes: Wenn DefaultMode wie folgt angegeben ist, muss DefaultMode 0644 sein:

  • ConfigMapVolumeSource:DefaultMode
  • ProjectedVolumeSource:DefaultMode
  • SecretVolumeSource:DefaultMode
 Beispiel: Folgendes wird nicht unterstützt:
- name: workload-volume
    configMap:
      name: myconfigmap
      defaultMode: 0400
Resources.Requests darf sich nicht von Resources.Limits unterscheiden Beispiel: Folgendes wird nicht unterstützt:
resources:
  requests:
    cpu: 50m
    memory: 200Mi
  limits:
    cpu: 100m
    memory: 400Mi
Volumen:DownwardAPI:ResourceFieldRef Beispiel: Folgendes wird nicht unterstützt:
resourceFieldRef:
  containerName: openssh
  resource: limits.cpu
TerminationGracePeriodSeconds Beispiel: Folgendes wird nicht unterstützt:
terminationGracePeriodSeconds: 30
DeletionGracePeriodSeconds Beispiel: Folgendes wird nicht unterstützt:
metadata:
  DeletionGracePeriodSeconds: 30
Container ausführen Beispiel: Folgendes wird nicht unterstützt:
kubectl exec workload1-589578899f-lwzm9 -- sh
Kubectl-Befehl "port-forward" Verwenden Sie stattdessen kubectl proxy (siehe Pod- und Serviceprobleme auf virtuellen Knoten mit kubectl-Proxy anstatt mit kubectl-Port-Forward beheben).
UpdatePod fordert Mutationen an pod.spec.containers[].image an. Keine zusätzlichen Informationen.
Propagierung an Pods von Updates an gemountete Configmaps und Secrets Keine zusätzlichen Informationen.

Die folgenden Metriken auf Containerebene im Endpunkt der virtuellen Kubelet-Metriken werden unterstützt:

  • container_cpu_usage_seconds_total
  • container_memory_working_set_bytes
Andere Metriken auf Containerebene im Endpunkt der virtuellen Kubelet-Metriken werden nicht unterstützt.		 Keine zusätzlichen Informationen.
Container: Untergeordnete Ressourcenanforderungen Keine zusätzlichen Informationen.
Container-stdin/stdinOnce, tty Keine zusätzlichen Informationen.
Beibehalten der Client-IP-Adressen bei externalTrafficPolicy: Lokal Keine zusätzlichen Informationen.
ImagePullSecret-Typen außer config und configJson Keine zusätzlichen Informationen.
ProjectedVolumeSource:ServiceAccountTokenProjektion:AblaufSekunden Keine zusätzlichen Informationen.
Der Befehl kubectl attach zur Interaktion mit einem Prozess, der bereits in einem vorhandenen Container ausgeführt wird. Keine zusätzlichen Informationen.

Bemerkenswerte Kubernetes Engine-(OKE-)Features und -Funktionen werden bei Verwendung virtueller Knoten nicht unterstützt

Einige Features und Funktionen der Kubernetes-Engine sind bei der Verwendung virtueller Knoten anstelle von verwalteten Knoten nicht verfügbar oder noch nicht verfügbar.

Kubernetes-Engine-Features werden nicht unterstützt Zusätzliche Informationen
SSH-Verbindungen zu Worker-Knoten (auch über eine Bastion) Nicht verfügbar.
Verwendung benutzerdefinierter Cloud-init-Skripte Nicht verfügbar.
Node Doctor-Skript Nicht verfügbar.
Unterstützung für Kubernetes-Versionen vor Version 1.25 Für virtuelle Knoten muss das Cluster mindestens Kubernetes-Version 1.25 ausführen.
Gemischte Cluster, die sowohl virtuelle als auch verwaltete Knoten enthalten. Noch nicht verfügbar.
Automatische Skalierung der Anzahl virtueller Knoten. Noch nicht verfügbar.
Kapazitätsreservierungen für das Provisioning virtueller Knoten. Noch nicht verfügbar.
Pods mit Intel- und GPU-Ausprägungen. Noch nicht verfügbar.

Gemeinsame Deployments werden bei Verwendung virtueller Knoten nicht unterstützt und unterschiedlich unterstützt

Die folgenden allgemeinen Deployments werden bei der Verwendung virtueller Knoten und nicht verwalteter Knoten nicht unterstützt oder werden anders unterstützt:

Deployment Hinweise
kube-proxy im kube-system-Namespace und das kube-proxy-cluster-Add-on kube-proxy wird in Pods ausgeführt, die auf virtuellen Knoten geplant sind, aber nicht im kube-system-Namespace bereitgestellt werden.
Kubernetes Dashboard Wird bei Verwendung virtueller Knoten nicht unterstützt.
Nginx-Ingress-Controller Deployment bei Verwendung virtueller Knoten unterschiedlich ausführen (siehe Beispiel für Ingress-Controller einrichten).
Autoscaler für Kubernetes-Cluster Wird bei Verwendung virtueller Knoten nicht unterstützt.
Vertical Pod Autoscaler Wird bei Verwendung virtueller Knoten nicht unterstützt.
Kubernetes Metrics Server Bei Verwendung virtueller Knoten anders bereitstellen (siehe Kubernetes-Metrikserver auf einem Cluster bereitstellen).

Verwaltete Knoten und verwaltete Knotenpools

Verwaltete Knoten werden auf Compute-Instanzen (entweder Bare Metal oder Virtual Machine) in Ihrem Mandanten ausgeführt. Sie erstellen verwaltete Knoten, indem Sie einen verwalteten Knotenpool erstellen. Verwaltete Knoten und verwaltete Knotenpools werden von Ihnen verwaltet.

Da Sie für die Verwaltung verwalteter Knoten verantwortlich sind, können Sie diese flexibel konfigurieren, um Ihre spezifischen Anforderungen zu erfüllen. Sie sind für das Upgrade von Kubernetes auf verwalteten Knoten und für das Verwalten der Clusterkapazität verantwortlich.

Wenn Sie verwaltete Knoten verwenden, zahlen Sie für die Compute-Instanzen, die Anwendungen ausführen.

Sie können verwaltete Knoten und Knotenpools sowohl in grundlegenden Clustern als auch in erweiterten Clustern erstellen.

Weitere Informationen finden Sie unter Verwaltete Knoten mit virtuellen Knoten vergleichen