Ein Artikel zum Verständnis der erweiterten Funktionen von K8S

Erweiterte Funktionen des K8S

Es gibt einige erweiterte Funktionen in K8S, die es wert sind, verstanden zu werden, wie z. B. die elastische Skalierung von Anwendungen (siehe oben), fortlaufende Updates (siehe oben), Konfigurationsverwaltung, Speichervolumes, Gateway-Routing usw.

Bevor wir diese erweiterten Funktionen verstehen, müssen wir uns einige Kernkonzepte von K8S ansehen:

ReplikatSet

Ein Replikatset stellt sicher, dass jederzeit eine bestimmte Anzahl von Pod-Replikaten ausgeführt wird. Wird normalerweise verwendet, um die Verfügbarkeit einer bestimmten Anzahl identischer Pods sicherzustellen. Es wird empfohlen, Deployment zum Verwalten von ReplicaSet zu verwenden, anstatt es direkt zu verwenden.

Konfigurationskarte

ConfigMap ist ein API-Objekt, das zum Speichern nicht vertraulicher Daten in Schlüssel-Wert-Paaren verwendet wird. Bei Verwendung können Pods sie als Umgebungsvariablen, Befehlszeilenparameter oder Konfigurationsdateien in Speichervolumes verwenden. Verwenden Sie ConfigMap, um Ihre Konfigurationsdaten von Ihrem Anwendungscode zu trennen.

Volumen

Mit „Volume“ wird das Speichervolumen bezeichnet, das das für die Container im Pod zugängliche Datenverzeichnis enthält. Die Dateien im Container werden vorübergehend auf der Festplatte gespeichert. Wenn der Container abstürzt, gehen die Dateien verloren. Gleichzeitig können die Dateien nicht zwischen mehreren Pods geteilt werden. Diese beiden Probleme können durch die Verwendung von Speichervolumes gelöst werden.
Häufig verwendete Speichervolumes sind die folgenden:

• configMap: Das configMap-Volume bietet eine Möglichkeit, Konfigurationsdaten in den Pod einzufügen. Auf die im ConfigMap-Objekt gespeicherten Daten kann durch ein Volume vom Typ „configMap“ verwiesen werden, und sie können dann von der im Pod ausgeführten Containeranwendung verwendet werden.
• emptyDir: Das emptyDir-Volume kann zum Speichern von Cache-Daten verwendet werden. Wenn ein Pod an einen Knoten gesendet wird, wird ein emptyDir-Volume erstellt und das Volume existiert, während der Pod auf dem Knoten ausgeführt wird. Wenn der Pod aus dem Knoten gelöscht wird, werden auch die Daten im emptyDir-Volume dauerhaft gelöscht.
• hostPath: Ein hostPath-Volume kann Dateien oder Verzeichnisse im Dateisystem des Hostknotens in Ihren Pod mounten. Der Host in Minikube bezieht sich auf die virtuelle Maschine, auf der sich Minikube befindet.
• lokal: Ein lokales Volume stellt ein gemountetes lokales Gerät dar, beispielsweise eine Festplatte, Partition oder ein Verzeichnis. Lokale Volumes können nur als statisch erstellte persistente Volumes verwendet werden und unterstützen noch keine dynamische Konfiguration.
• nfs: nfs-Volumes können NFS (Network File System) in Ihren Pod mounten.
• persistentVolumeClaim: Das persistentVolumeClaim-Volume wird verwendet, um ein persistentes Volume (PersistentVolume) in einem Pod bereitzustellen. Ein persistentes Volume (PV) ist ein Speicherelement in einem Cluster, das von einem Administrator im Voraus bereitgestellt oder mithilfe einer Speicherklasse dynamisch bereitgestellt werden kann. Ein persistentes Volume ist eine Clusterressource, die einem Knoten ähnelt.
  

Schutz

Ingress kann über die Ingress-Ressourcen von K8S einen domänennamenbasierten Zugriff ähnlich wie Nginx implementieren und so einen lastausgeglichenen Zugriff auf Pods erreichen.

Ingress installieren

Gehen Sie zur Seite https://github.com/kubernetes/ingress-nginx/blob/nginx-0.20.0/deploy/mandatory.yaml, kopieren Sie den Inhalt und speichern Sie ihn in einer Datei ingress-controller.yaml auf dem k8s-Mastercomputer. Die darin enthaltene Bildadresse muss geändert werden. Sie können den folgenden YAML-Inhalt direkt verwenden:

