Preguntas y Respuestas de Entrevista de Kubernetes

Introducción

Bienvenido a esta guía completa diseñada para equiparte con el conocimiento y la confianza necesarios para destacar en entrevistas de Kubernetes. Ya sea que estés comenzando tu viaje con la orquestación de contenedores o seas un profesional experimentado que busca profundizar tu experiencia, este documento proporciona un enfoque estructurado para dominar los conceptos de Kubernetes. Hemos seleccionado meticulosamente una amplia gama de preguntas, que abarcan desde principios fundamentales y consideraciones arquitectónicas avanzadas hasta resolución práctica de problemas, desafíos basados en escenarios y consultas específicas para desarrolladores, administradores e ingenieros de DevOps. Prepárate para mejorar tu comprensión, refinar tus habilidades de resolución de problemas y navegar con confianza en cualquier entrevista de Kubernetes.

Fundamentos y Conceptos Clave de Kubernetes

¿Qué es Kubernetes y para qué se utiliza?

Respuesta:

Kubernetes es una plataforma de orquestación de contenedores de código abierto que automatiza el despliegue, escalado y gestión de aplicaciones contenerizadas. Se utiliza para manejar las complejidades de ejecutar aplicaciones en producción, garantizando alta disponibilidad, escalabilidad y una utilización eficiente de los recursos.

Explica la diferencia entre un Pod y un Contenedor en Kubernetes.

Respuesta:

Un contenedor es un paquete de software ligero y ejecutable que incluye todo lo necesario para ejecutar una aplicación. Un Pod es la unidad desplegable más pequeña en Kubernetes, que encapsula uno o más contenedores, recursos de almacenamiento, una IP de red única y opciones que rigen cómo deben ejecutarse los contenedores. Todos los contenedores dentro de un Pod comparten el mismo espacio de nombres de red y pueden comunicarse a través de localhost.

¿Qué es un Nodo en Kubernetes?

Respuesta:

Un Nodo es una máquina de trabajo en Kubernetes, que puede ser una VM o una máquina física. Cada Nodo contiene los componentes necesarios para ejecutar Pods, incluyendo el Kubelet (agente del master), Kube-proxy (proxy de red) y un runtime de contenedores (por ejemplo, Docker, containerd).

Describe los componentes principales del Plano de Control de Kubernetes (Nodo Master).

Respuesta:

El Plano de Control consta del Kube-API Server (expone la API de Kubernetes), etcd (almacén de clave-valor consistente y altamente disponible para los datos del clúster), Kube-Scheduler (observa nuevos Pods y los asigna a Nodos) y Kube-Controller-Manager (ejecuta procesos de controladores como los controladores de Nodo, Réplica, Endpoint y Cuenta de Servicio).

¿Qué es un Deployment en Kubernetes y para qué se utiliza?

Respuesta:

Un Deployment es una abstracción de alto nivel que gestiona el estado deseado de tus Pods y ReplicaSets. Proporciona actualizaciones declarativas para Pods y ReplicaSets, permitiéndote definir cuántas réplicas de una aplicación deben estar en ejecución y cómo desplegar actualizaciones o revertir a versiones anteriores.

¿Cómo gestiona Kubernetes la red para los Pods?

Respuesta:

Kubernetes asigna una dirección IP única a cada Pod. Todos los contenedores dentro de un Pod comparten esta IP y pueden comunicarse a través de localhost. Los Pods en diferentes nodos pueden comunicarse utilizando un plugin CNI (Container Network Interface), que implementa la superposición de red (network overlay). Kube-proxy gestiona las reglas de red en los nodos para permitir el descubrimiento de servicios y el balanceo de carga.

¿Qué es un Service en Kubernetes y cuáles son sus tipos?

Respuesta:

Un Service es una forma abstracta de exponer una aplicación que se ejecuta en un conjunto de Pods como un servicio de red. Proporciona una dirección IP y un nombre DNS estables para un grupo de Pods. Los tipos comunes incluyen ClusterIP (interno al clúster), NodePort (expone el servicio en un puerto estático en la IP de cada Nodo) y LoadBalancer (expone el servicio externamente utilizando un balanceador de carga del proveedor de la nube).

Explica el propósito de un ReplicaSet.

Respuesta:

