Durante el tiempo que tuve un rol de evaluador técnico, me gustaba incluir estas 10 preguntas sobre Kubernetes. Estas me permitían filtrar con mayor facilidad a los candidatos. Veamos cuáles son.
1. ¿Cuántos nodos Master debe tener como mínimo un clúster en Producción?
El Control Plane está formado por uno o más nodos. Para laboratorios, pruebas y entornos de Desarrollo, solo basta un único nodo. Para Producción, en cambio, la lógica haría pensar que mínimo deben ser dos. Y, mientras más nodos haya, será mejor, ¿cierto?
Sin embargo, etcd, el componente más importante del Control Plane, está basado en el algoritmo de consenso llamado Raft. Este requiere un número impar de nodos para evitar los puntos únicos de fallo que afecten la disponibilidad del cluster.
Por lo tanto, un cluster en Producción requiere como mínimo tres nodos Master.
2. ¿Con qué único comando veo la lista de Pods corriendo en todos los namespaces?
Esta es fácil y la respuesta es:
kubectl get pods -A¿Muy fácil? Aún no cantes victoria, pues faltan ocho para completar las 10 preguntas sobre Kubernetes que seguramente te pondrán a prueba.
3. Define qué entiendes por Ingress y la diferencia con LoadBalancer
Primero, me gusta escuchar cómo los candidatos intentan explicarlo en sus propias palabras. Suelen usar ejemplos, términos técnicos, analogías u otros. Observo también el tiempo que se toman en pensar antes de responder. Ello lo someto a mi análisis que, en términos prácticos, lo entiendo como sigue:
Ingress y LoadBalancer, ambos son tipos de Servicios de Kubernetes. Los dos permiten exponer una aplicación dentro del cluster hacia el exterior. Pero, cada una lo hace de una forma diferente, con un costo y flexibilidad distinta.
Un servicio LoadBalancer interactúa con el proveedor de Cloud donde corre (Ejm: AWS, Azure, Google Cloud). Luego, crea un recurso de tipo “Load Balancer” de nube por cada instancia del servicio LoadBalancer de Kubernetes. Obviamente, eso implica costos más altos.
Un servicio Ingress puede funcionar como única puerta de ingreso a múltiples aplicaciones dentro del cluster. Eso es posible gracias a que Ingress trabaja a nivel de capa de aplicación (capa 7). Por lo tanto, soporta el análisis y evaluación de reglas basadas en HTTP (encabezados y rutas). Esto lo hace para para servir y redireccionar a diferentes aplicaciones internas con una única IP externa.
4. ¿Qué estrategias de Deployment (despliegue) en Kubernetes conoces?
De manera nativa, Kubernetes soporta dos: Recreate y RollingUpdate. La primera consiste en eliminar todos los Pods de un Deployment y crear nuevos de inmediato. La segunda hace un recambio de Pods, creando nuevos y eliminando antiguos progresivamente. Esto lo hace de acuerdo a los valores de las opciones maxSurge y maxUnavailable.
Otras estrategias soportadas con el uso complementario de otras herramientas (Ejm: Istio) o servicios (Load Balancer, DNS) son Blue/Green y Canary.
En ese momento aprovecho en re-preguntar qué diferencia a estas dos últimas. Espero escuchar que Blue/Green genera mínima indisponibilidad al crear un nuevo entorno de Pods (con la nueva versión de la aplicación). Luego se hace un cambio o switch inmediato hacia dicho nuevo entorno. El anterior, Blue, deja de usarse y todo el tráfico pasa ahora hacia el nuevo, Green.
Por otro lado, Canary es una estrategia que también crea un nuevo entorno de la aplicación el cual convive con la anterior. En un inicio, el entorno actual, recibe el 100% de tráfico de usuarios, mientras que el nuevo entorno no recibe tráfico aún (0%). A través de incrementos progresivos, con intervalos de tiempo, el nuevo entorno va recibiendo mayor cantidad de tráfico. Esto aumenta progresivamente (5%, 10%, 20%, …) hasta llegar al 100%. Por otro lado, el entorno anterior recibe cada vez menos tráfico hasta llegar a ser nulo.
5. ¿Cómo creo un archivo nginx.conf personalizado a mis Pods?
No importa si es un archivo de nginx, la respuesta es la misma: a través del uso de configMaps.
Un configMap permite almacenar cualquier tipo de datos, ya sea para variables de entorno, texto misceláneo o archivos de configuración. Luego, se modifica el Deployment para referenciar a dicho configMap para que se monte como volumen dentro de los Pods. También, se define la ruta y nombre del archivo con el cual se visualizará en cada contenedor de los Pods.
6. Explícame algunos casos donde un Pod use más de un contenedor
Una respuesta válida es el uso de contenedores sidecar, que sirven para ejecutar algún proceso complementario y diferente del contenedor principal. Por ejemplo, para correr algún agente de monitoreo, recolección o procesamiento de logs.
Otra posibilidad es la de usos más específicos del contenedor complementario para desempeñar otras funciones. Por ejemplo, como un proxy o intermediario entre el contenedor principal y servicios exteriores al Pod. Por ejemplo, se puede usar para una especie de proxy reverso que limita el acceso hacia el contenedor principal.
Finalmente, aunque esto refiere a otro tema distinto, suelo aceptar como válida la respuesta que hace referencia a los initContainers. Estos son contenedores de corta duración que se ejecutan de manera previa al contenedor principal del Pod. Esto es con el fin de realizar tareas diversas como inicialización, preparación, configuración de dependencias, etc.
7. ¿Has creado un cluster alguna vez? ¿Cómo o con qué herramientas?
Esta pregunta me permite generar re-preguntas que muestren qué tanto sabe el candidato sobre la infraestructura y arquitectura de Kubernetes. A veces, el postulante solo tuvo experiencias manejando Deployments, pero nunca supo cómo funciona un cluster por detrás. Este tipo de preguntas me permite descubrir eso.
Aceptaba como válidas las respuestas de haber creado clusters gestionados por proveedores de Cloud. Ejemplos: EKS (Elastic Kubernetes Service), AKS (Azure Kubernetes Service), GKE (Google Kubernetes Engine). Suelen haber usado la consola Web, o herramientas de línea de comandos como eksctl para crear el cluster.
Me era grato oir que habían desplegado alguna vez un cluster usando herramientas como KOps o kubespray. Más sorprendente aún si lo hicieron directamente con kubeadm.
También aceptaba como válidas las experiencias que habían tenido como opciones como Minikube, Kind, k3s o microk8s.
8. Háblame todo lo que sabes sobre RBAC
De nuevo, pregunta abierta. Muchas veces no saben, pero me conformo con al menos oir estas palabras clave:
- Service Account
- Role, Role Binding
- ClusterRole, ClusterRole Binding
Estos son objetos comunes a la hora de gestionar Controles de Accesos Basados en Roles (Role-based Access Control) en Kubernetes. También están los Users y Groups, a los cuales también se pueden asociar Roles y ClusterRoles.
Un User se define en el campo CommonName de una solicitud CSR. Luego, esta se firma para producir un certificado digitale usado para la autenticación.
En los roles se definen verbos (get, list, watch, etc.), sobre un grupo de recursos (Pods, Secrets, Deployments, etc) y grupo de APIs. Todos ellos en conjunto forman las reglas que son parte de los Roles o ClusterRoles.
9. Define y menciona las diferencias entre Deployment, StatefulSet y daemonSet
Ya casi llegamos al final de las 10 preguntas sobre Kubernetes. Sigue leyendo…
Deployments y StatefulSets, ambos son usados para el despliegue de aplicaciones en Kubernetes.
Los Deployments se usan para aplicaciones volátiles o sin estado (stateless). Para ello, se crea un ReplicaSet que se encarga de mantener el número de Pods deseado. Si algún Pod falla o se destruye, el ReplicaSet los recrea. Cada Pod puede crearse en cualquier orden. No hay necesidad de usar nombres dedicados y persistentes para ellos. Tampoco para los volúmenes que usan. Para la aplicación es indiferente si corre en uno, dos o diez pods. Mucho menos importa los nombres y volúmenes usados.
Los StatefulSets, en cambio, se usan para aplicaciones persistentes (stateful). Su información de estado, configuraciones y datos sí debe persistir en el tiempo de forma predecible en los Pods y volúmenes. Para ello, no se crean ReplicaSets, sino que se crean individualmente uno o más Pods con nombres específicos no aleatorios. Estos Pods tienen una secuencia y orden de creación, lo mismo que para sus volúmenes usados. Sus identificadores de red también deben ser conocidos y persistentes en el tiempo.
Un DaemonSet no es para el despliegue de aplicaciones enteras, sino para correr procesos en todos los nodos del cluster. Por ejemplo, los agentes de monitoreo corren en cada nodo siendo parte de una definición de DaemonSet. También se usan para tareas misceláneas, como ejecución de scripts u otros procesos específicos.
10. ¿Supiste que Kubernetes retiró el soporte a Docker? ¿Cómo te impacta eso?
Es importante saber que el candidato está un poco enterado de las noticias tecnológicas y el impacto que puede tener en su trabajo.
Respondiendo a la pregunta, pues sí, Kubernetes soportó oficialmente a Docker solo hasta la versión 1.23. En versiones previas a la 1.24, dicho soporte se daba a través de Dockershim. Este permitía una interoperabilidad no basada en CRI (el estándar que Docker no soportaba).
Aquí espero escuchar el término Container Runtime. Actualmente, tenemos solo dos soportados por Kubernetes: containerd y cri-o. Ambos sí soportan CRI (Container Runtime Interface). Kubernetes habla de manera transparente con los Container Runtimes a través de CRI. Por lo tanto, el retiro del soporte de Docker no debería representar problema alguno para quienes operan esta plataforma. En nuestro día a día, seguiremos trabajando de la misma forma con las herramientas y APIs de siempre. Pero, de forma transparente a nosotros, habremos dejado de usar Docker para ahora usar containerd o cri-o.
Cierre
Es así que llegamos al final de esta lista de 10 preguntas sobre Kubernetes en entrevistas. ¿Cuántas de ellas tú sabías cómo responder correctamente? ¿Te han hecho otras preguntas más desafiantes sobre el tema en tus entrevistas? ¡Déjame tus comentarios y comparte!
Deja un comentario