Verificación de conocimientos - Contenedores y CI/CD
Un equipo desea otorgar a un pipeline de CI el permiso para realizar push únicamente al repositorio taskboard/api y a un pipeline separado el permiso para realizar push únicamente a taskboard/web, ambos dentro del mismo IONOS CLOUD Container Registry. Planean crear un token por pipeline con una ACL de push por repositorio. ¿Por qué este enfoque no funcionará como se espera?
IONOS CLOUD Container Registry utiliza docker login basado en tokens, sin RBAC. Los tokens tienen un tipo de alcance de Registro o Repositorio, pero las ACL de push/pull/delete granulares por repositorio no están disponibles, por lo que no es posible restringir un token para que escriba en exactamente un repositorio. Los tokens se crean a través de la API de IONOS CLOUD o DCD, no son inventados por la CLI de Docker, lo que descarta la primera opción.
Un desarrollador envió la imagen de la API TaskBoard a tue1608es.cr.es-vit.ionos.com/taskboard/api:abc123 y escribió un manifiesto de Deployment que la referencia. Los pods fallan con ImagePullBackOff. La imagen existe y la etiqueta es correcta. ¿Qué configuración es más probable que falte?
El Container Registry de IONOS CLOUD es privado y requiere autenticación para cada extracción, por lo que el kubelet necesita credenciales proporcionadas a través de imagePullSecrets que referencia un Secret de docker-registry creado a partir de un token del registro. Sin él, las extracciones anónimas se rechazan y los pods quedan en bucle en ImagePullBackOff. Un NodeSelector, Ingress o ConfigMap no proporciona credenciales de extracción.
Un desarrollador crea un Servicio de Kubernetes de tipo LoadBalancer en IONOS CLOUD Managed Kubernetes, esperando que se aprovisione un equilibrador de carga externo dedicado frente al clúster. Más tarde, observa que todo el tráfico fluye a través de un único nodo de trabajo y que el rendimiento alcanza un punto máximo. ¿Cuál es la comprensión correcta de este comportamiento?
En IONOS CLOUD Managed Kubernetes, un Servicio de tipo LoadBalancer no despliega un equilibrador de carga externo. IONOS CLOUD reserva una IP pública estática y la adjunta como IP secundaria a un único nodo de trabajo, que enruta el tráfico hacia el clúster, de modo que el rendimiento queda limitado por ese único nodo de entrada. Para escalar o colocar un equilibrador de carga administrado real en la parte frontal, debe aprovisionar un ALB o NLB de IONOS CLOUD por separado, ya que estos no se crean automáticamente a partir de manifiestos de Kubernetes.
Un flujo de trabajo de GitHub Actions compila la imagen de TaskBoard, la envía a Container Registry y ejecuta kubectl apply contra Managed Kubernetes. La pipeline actual codifica de forma fija el IONOS_TOKEN, el token del registro y el kubeconfig directamente en el YAML del flujo de trabajo. ¿Cuál es la forma correcta de proporcionar estas credenciales?
Las credenciales de la pipeline, como IONOS_TOKEN, el token de Container Registry y el kubeconfig, deben almacenarse como secretos cifrados de CI e inyectarse en tiempo de ejecución, sin comprometerlas nunca en el código fuente ni incorporarlas en las imágenes. Comprometerlas en una rama privada aún deja los secretos en el historial de Git, e incorporarlas en la imagen las expone a cualquier persona que pueda descargarla. Generar credenciales a partir de la contraseña de una cuenta mediante autenticación básica invalida el principio de privilegio mínimo y el acotado de tokens por servicio.
Se desplegó una imagen defectuosa en el Deployment de la API de TaskBoard en Managed Kubernetes y los pods están en bucle de reinicio (crash-looping). La imagen anterior funcionaba correctamente. El desarrollador necesita la forma más rápida y segura de devolver la carga de trabajo en ejecución a la versión anterior. ¿Qué comando debe utilizar?
Un Deployment conserva un historial de revisiones de sus ReplicaSets, por lo que kubectl rollout undo revierte a la revisión anterior que funcionaba correctamente mediante un reemplazo rodado controlado y con una interrupción mínima. Eliminar el Deployment provoca tiempo de inactividad y descarta el estado del despliegue, mientras que terraform destroy desmonta el clúster completo. Escalar a cero réplicas elimina todos los pods sin restaurar ninguna versión anterior, ya que la especificación del Deployment sigue haciendo referencia a la imagen defectuosa.