Un ReplicaSet asegura que un número especificado de réplicas de Pods estén en ejecución en cualquier momento dado. Su propósito principal es mantener la estabilidad y disponibilidad de un conjunto de Pods. Aunque puedes usar ReplicaSets directamente, generalmente son gestionados por Deployments para características más avanzadas como las actualizaciones continuas (rolling updates).

¿Qué es kubectl y cuál es su función principal?

Respuesta:

kubectl es la herramienta de línea de comandos para interactuar con un clúster de Kubernetes. Permite a los usuarios ejecutar comandos contra clústeres de Kubernetes, desplegar aplicaciones, inspeccionar y gestionar recursos del clúster, y ver logs. Se comunica con el servidor de la API de Kubernetes.

¿Cuál es el rol de etcd en Kubernetes?

Respuesta:

etcd es un almacén de clave-valor distribuido, consistente y altamente disponible utilizado por Kubernetes para almacenar todos los datos del clúster. Esto incluye datos de configuración, información de estado, metadatos y el estado deseado del clúster. Actúa como la única fuente de verdad para el clúster de Kubernetes.

Temas Avanzados de Kubernetes y Arquitectura

Explica el concepto de un Operador de Kubernetes y proporciona un ejemplo de cuándo usarías uno.

Respuesta:

Un Operador de Kubernetes es un método para empaquetar, desplegar y gestionar una aplicación nativa de Kubernetes. Extiende la API de Kubernetes para crear, configurar y gestionar instancias de aplicaciones complejas. Usarías un Operador para aplicaciones con estado (stateful) como bases de datos (por ejemplo, Cassandra, MySQL) para automatizar tareas como copias de seguridad, actualizaciones y escalado.

Describe el propósito de una Definición de Recurso Personalizado (CRD) en Kubernetes.

Respuesta:

Una Definición de Recurso Personalizado (CRD) te permite definir tus propios recursos personalizados en Kubernetes, extendiendo la API de Kubernetes. Esto te permite almacenar y recuperar datos estructurados que Kubernetes puede gestionar. Las CRDs son fundamentales para construir Operadores y definir objetos específicos de la aplicación.

¿Cómo maneja el API Server de Kubernetes la autenticación y autorización de las solicitudes?

Respuesta:

El API Server maneja la autenticación a través de varios métodos como certificados de cliente, tokens de portador (bearer tokens) o tokens de cuentas de servicio. Después de la autenticación, la autorización se realiza utilizando módulos como RBAC (Role-Based Access Control), autorización de Nodos o ABAC (Attribute-Based Access Control). RBAC es el más común, definiendo roles con permisos y vinculándolos a usuarios o cuentas de servicio.

¿Cuál es la diferencia entre un DaemonSet y un Deployment en Kubernetes?

Respuesta:

Un Deployment gestiona un conjunto de pods idénticos, asegurando que un número deseado de réplicas estén en ejecución en todo el clúster, típicamente para aplicaciones sin estado (stateless). Un DaemonSet asegura que todos (o algunos) nodos ejecuten una copia de un pod, útil para servicios a nivel de clúster como recolectores de logs (por ejemplo, Fluentd) o agentes de monitorización (por ejemplo, Node Exporter) que necesitan ejecutarse en cada nodo.

Explica el concepto de Políticas de Seguridad de Pods (PSPs) y por qué están siendo deprecadas.

Respuesta:

Las Políticas de Seguridad de Pods (PSPs) eran un controlador de admisión que aplicaba estándares de seguridad a pods y contenedores. Permitían a los administradores del clúster controlar aspectos sensibles de seguridad como el modo privilegiado, el acceso a la red del host y los tipos de volúmenes. Las PSPs están siendo deprecadas en favor de la Admisión de Seguridad de Pods (PSA) y motores de políticas como OPA Gatekeeper, que ofrecen un control más flexible y granular.

¿Cómo se logra la alta disponibilidad para el plano de control de Kubernetes?

Respuesta:

La alta disponibilidad para el plano de control se logra ejecutando múltiples instancias del API Server, etcd, Controller Manager y Scheduler. etcd típicamente se ejecuta como un clúster basado en quórum (por ejemplo, 3 o 5 nodos). Se coloca un balanceador de carga delante de los API Servers para distribuir el tráfico y proporcionar failover.

¿Qué es un webhook de admisión mutador (mutating admission webhook) y cómo se puede utilizar?

