Vérification des connaissances - Conteneurs et CI/CD
Évaluez votre compréhension des concepts clés du Module 3. Sélectionnez la meilleure réponse pour chaque question, puis soumettez pour voir vos résultats. Vous devez obtenir au moins 60 % pour réussir.
Une équipe souhaite accorder à un pipeline CI l'autorisation de pousser uniquement vers le dépôt taskboard/api et à un pipeline distinct l'autorisation de pousser uniquement vers taskboard/web, tous deux situés dans le même IONOS CLOUD Container Registry. Ils prévoient de créer un jeton par pipeline avec une ACL de poussée par dépôt. Pourquoi cette approche ne fonctionnera-t-elle pas comme prévu ?
Le IONOS CLOUD Container Registry utilise des docker login basées sur des jetons uniquement, sans RBAC. Les jetons portent un type de périmètre Registre ou Dépôt, mais les ACL de poussée/tirage/suppression par dépôt à granularité fine ne sont pas disponibles, ce qui empêche de restreindre un jeton à l'écriture sur un seul dépôt précis. Les jetons sont créés via l'API IONOS CLOUD ou DCD, et non inventés par la CLI Docker, ce qui écarte la première option.
Un développeur a poussé l'image TaskBoard API vers tue1608es.cr.es-vit.ionos.com/taskboard/api:abc123 et a rédigé un manifeste de Deployment qui y fait référence. Les pods échouent avec ImagePullBackOff. L'image existe et le tag est correct. Quelle configuration est la plus probablement manquante ?
Le Container Registry IONOS CLOUD est privé et exige une authentification pour chaque récupération. Le kubelet a donc besoin d'identifiants fournis via imagePullSecrets faisant référence à un Secret docker-registry créé à partir d'un jeton de registre. Sans cela, les récupérations anonymes sont rejetées et les pods restent en boucle dans l'état ImagePullBackOff. Un NodeSelector, un Ingress ou un ConfigMap ne fournit pas d'identifiants de récupération.
Un développeur crée un Service Kubernetes de type LoadBalancer sur IONOS CLOUD Managed Kubernetes, en s'attendant à ce qu'un équilibreur de charge externe dédié soit provisionné devant le cluster. Il constate ensuite que tout le trafic transite par un seul nœud worker et que le débit plafonne. Quelle est la bonne compréhension de ce comportement ?
Sur IONOS CLOUD Managed Kubernetes, un Service LoadBalancer ne déploie pas d'équilibreur de charge externe. IONOS CLOUD réserve une IP publique statique et l'attache en tant qu'IP secondaire à un seul nœud worker, qui achemine le trafic vers le cluster ; le débit est donc limité par ce nœud d'entrée unique. Pour mettre à l'échelle ou placer un véritable équilibreur de charge managé en amont, il faut provisionner séparément un ALB ou un NLB IONOS CLOUD, car ces derniers ne sont pas créés automatiquement à partir des manifests Kubernetes.
Un workflow GitHub Actions construit l'image TaskBoard, la pousse vers Container Registry, et exécute kubectl apply contre Managed Kubernetes. Le pipeline code actuellement en dur le IONOS_TOKEN, le jeton du registre et le kubeconfig directement dans le fichier YAML du workflow. Quelle est la méthode correcte pour fournir ces identifiants ?
Les identifiants du pipeline tels que IONOS_TOKEN, le jeton de Container Registry et le kubeconfig doivent être stockés en tant que secrets CI chiffrés et injectés à l'exécution, et ne doivent jamais être commettus dans le code source ni intégrés dans les images. Commettre sur une branche privée place toujours les secrets dans l'historique Git, et les intégrer dans l'image les expose à quiconque peut l'extraire. Générer des identifiants à partir d'un mot de passe de compte via l'authentification de base contrevient au principe du moindre privilège et à l'attribution de jetons par service.
Une image défectueuse a été déployée sur le Deployment de l'API TaskBoard sur Managed Kubernetes, et les pods sont en boucle de redémarrage. L'image précédente fonctionnait. Le développeur a besoin de la méthode la plus rapide et la plus sûre pour ramener la charge de travail en cours d'exécution à la version antérieure. Quelle commande doit-il utiliser ?
Un Deployment conserve un historique des révisions de ses ReplicaSets, de sorte que kubectl rollout undo permet de revenir à la révision précédente fonctionnelle avec un remplacement en cours contrôlé et une perturbation minimale. La suppression du Deployment entraîne une interruption de service et supprime l'état du déploiement, tandis que terraform destroy démantèle l'ensemble du cluster. La mise à l'échelle à zéro réplique supprime tous les pods sans restaurer aucune version antérieure, car la spécification du Deployment fait toujours référence à l'image défectueuse.