Download-Adresse (keine Punkte erforderlich): Download-Adresse

API-Version: v1
Art: Namespace
Metadaten:
  Name: ingress-nginx
  Beschriftungen:
    app.kubernetes.io/Name: ingress-nginx
    app.kubernetes.io/Teil von: ingress-nginx

---

Art: ConfigMap
API-Version: v1
Metadaten:
  Name: nginx-Konfiguration
  Namespace: ingress-nginx
  Beschriftungen:
    app.kubernetes.io/Name: ingress-nginx
    app.kubernetes.io/Teil von: ingress-nginx

---

Art: ConfigMap
API-Version: v1
Metadaten:
  Name: TCP-Dienste
  Namespace: ingress-nginx
  Beschriftungen:
    app.kubernetes.io/Name: ingress-nginx
    app.kubernetes.io/Teil von: ingress-nginx

---

Art: ConfigMap
API-Version: v1
Metadaten:
  Name: UDP-Dienste
  Namespace: ingress-nginx
  Beschriftungen:
    app.kubernetes.io/Name: ingress-nginx
    app.kubernetes.io/Teil von: ingress-nginx

---

API-Version: v1
Art: ServiceAccount
Metadaten:
  Name: nginx-ingress-serviceaccount
  Namespace: ingress-nginx
  Beschriftungen:
    app.kubernetes.io/Name: ingress-nginx
    app.kubernetes.io/Teil von: ingress-nginx

---

API-Version: rbac.authorization.k8s.io/v1beta1
Art: ClusterRole
Metadaten:
  Name: nginx-ingress-clusterrole
  Beschriftungen:
    app.kubernetes.io/Name: ingress-nginx
    app.kubernetes.io/Teil von: ingress-nginx
Regeln:
  -API-Gruppen:
      - ""
    Ressourcen:
      - Konfigurationskarten
      - Endpunkte
      - Knoten
      - Schoten
      - Geheimnisse
    Verben:
      - Liste
      - betrachten
  -API-Gruppen:
      - ""
    Ressourcen:
      - Knoten
    Verben:
      - erhalten
  -API-Gruppen:
      - ""
    Ressourcen:
      - Dienstleistungen
    Verben:
      - erhalten
      - Liste
      - betrachten
  -API-Gruppen:
      - "Erweiterungen"
    Ressourcen:
      - Eingänge
    Verben:
      - erhalten
      - Liste
      - betrachten
  -API-Gruppen:
      - ""
    Ressourcen:
      - Veranstaltungen
    Verben:
      - erstellen
      -Patch
  -API-Gruppen:
      - "Erweiterungen"
    Ressourcen:
      - Eingänge/Status
    Verben:
      - aktualisieren

---

API-Version: rbac.authorization.k8s.io/v1beta1
Art: Rolle
Metadaten:
  Name: nginx-ingress-Rolle
  Namespace: ingress-nginx
  Beschriftungen:
    app.kubernetes.io/Name: ingress-nginx
    app.kubernetes.io/Teil von: ingress-nginx
Regeln:
  -API-Gruppen:
      - ""
    Ressourcen:
      - Konfigurationskarten
      - Schoten
      - Geheimnisse
      - Namensräume
    Verben:
      - erhalten
  -API-Gruppen:
      - ""
    Ressourcen:
      - Konfigurationskarten
    Ressourcennamen:
      # Der Standardwert ist „<Wahl-ID>-<Eingangsklasse>“
      # Hier: „<ingress-controller-leader>-<nginx>“
      # Dies muss angepasst werden, wenn Sie einen der Parameter ändern
      # beim Starten des Nginx-Ingress-Controllers.
      - "Ingress-Controller-Leader-Nginx"
    Verben:
      - erhalten
      - aktualisieren
  -API-Gruppen:
      - ""
    Ressourcen:
      - Konfigurationskarten
    Verben:
      - erstellen
  -API-Gruppen:
      - ""
    Ressourcen:
      - Endpunkte
    Verben:
      - erhalten

---

API-Version: rbac.authorization.k8s.io/v1beta1
Art: RoleBinding
Metadaten:
  Name: nginx-ingress-role-nisa-binding
  Namespace: ingress-nginx
  Beschriftungen:
    app.kubernetes.io/Name: ingress-nginx
    app.kubernetes.io/Teil von: ingress-nginx
Rollenreferenz:
  API-Gruppe: rbac.authorization.k8s.io
  Art: Rolle
  Name: nginx-ingress-Rolle
Themen:
  - Art: ServiceAccount
    Name: nginx-ingress-serviceaccount
    Namespace: ingress-nginx

---

API-Version: rbac.authorization.k8s.io/v1beta1
Art: ClusterRoleBinding
Metadaten:
  Name: nginx-ingress-clusterrole-nisa-binding
  Beschriftungen:
    app.kubernetes.io/Name: ingress-nginx
    app.kubernetes.io/Teil von: ingress-nginx
Rollenreferenz:
  API-Gruppe: rbac.authorization.k8s.io
  Art: ClusterRole
  Name: nginx-ingress-clusterrole
Themen:
  - Art: ServiceAccount
    Name: nginx-ingress-serviceaccount
    Namespace: ingress-nginx

---

API-Version: Apps/v1
Art: DaemonSet
Metadaten:
  Name: nginx-ingress-controller
  Namespace: ingress-nginx
  Beschriftungen:
    app.kubernetes.io/Name: ingress-nginx
    app.kubernetes.io/Teil von: ingress-nginx
Spezifikation:
  Wähler:
    Übereinstimmungsetiketten:
      app.kubernetes.io/Name: ingress-nginx
      app.kubernetes.io/Teil von: ingress-nginx
  Vorlage:
    Metadaten:
      Beschriftungen:
        app.kubernetes.io/Name: ingress-nginx
        app.kubernetes.io/Teil von: ingress-nginx
      Anmerkungen:
        prometheus.io/port: "10254"
        prometheus.io/scrape: "wahr"
    Spezifikation:
      hostNetwork: wahr
      Dienstkontoname: nginx-ingress-serviceaccount
      Behälter:
        - Name: nginx-ingress-controller
          Bild: siriuszg/nginx-ingress-controller:0.20.0
          Argumente:
            - /nginx-ingress-controller
            – –configmap=$(POD_NAMESPACE)/nginx-Konfiguration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            – –publish-service=$(POD_NAMESPACE)/ingress-nginx
            - --annotations-prefix=nginx.ingress.kubernetes.io
          Sicherheitskontext:
            allowPrivilegeEscalation: true
            Fähigkeiten:
              fallen:
                - ALLE
              hinzufügen:
                -NET_BIND_SERVICE
            # www-Daten -> 33
            Als Benutzer ausführen: 33
          Umgebung:
            - Name: POD_NAME
              Wert von:
                FeldRef:
                  Feldpfad: Metadatenname
            - Name: POD_NAMESPACE
              Wert von:
                FeldRef:
                  Feldpfad: metadata.namespace
          Häfen:
            - Name: http
              ContainerPort: 80
            - Name: https
              ContainerPort: 443
          LivenessProbe:
            Fehlerschwelle: 3
            httpGet:
              Pfad: /healthz
              Port: 10254
              Schema: HTTP
            AnfangsverzögerungSekunden: 10
            PeriodeSekunden: 10
            Erfolgsschwelle: 1
            TimeoutSekunden: 1
          Bereitschaftsprobe:
            Fehlerschwelle: 3
            httpGet:
              Pfad: /healthz
              Port: 10254
              Schema: HTTP
            PeriodeSekunden: 10
            Erfolgsschwelle: 1
            TimeoutSekunden: 1

---

API-Version: v1
Art: Dienstleistung
Metadaten:
  Name: ingress-nginx
  Namespace: ingress-nginx
Spezifikation:
  Häfen:
    - Name: http
      Anschluss: 80
      ZielPort: 80
      Protokoll: TCP
    - Name: https
      Port: 443
      ZielPort: 443
      Protokoll: TCP
  Wähler:
    app.kubernetes.io/name: Standard-http-backend
    app.kubernetes.io/Teil von: ingress-nginx

---

Überprüfen Sie, ob die Installation erfolgreich war

kubectl get pods -n ingress-nginx -o wide

Konfigurieren Sie Ingress-Zugriffsregeln (ähnlich wie bei der Konfiguration der Nginx-Proxy-Weiterleitungskonfiguration), damit Ingress den Domänennamen tomcat.core.com an den Backend-Dienst tomcat-service-yaml weiterleitet. Erstellen Sie eine neue Datei ingress-tomcat.yaml mit folgendem Inhalt:

API-Version: networking.k8s.io/v1beta1
Art: Ingress
Metadaten:
 Name: Web-Ingress
Spezifikation:
 Regeln:
 - Host: tomcat.core.com # Weiterleitungsdomänenname http:
    Pfade:
    - Weg: /
      Backend: 
       Dienstname: Tomcat-Dienst-YAML
       servicePort: 80 # Service-Port 

Sehen Sie sich die geltenden Ingress-Regeln an:

kubectl wird geladen

Konfigurieren Sie den Host auf der Zugriffsmaschine, Hauptverzeichnis: /etc/hosts, fügen Sie dem Host den folgenden Host hinzu (die von Ingress bereitgestellte Maschinen-IP entspricht dem Domänennamen, auf den zugegriffen werden soll).

192.168.159.131 tomcat.core.com
oder 192.168.159.132 tomcat.core.com

Besuchen Sie nach der Konfiguration http://tomcat.core.com/ direkt im Client-Browser, um normal auf Tomcat zuzugreifen.

Erweiterte Funktionen

Konfigurationsmanagement

Mit ConfigMap können Sie Konfigurationsdateien von Image-Dateien trennen, um containerisierte Anwendungen portierbar zu machen. Als Nächstes zeigen wir, wie die Eigenschaften von ConfigMap in die Umgebungsvariablen von Pod eingefügt werden.

Fügen Sie die Konfigurationsdatei nginx-config.yaml hinzu, um eine ConfigMap zu erstellen. Der Name der ConfigMap lautet nginx-config und die Speicherinformationen werden unter dem Datenknoten abgelegt:

API-Version: v1
Art: ConfigMap
Metadaten: 
 Name: nginx-config
 Namespace: Standard
Daten:
 nginx-env:test

Wenden Sie die Datei nginx-config.yaml an, um eine ConfigMap zu erstellen:

kubectl create -f nginx-config.yaml

Alle ConfigMaps abrufen:

kubectl get configmap

Sehen Sie sich den Inhalt von ConfigMap im YAML-Format an:

kubectl get configmaps nginx-config -o yaml

Fügen Sie die Konfigurationsdatei nginx-deployment.yaml hinzu, um ein Deployment zu erstellen, einen Nginx-Dienst bereitzustellen und in den Nginx-Umgebungsvariablen auf die Eigenschaften in der ConfigMap zu verweisen:

API-Version: Apps/v1
Art: Bereitstellung
Metadaten: 
 Name: nginx-Bereitstellung
 Beschriftungen:
  App: nginx
Spezifikation:
 Replikate: 1
 Wähler:
  Übereinstimmungsetiketten:
   App: nginx
 Vorlage:
  Metadaten:
   Beschriftungen:
    App: nginx
  Spezifikation:
   Behälter:
    - Bezeichnung: nginx
      Bild: nginx:1.10
      Häfen:
       - ContainerPort: 80
      Umgebung:
       - Name: NGINX_ENV # Umgebungsvariablen in Nginx festlegen valueFrom:
          configMapKeyRef:
           Name: nginx-config # Setzt den Namen der ConfigMap Schlüssel: nginx-env # Der zu verwendende Schlüssel

Wenden Sie die Konfigurationsdatei an, um eine Bereitstellung zu erstellen:

kubectl apply -f nginx-deployment.yaml

Überprüfen Sie nach erfolgreicher Erstellung die Umgebungsvariablen im Pod und stellen Sie fest, dass die Variable NGINX_ENV eingefügt wurde.

kubectl get pod -o breit

kubectl exec -it nginx-deployment-5ff74658b6-rlft8 --sh
# Rufen Sie die Containerkonsole auf und führen Sie den folgenden Befehl aus: ECHO $NGINX_ENV

Speichervolumennutzung

Über Speichervolumes können wir externe Daten in Container einbinden, damit Anwendungen im Container darauf zugreifen können, sodass die Daten auch dann noch vorhanden sein können, wenn der Container abstürzt.

Denken Sie daran, dass wir, als wir zuvor Docker zum Bereitstellen von Nginx verwendet haben, die HTML-, Protokoll- und Konfigurationsverzeichnisse von Nginx von außen in den Container gemountet haben.

docker run -p 80:80 --name nginx \
-v /meineDaten/nginx/html:/usr/share/nginx/html \
-v /meineDaten/nginx/logs:/var/log/nginx \
-v /meineDaten/nginx/conf:/etc/nginx \
-d nginx:1.10