Respuesta:

Un webhook de admisión mutador es una devolución de llamada HTTP que puede modificar las solicitudes al servidor de la API de Kubernetes antes de que se persistan. Puede inyectar contenedores sidecar, añadir etiquetas/anotaciones o establecer valores predeterminados para los campos. Por ejemplo, puede inyectar automáticamente un sidecar istio-proxy en los pods para la integración de service mesh.

Describe el rol de etcd en un clúster de Kubernetes.

Respuesta:

etcd sirve como el almacén de clave-valor consistente y altamente disponible de Kubernetes. Almacena todos los datos del clúster, incluyendo la configuración, el estado y los metadatos de todos los objetos de Kubernetes (pods, deployments, services, etc.). Es crítico para la operación del clúster, y su disponibilidad impacta directamente en la salud del clúster.

¿Cómo aplica Kubernetes la política de red?

Respuesta:

Las Políticas de Red de Kubernetes son especificaciones que definen cómo los grupos de pods pueden comunicarse entre sí y con puntos finales externos. Son implementadas por un plugin de red (CNI) que soporta NetworkPolicy, como Calico, Cilium o Weave Net. El plugin CNI traduce estas políticas en reglas de firewall.

¿Qué son Taints y Tolerations, y cómo se utilizan para la programación de pods?

Respuesta:

Los Taints se aplican a los nodos, marcándolos como 'no aptos' para ciertos pods a menos que esos pods tengan Tolerations coincidentes. Las Tolerations se aplican a los pods, permitiéndoles ser programados en nodos con taint. Este mecanismo se utiliza para reservar nodos para cargas de trabajo específicas (por ejemplo, nodos GPU) o para desalojar pods de nodos no saludables.

Preguntas Basadas en Escenarios y Diseño

Tus pods de aplicación se reinician frecuentemente. ¿Cómo solucionarías este problema en Kubernetes?

Respuesta:

Comenzaría revisando kubectl describe pod <nombre-del-pod> para ver eventos y estado. Luego, usaría kubectl logs <nombre-del-pod> para revisar los logs de la aplicación en busca de errores. Finalmente, inspeccionaría kubectl logs <nombre-del-pod> -p para ver los logs de instancias de contenedor anteriores y comprender la causa del fallo.

Necesitas desplegar una nueva versión de tu aplicación con cero tiempo de inactividad. ¿Cómo lograrías esto en Kubernetes?

Respuesta:

Usaría una estrategia RollingUpdate para el Deployment. Esto permite a Kubernetes reemplazar gradualmente los pods antiguos por los nuevos, asegurando que siempre haya un número mínimo de pods disponibles. Las comprobaciones de salud (readiness probes) son cruciales para asegurar que los nuevos pods estén listos antes de que se les dirija el tráfico.

Describe un escenario en el que usarías un StatefulSet en lugar de un Deployment.

Respuesta:

Usaría un StatefulSet para aplicaciones que requieren identificadores de red estables y únicos, almacenamiento persistente estable y despliegue/escalado/eliminación ordenados y limpios. Ejemplos incluyen bases de datos como PostgreSQL o sistemas distribuidos como Apache Kafka, donde cada réplica necesita su propio volumen persistente y un nombre de host predecible.

Tu clúster de Kubernetes se está quedando sin recursos (CPU/Memoria). ¿Qué pasos tomarías para diagnosticar y mitigar esto?

Respuesta:

Primero, usaría kubectl top nodes y kubectl top pods para identificar los que consumen más recursos. Luego, revisaría las solicitudes y límites de recursos en los pods para asegurar que estén configurados apropiadamente. Los pasos de mitigación incluyen optimizar el uso de recursos de la aplicación, escalar el clúster horizontalmente o ajustar las solicitudes/límites de recursos.

¿Cómo expondrías una aplicación web que se ejecuta en Kubernetes a Internet de forma segura?

Respuesta:

Usaría un Service de Kubernetes de tipo LoadBalancer o NodePort para exponer la aplicación dentro del clúster o al tráfico externo. Para un acceso seguro HTTP/HTTPS, desplegaría un controlador Ingress (por ejemplo, Nginx Ingress) y definiría recursos Ingress con terminación TLS, a menudo integrando con Cert-Manager para el aprovisionamiento automatizado de certificados.

Necesitas ejecutar un trabajo por lotes (batch job) único que procesa datos y luego sale. ¿Qué objeto de Kubernetes usarías?

Respuesta:

Usaría un objeto Job de Kubernetes. Un Job asegura que un número especificado de pods completen sus tareas con éxito. Para tareas recurrentes, usaría un CronJob, que crea objetos Job según un horario definido.

Diseña una estrategia de alta disponibilidad para un microservicio crítico en Kubernetes.

Respuesta:

Desplegaría el microservicio como un Deployment con múltiples réplicas (por ejemplo, 3 o más) distribuidas en diferentes nodos utilizando reglas de anti-afinidad. Implementaría sondas de preparación (readiness probes) y de vivacidad (liveness probes) robustas. Para la persistencia de datos, usaría una base de datos distribuida o un StatefulSet con volúmenes persistentes. Finalmente, aseguraría solicitudes/límites de recursos adecuados y escalado automático.

¿Cómo manejarías información sensible como claves de API o credenciales de bases de datos para tus aplicaciones en Kubernetes?

Respuesta:

Usaría Secrets de Kubernetes para almacenar información sensible. Estos secrets se pueden montar como archivos en los pods o exponerse como variables de entorno. Para una seguridad mejorada, me integraría con sistemas externos de gestión de secretos como HashiCorp Vault o servicios KMS del proveedor de la nube.

Tu aplicación necesita acceder a una base de datos que se ejecuta fuera del clúster de Kubernetes. ¿Cómo configurarías esto de forma segura?

Respuesta:

Crearía un Service de Kubernetes de tipo ExternalName o un Service sin cabeza (headless Service) con Endpoints para representar la base de datos externa dentro del clúster. Esto permite a los pods resolver la base de datos por un nombre de servicio de Kubernetes. Se usarían políticas de red para restringir el tráfico de salida solo a la IP y puerto de la base de datos, y las credenciales se gestionarían a través de Secrets de Kubernetes.

Observas que el tiempo de respuesta de tu aplicación aumenta bajo carga pesada. ¿Cómo escalarías tu aplicación en Kubernetes para manejar esto?

Respuesta:

Implementaría el Escalado Automático Horizontal de Pods (HPA) para el Deployment, configurado para escalar basándose en la utilización de CPU o métricas personalizadas como solicitudes por segundo. Esto añade automáticamente más réplicas de pods cuando la demanda aumenta. También me aseguraría de que el clúster subyacente tenga suficiente capacidad de nodos o implementaría el Cluster Autoscaler.

Preguntas Específicas por Rol (Desarrollador, Administrador, DevOps)

Desarrollador: ¿Cómo solucionarías un Pod que está atascado en estado 'Pending'?

Respuesta:

Primero revisaría kubectl describe pod <nombre-del-pod> para ver eventos que indiquen problemas como recursos insuficientes (CPU/memoria), problemas de afinidad/taint de nodo, o que los reclamos de volúmenes persistentes no estén enlazados. Luego, inspeccionaría las condiciones del nodo y la disponibilidad de recursos usando kubectl describe node <nombre-del-nodo>.

Desarrollador: Necesitas desplegar una nueva versión de tu aplicación. ¿Cuál es la forma más segura de hacerlo en Kubernetes para minimizar el tiempo de inactividad?

Respuesta:

Usaría una estrategia RollingUpdate para el Deployment. Esto reemplaza gradualmente los Pods antiguos por los nuevos, asegurando la disponibilidad continua. También definiría sondas de preparación (readiness probes) para asegurar que los nuevos Pods estén saludables antes de que se les dirija el tráfico.

Administrador: Un usuario informa que no puede acceder a un servicio que se ejecuta en el clúster. ¿Qué pasos tomarías para diagnosticar el problema?

Respuesta:

Comenzaría revisando kubectl describe service <nombre-del-servicio> para verificar su configuración y la preparación de los endpoints. Luego, inspeccionaría los Pods que respaldan el servicio para verificar su estado de salud (kubectl get pods -o wide) y revisaría sus logs en busca de errores de la aplicación. Las políticas de red o las reglas de firewall también podrían ser un factor.

Administrador: ¿Cómo te aseguras de que solo los usuarios autorizados puedan acceder a recursos específicos dentro de un clúster de Kubernetes?

Respuesta:

Implementaría el Control de Acceso Basado en Roles (RBAC). Esto implica definir Roles (permisos dentro de un namespace) o ClusterRoles (permisos a nivel de clúster) y luego enlazarlos a usuarios o cuentas de servicio usando RoleBindings o ClusterRoleBindings.

Administrador: Describe un escenario en el que usarías una NetworkPolicy.

Respuesta:

Usaría una NetworkPolicy para controlar el flujo de tráfico entre Pods o entre Pods y puntos finales externos. Por ejemplo, para aislar un Pod de base de datos de modo que solo Pods de aplicaciones específicas puedan conectarse a él, o para restringir el tráfico de salida de un namespace de desarrollo.

DevOps: ¿Cómo gestionas secretos (por ejemplo, claves de API, credenciales de bases de datos) de forma segura en Kubernetes?

Respuesta:

Si bien los Secrets de Kubernetes proporcionan una codificación básica, para una seguridad real, me integraría con soluciones externas de gestión de secretos como HashiCorp Vault, AWS Secrets Manager o Azure Key Vault. Estas soluciones pueden inyectar secretos directamente en los Pods o usar drivers CSI para el montaje dinámico, evitando almacenar datos sensibles directamente en Git.

DevOps: Explica el propósito de un chart de Helm y cómo beneficia a las pipelines de CI/CD.

Respuesta:

Un chart de Helm es un gestor de paquetes para Kubernetes, que agrupa todos los recursos necesarios de Kubernetes (Deployments, Services, ConfigMaps, etc.) en una única unidad versionable. En CI/CD, permite despliegues consistentes y repetibles en diferentes entornos, actualizaciones/reversiones de versión fáciles y la parametrización de configuraciones.

DevOps: ¿Cómo implementarías el despliegue continuo para una aplicación de microservicios en Kubernetes?

Respuesta:

Usaría un enfoque GitOps con una herramienta como Argo CD o Flux. Después de que el código se fusiona y prueba, una pipeline de CI construye la imagen Docker y actualiza la etiqueta de la imagen en el manifiesto de Kubernetes (por ejemplo, en un repositorio Git). El operador GitOps detecta entonces el cambio en Git y lo aplica automáticamente al clúster, asegurando la sincronización del estado deseado.

DevOps: ¿Cuáles son algunas métricas clave que monitorizarías para un clúster de Kubernetes y sus aplicaciones?

Respuesta:

Para el clúster, monitorizaría la utilización de recursos de los nodos (CPU, memoria, disco), la latencia del API server y la salud de etcd. Para las aplicaciones, las métricas clave incluyen el uso de CPU/memoria de los Pods, tasas de solicitudes, tasas de error, latencia y métricas de negocio específicas de la aplicación. Prometheus y Grafana son herramientas comunes para esto.

DevOps: Describe cómo manejarías el almacenamiento persistente para aplicaciones con estado en Kubernetes.

Respuesta:

Usaría PersistentVolumes (PVs) y PersistentVolumeClaims (PVCs). Una PVC solicita almacenamiento de un PV, que es aprovisionado por una StorageClass. Esto abstrae la infraestructura de almacenamiento subyacente, permitiendo a las aplicaciones solicitar almacenamiento sin conocer sus especificidades, y asegura la persistencia de los datos incluso si los Pods son re-programados.

Solución de Problemas y Depuración de Kubernetes

Tu pod está atascado en estado 'Pending'. ¿Cuáles son las razones comunes y cómo lo solucionarías?

Respuesta:

Las razones comunes incluyen recursos insuficientes (CPU/memoria), taints/tolerations de nodo, o problemas con volúmenes persistentes. Usaría kubectl describe pod <nombre-del-pod> para verificar eventos de fallos de planificación, solicitudes de recursos y estado de enlace de volúmenes.

Un pod está en estado 'CrashLoopBackOff'. ¿Qué indica esto y cómo lo depuras?

Respuesta:

Esto indica que el contenedor dentro del pod se está iniciando y fallando repetidamente. Primero revisaría kubectl logs <nombre-del-pod> para ver errores de la aplicación. Si los logs no son útiles, usaría kubectl describe pod <nombre-del-pod> para buscar eventos OOMKilled o fallos en las sondas de preparación/vivacidad.

¿Cómo revisas los logs de un contenedor específico dentro de un pod con múltiples contenedores?

Respuesta:

Puedes especificar el nombre del contenedor usando la bandera -c con kubectl logs. Por ejemplo: kubectl logs <nombre-del-pod> -c <nombre-del-contenedor>. Esto permite aislar los logs de un servicio en particular.

Un servicio no es accesible desde fuera del clúster. ¿Qué pasos tomarías para diagnosticar esto?

Respuesta:

Verificaría el tipo de servicio (por ejemplo, NodePort, LoadBalancer) y su IP/puerto externo. Luego, verificaría las reglas de firewall, grupos de seguridad y políticas de red. Finalmente, comprobaría si los selectores del servicio coinciden correctamente con las etiquetas de los pods y si los pods se están ejecutando y están saludables.

Sospechas que una política de red está bloqueando el tráfico a tu aplicación. ¿Cómo lo confirmarías?

Respuesta:

Usaría kubectl describe networkpolicy <nombre-de-la-politica> para entender sus reglas. Luego, revisaría las etiquetas y namespaces del pod para ver si están siendo dirigidos por alguna política. Herramientas como kube-no-trouble o netshoot dentro de un pod de depuración también pueden ayudar a probar la conectividad.

¿Cómo obtienes un shell dentro de un contenedor en ejecución para fines de depuración?

Respuesta:

Puedes usar kubectl exec -it <nombre-del-pod> -- /bin/bash (o /bin/sh si bash no está disponible). Esto te permite inspeccionar el sistema de archivos del contenedor, ejecutar comandos y diagnosticar problemas directamente dentro de su entorno.

¿Cuáles son las causas comunes de 'ImagePullBackOff' y cómo las solucionas?

Respuesta:

Las causas comunes incluyen un nombre/etiqueta de imagen incorrecto, problemas de autenticación con el registro privado o problemas de conectividad de red con el registro. Revisaría kubectl describe pod <nombre-del-pod> para ver errores de extracción de imagen y verificaría los nombres de imagen, las credenciales del registro (secrets) y el acceso a la red.

Tu aplicación está experimentando alta latencia, pero los pods parecen estar saludables. ¿Cuál podría ser el problema?

Respuesta:

Esto podría indicar contención de recursos (throttling de CPU), código de aplicación ineficiente o problemas con dependencias externas. Revisaría las métricas de utilización de recursos (CPU/memoria) de los pods, revisaría los logs de la aplicación en busca de consultas lentas e inspeccionaría la latencia de red a servicios externos.

¿Cómo depurarías un fallo en una sonda de vivacidad (liveness) o preparación (readiness)?

Respuesta:

Revisaría kubectl describe pod <nombre-del-pod> para ver los eventos de fallo de la sonda y el comando/ruta específica que se está utilizando. Luego, usaría kubectl logs <nombre-del-pod> para ver si la aplicación se está cerrando o no responde al endpoint de la sonda. Ejecutar el comando de la sonda manualmente dentro del contenedor también puede ayudar.

Un nodo está en estado 'NotReady'. ¿Cuáles son las razones típicas y cómo lo investigas?

Respuesta:

Las razones típicas incluyen que kubelet no se esté ejecutando, problemas de red que impidan la comunicación con el plano de control, o recursos insuficientes en el nodo. Me conectaría por SSH al nodo, verificaría systemctl status kubelet, revisaría los logs de kubelet (journalctl -u kubelet) y verificaría la conectividad de red con el API server.

Mejores Prácticas y Seguridad en Kubernetes

¿Cuáles son algunas de las mejores prácticas clave para asegurar clústeres de Kubernetes?

Respuesta:

Las prácticas clave incluyen implementar el Control de Acceso Basado en Roles (RBAC) con el principio de mínimo privilegio, actualizar regularmente Kubernetes y sus componentes, escanear imágenes de contenedores en busca de vulnerabilidades, segmentación de red usando Network Policies y asegurar el acceso al API server.

Explica el principio de 'mínimo privilegio' en el RBAC de Kubernetes.

Respuesta:

El mínimo privilegio significa otorgar a los usuarios y cuentas de servicio solo los permisos mínimos necesarios para realizar sus tareas. Esto minimiza el impacto potencial si una cuenta se ve comprometida, reduciendo la superficie de ataque dentro del clúster.

¿Cómo mejoran las Network Policies la seguridad en un clúster de Kubernetes?

