Verificación de conocimientos - Contenedores y CI/CD
Un equipo quiere dar a una tubería de CI permiso para push solo al repositorio taskboard/api y a una tubería separada permiso para push solo al taskboard/web, ambos dentro del mismo Registro de Contenedores de IONOS. Planean crear un token por tubería con un ACL de push por repositorio. ¿Por qué este enfoque no funcionará como se pretende?
El Registro de Contenedores de IONOS utiliza autenticación basada en tokens solo con no RBAC. Los tokens llevan un tipo de alcance de Registro o Repositorio, pero los ACL de push/pull/eliminación por repositorio detallados no están disponibles, por lo que no puede restringir un token para que escriba exactamente en un repositorio. Los tokens se crean a través de IONOS API o DCD, no inventados por la CLI de Docker, lo que descarta la primera opción.
Un desarrollador empujó la imagen de TaskBoard API a tue1608es.cr.es-vit.ionos.com/taskboard/api:abc123 y escribió un manifiesto de implementación que hace referencia a ella. El Pods falla con ImagePullBackOff. La imagen existe y la etiqueta es correcta. ¿Cuál es la configuración que más probablemente esté faltando?
El registro de contenedores de IONOS es privado y requiere autenticación para cada extracción, por lo que el kubelet necesita credenciales suministradas a través de imagePullSecrets que hace referencia a un Secreto Docker-registry creado a partir de un token de registro. Sin ello, las extracciones anónimas son rechazadas y el Pods se bucla en ImagePullBackOff. Un NodeSelector, Ingress o ConfigMap no proporciona credenciales de extracción.
Un desarrollador crea un Kubernetes Service de tipo LoadBalancer en IONOS Managed Kubernetes esperando que se proporcione un Load Balancer externo dedicado frente al Cluster. Más tarde, nota que todo el tráfico fluye a través de un solo worker Node y el rendimiento se estanca. ¿Cuál es la comprensión correcta de este comportamiento?
En IONOS Managed Kubernetes, un Service LoadBalancer no despliega un Load Balancer externo. IONOS reserva una dirección pública estática IP y la adjunta como una dirección secundaria IP a un solo worker Node, que enruta el tráfico hacia el Cluster, por lo que el rendimiento está limitado por ese solo ingreso Node. Para escalar o poner un verdadero Load Balancer administrado en frente, usted provisiona un ALB o NLB de IONOS por separado, ya que estos no se crean automáticamente a partir de los manifiestos Kubernetes.
Un flujo de trabajo de GitHub Actions construye la imagen de TaskBoard, la envía a Container Registry y ejecuta kubectl apply contra Managed Kubernetes. La canalización actualmente codifica de forma rígida el IONOS_TOKEN, el token del registro y el kubeconfig directamente en el flujo de trabajo YAML. ¿Cuál es la forma correcta de proporcionar estas credenciales?
Las credenciales de la canalización, como IONOS_TOKEN, el token de Container Registry y el kubeconfig, deben almacenarse como secretos CI cifrados e inyectarse en tiempo de ejecución, nunca comprometiendo el código fuente o integrándolos en las imágenes. Comprometer en una rama privada todavía coloca secretos en el historial de Git, y incorporarlos en la imagen los expone a cualquier persona que pueda extraerla. Acuñar credenciales desde la contraseña de una cuenta sobre autenticación básica derrota el ámbito de token por servicio con los privilegios mínimos.
Se implementó una imagen defectuosa en la implementación de TaskBoard API en Managed Kubernetes y Pods están experimentando un bucle de fallo. La imagen anterior funcionaba. El desarrollador necesita la forma más rápida y segura de regresar la ejecución de Workload a la versión anterior. ¿Qué comando debería utilizar?
Una Implementación mantiene un historial de revisiones de sus ReplicaSets, por lo que kubectl rollout undo revierte a la revisión anterior que funcionaba con un reemplazo controlado y una interrupción mínima. Eliminar la Implementación causa tiempo de inactividad y descarta el estado de implementación, mientras que terraform destroy desmantela todo el Cluster. Escalar a cero réplicas elimina todos los Pods sin restaurar ninguna versión anterior, ya que la especificación de la Implementación todavía hace referencia a la imagen defectuosa.