Einleitung
Docker gilt als “der Standard” in Sachen Container. Nahezu jeder kennt den Begriff “Docker” und verwendet diesen oft als Synonym für Container. Docker selbst hatte durch ein gutes Produkt und ein gutes Timing schnell große Verbreitung gefunden. Oft werden Container Images auch als “Docker Images” bezeichnet - was jedoch nicht korrekt ist:
Es handelt sich um OCI Images welche mit jeder (OCI kompatiblen, dem eigentlichen Standard für Container) Container Runtime funktionieren - wie z.B. CRI-O oder containerd .
Docker selbst ist ein kompletter Technologie-Stack. Die Container–Runtime selbst ist “containerd”. Darum herum wurde jedoch sehr viel entwickelt, wie z.B. ein User-Interface für Entwickler und vieles mehr. Diese Dinge benötigen wir in skalierbaren Container und Kubernetes-Umgebungen hingegen nicht.
Docker ist aktuell (noch) relativ weit verbreitet - allerdings hat dieses Produkt im Kubernetes Umfeld ein Ablaufdatum. Konkret ist Docker seit Kubernetes v1.20 deprecated und der support für Docker via “dockershim” wird in Kubernetes v1.24 eingestellt werden.
Was ist "dockershim"?
Die ersten Kubernetes Versionen basierten auf Docker als Container Runtime. Allerdings wandelte sich das Kubernetes Projekt durch seine große Offenheit, welche auch die Basis für dessen Innovationsfähigkeit darstellt, zu einem auf Plugins und Interfaces basierendem Konstrukt. Aus diesem Wandel entstand unter anderem das Container Runtime Interface, kurz CRI. Die CRI ist seit 2016 die Schnittstelle für Container Runtimes in Kubernetes - und Docker unterstützt kein CRI.
Aus diesem Grund wurde "dockershim" implementiert. Über dockershim kann die Container-Runtime "containerd" als eine Art "wrapper" über die CRI angesprochen werden:
Dieser Aufbau ist wenig effizient und lässt sich schlanker und effizienter gestalten:
SUSE Rancher RKE1 und RKE2
Mit SUSE Rancher RKE1 steht eine grundsolide, ausgereifte und ordentliche, aber (relativ) alte sowie auf der Docker-Technologie basierende Kubernetes Distribution zur Verfügung. FullStackS verwendete bislang RKE1 aus Gründen der Robustheit und durchweg sehr guten Erfahrung.
Der Nachfolger von RKE1 ist RKE2 - ebenfalls robust und ausgereift - sowie darüber hinaus sehr stark hinsichtlich Security gehärtet (FIPS-140, CIS 1.6) und RKE2 basiert auf containerd.
Warum verwendete FullStackS bislang RKE1 und empfiehlt nun RKE2 zu verwenden?
Der Grund liegt darin, dass sich die neue Cluster-API für die Bereitstellung von Kubernetes Downstream Clustern in SUSE Rancher bis zur Version v2.6.3 im sog. “Tech Preview” befand:
Mit den folgenden SUSE Rancher Versionen wird das neue, auf der Cluster-API basierende provisioning von RKE2 (und K3S) Clustern "GA".
Das neue Provisioning ist drüber hinaus optimal in unsere modulare Infrastructure as Code Plattform für SUSE Rancher auf jeglichen Umgebungen (On-Prem, Edge und Cloud) integriert und kann ab sofort genutzt werden.
In unserem Labor haben wie die Integration in den letzten Monaten entwickelt, getestet und finalisiert.
Wir empfehlen für den Aufbau von neuen Downstream Clustern ab dem Erscheinen von SUSE Rancher v2.6.4 konsequent den Einsatz von RKE2 und die aktive Vermeidung von Docker in neuen Projekten.
Darüber hinaus erfüllen unsere FullStackS Terraform Module alle Anforderungen für CIS 1.6 “hardened / restricted” & FIPS-140 konforme Kubernetes Cluster.
Interesse? Kommen Sie auf uns zu!
TL;DR
Docker unterstützt kein CRI die Schnittstelle für Container Runtimes in Kubernetes
Docker hat ein Ablaufdatum hinsichtlich Support und Technologie
RKE2 bietet zusätzlich zur "Robustheit" eine höhere Security
Comentarios