Hinweis perev. : Wir haben mehr als einmal über Containerd und andere Laufzeiten für Kubernetes geschrieben. Die neue Veröffentlichung ist eine Übersetzung der jüngsten Ankündigung eines wichtigen Meilensteins in der Entwicklung von Containerd, die im offiziellen Blog des Kubernetes-Projekts veröffentlicht wurde. Der Text wurde von Mitarbeitern von Google und IBM verfasst, die (natürlich zusammen mit Docker Inc) erheblich zur Verbesserung von Containerd beitragen.Zu Beginn des Blogs haben wir in der Notiz "
Containerd bringt mehr Container-Laufzeitoptionen für Kubernetes" eine Alpha-Version der Integration von Containerd in Kubernetes vorgestellt. Die nächsten 6 Monate der Entwicklung führten dazu, dass die Integration öffentlich verfügbar wurde! Dies bedeutet, dass Sie jetzt
Containerd 1.1 als Laufzeit für Container in Kubernetes-Clustern in der Produktion verwenden können.
Containerd 1.1 funktioniert mit Kubernetes Version 1.10 und höher und unterstützt alle Kubernetes-Funktionen. In der Kubernetes-Testinfrastruktur entspricht die Abdeckung von Containerd-Integrationstests auf der Google Cloud Platform der Integration mit Docker (siehe
Test-Dashboard ).
„Wir freuen uns, dass Containerd diesen wichtigen Meilenstein schnell erreicht. Bei Alibaba Cloud haben wir von Anfang an begonnen, Containerd aktiv einzusetzen, und dank seiner Betonung auf Einfachheit und Zuverlässigkeit wurde Containerd zur Standard-Container-Engine in seinem Produkt Serverless Kubernetes, das hohe Anforderungen an Leistung und Stabilität stellt. Containerd wird zweifellos der Hauptmotor der Container-Ära sein und zur Entwicklung von Innovationen führen. “ - Xinwei, ein Vollzeitingenieur von Alibaba Cloud
Architektonische Verbesserungen
Die Architektur für die Integration von Containerd in Kubernetes wurde zweimal geändert. Jeder seiner Evolutionsschritte stabilisierte und verbesserte die Effizienz des Stapels.
Containerd 1.0 - CRI-Containerd (nicht mehr vorhanden)
In Containerd 1.0 wurde der Cri-Containerd-Daemon für die Interaktion zwischen
Kubelet und Containerd benötigt
(wir haben darüber am Ende dieses Artikels geschrieben - ca. Transl. ) . Dieser Daemon hat Anforderungen an das
Container Runtime Interface (CRI) von
Kubelet bereitgestellt und Containerd verwendet, um Container und Container-Images ordnungsgemäß zu verwalten. Dieser Ansatz eliminierte eine zusätzliche Verknüpfung im Stapel im Vergleich zur Docker CRI-Implementierung (
Dockershim ) -
siehe Abbildung oben .
Cri-Containerd und Containerd 1.0 waren jedoch zwei separate Dämonen, die über GRPC interagierten. Ein zusätzlicher Daemon in diesem Bundle erschwerte den Benutzern das Verständnis des Geräts und der Bereitstellung und verursachte unnötigen Overhead für die Interaktion.
Containerd 1.1 - CRI Plugin (aktuelle Version)
In Containerd 1.1 wurde der Cri-Containerd-Daemon in das Containerd-CRI-Plugin übernommen. Dieses Plugin ist in Containerd 1.1 integriert und standardmäßig aktiviert. Im Gegensatz zu Cri-Containerd interagiert das Plugin mit Containerd, indem es die erforderlichen Funktionen direkt aufruft. Die neue Architektur hat die Integration stabiler und produktiver gemacht und eine weitere Verbindung (GRPC) aus dem Stapel entfernt. Jetzt kann Containerd 1.1 direkt in Kubernetes verwendet werden, und der Cri-Containerd-Daemon wird nicht mehr benötigt.
Leistung
Eines der Hauptziele von Containerd 1.1 war die Verbesserung der Leistung. Optimierungen wurden im Bereich der Startzeit und der vom Dämon verwendeten Ressourcen durchgeführt.
Die folgenden Ergebnisse sind ein Vergleich von Containerd 1.1 und Docker 18.03 CE. Integration Containerd 1.1 verwendet das integrierte CRI-Plugin, und die Integration für Docker 18.03 CE funktioniert mit Dockershim. Die Ergebnisse wurden mithilfe des Kubernetes-
Knotenleistungs- Benchmarks generiert, der Teil der
e2e-Tests für K8s-Knoten ist . Die meisten Vergleichsdaten sind im
Node Performance Dashboard öffentlich verfügbar.
Verzögerung des Herdstarts
Die Ergebnisse des
105-Pod-Batch-Startbenchmarks zeigen, dass die Integration von Containerd 1.1 beim Starten des Pods weniger Verzögerungen aufweist als Docker 18.03 CE mit Dockershim (je kleiner desto besser).
CPU und Speicher
Im Leerlauf verbraucht die Integration von Containerd 1.1 mit 105 Herden weniger Prozessor und Speicher als die Integration von Docker 18.03 CE mit Dockershim. Die Ergebnisse können abhängig von der Anzahl der auf dem Knoten gestarteten Herde variieren - die Anzahl von 105 Herden wird ausgewählt, weil Der Standardwert ist jetzt der Maximalwert für benutzerdefinierte Herde auf dem Knoten.
Wie aus den folgenden Grafiken
ersichtlich ist, verbraucht die Integration von Containerd 1.1 in
Kubelet 30,89% weniger CPU und 11,30% weniger RSS-Speicher (residente
Satzgröße ) sowie 12,78% weniger RSS-Speicher, der von der Container-Laufzeit verbraucht wird .
Ergänzung durch den Übersetzer
Es ist zu beachten, dass sich eine weitere alternative Lösung, CRI-O , weiterentwickelt. Insbesondere auf einem Open Source Summit Japan 2018 in diesen Tagen präsentierte ein Mitarbeiter von NTT einen Bericht mit einem umfassenden Vergleich bestehender ausführbarer Umgebungen für Container. Und hier ist eine seiner Folien, die ihre Leistung vergleicht:
crictl
Die Container Runtime Console Interface (CLI) ist ein nützliches Tool zum Erkennen von Problemen im System und in der Anwendung. Wenn Sie Docker als Containerumgebung in Kubernetes verwenden, rufen Systemadministratoren manchmal die Kubernetes-Site auf, um Docker-Befehle auszuführen und Informationen über das System und / oder die Anwendung zu sammeln. Beispielsweise können sie
docker ps und
docker inspect , um den Status des Prozesses zu überprüfen,
docker images , um eine Liste der Bilder auf dem Knoten
docker info ,
docker info , um die Konfiguration der Laufzeit für Container usw. abzurufen.
Für Containerd und alle anderen CRI-kompatiblen Umgebungen wie Dockershim empfehlen wir die Verwendung von
crictl als CLI-Alternative zu Docker-Konsolenbefehlen, um Probleme auf Pods, Containern und Container-Images zu analysieren, die auf Kubernetes-Knoten gehostet werden.
crictl ist ein Dienstprogramm, das ähnliche Funktionen wie die Docker-CLI bietet und für alle Laufzeitumgebungen für mit CRI kompatible Container gleich gut funktioniert. Es befindet sich im Repository von
kubernetes-inkubator / cri-tools . Die aktuelle Version ist
cri-tools v1.11.0 (die Version wurde für die aktuelle Version vor 3 Tagen anstelle von v1.0.0-beta.1 , angegeben im Originalartikel, ca. übersetzt ) korrigiert . Obwohl das Dienstprogramm
crictl der Docker-CLI ähnelt und einen einfachen Übergang für Benutzer bietet, handelt es sich nicht um eine vollständige Kopie davon. Einige wichtige Unterschiede werden nachstehend beschrieben.
Eingeschränkte Verwendung: crictl ist ein Tool zur Fehlerbehebung
crictl ist kein Ersatz für
kubectl oder
kubectl - seine Verwendung beschränkt sich auf den Umfang der Problemidentifizierung und -analyse. Die Docker-Konsolenoberfläche bietet eine Vielzahl von Befehlen und ist daher ein sehr nützliches Entwicklungswerkzeug. Dies ist jedoch nicht die beste Option zur Fehlerbehebung auf Kubernetes-Knoten. Einige Docker-Befehle (z. B.
docker network und
docker build ) sind für Kubernetes unbrauchbar, und einige (z. B.
docker rename ) können alles beschädigen. Der Zweck von
crictl besteht darin, genügend Befehle bereitzustellen, um Probleme auf Knoten zu identifizieren, die in Produktionsumgebungen sicher verwendet werden können.
Kubernetes Fokus
crictl bietet eine verständlichere Containeransicht in der Kubernetes-Welt. Die Docker-Konsolenschnittstelle funktioniert nicht mit grundlegenden Kubernetes-Konzepten wie unter (pod) und Namespace (
Namespace ), wodurch die visuelle Darstellung von Containern und Herden verhindert wird
(die Bedeutung dieses Problems ist bereits im Überwachungskontext zutreffend, über den wir kürzlich in diesem Bericht gesprochen haben - Hinweis . perev. ) . Ein solches Beispiel ist
docker ps das obskure, lange Namen für Docker-Container und eine Liste von Pausencontainern zusammen mit Anwendungscontainern anzeigt:
Pausencontainer sind jedoch Teil der Herdimplementierung, wobei für jeden Herd ein solcher Container verwendet wird. Sie sollten nicht angezeigt werden, wenn Container angezeigt werden, die Teil des Herdes sind.
crictl wurde dagegen für Kubernetes erstellt. Das Dienstprogramm bietet verschiedene Befehlssätze für Herde und Container. Beispielsweise zeigt
crictl pods Informationen zu
crictl pods , und
crictl ps zeigt nur Informationen zu Anwendungscontainern an. Alle Daten werden in einer Tabellenansicht formatiert:
Ein weiteres Beispiel - in
crictl pods gibt es ein Argument -
--namespace , mit dem Pods nach in Kubernetes definierten Namespaces
--namespace werden können:
Weitere Informationen zur Verwendung von crictl mit Containerd finden Sie hier:
Aber was ist mit der Docker Engine?
Wir hören oft die folgende Frage: "Bedeutet der Wechsel zu Containerd, dass ich die Docker Engine nicht mehr verwenden kann?", Und die kurze Antwort darauf lautet "NEIN".
Docker Engine basiert auf Containerd. Die nächste Version der Docker Community Edition (Docker CE) wird Containerd Version 1.1 verwenden. Dementsprechend wird es ein eingebautes und standardmäßig aktiviertes CRI-Plugin haben. Dies bedeutet, dass Benutzer die Möglichkeit haben, weiterhin mit der Docker Engine für andere typische Szenarien zu arbeiten sowie Kubernetes so zu konfigurieren, dass das zugrunde liegende Containerd verwendet wird, das mit der Docker Engine geliefert wird und gleichzeitig von der Docker Engine auf demselben Host verwendet wird. Schauen Sie sich das folgende Architekturdiagramm an, das zeigt, wie Docker Engine und
Kubelet denselben Container verwenden:
Da Containerd sowohl von
Kubelet als auch von der Docker Engine verwendet wird, erhalten Benutzer, die sich für die Integration in Containerd entscheiden, nicht nur alle neuen Funktionen für Kubernetes, Verbesserungen der Leistung und Stabilität, sondern auch die Option, die Docker Engine wie zuvor für andere Anforderungen zu verwenden.
Der
Namespace- Mechanismus in Containerd stellt sicher, dass
Kubelet und die Docker Engine keinen Zugriff auf Container und Images haben, die nicht von ihnen erstellt wurden. Dies bedeutet, dass sie sich nicht gegenseitig stören sowie:
- Benutzer, die den
docker ps eingeben, sehen die in Kubernetes erstellten Container nicht. Verwenden Sie dazu crictl ps . Umgekehrt sehen Benutzer keine Container, die in der Docker-CLI auf Kubernetes oder im Befehl crictl ps . Die crictl run crictl create und crictl run dienen nur zur Fehlerbehebung. Das manuelle Ausführen von Herden oder Containern mit crictl auf Produktionsknoten wird nicht empfohlen. - Benutzer, die den
docker images docker images eingeben, sehen die Bilder von Kubernetes nicht. Verwenden Sie dazu den Befehl crictl images . Umgekehrt sieht Kubernetes die Bilder nicht, die mit den Befehlen docker pull , docker load und docker build . Verwenden Sie dazu den Befehl crictl pull sowie ctr cri load , wenn Sie das Bild laden möchten.
Zusammenfassung
- Containerd 1.1 bietet native CRI-Unterstützung. Es kann direkt von Kubernetes verwendet werden.
- Containerd 1.1 ist produktionsbereit.
- Containerd 1.1 bietet eine gute Leistung in Bezug auf die Startzeit des Pods und die Auslastung der Systemressourcen.
- crictl ist ein Konsolen-Dienstprogramm (CLI) für die Kommunikation mit Containerd 1.1 und anderen Laufzeitumgebungen für Container, die CRI entsprechen, um Probleme auf dem Knoten zu identifizieren.
- Containerd 1.1 wird in der nächsten stabilen Version von Docker CE enthalten sein. Benutzer haben die Möglichkeit, in Fällen, die nicht von Kubernetes stammen, weiterhin mit Docker zu arbeiten und Kubernetes so zu konfigurieren, dass das zugrunde liegende Containerd verwendet wird, das Teil von Docker ist.
Wir möchten uns bei allen von Google, IBM, Docker, ZTE, ZJU und einzelnen Entwicklern bedanken, die dazu beigetragen und alles möglich gemacht haben!
Eine detaillierte Liste der Änderungen in Containerd 1.1 finden Sie in den
Versionshinweisen .
Wie man es versucht
Anweisungen zum Einrichten eines Kubernetes-Clusters zur Verwendung von Containerd als Standardlaufzeit:
- für einen Cluster auf GCE, der mit
kube-up.sh , - hier ; - einen Cluster mit vielen Knoten mit Ansible und kubeadm installieren - hier ;
- Informationen zum Erstellen eines Clusters von Grund auf in Google Cloud finden Sie unter " Kubernetes the Hard Way ".
- zur manuellen Installation aus dem Tarball-Archiv - hier ;
- zur Installation mit LinuxKit auf einer lokalen virtuellen Maschine - hier .
Wie man dazu beiträgt
Containerd CRI-Plugin - Ein Open Source-Projekt auf GitHub, das Teil von Containerd ist:
https://github.com/containerd/cri . Alle vorgeschlagenen Änderungen sind in Form von Ideen, Tickets und Korrekturen willkommen. Diese
Anleitung für Entwickler ist ein guter Ausgangspunkt, um Änderungen vorzunehmen.
PS vom Übersetzer
Lesen Sie auch in unserem Blog: