Wissensprüfung - Container und CI/CD
Ein Team möchte einer CI-Pipeline die Berechtigung erteilen, nur in das taskboard/api-Repository zu pushen, und einer separaten Pipeline die Berechtigung, nur in das taskboard/web-Repository zu pushen, beides innerhalb des gleichen IONOS Container-Registries. Sie planen, pro Pipeline ein Token mit einer pro-Repository-Push-ACL zu erstellen. Warum wird dieser Ansatz nicht wie beabsichtigt funktionieren?
IONOS Container-Registry verwendet tokenbasierte docker login nur ohne RBAC. Token tragen einen Registry- oder Repository-Scope-Typ, aber fein granulierte pro-Repository-Push/Pull/Löschen-ACLs sind nicht verfügbar, sodass Sie ein Token nicht auf genau ein Repository beschränken können. Token werden über die IONOS API oder DCD erstellt, nicht durch die Docker-CLI, was die erste Option ausschließt.
Ein Entwickler hat das TaskBoard API-Bild zu tue1608es.cr.es-vit.ionos.com/taskboard/api:abc123 gepusht und eine Deployment-Manifestdatei erstellt, die darauf verweist. Die Pods schlagen mit ImagePullBackOff fehl. Das Bild existiert und der Tag ist korrekt. Welche Konfiguration fehlt wahrscheinlich am meisten?
Das IONOS Container-Repository ist privat und erfordert für jeden Pull eine Authentifizierung, sodass der Kubelet Anmeldeinformationen benötigt, die über imagePullSecrets bereitgestellt werden, der auf ein Docker-Repository-Secret verweist, das aus einem Repository-Token erstellt wurde. Ohne diese Anmeldeinformationen werden anonyme Pulls abgelehnt und die Pods laufen in ImagePullBackOff weiter. Ein NodeSelector, Ingress oder ConfigMap stellt keine Pull-Anmeldeinformationen bereit.
Ein Entwickler erstellt einen Kubernetes-Service des Typs LoadBalancer auf IONOS Managed Kubernetes und erwartet, dass ein dedizierter externer Load Balancer vor dem Cluster bereitgestellt wird. Später stellt er fest, dass alle Datenverkehr über einen einzelnen Worker-Node fließt und die Durchsatzleistung einen Plateau erreicht. Was ist das korrekte Verständnis dieses Verhaltens?
Auf IONOS Managed Kubernetes deployt ein LoadBalancer-Service keinen externen Load Balancer. IONOS reserviert eine statische öffentliche IP und bindet sie als sekundäre IP an einen einzelnen Worker-Node, der den Datenverkehr in den Cluster leitet, so dass die Durchsatzleistung durch diesen einen Eingangs-Node begrenzt ist. Um die Skalierbarkeit zu erhöhen oder einen echten gemanagten Load Balancer voranzustellen, muss ein IONOS-ALB oder NLB separat bereitgestellt werden, da diese nicht automatisch aus Kubernetes-Manifesten erstellt werden.
Ein GitHub-Actions-Workflow erstellt das TaskBoard-Image, pusht es in das Container-Registrierungssystem und führt kubectl apply gegen Managed Kubernetes aus. Die Pipeline codiert derzeit die IONOS_TOKEN, das Registrierungstoken und die Kubeconfig direkt im Workflow-YAML-Code. Wie ist der korrekte Weg, um diese Anmeldeinformationen bereitzustellen?
Pipeline-Anmeldeinformationen wie IONOS_TOKEN, das Container-Registrierungstoken und die Kubeconfig müssen als verschlüsselte CI-Geheimnisse gespeichert und zur Laufzeit injiziert werden, ohne jemals in den Quellcode oder in die Bilder eingefügt zu werden. Das Committen in einen privaten Zweig bringt die Geheimnisse immer noch in die Git-Historie, und das Einbetten in das Image legt sie jedem offen, der es abrufen kann. Die Erstellung von Anmeldeinformationen aus einem Kontopasswort über Basic-Authentifizierung untergräbt die Prinzipien der geringsten Rechte und der pro-Service-Token-Berechtigung.
Ein schlechtes Bild wurde auf die TaskBoard API-Bereitstellung auf Managed Kubernetes und Pods ausgerollt und diese sind im Crash-Loop-Modus. Das vorherige Bild hat funktioniert. Der Entwickler benötigt den schnellsten sicheren Weg, um die laufende Workload-Instanz zur vorherigen Version zurückzusetzen. Welchen Befehl sollten sie verwenden?
Eine Bereitstellung behält eine Revisionshistorie ihrer ReplicaSets, sodass kubectl rollout undo auf die vorherige funktionierende Revision mit einer kontrollierten rollingen Ersetzung und minimaler Störung zurücksetzt. Das Löschen der Bereitstellung verursacht Ausfallzeiten und verwirft den Rollout-Zustand, während terraform destroy den gesamten Cluster-Bereich abbaut. Die Skalierung auf Null-Replikate entfernt alle Pods-Instanzen, ohne eine vorherige Version wiederherzustellen, da die Bereitstellungs-Spezifikation immer noch auf das schlechte Bild verweist.