Las 44 mejores preguntas y respuestas de la entrevista sobre Kubernetes en 2025

Preguntas básicas de la entrevista sobre Kubernetes

Empecemos ahora con las preguntas básicas de la entrevista sobre Kubernetes. Estas preguntas cubren los conocimientos básicos necesarios para comprender y trabajar con Kubernetes. 

¿Qué es un Pod en Kubernetes?

Un Pod es la unidad desplegable más pequeña en Kubernetes. Representa uno o varios contenedores que se ejecutan en un entorno compartido. Los contenedores de un Pod comparten recursos de red y almacenamiento.

Aquí tienes un sencillo archivo YAML de definición de Pod:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:1.21
    ports:
    - containerPort: 80

¿Para qué sirve kubectl?

Kubectl es la principal herramienta CLI para gestionar los recursos de Kubernetes e interactuar con el clúster. Aquí tienes algunos comandos kubectl comunes con los que deberías estar familiarizado:

kubectl get pods 				 # list all Pods
kubectl get services 			 # list all Services
kubectl logs <pod-name> 	  	 # view logs of a Pod
kubectl exec -it <pod-name> – /bin/sh # open a shell inside a Pod

¿Qué es un despliegue en Kubernetes?

Un Despliegue en Kubernetes es una abstracción de nivel superior que gestiona el ciclo de vida de los Pods. Garantiza que el número deseado de réplicas esté en funcionamiento y ofrece funciones como actualizaciones continuas, reversiones y autorreparación. 

Este es el aspecto de un simple archivo YAML de definición de Despliegue: 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

¿Qué es un Servicio Kubernetes y por qué es necesario?

Un Servicio en Kubernetes expone un grupo de Pods y permite la comunicación entre ellos y con ellos. 

Como los Pods son efímeros, sus IPs pueden cambiar, lo que significa que la aplicación que habla con los Pods también debe cambiar la dirección IP. Los servicios, por tanto, proporcionan un punto final de red estable con una dirección IP fija.

Una simple definición YAML de Servicio:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

El Servicio anterior reenvía el tráfico a los Pods que tienen la etiqueta app: my-app.

¿Qué tipos de servicios están disponibles en los Servicios Kubernetes?

Kubernetes proporciona cuatro tipos principales de Servicios, cada uno de los cuales sirve a un propósito de red diferente:

• ClusterIP (por defecto): Permite la comunicación interna de los Pods. Sólo accesible desde el clúster.
• PuertoNodo: Esto expone el Servicio en un puerto estático de cada Nodo, haciéndolo accesible desde fuera del clúster.
• LoadBalancer: Utiliza un equilibrador de carga externo del proveedor de la nube. El Servicio es entonces accesible a través de una IP pública.
• NombreExterno: Asigna un Servicio Kubernetes a un nombre de host externo. 

¿Cuál es el papel de los ConfigMaps y los secretos en Kubernetes?

ConfigMaps almacena datos de configuración no sensibles, mientras que secrets almacena datos sensibles como claves API y contraseñas.

Utilizar secretos te permite evitar introducir información secreta en el código de tu aplicación. En cambio, ConfigMaps te permitirá hacer tus aplicaciones más configurables, ya que estos valores se pueden editar fácilmente, y no necesitas persistirlos en el código de tu aplicación.

Ejemplo de definición ConfigMap YAML:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  database_url: "postgres://db.example.com"

Ejemplo de definición YAML secreta (con datos codificados en base64):

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  password: cGFzc3dvcmQ=  # "password" encoded in Base64

¿Qué son los espacios de nombres en Kubernetes?

Un Namespace es un clúster virtual dentro de un clúster Kubernetes. Ayuda a organizar las cargas de trabajo en entornos multiusuario aislando los recursos dentro de un clúster.

A continuación, puedes encontrar un breve fragmento de código que muestra cómo crear un Namespace utilizando kubectl y cómo crear y recuperar Pods en ese Namespace:

# create a namespace called “dev”
kubectl create namespace dev

# create a Pod in that namespace
kubectl run nginx --image=nginx --namespace=dev

# get Pods in that namespace
kubectl get pods --namespace=dev

¿Qué son las Etiquetas y los Selectores en Kubernetes?

Las etiquetas son pares clave/valor adjuntos a objetos (por ejemplo, Pods). Ayudan a organizar los objetos de Kubernetes. Los selectores filtran los recursos en función de las Etiquetas. 

Aquí tienes un ejemplo de Pod que tiene las etiquetas environment: production y app: nginx:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:1.21
    ports:
    - containerPort: 80

Ahora podrías utilizar el siguiente selector de etiquetas para obtener todos los Pods que tengan asignada la etiqueta environment: pod:

kubectl get pods -l environment=production

¿Qué son los Volúmenes Persistentes (PV) y las Demandas de Volumen Persistente (PVC)?

Los Volúmenes Persistentes (PV) proporcionan almacenamiento que persiste más allá de los ciclos de vida del Pod. El PV es una pieza de almacenamiento del clúster que ha sido aprovisionada por un administrador del clúster o aprovisionada dinámicamente mediante Clases de Almacenamiento.

Una Solicitud de Volumen Persistente (PVC) es una petición de almacenamiento por parte de un usuario. 

Aquí tienes un ejemplo de definición PV y PVC YAML: 

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/mnt/data"

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Preguntas de la entrevista sobre Kubernetes intermedio

Ahora que has practicado lo básico, podemos pasar a las preguntas de nivel intermedio. Comprender conceptos como redes, seguridad, gestión de recursos y resolución de problemas es esencial en este nivel.

¿Qué es la red Kubernetes y cómo funciona?

La red Kubernetes permite la comunicación entre Pods, Servicios y clientes externos. Sigue una estructura de red plana, lo que significa que, por defecto, todos los Pods pueden comunicarse entre sí.  

Los conceptos clave de red en Kubernetes incluyen

• Comunicación pod-a-pod: A cada Pod se le asigna una IP única y puede comunicarse dentro del clúster. 
• Comunicación servicio-a-pod: Los servicios proporcionan un punto final de red estable para un grupo de Pods, ya que los Pods son efímeros. A cada pod se le asigna una nueva IP cada vez que se crea.
• Controladores de entrada: Gestiona el tráfico HTTP/HTTPS externo.
• Políticas de red: Define reglas para restringir o permitir la comunicación entre Pods.

¿Qué es el Control de Acceso Basado en Roles (RBAC) en Kubernetes?

RBAC es un mecanismo de seguridad que restringe usuarios y servicios en función de sus permisos. Consta de:

• Roles y ClusterRoles: Define las acciones permitidas sobre los recursos.
• RoleBindings y ClusterRoleBindings: Asigna funciones a usuarios o cuentas de servicio.

El siguiente YAML muestra un ejemplo de rol que sólo permite el acceso de sólo lectura a los Pods:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]

Este rol pod-reader se puede vincular ahora a un usuario mediante RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
subjects:
  - kind: User
    name: dummy
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

¿Cómo funciona el autoescalado de Kubernetes?

Kubernetes proporciona tres tipos de autoescalado para optimizar el uso de los recursos:

1. Autoescalador horizontal de vainas (HPA): Ajusta el número de Pods en función del uso de CPU, memoria o métricas personalizadas.
2. Autoescalador vertical de vainas (VPA): Ajusta las peticiones de CPU y memoria de los Pods individuales.
3. Cluster Autoscaler: Ajusta el número de nodos trabajadores del clúster en función de las necesidades de recursos.

Puedes crear una HPA utilizando kubectl:

kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10

El comando anterior crea una HPA para un Despliegue con el nombre nginx e intenta mantener la utilización media de la CPU en todos los Pods al 50%, con un número mínimo de réplicas de 1 y un número máximo de réplicas de 10.

¿Cómo se depuran los Pods de Kubernetes?

Cuando los Pods fallan, Kubernetes proporciona múltiples formas de depurarlo:

• Utiliza kubectl logs para comprobar si hay errores en los registros de los contenedores.
• Utiliza kubectl describe pod para inspeccionar los eventos y los cambios de estado recientes.
• Utiliza kubectl exec para abrir un intérprete de comandos interactivo e investigar desde el interior del contenedor.
• Utiliza kubectl get pods --field-selector=status.phase=Failed para listar todos los Pods que fallan.

# get logs of a specific Pod
kubectl get logs <pod-name>

# describe the Pod and check events
kubectl describe pod <pod-name>

# open an interactive shell inside the Pod
kubectl exec -it <pod-name> – /bin/sh

# check all failing pods
kubectl get pods --field-selector=status.phase=Failed

Estos comandos ayudan a identificar errores de configuración, limitaciones de recursos o errores de aplicación.

¿Cómo se realizan las rolling updates y rollbacks en Kubernetes?

Los despliegues de Kubernetes admiten actualizaciones continuas para evitar tiempos de inactividad. Puedes realizar una actualización continua editando una Implantación o ajustando explícitamente su imagen a una nueva versión utilizando:

kubectl set image deployment/my-deployment nginx=nginx:1.21

A continuación, puedes comprobar el estado del Despliegue:

kubectl rollout status deployment my-deployment

Si quieres volver a la versión anterior, puedes ejecutar

kubectl rollout undo deployment my-deployment

¿Qué es un Ingress en Kubernetes y cómo funciona?

Un Ingress es un objeto API que gestiona el acceso externo HTTP/HTTPS a los Servicios dentro de un clúster Kubernetes.  Permite enrutar las peticiones basándose en el nombre de host y las rutas, actuando como proxy inverso para múltiples aplicaciones.

Ejemplo de definición YAML de entrada:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - host: my-app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

¿Cómo gestiona Kubernetes las solicitudes y los límites de recursos?

Kubernetes te permite establecer solicitudes y límites de recursos para Pods con el fin de garantizar una asignación justa y evitar el uso excesivo de los recursos del clúster.

• Las peticiones son la cantidad mínima de CPU y memoria que necesita un Pod. Se asignan permanentemente a un Pod. 
• Los límites son el máximo que puede utilizar un Pod. No se asignan al Pod, pero si necesita más recursos, puede crecer hasta alcanzar el límite.

Ejemplo de definición YAML Pod que establece solicitudes y límites de recursos:

apiVersion: v1
kind: Pod
metadata:
  name: resource-limited-pod
spec:
  containers:
    - name: my-container
      image: nginx
      resources:
        requests:
          memory: "256Mi"
          cpu: "250m"
        limits:
          memory: "512Mi"
          cpu: "500m"

¿Qué ocurre si un recurso Pod necesita crecer más allá de los límites asignados?

Si el consumo de memoria de un Pod supera el límite de memoria asignado, Kubernetes mata inmediatamente el contenedor con un error de memoria agotada (OOM). El contenedor se reinicia si se define una política de reinicio.

A diferencia de la memoria, si un Pod supera el límite de CPU que tiene asignado, no es eliminado. En su lugar, Kubernetes estrangula el uso de la CPU, haciendo que la aplicación se ralentice.

¿Qué son los contenedores init y cuándo debes utilizarlos?

Los contenedores init son contenedores especiales que se ejecutan antes de que comiencen los contenedores primarios. Ayudan a preparar el entorno comprobando dependencias, cargando archivos de configuración o configurando datos.

Un ejemplo podría ser un contenedor init que espera a que una base de datos esté en funcionamiento:

apiVersion: v1
kind: Pod
metadata:
  name: app-with-init
spec:
  initContainers:
    - name: wait-for-db
      image: busybox
      command: ['sh', '-c', 'until nc -z db-service 5432; do sleep 2; done']
  containers:
    - name: my-app
      image: my-app-image

¿Cómo gestiona Kubernetes las interrupciones de Pod y la alta disponibilidad?

Kubernetes garantiza una alta disponibilidad mediante Presupuestos de Interrupción de Pods (PDB), reglas antiafinidad y mecanismos de autorreparación. He aquí cómo funcionan estos mecanismos:

• Presupuesto de Disrupción Pod (PDB): Garantiza que un número mínimo de Pods permanezca disponible durante interrupciones voluntarias (por ejemplo, actualizaciones de clusters en las que haya que reducir nodos).
• Pod afinidad y antiafinidad: Controla qué Pods se pueden programar juntos o por separado.
• Selectores de nodos y Manchas/Tolerancias: Controla cómo se distribuyen las cargas de trabajo entre los Nodos.

Aquí tienes un ejemplo de definición PDB YAML que garantiza que al menos dos Pods sigan funcionando durante las interrupciones:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

Preguntas avanzadas de la entrevista sobre Kubernetes

Esta sección cubre las preguntas avanzadas de la entrevista sobre Kubernetes, centrándose en las aplicaciones con estado, la gestión multiclúster, la seguridad, la optimización del rendimiento y la resolución de problemas. Si te presentas a un puesto superior, asegúrate de consultarlas.

¿Qué son los StatefulSets y en qué se diferencian de los Despliegues?

Un StatefulSet se utiliza para aplicaciones con estado que requieren identidades de red estables, almacenamiento persistente y despliegue ordenado. A diferencia de los Despliegues, los StatefulSets garantizan que:

• Los Pods tienen identidades de red estables y únicas, donde los Pods se denominan como pod-0, pod-1 etc.
• Los pods se crean, actualizan y eliminan en orden.
• Cada Pod conserva el almacenamiento persistente a través de los reinicios. El almacenamiento persistente se define como parte de la definición YAML de StatefulSet.

¿Qué es una malla de servicios y por qué se utiliza en Kubernetes?

Una malla de servicios gestiona de servicio a servicio comunicaciónproporcionando:

• Gestión del tráfico (equilibrio de carga, despliegues canarios).
• Seguridad (encriptación mTLS entre servicios).
• Observabilidad (rastreo, métricas, registro)

Todas estas funciones están incluidas en la capa de infraestructura, por lo que no es necesario cambiar el código. 

Las soluciones populares de malla de servicios Kubernetes incluyen Istio, Linkerd y Cónsul.

¿Cómo puedes asegurar un clúster Kubernetes?

Sigue el modelo de seguridad 4C para asegurar un clúster Kubernetes:

1. Seguridad del proveedor de la nube: Utiliza roles IAM y reglas de cortafuegos.
2. Seguridad de la agrupación: Activa RBAC, los registros de auditoría y la seguridad del servidor API.
3. Seguridad de los contenedores: Escanea imágenes y utiliza usuarios no root.
4. Código de seguridad: Aplica la gestión de secretos y utiliza políticas de red.

¿Qué son los Taints y las Toleraciones en Kubernetes?

Las Manchas y Toleraciones controlan dónde se ejecutan los Pods:

• Mancha: Marcar nodos para rechazar Pods.
• Tolerancias: Permitir que los Pods ignoren ciertas Manchas.

Aquí tienes un ejemplo para contaminar un nodo sólo para que acepte cargas de trabajo específicas:

kubectl taint nodes node1 key1=value1:NoSchedule

Esto significa que ningún Pod puede programarse en node1 hasta que tenga la Tolerancia requerida.

Se añade una Tolerancia en la sección PodSpec como la siguiente:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: “value1”
    effect: "NoSchedule"

El Pod podría programarse en node1.

¿Qué son los contenedores sidecar de Kubernetes y cómo se utilizan?

Un contenedor sidecar se ejecuta junto al contenedor de la aplicación principal dentro del mismo Pod. Se utiliza habitualmente para:

• Registro y monitorización (por ejemplo, recopilando registros con Fluentd).
• Proxies de seguridad (por ejemplo, ejecutando el proxy Envoy de Istio para la malla de servicios).
• Gestión de la configuración (por ejemplo, sincronizar la configuración de las aplicaciones).

Ejemplo de contenedor sidecar para el procesamiento de registros:

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  containers:
    - name: main-app
      image: my-app
      volumeMounts:
        - mountPath: /var/log
          name: shared-logs
    - name: log-collector
      image: fluentd
      volumeMounts:
        - mountPath: /var/log
          name: shared-logs
  volumes:
    - name: shared-logs
      emptyDir: {}

El contenedor sidecar ejecuta Fluentd, que recoge los registros del contenedor principal a través de un volumen compartido.

Nombra tres causas típicas de error de Pod y cómo se pueden solucionar.

Los pods pueden atascarse en Pendiente, CrashLoopBackOffo ImagePullBackOff estados:

• Vaina atascada en Pendiente: Comprueba la disponibilidad de los nodos y los límites de recursos. Puedes consultar los eventos del Pod para obtener más información.
• CrashLoopBackOff: Investiga los registros de la aplicación y comprueba los errores de configuración.
• ImagePullBackOff: Asegúrate de que el nombre de la imagen y las credenciales de extracción son correctos. De nuevo, investiga los acontecimientos del Pod para obtener más información.

Puedes comprobar los eventos del Pod utilizando el comando describe:

kubectl describe pod <pod-name>

¿Qué es un webhook de admisión mutante de Kubernetes y cómo funciona?

Un webhook de admisión de mutaciones permite modificar en tiempo real los objetos de Kubernetes antes de aplicarlos al clúster y persistir en él. Ejecuta un controlador de admisión dinámico en Kubernetes que intercepta las peticiones de la API antes de que los objetos persistan en etcd. Puede modificar la carga útil de la solicitud inyectando, alterando o eliminando campos antes de permitir que la solicitud continúe.

Se suelen utilizar para:

• Inyectar sidecares.
• Establecer valores por defecto para Pods, Despliegues u otros recursos.
• Aplicar las mejores prácticas (por ejemplo, asignar automáticamente límites de recursos).
• Añadir configuraciones de seguridad (por ejemplo, exigir etiquetas para el seguimiento de auditorías).

¿Cómo se implementan los Despliegues de tiempo cero en Kubernetes?

Las implantaciones sin tiempo de inactividad garantizan que las actualizaciones no interrumpan el tráfico en directo. Kubernetes lo consigue utilizando:

• Actualizaciones continuas (por defecto, sustituye gradualmente los Pods antiguos por los nuevos).
• Despliegues canarios (pruebas con un subconjunto de usuarios).
• Despliegues azul-verde (cambio entre entornos de producción y de prueba).

Las sondas de preparación ayudan a Kubernetes a evitar que se envíe tráfico a Pods no preparados.

¿Qué son las Definiciones Personalizadas de Recursos (CRD) de Kubernetes y cuándo debes utilizarlas?

Una Definición Personalizada de Recursos (CRD) amplía las API de Kubernetes, permitiendo a los usuarios definir y gestionar recursos personalizados. Se utilizan para casos de uso específicos en los que la API de Kubernetes debe seguir utilizándose para gestionar estos recursos, como por ejemplo:

• Gestionar aplicaciones personalizadas (por ejemplo, modelos de aprendizaje automático).
• Habilitación de operadores Kubernetes para aplicaciones autorreparadoras.

Ejemplo de definición CRD YAML:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: shirts.stable.example.com
spec:
  group: stable.example.com
  scope: Namespaced
  names:
    plural: shirts
    singular: shirt
    kind: Shirt
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              color:
                type: string
              size:
                type: string
    selectableFields:
    - jsonPath: .spec.color
    - jsonPath: .spec.size
    additionalPrinterColumns:
    - jsonPath: .spec.color
      name: Color
      type: string
    - jsonPath: .spec.size
      name: Size
      type: string

Ahora podrías, por ejemplo, recuperar el objeto shirt utilizando kubectl:

kubectl get shirts

Descubre cómo aprovechar Docker y Kubernetes para los flujos de trabajo de aprendizaje automático eneste tutorial práctico sobre la contenedorización.

¿Qué son los operadores Kubernetes y cómo funcionan?

Un operador de Kubernetes amplía la funcionalidad de Kubernetes automatizando el despliegue, escalado y gestión de aplicaciones complejas. Se construye utilizando CRDs y controladores personalizados para manejar la lógica específica de la aplicación.

Los operadores trabajan definiendo recursos personalizados en Kubernetes y vigilando los cambios en el clúster para automatizar tareas específicas. 

Estos son los componentes clave de un operador:

• Definición personalizada de recursos (CRD): Define un nuevo recurso de la API de Kubernetes.
• Controlador personalizado: Observa el CRD y aplica la lógica de automatización en función del estado deseado.
• Bucle de conciliación: Garantiza continuamente que el estado de la aplicación coincide con el estado esperado.

Preguntas de la entrevista sobre Kubernetes para administradores

Los administradores de Kubernetes mantienen, aseguran y optimizan los clusters para cargas de trabajo de producción. Esta sección cubre las preguntas de la entrevista sobre Kubernetes, centrándose en la gestión de clústeres.

¿Cómo se hace una copia de seguridad y se restaura un clúster etcd en Kubernetes?

Etcd es el almacén clave-valor que contiene todo el estado del clúster. Las copias de seguridad periódicas son esenciales para evitar la pérdida de datos.

Puedes crear una copia de seguridad utilizando el siguiente comando:

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> \
  snapshot save <backup-file-location>

Si ahora quieres restaurar a partir de una copia de seguridad, puedes ejecutar

etcdutl --data-dir <data-dir-location> snapshot restore snapshot.db

¿Cómo actualizar de forma segura un clúster Kubernetes?

Actualizar un clúster Kubernetes es un proceso de varios pasos que requiere un tiempo de inactividad mínimo y mantiene la estabilidad del clúster. Los administradores deben seguir un enfoque estructurado para evitar problemas durante la actualización:

1. Drena y haz una copia de seguridad de etcd, antes de la actualización, para asegurarte de que puedes restaurarlo en caso de que falle la actualización.
2. Actualiza el nodo del plano de control.
3. Actualiza kubelet y kubectl en los nodos del plano de control.
4. Actualiza los nodos trabajadores uno a uno. Antes de actualizar, cada nodo trabajador debe vaciarse para evitar la interrupción de la carga de trabajo.
5. Actualiza los complementos del clúster (por ejemplo, controladores Ingress, herramientas de monitorización, ...).

¿Cómo se supervisa un clúster Kubernetes?

Los administradores de Kubernetes deben supervisar el estado de la CPU, la memoria, el disco, la red y la aplicación. Se recomiendan las siguientes herramientas para estas tareas:

• Prometheus + Grafana: Recopila y visualiza las métricas de los clústeres. Crea alertas en tiempo real para recibir notificaciones en caso de que surjan problemas.
• Loki + Fluentd: Recoge y analiza los registros.
• Panel de control de Kubernetes: Supervisión del clúster basada en la interfaz de usuario.
• Jaeger/OpenTelemetry: Rastreo distribuido.

