Comprobación de conocimientos - Operaciones de producción
Un desarrollador implementa TaskBoard en Managed Kubernetes y luego abre el Logging Service Grafana, esperando ver los registros del pod y del plano de control de Cluster. La vista está vacía. ¿Cuál es la solución correcta?
Los eventos del plano de control de Kubernetes NO fluyen a través del Logging Service de IONOS de forma automática; la plataforma no envía registros de Cluster por usted. Usted debe reenviarlos usted mismo con un DaemonSet de Fluent Bit o habilitando el registro centralizado. Los valores de retención y la restricción de solo JSON se aplican a la fuente HTTP, no al camino de reenvío de Kubernetes, y no hay una bandera loggingEnabled de creación que resuelva esto.
Un desarrollador crea una Monitoring Service pipeline, ve una respuesta 201 exitosa, luego cierra el terminal sin leer el cuerpo. Al día siguiente, su agente de métricas devuelve 401 en cada push a /api/v1/push y no puede encontrar una forma de recuperar la clave de ingesta. ¿Qué sucedió?
El Monitoring Service devuelve la clave de ingesta por pipeline solo una vez, en metadata.key al crear, y nunca más por razones de seguridad. Si el cuerpo de la respuesta no se captura, la clave no se puede recuperar y debe provisionar un pipeline fresco o rotar la clave. Prometheus, Grafana Agent y OpenTelemetry autenticar con el encabezado APIKEY, por lo que el formato de encabezado es correcto; no hay un TTL de clave diario.
Un desarrollador está depurando una falla de conectividad entre los niveles de TaskBoard. Los registros de la aplicación están en silencio, por lo que necesitan confirmar en la capa de red si el tráfico está siendo bloqueado. Agregan un registro de flujo en la NIC, luego se dan cuenta de que configuraron la dirección de captura incorrecta. ¿Cuál es la forma correcta de cambiarla?
La configuración del registro de flujo es inmutable después de la creación, y hay un registro de flujo por recurso. Para cambiar cualquier configuración, incluyendo la dirección de captura, se elimina el registro de flujo existente y se crea uno nuevo; no hay camino de actualización en el lugar a través de PATCH o Terraform, y no se puede adjuntar un segundo registro de flujo al mismo recurso.
Un desarrollador necesita que la tubería de CI de TaskBoard se autentique en el IONOS API y quiere que una filtración de esa credencial sea contenida y recuperable rápidamente. ¿Cuál es el enfoque de token correcto?
El patrón seguro es uno de token por servicio por entorno (hasta 100 por usuario) con el TTL más corto tolerable del conjunto fijo, rotado generación-revocación para que nunca haya una brecha. Un token compartido a nivel de contrato significa que una sola filtración puede provocar el descenso de todo, la autenticación básica está siendo descontinuada y no debe utilizarse en la automatización, y el valor del token se muestra exactamente una vez sin un punto final de lectura nuevamente.
Un desarrollador expone TaskBoard en MKS con un Service de type: LoadBalancer. En producción, observan que todo el tráfico llega a un worker Node, la fuente del cliente IP se pierde y el rendimiento se estabiliza alrededor de 2 Gbit/s. ¿Cuál es la afirmación que correctamente explica esto y la solución de producción?
En MKS, un Servicio type: LoadBalancer asigna una dirección IP pública reservada como una dirección IP secundaria a un solo ingreso Node y kube-proxy NAT a la cápsula, por lo que la fuente IP se pierde (solucionado con externalTrafficPolicy: Local) y el rendimiento está limitado a 2 Gbit/s en el techo de ese Node. El tráfico de producción debe pasar por un Managed ALB provisionado por separado desde la capa Terraform. Los NSG no se unen a los equilibradores de carga administrados ni a los nodos MKS, y un PodDisruptionBudget protege la disponibilidad durante las reconstrucciones en lugar de afectar la ruta.