Respuesta:

Las Network Policies definen cómo los pods pueden comunicarse entre sí y con puntos finales externos. Actúan como firewalls a nivel de pod, permitiendo la segmentación de red y aislando cargas de trabajo sensibles para prevenir comunicaciones no autorizadas.

¿Cuál es la importancia del escaneo de imágenes en una pipeline de CI/CD para despliegues en Kubernetes?

Respuesta:

El escaneo de imágenes identifica vulnerabilidades conocidas (CVEs) y configuraciones erróneas dentro de las imágenes de contenedores antes del despliegue. Integrarlo en CI/CD asegura que solo se envíen imágenes seguras y conformes a los registros y se desplieguen en el clúster, previniendo la ejecución de software vulnerable.

Describe un método común para gestionar secretos de forma segura en Kubernetes.

Respuesta:

Si bien los Secrets de Kubernetes proporcionan almacenamiento básico, están codificados en base64, no cifrados en reposo por defecto. Las mejores prácticas implican el uso de soluciones externas de gestión de secretos como HashiCorp Vault, AWS Secrets Manager o Azure Key Vault, a menudo integradas a través de drivers CSI u operadores de secretos externos, para cifrar y gestionar datos sensibles.

¿Qué son los Pod Security Standards (PSS) y por qué son importantes?

Respuesta:

Los Pod Security Standards son controles de seguridad integrados que definen diferentes niveles de aislamiento para los pods (Privileged, Baseline, Restricted). Ayudan a aplicar las mejores prácticas de seguridad al prevenir que los pods se ejecuten con configuraciones excesivamente permisivas, como acceso root o montajes de rutas de host.

¿Cómo puedes prevenir ataques de escalada de privilegios dentro de un clúster de Kubernetes?

Respuesta:

Prevenir la escalada de privilegios implica varias medidas: aplicar los Pod Security Standards, usar contenedores inmutables, limitar el acceso al host, implementar RBAC estricto y auditar regularmente las configuraciones del clúster y las actividades de los usuarios. Limitar las capacidades y prohibir los contenedores privilegiados son cruciales.

¿Cuál es el rol de un Service Mesh (por ejemplo, Istio, Linkerd) en la seguridad de Kubernetes?

Respuesta:

Un Service Mesh mejora la seguridad al proporcionar características como mTLS (mutual TLS) para comunicación cifrada entre servicios, políticas de control de acceso granulares y cifrado de tráfico. Centraliza las configuraciones de seguridad y la observabilidad para la comunicación de microservicios.

Explica el concepto de 'infraestructura inmutable' en Kubernetes.

Respuesta:

La infraestructura inmutable significa que una vez que un componente (como una imagen de contenedor o una aplicación desplegada) se construye y despliega, nunca se modifica. Cualquier cambio requiere construir una nueva imagen y reemplazar la instancia antigua, lo que mejora la consistencia, la fiabilidad y la seguridad al reducir la deriva de configuración.

¿Cómo contribuyen las cuotas de recursos (resource quotas) y los rangos de límites (limit ranges) a la estabilidad y seguridad del clúster?

Respuesta:

Las cuotas de recursos limitan la cantidad total de CPU, memoria y otros recursos que pueden ser consumidos por un namespace, previniendo el agotamiento de recursos. Los rangos de límites definen las solicitudes/límites de recursos predeterminados y máximos para los pods dentro de un namespace, asegurando que las aplicaciones no consuman recursos excesivos y mejorando la estabilidad y la equidad del clúster.

Desafíos Prácticos y de Manos a la Obra en Kubernetes

Tienes un Pod que se sigue reiniciando. ¿Cómo solucionarías este problema?

Respuesta:

Comenzaría revisando kubectl describe pod <nombre-del-pod> para ver eventos y estado. Luego, usaría kubectl logs <nombre-del-pod> para revisar los logs de la aplicación. Si es un bucle de reinicio, revisaría kubectl logs --previous <nombre-del-pod> para ver los logs del último contenedor terminado.

Un Deployment está atascado en estado pendiente. ¿Cuáles son las razones comunes y cómo las diagnosticas?

Respuesta:

Las razones comunes incluyen recursos insuficientes (CPU/memoria), taints/tolerations de nodo o problemas con selectores/afinidad de nodo. Usaría kubectl describe pod <nombre-del-pod> para ver los eventos de planificación y kubectl get events --field-selector involvedObject.kind=Node para verificar las condiciones del nodo.