¿Cómo asegurar un clúster Kubernetes?

La seguridad es un aspecto clave, y todo administrador debe seguir las mejores prácticas para asegurar un clúster Kubernetes:

• Activa RBAC: Restringe el acceso de los usuarios mediante Roles y RoleBindings.
• Admisión de seguridad de la vaina: Utiliza controladores de admisión para hacer cumplir las normas de seguridad Pod.
• Aplicar políticas de red: Restringir la comunicación entre Pods, ya que por defecto, todos los Pods pueden comunicarse entre sí.
• Rota regularmente los tokens y certificados API.
• Utiliza la gestión de secretos: Utiliza herramientas como Vault, AWS Secrets Manager, etc. 

Aprende cómo se implementa Kubernetes en la nube con esta guía sobre la orquestación de contenedores mediante AWS Elastic Kubernetes Service (EKS).

¿Cómo se configura el registro de Kubernetes?

El registro centralizado es necesario para la depuración y la auditoría. Dos opciones diferentes de pila de registro:

• Loki + Fluentd + Grafana (Ligero y rápido).
• Pila ELK (Elastic, Logstash, Kibana) (Escalable y de nivel empresarial).

¿Cómo se implementa la alta disponibilidad en Kubernetes?

La alta disponibilidad es esencial para evitar el tiempo de inactividad de las aplicaciones que se ejecutan en tu clúster Kubernetes. Puedes garantizar una alta disponibilidad

• Utilizar varios nodos del plano de control. Múltiples servidores API evitan el tiempo de inactividad si uno falla.
• Activar el autoescalador del clúster. Esto añade/elimina nodos automáticamente en función de la demanda.

¿Cómo se implementa la multitenencia del clúster Kubernetes?

La multitenencia es bastante importante si estás configurando Kubernetes para tu empresa. Permite que varios equipos o aplicaciones compartan un clúster Kubernetes de forma segura sin interferir entre sí.

Hay dos tipos de multiarrendamiento:

1. Multiarrendamiento suave: Utiliza Namespaces, RBAC y NetworkPolicies para aislar a nivel de espacio de nombres.
2. Multiarrendamiento duro: Utiliza clusters virtuales o planos de control separados para aislar un cluster físico (por ejemplo, KCP).

¿Cómo encriptar los secretos de Kubernetes en etcd?

Etcd almacena el estado completo del clúster, lo que significa que la información crítica se almacena allí. 

Por defecto, Kubernetesalmacena los secretos sin encriptar en etcd, lo que los hace vulnerables a las amenazas. Por lo tanto, puede ser crucial activar el cifrado de secretos en REST para que los secretos se almacenen y cifren.

Como primer paso, necesitas crear un archivo de configuración de encriptación y almacenar una clave de encriptación/desencriptación en ese archivo:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <BASE64_ENCODED_SECRET>
      - identity: {}

La configuración anterior especifica que Kubernetes utilizará el proveedor aescbc para cifrar los recursos Secretos, con un recurso a identity para los datos no cifrados.

A continuación, tienes que adaptar el archivo de configuración kube-apiserver, que normalmente se encuentra en /etc/kubernetes/manifests/kube-apiserver.yaml en un nodo del plano de control, e incluir la bandera -- encryption-provider-config que apunta al archivo de configuración de encriptación que has creado:

command:
  - kube-apiserver
  ...
  - --encryption-provider-config=/path/to/encryption-config.yaml

Guarda los cambios y reinicia el kube-apiserver para aplicar la nueva configuración.

¿Cómo se gestionan las cuotas de recursos de Kubernetes en entornos multi-tenant?

Las cuotas de recursos evitan que un único inquilino (espacio de nombres) consuma en exceso los recursos del clúster, perturbando el trabajo de otros inquilinos.

Puedes definir ResourceQuotas para los espacios de nombres con el fin de asignar una determinada cantidad de recursos a ese espacio de nombres concreto. Los usuarios de ese espacio de nombres pueden entonces crear recursos que consuman tantos recursos como se defina en la ResourceQuota de ese espacio de nombres.

Ejemplo de definición YAML de ResourceQuota:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: namespace-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    pods: "20"

Puedes comprobar la ResourceQuota de un espacio de nombres utilizando:

kubectl describe resourcequota namespace-quota -n team-a

¿Qué es CoreDNS? ¿Cómo se configura y utiliza?

CoreDNS es el proveedor de DNS por defecto para los clusters Kubernetes. Proporciona descubrimiento de servicios y permite que los Pods se comuniquen utilizando nombres DNS internos en lugar de direcciones IP.

