Vérification des connaissances - Conteneurs et CI/CD
Testez 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 un score d'au moins 60 % pour réussir.
Une équipe souhaite accorder à un pipeline CI l'autorisation de pousser uniquement vers le taskboard/api référentiel et à un pipeline séparé l'autorisation de pousser uniquement vers taskboard/web, tous deux à l'intérieur du même Registre de conteneurs IONOS. Ils prévoient de créer un jeton par pipeline avec un ACL de poussée par référentiel. Pourquoi cette approche ne fonctionnera-t-elle pas comme prévu ?
Le Registre de conteneurs IONOS utilise des jetons basés sur docker login uniquement sans RBAC. Les jetons portent un type de portée de Registre ou de Référentiel, mais des ACL de poussée/lecture/suppression par référentiel fines ne sont pas disponibles, vous ne pouvez donc pas restreindre un jeton pour écrire exactement dans un référentiel. Les jetons sont créés via IONOS API ou DCD, et non inventés par la Docker CLI, ce qui exclut 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 écrit un manifeste de déploiement qui la référence. Le Pods échoue avec ImagePullBackOff. L'image existe et le tag est correct. Quelle configuration est la plus susceptible d'être manquante ?
Le registre de conteneurs IONOS est privé et nécessite une authentification pour chaque extraction, donc le kubelet a besoin de données d'identification fournies via imagePullSecrets qui référence un Secret Docker-registre créé à partir d'un jeton de registre. Sans cela, les extractions anonymes sont rejetées et le Pods boucle dans ImagePullBackOff. Un NodeSelector, Ingress ou ConfigMap ne fournit pas de données d'identification pour l'extraction.
Un développeur crée un Kubernetes Service de type LoadBalancer sur IONOS Managed Kubernetes en attendant qu'un Load Balancer externe dédié soit provisionné devant le Cluster. Plus tard, ils remarquent que tout le trafic passe par un seul worker Node et que le débit atteint un plateau. Quelle est la compréhension correcte de ce comportement ?
Sur IONOS Managed Kubernetes, un Service LoadBalancer ne déploie pas de Load Balancer externe. IONOS réserve une adresse IP publique statique IP et l'attache en tant qu'adresse IP secondaire IP à un worker Node unique, qui achemine le trafic vers le Cluster, donc le débit est limité par ce point d'entrée Node. Pour mettre à l'échelle ou pour placer un véritable Load Balancer géré devant, vous provisionnez un ALB ou un NLB IONOS séparément, puisque ceux-ci ne sont pas créés automatiquement à partir de manifestes Kubernetes.
Un workflow GitHub Actions construit l'image TaskBoard, la pousse vers le Container Registry, et exécute kubectl apply contre Managed Kubernetes. Le pipeline code actuellement en dur le IONOS_TOKEN, le jeton de registre, et le kubeconfig directement dans le workflow YAML. Quelle est la bonne façon de fournir ces informations d'identification ?
Les informations d'identification de pipeline, telles que IONOS_TOKEN, le jeton de Container Registry, et le kubeconfig, doivent être stockées comme secrets CI chiffrés et injectées au moment de l'exécution, sans jamais être consignées à la source ou intégrées dans les images. Consigner à une branche privée place toujours les secrets dans l'historique Git, et les intégrer dans l'image les expose à quiconque peut la télécharger. Créer des informations d'identification à partir d'un mot de passe de compte via l'authentification de base défait la portée des jetons de service avec les privilèges minimum.
Une mauvaise image a été déployée sur le déploiement TaskBoard API sur Managed Kubernetes et Pods sont en boucle de crash. L'image précédente fonctionnait. Le développeur a besoin de la façon la plus rapide et la plus sûre de restaurer la charge de travail en cours d'exécution à la version précédente. Quelle commande devrait-il utiliser ?
Un déploiement conserve un historique des révisions de ses ReplicaSets, donc kubectl rollout undo revient à la révision de travail précédente avec un remplacement contrôlé et une perturbation minimale. La suppression du déploiement entraîne une interruption de service et supprime l'état de déploiement, tandis que terraform destroy détruit l'ensemble du Cluster. La mise à l'échelle à zéro répliques supprime toutes les Pods sans restaurer aucune version précédente, puisque la spécification de déploiement fait toujours référence à la mauvaise image.