Minikube kann als virtuelle Maschine betrachtet werden. Wir können darauf mit dem SSH-Befehl von Minikube zugreifen

Minikube SSH

In Minikube gibt es standardmäßig einen Docker-Benutzer. Lassen Sie uns zuerst sein Passwort zurücksetzen.

sudo passwd docker

Erstellen Sie das Verzeichnis mydata in Minikube

mkdir /home/docker/meinedaten

Wir müssen das nginx-Verzeichnis nach Minikube kopieren, um das Verzeichnis zu mounten. Beachten Sie, dass der Docker-Benutzer nur Dateien im Verzeichnis /home/docker ändern kann. Wir kopieren die Dateien mit dem scp-Befehl.

scp -r /home/macro/meinedaten/nginx [email protected]:/home/docker/meinedaten/nginx

Fügen Sie die Konfigurationsdatei nginx-volume-deployment.yaml hinzu, um ein Deployment zu erstellen:

API-Version: Apps/v1
Art: Bereitstellung
Metadaten: 
 Name: nginx-volume-bereitstellung
 Beschriftungen:
  App: nginx
Spezifikation:
 Replikate: 1
 Wähler:
  Übereinstimmungsetiketten:
   App: nginx
 Vorlage:
  Metadaten:
   Beschriftungen:
    App: nginx
  Spezifikation:
   Behälter:
    - Bezeichnung: nginx
      Bild: nginx:1.10
      Häfen:
       - ContainerPort: 80
      Volumenhalterungen:
       – MountPfad: /usr/share/nginx/html
         Name: HTML-Volumen
       -mountPath: /var/logs/nginx
         Name: Protokoll-Volume
       – MountPfad: /etc/nginx
         Name: Conf-Volume
   Bände:
    - Name: HTML-Volumen
      Hostpfad:
       Pfad: /home/docker/mydata/nginx/html
       Typ: Verzeichnis
    - Name: Protokoll-Volume
      Hostpfad:
       Pfad: /home/docker/mydata/nginx/logs
       Typ: Verzeichnis
    - Name: Conf-Volume
      Hostpfad:
       Pfad: /home/docker/mydata/nginx/conf
       Typ: Verzeichnis

Wenden Sie die Konfigurationsdatei an, um eine Bereitstellung zu erstellen

kubectl apply -f nginx-volume-deployment.yaml

Fügen Sie die Konfigurationsdatei nginx-service.yaml hinzu, um den Dienst zu erstellen

API-Version: v1
Art: Dienstleistung
Metadaten: 
 Name: nginx-Dienst
Spezifikation:
 Typ: NodePort
 Wähler:
  App: nginx
 Häfen:
 - Name: http
    Protokoll: TCP
    Anschluss: 80
    ZielPort: 80
    KnotenPort: 30080

Überprüfen Sie den Service-Zugriffsport

kubectl get-Dienste

Greifen Sie über den CURL-Befehl auf die Informationen zur Nginx-Homepage zu.

Zusammenfassen

Der Service ist der Kern des K8S-Dienstes. Er schützt die Servicedetails und stellt die Serviceschnittstellen einheitlich nach außen dar, wodurch wirklich „Mikrodienste“ erreicht werden . Beispielsweise sind in einem unserer Dienste A drei Backups bereitgestellt, also drei Pods. Benutzer müssen nur auf den Eingang eines Dienstes achten und müssen sich keine Gedanken darüber machen, welchen Pod sie anfordern sollen. Die Vorteile liegen auf der Hand: Einerseits müssen externe Benutzer nicht über die IP-Änderungen informiert werden, die durch den unerwarteten Absturz des Dienstes auf dem Pod und das erneute Abrufen des Pods durch K8S verursacht werden. Externe Benutzer müssen auch nicht über die IP-Änderungen informiert werden, die durch den Pod-Austausch aufgrund des Upgrades oder der Änderung des Dienstes verursacht werden. Andererseits kann der Dienst auch einen Verkehrslastausgleich durchführen.

Der Service ist jedoch hauptsächlich für die Netzwerktopologie innerhalb des K8S-Clusters verantwortlich. Wie kann also von außerhalb des Clusters auf das Innere des Clusters zugegriffen werden? Zu diesem Zeitpunkt wird Ingress benötigt. Die Erklärung im offiziellen Dokument lautet:

Ingress ist ein API-Objekt, das den externen Zugriff auf Dienste in einem Cluster verwaltet. Die typische Zugriffsmethode ist HTTP.

ngress kann Lastausgleich, SSL-Terminierung und namensbasiertes virtuelles Hosting bereitstellen.

Übersetzung: Ingress ist die Zugriffsschicht des gesamten K8S-Clusters, der komplexen internen und externen Cluster-Kommunikation.

Das Netzwerktopologiediagramm von Ingress und Service sieht wie folgt aus:

kubectl - Fehlerbehebung bei Serviceproblemen

Wie behebt man einen Fehler bei der Dienstbereitstellung auf K8S?

Verwenden Sie diesen Befehl:

kubectl beschreiben ${RESOURCE} ${NAME}

Scrollen Sie bis zum Ende und sehen Sie sich den Abschnitt „Ereignisse“ an, in dem die wichtigsten Protokolle von K8S beim Bereitstellen dieses Dienstes angezeigt werden.

Im Allgemeinen können die meisten Bereitstellungsfehler über kubectl describe pod ${POD_NAME} lokalisiert werden. Bestimmte Probleme erfordern natürlich immer noch eine spezifische Analyse.

Wie behebe ich Probleme mit abnormalen Diensten, die auf K8S bereitgestellt werden?

Wenn der Dienst erfolgreich bereitgestellt wurde und der Status „Läuft“ lautet, müssen Sie den Container im Pod aufrufen, um Ihre Dienstprotokolle anzuzeigen:

Zeigen Sie die von einem Container im Pod gedruckten Protokolle an:

kubectl-Protokoll ${POD_NAME} –c ${CONTAINER_NAME}.

Geben Sie einen Container in den Pod ein:

kubectl exec ‐it [Optionen] ${POD_NAME} ‐c ${CONTAINER_NAME} [Argumente]

Der Zweck dieses Befehls besteht darin, Docker Exec XXX über Kubectl auszuführen, um die Containerinstanz aufzurufen. Anschließend überprüfen Benutzer die Protokolle ihrer eigenen Dienste, um das Problem zu lokalisieren.

Hat K8S Docker wirklich aufgegeben?

Docker ist eine sehr beliebte Containertechnologie. In vielen Artikeln hieß es, dass sie von K8S aufgegeben und durch eine andere Containertechnologie ersetzt wurde: containerd! Tatsächlich ist containerd nur die zugrunde liegende Container-Laufzeit, die von Docker getrennt ist. In der Verwendung unterscheidet es sich nicht von Docker. Der Übergang von Docker zu containerd ist sehr einfach und es gibt im Grunde keine Schwelle. Ändern Sie einfach den Docker im vorherigen Docker-Befehl in crictl und es ist im Grunde erledigt. Sie werden beide von derselben Firma hergestellt und haben dieselbe Verwendung. Unabhängig davon, ob K8S Docker aufgibt oder nicht, hat dies grundsätzlich keine Auswirkungen auf unsere Entwickler!

K8S CRI

K8S hat CRI (Container Runtime Interface) veröffentlicht, das die Container-Laufzeitschnittstelle vereinheitlicht. Jede Container-Laufzeit, die CRI unterstützt, kann als zugrunde liegende Container-Laufzeit von K8S verwendet werden.

Warum verzichtet K8S auf Docker als Container-Laufzeitumgebung und verwendet containerd?

Wenn Sie Docker als K8S-Containerlaufzeit verwenden, muss Kubelet zuerst Docker über Dockershim und dann Containerd über Docker aufrufen.

Wenn Sie containerd als K8S-Containerlaufzeit verwenden, kann kubelet containerd direkt aufrufen, da containerd über ein integriertes CRI-Plug-In verfügt.
Durch die Verwendung von containerd wird nicht nur die Leistung verbessert (die Aufrufkette wird kürzer), sondern auch der Ressourcenverbrauch reduziert (Docker ist keine reine Container-Laufzeitumgebung und verfügt über zahlreiche weitere Funktionen).

Natürlich kann Docker in Zukunft die K8S CRI-Schnittstelle direkt implementieren, um mit der zugrunde liegenden Verwendung von K8S kompatibel zu sein.

Dies ist das Ende dieses Artikels über die erweiterten Funktionen von K8S. Weitere relevante Inhalte zu den erweiterten Funktionen von K8S finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!