Wissensprüfung - Container und CI/CD
Ein Team möchte einer CI-Pipeline die Berechtigung erteilen, ausschließlich in das Repository taskboard/api zu pushen, und einer separaten Pipeline die Berechtigung, ausschließlich in taskboard/web zu pushen, wobei sich beide in derselben IONOS CLOUD Container Registry befinden. Sie planen, pro Pipeline ein Token mit einer Push-ACL pro Repository zu erstellen. Warum wird dieser Ansatz nicht wie beabsichtigt funktionieren?
Die IONOS CLOUD Container Registry verwendet tokenbasiertes docker login ohne RBAC. Tokens tragen einen Scope-Typ Registry oder Repository, jedoch sind feingranulare Push/Pull/Delete-ACLs pro Repository nicht verfügbar, sodass ein Token nicht darauf beschränkt werden kann, genau in ein einzelnes Repository zu schreiben. Tokens werden über die IONOS CLOUD API oder DCD erstellt, nicht von der Docker CLI erfunden, was die erste Option ausschließt.
Eine Entwicklerin oder ein Entwickler hat das TaskBoard-API-Image zu tue1608es.cr.es-vit.ionos.com/taskboard/api:abc123 hochgeladen und ein Deployment-Manifest erstellt, das darauf verweist. Die Pods scheitern mit ImagePullBackOff. Das Image existiert und der Tag ist korrekt. Welche Konfiguration fehlt am wahrscheinlichsten?
Das IONOS CLOUD Container Registry ist privat und erfordert für jeden Pull eine Authentifizierung. Daher benötigt der kubelet Anmeldedaten, die über imagePullSecrets bereitgestellt werden und ein docker-registry-Secret referenzieren, das aus einem Registry-Token erstellt wurde. Ohne diese Angabe werden anonyme Pulls abgelehnt und die Pods laufen in ImagePullBackOff-Schleifen. Ein NodeSelector, Ingress oder ConfigMap stellt keine Zugangsdaten für den Pull bereit.
Eine Entwicklerin erstellt einen Kubernetes Service vom Typ LoadBalancer auf IONOS CLOUD Managed Kubernetes und erwartet, dass ein dedizierter externer Load Balancer vor dem Cluster bereitgestellt wird. Später stellt sie fest, dass der gesamte Verkehr über einen einzelnen Worker-Node fließt und die Durchsatzrate stagniert. Was ist das korrekte Verständnis dieses Verhaltens?
Auf IONOS CLOUD Managed Kubernetes deployt ein LoadBalancer Service keinen externen Load Balancer. IONOS CLOUD reserviert eine statische öffentliche IP und hängt sie als sekundäre IP an einen einzelnen Worker-Node, der den Verkehr in den Cluster leitet. Dadurch ist der Durchsatz durch diesen einen Ingress-Node begrenzt. Um zu skalieren oder einen echten verwalteten Load Balancer vor das Cluster zu schalten, wird ein IONOS CLOUD ALB oder NLB separat bereitgestellt, da diese nicht automatisch aus Kubernetes-Manifests erstellt werden.
Ein GitHub Actions Workflow baut das TaskBoard-Image, pusht es in die Container Registry und führt kubectl apply gegen Managed Kubernetes aus. Die Pipeline kodiert derzeit das IONOS_TOKEN, das Registry-Token und die kubeconfig direkt im Workflow YAML hart. Wie ist die korrekte Methode, um diese Zugangsdaten bereitzustellen?
Pipeline-Zugangsdaten wie IONOS_TOKEN, das Container Registry-Token und die kubeconfig müssen als verschlüsselte CI-Secrets gespeichert und zur Laufzeit injiziert werden, niemals in den Quellcode committen oder in Images einbrennen. Das Committen in einen privaten Branch führt weiterhin dazu, dass Secrets in der Git-Verlaufsgeschichte landen, und das Einbetten in das Image macht sie für jeden zugänglich, der es ziehen kann. Das Erzeugen von Zugangsdaten aus einem Kontopasswort über Basic auth untergräbt das Prinzip der geringsten Berechtigung und die Token-Bereitstellung pro Dienst.
Ein fehlerhaftes Image wurde für das TaskBoard API Deployment auf Managed Kubernetes ausgerollt, und die Pods befinden sich in einem Crash-Loop. Das vorherige Image hat funktioniert. Die Entwicklerin oder der Entwickler benötigt den schnellsten sicheren Weg, um die laufende Workload auf die vorherige Version zurückzusetzen. Welchen Befehl sollte sie oder er verwenden?
Ein Deployment führt eine Revisionshistorie seiner ReplicaSets, sodass kubectl rollout undo zu der vorherigen funktionierenden Revision zurückkehrt und dabei einen kontrollierten rollenden Austausch mit minimaler Störung durchführt. Das Löschen des Deployments führt zu Ausfallzeiten und verwirft den Rollout-Zustand, während terraform destroy den gesamten Cluster abbaut. Das Skalieren auf null Replikate entfernt alle Pods, ohne eine vorherige Version wiederherzustellen, da die Deployment-Spezifikation immer noch das fehlerhafte Image referenziert.