Características de CoreDNS:

• Gestiona la resolución DNS interna (my-service.default.svc.cluster.local).
• Admite configuración DNS personalizada.
• Equilibra la carga de consultas DNS entre varios Pods.
• Permite el almacenamiento en caché para mejorar el rendimiento.

Puedes configurar CoreDNS utilizando el ConfigMap almacenado en el espacio de nombres kube-system. Puedes ver los ajustes actuales utilizando:

kubectl get configmap coredns -n kube-system -o yaml

Sólo tienes que actualizar ese ConfigMap y aplicar los cambios para adaptar la configuración CoreDNS.

Preguntas de la entrevista sobre Kubernetes basadas en escenarios y en la resolución de problemas

Los ingenieros se enfrentan regularmente a complejos retos de escalabilidad, redes, seguridad, rendimiento y resolución de problemas en entornos Kubernetes del mundo real, y los entrevistadores lo saben. Esta sección presenta preguntas de entrevista basadas en escenarios que ponen a prueba tu capacidad para resolver problemas prácticos de Kubernetes.

Depurar una aplicación Kubernetes lenta

"Tu equipo informa de que una aplicación que se ejecuta en Kubernetes se ha vuelto lenta, y los usuarios experimentan tiempos de respuesta elevados. ¿Cómo se resuelve este problema?"

Puedes abordar el problema siguiendo los siguientes pasos:

1. Comprueba la utilización de los recursos Pod. Aumenta los recursos en caso de que estén al límite.

kubectl top pods --sort-by=cpu
kubectl top pods --sort-by=memory

2. Describe el Pod lento para obtener más información. Busca estrangulamientos de recursos, recuentos de reinicios o fallos de la sonda de liveness.

kubectl describe pod <pod-name>

3. Comprueba si hay errores en los registros del contenedor. Busca tiempos de espera, errores o fallos de conexión.

kubectl logs <pod-name>

4. Comprueba la latencia de la red, ya que puede ralentizar las aplicaciones.

kubectl exec -it <pod-name> -- ping my-database
kubectl exec -it <pod-name> -- curl http://my-service

5. Verifica la salud del nodo Kubernetes y comprueba si se han agotado los recursos en los nodos.

kubectl get nodes
kubectl describe node <node-name>

Se está ejecutando un servidor web Nginx, pero la URL expuesta no consigue conectarse

"Has desplegado un servidor web Nginx en Kubernetes, y el Pod funciona correctamente, pero no se puede acceder ala aplicación a través de la URL expuesta. ¿Qué puedes hacer al respecto?"

Pasos para abordar el problema anterior:

1. Comprueba que el Pod Nginx se está ejecutando y que funciona correctamente.

kubectl get pods -o wide
kubectl describe pod nginx-web

2. Comprueba la asignación de servicios y puertos. Asegúrate de que se expone el puerto correcto y que coincide con el puerto contenedor del Pod. Comprueba que el Servicio encuentra los Pods correctos.

kubectl describe service nginx-service

3. Comprueba las políticas de red. Si una política de red bloquea el tráfico de entrada, el Servicio no será accesible.

kubectl get networkpolicies
kubectl describe networkpolicy <policy-name>

4. Verifica la configuración del DNS de entrada y externo.

kubectl describe ingress nginx-ingress

El despliegue de Kubernetes falla tras una actualización

"Has desplegado una nueva versión de tu aplicación, pero no se inicia, causando tiempo de inactividad a tus usuarios. ¿Cómo puedes solucionar el problema?"

Enfoque para abordar el problema:

1. Retrocede a la versión de trabajo anterior.

kubectl rollout undo deployment my-app

2. Comprueba el Historial de implantaciones e identifica lo que ha cambiado en la nueva versión.

kubectl rollout history deployment my-app

3. Comprueba si hay errores en los registros del nuevo Pod.

kubectl logs -l app=my-app

4. Comprueba las sondas de disponibilidad y liveness.

5. Verifica los problemas de extracción de imágenes. A veces, la nueva imagen es errónea o no está disponible.

La aplicación no puede conectarse a una base de datos externa

"Un microservicio que se ejecuta en Kubernetes no consigue conectarse a una base de datos externa, que está alojada fuera del clúster. ¿Cómo puedes solucionar el problema?"

Pasos para abordar el problema:

1. Verifica la conectividad externa desde el interior de un Pod. Comprueba si se puede acceder a la base de datos desde la red Kubernetes.

kubectl exec -it <pod-name> -- curl http://my-database.example.com:5432