¿Cómo expondrías un aplicación sin estado que se ejecuta en un Deployment al tráfico externo?

Respuesta:

Crearía un Service de tipo LoadBalancer o NodePort para exponer el Deployment. Para un enrutamiento más avanzado y terminación SSL, usaría un recurso Ingress, que requiere un Ingress Controller.

Necesitas realizar una actualización gradual (rolling update) en un Deployment sin tiempo de inactividad. ¿Cómo maneja Kubernetes esto y cuáles son las consideraciones clave?

Respuesta:

Los Deployments de Kubernetes manejan las actualizaciones graduales por defecto, creando nuevos Pods antes de terminar los antiguos basándose en la configuración de maxUnavailable y maxSurge. Las consideraciones clave incluyen sondas de preparación (readiness probes) adecuadas, asignación de recursos suficiente y probar la nueva versión antes del despliegue completo.

Describe un escenario en el que usarías un ConfigMap frente a un Secret.

Respuesta:

Usaría un ConfigMap para datos de configuración no sensibles, como variables de entorno de la aplicación o archivos de configuración. Usaría un Secret para datos sensibles, como claves de API, credenciales de bases de datos o certificados TLS, que se almacenan cifrados por defecto.

¿Cómo te aseguras de que un Pod solo se ejecute en nodos con hardware específico (por ejemplo, GPUs)?

Respuesta:

Usaría Node Selectors o Node Affinity. Los Node Selectors son más simples para coincidencias exactas (nodeSelector: {gpu: 'true'}). Node Affinity ofrece más flexibilidad con reglas requiredDuringSchedulingIgnoredDuringExecution o preferredDuringSchedulingIgnoredDuringExecution.

Un Service no está enrutando tráfico a sus Pods. ¿Qué pasos tomarías para depurar esto?

Respuesta:

Primero, revisaría kubectl describe service <nombre-del-servicio> para verificar que su selector coincida con las etiquetas de los Pods. Luego, revisaría kubectl get endpoints <nombre-del-servicio> para ver si se listan IPs de Pods. Finalmente, me aseguraría de que los Pods estén saludables y que sus sondas de preparación estén pasando.

Necesitas ejecutar una tarea única, como una migración de base de datos, dentro de tu clúster. ¿Qué recurso de Kubernetes usarías?

Respuesta:

Usaría un recurso Job de Kubernetes. Un Job crea uno o más Pods y asegura que un número especificado de ellos termine exitosamente. Para tareas programadas, usaría un CronJob.

Explica el propósito de un PersistentVolume (PV) y un PersistentVolumeClaim (PVC).

Respuesta:

Un PersistentVolume (PV) es una porción de almacenamiento en el clúster aprovisionada por un administrador. Un PersistentVolumeClaim (PVC) es una solicitud de almacenamiento por parte de un usuario. El PVC se enlaza a un PV adecuado, permitiendo a los Pods consumir almacenamiento duradero independientemente de su ciclo de vida.

¿Cómo escalarías un Deployment manualmente y automáticamente?

Respuesta:

Manualmente, usaría kubectl scale deployment <nombre-del-deployment> --replicas=<numero>. Automáticamente, usaría un Horizontal Pod Autoscaler (HPA), que escala el número de Pods en un Deployment o ReplicaSet basándose en la utilización de CPU observada u otras métricas personalizadas.

Resumen

Navegar una entrevista de Kubernetes puede ser una experiencia desafiante pero gratificante. Este documento ha proporcionado una visión general completa de preguntas comunes y respuestas perspicaces, diseñadas para equiparte con el conocimiento y la confianza necesarios para sobresalir. Recuerda, la preparación exhaustiva es primordial; comprender los conceptos centrales, las aplicaciones prácticas y los escenarios de resolución de problemas mejorará significativamente tu desempeño.

Más allá de la entrevista, el viaje con Kubernetes es de aprendizaje y adaptación continuos. El panorama evoluciona rápidamente, y mantenerse curioso, experimentar con nuevas características e interactuar con la comunidad asegurará que tus habilidades se mantengan agudas y relevantes. Abraza los desafíos, celebra tus éxitos y sigue construyendo tu experiencia en esta tecnología dinámica y esencial.