Verificación de conocimientos - Operaciones de producción
Un desarrollador implementa TaskBoard en Managed Kubernetes y luego abre Grafana de Logging Service, esperando ver los registros de pods y del plano de control del clúster. La vista está vacía. ¿Cuál es la solución correcta?
Los eventos del plano de control de Kubernetes NO fluyen automáticamente a través de IONOS CLOUD Logging Service; la plataforma no envía los registros del clúster por usted. Debe reenviarlos usted mismo mediante un DaemonSet de Fluent Bit o habilitando Central Logging. Los valores de retención y la restricción de solo JSON aplican a la fuente HTTP, no a la ruta de reenvío de Kubernetes, y no existe una bandera loggingEnabled en el momento de la creación que resuelva esto.
Un desarrollador crea una canalización de Monitoring Service, ve una respuesta exitosa de 201 y luego cierra la terminal sin leer el cuerpo de la respuesta. Al día siguiente, su agente de métricas devuelve 401 en cada envío a /api/v1/push y no encuentra forma de recuperar la clave de ingesta. ¿Qué ocurrió?
Monitoring Service devuelve la clave de ingesta por canalización solo una vez, en metadata.key durante la creación, y nunca vuelve a hacerlo por razones de seguridad. Si el cuerpo de la respuesta no se captura, la clave no puede recuperarse y debe provisionar una canalización nueva o rotar la clave. Prometheus, Grafana Agent y OpenTelemetry se autentican todos con la cabecera APIKEY, por lo que el formato de la cabecera es correcto; no existe un TTL diario para la clave.
Un desarrollador está depurando una falla de conectividad entre las capas de TaskBoard. Los registros de la aplicación no muestran información, por lo que necesita confirmar a nivel de red si el tráfico está siendo bloqueado. Agrega un Flow Log en la NIC y luego se da cuenta de que configuró la dirección de captura incorrecta. ¿Cuál es la forma correcta de cambiarla?
La configuración del Flow Log es inmutable después de su creación, y hay un solo flow log por recurso. Para cambiar cualquier configuración, incluida la dirección de captura, debe eliminar el flow log existente y crear uno nuevo; no existe una ruta de actualización in situ mediante PATCH o Terraform, y no se puede adjuntar un segundo flow log al mismo recurso.
Un desarrollador necesita que la pipeline CI de TaskBoard se autentique en la API de IONOS CLOUD y desea que una fuga de esa credencial se contenga y sea recuperable rápidamente. ¿Qué enfoque de token es correcto?
El patrón seguro consiste en un token por servicio y por entorno (hasta 100 por usuario) con el TTL más corto tolerable del conjunto fijo, rotado mediante la secuencia de generar y luego revocar, de modo que nunca exista un hueco. Un token compartido para todo el contrato implica que una sola fuga afecta a todo; la autenticación básica está en proceso de descontinuación y no debe usarse en automatización; y el valor del token se muestra exactamente una vez, sin un punto de acceso para volver a leerlo.
Un desarrollador expone TaskBoard en MKS con un Service de type: LoadBalancer. En producción, observa que todo el tráfico llega a un solo nodo de trabajo, la IP de origen del cliente se pierde y el rendimiento se estanca en aproximadamente 2 Gbit/s. ¿Qué enunciado explica correctamente esto y la solución en producción?
En MKS, un Service type: LoadBalancer asigna una IP pública reservada como IP secundaria a un solo nodo de entrada y kube-proxy realiza NAT hacia el pod, por lo que la IP de origen se pierde (se corrige con externalTrafficPolicy: Local) y el rendimiento se limita al máximo de 2 Gbit/s de ese nodo. El tráfico de producción debe pasar a través de un Managed ALB aprovisionado por separado desde la capa de Terraform. Los NSG no se vinculan a equilibradores de carga administrados ni a nodos de MKS, y un PodDisruptionBudget protege la disponibilidad durante las reconstrucciones, en lugar de afectar la enrutación.