2. Comprueba la resolución DNS dentro del Pod. Si falla, puede que CoreDNS esté mal configurado.

kubectl exec -it <pod-name> -- nslookup my-database.example.com

3. Comprueba si existen políticas de red que bloqueen el acceso externo, ya que pueden impedir el tráfico saliente.

kubectl get networkpolicies
kubectl describe networkpolicy <policy-name>

Los recursos del cluster están agotados, lo que provoca que los nuevos Pods permanezcan en estado pendiente

"Las nuevas vainas permanecen en el estado Pendiente. Profundizando en los pods, vemos que aparece el mensaje "0/3 nodos disponibles: CPU y memoria insuficientes". ¿Cómo se depura y resuelve el problema?".

Pasos para abordar el problema:

1. Comprueba la disponibilidad de recursos del clúster. Busca un uso elevado de CPU/memoria que impida la programación.

kubectl describe node <node-name>
kubectl top nodes

2. Comprueba qué Pods consumen más recursos. Establece recursos y límites para los Pods para asegurarte de que no consumen demasiado. También puedes imponerlo a todos los espacios de nombres del clúster.

kubectl top pods --all-namespaces

3. Reduce las cargas de trabajo no esenciales para liberar recursos.

kubectl scale deployment <deployment-name> --replicas=0

4. Aumenta los nodos disponibles para aumentar los recursos del clúster. También puedes añadir más nodos al autoescalador del clúster si se utiliza uno.

Consejos para preparar una entrevista sobre Kubernetes

A través de mi propia experiencia en entrevistas sobre Kubernetes, he aprendido que el éxito requiere algo más que memorizar conceptos. Tienes que aplicar tus conocimientos en escenarios del mundo real, solucionar problemas de forma eficaz y explicar claramente tus soluciones.

Si quieres tener éxito en las entrevistas sobre Kubernetes, sigue los siguientes consejos:

1. Domina los conceptos básicos de Kubernetes. Asegúrate de que entiendes Pods, Despliegues, Servicios, Volúmenes Persistentes, ConfigMaps, Secretos, etc.
2. Obtén experiencia práctica con Kubernetes. Cuando me preparaba para mis entrevistas, descubrí que montar mi propio clúster Minikube y desplegar microservicios me ayudaba a reforzar mis conocimientos. También puedes utilizar un servicio Kubernetes gestionado de un proveedor en la nube para practicar a escala.
3. Aprende a depurar los problemas de Kubernetes, ya que la resolución de problemas es una parte importante del trabajo con Kubernetes en el mundo real. Probablemente pasarás la mayor parte del tiempo solucionando problemas de aplicaciones en el trabajo.
• Los problemas típicos que se producen incluyen Pods atascados, fallos de red, volúmenes persistentes que no se montan correctamente y fallos de nodo.
4. Comprender las redes y el equilibrio de carga de Kubernetes. Céntrate en cómo se implementa la red, cómo se comunican los Pods, qué tipos de Servicio existen y cómo exponer aplicaciones.
5. Saber cómo escalar y optimizar las cargas de trabajo de Kubernetes. Los entrevistadores suelen preguntar sobre estrategias de ampliación y optimización de costes. Domina el HPA, el autoescalador de clústeres, las solicitudes de recursos y los límites. 
6. Comprender las mejores prácticas de seguridad de Kubernetes. Estar familiarizado con RBAC, el contexto de seguridad Pod, las políticas de red y la gestión de secretos.
7. Estudia la arquitectura y el funcionamiento interno de Kubernetes. Familiarízate con los componentes del plano de control y cómo interactúan el kubelet y el tiempo de ejecución del contenedor.

Combinando los conocimientos teóricos con la práctica, y aprendiendo de la resolución de problemas del mundo real, dominarás cualquier entrevista sobre Kubernetes.

Conclusión

Kubernetes es un sistema de orquestación de contenedores potente pero complejo. Las entrevistas para puestos relacionados con Kubernetes requieren un profundo conocimiento de la teoría y de la resolución de problemas en el mundo real. Tanto si eres un ingeniero junior que busca su primer trabajo como si eres un ingeniero senior que aspira a puestos más avanzados, la preparación siempre es clave.

No puedo insistir lo suficiente en lo importante que es la práctica. Te ayuda a encontrar problemas en tus aplicaciones más rápidamente y a confiar más en tus capacidades.

Si quieres reforzar tus fundamentos, te recomiendo encarecidamente que explores cursos como Conceptos de virtualización y contenedores para construir una base sólida, seguido de Introducción a Kubernetes para obtener experiencia práctica con Kubernetes.

¡Te deseo lo mejor en tus entrevistas!