¿Qué sucede durante una falla en el plano de control de Kubernetes?

Kubernetes es el orquestador líder para distribuir instancias de contenedores en múltiples nodos físicos. Los nodos son administrados por el plano de control de Kubernetes, una colección de componentes que mantienen el estado del clúster, responden a las condiciones cambiantes y manejan las decisiones de programación.

Es fundamental comprender la función del plano de control cuando opera clústeres que necesitan una disponibilidad constante. En este artículo, aprenderá qué sucede cuando falla el plano de control para que pueda planificar con anticipación e implementar protecciones.

Índice de contenidos
  1. Comprender el plano de control
  2. ¿Qué sucede durante la falla del plano de control?
  3. ¿Qué sucede con los nodos trabajadores y los pods en ejecución?
  4. Evitar la falla del plano de control
  5. Resumen

Comprender el plano de control

El plano de control de Kubernetes es responsable de las operaciones globales de su clúster. Coordina acciones que afectan a sus nodos trabajadores. El plano de control también proporciona almacenamiento de datos etcd para el clúster, así como el servidor API con el que interactúa mediante herramientas como Kubectl.

Estas son algunas de las principales responsabilidades del plano de control:

  • kube-apiserver aloja el servidor API de Kubernetes.
  • kube-controller-manager inicia y ejecuta los controladores dentro de su clúster, lo que permite detectar y aplicar los cambios de estado solicitados por el servidor API.
  • kube-scheduler asigna Pods a los nodos trabajadores al determinar qué nodo está mejor equipado para admitir cada nuevo Pod.
  • etc. es un almacén de datos clave-valor que contiene todos los datos del clúster e información de estado de Kubernetes.

La arquitectura de Kubernetes se basa en que estos componentes estén disponibles continuamente. Trabajan juntos para crear el estado operativo normal en el que todo funciona sin problemas y su clúster cumple con las expectativas.

¿Qué sucede durante la falla del plano de control?

El plano de control no es inmune a fallas. La gran cantidad de componentes involucrados significa que las piezas individuales pueden dejar de funcionar y causar efectos colaterales en su grupo. Un componente podría fallar o el host físico que ejecuta el plano de control podría sufrir una falla de hardware.

Los efectos reales en su clúster variarán según el componente que tenga el problema. Sin embargo, una falla en el plano de control generalmente le impedirá administrar su clúster y podría evitar que las cargas de trabajo existentes reaccionen a nuevos eventos:

  • Si el servidor API falla, Kubectl, el panel de control de Kubernetes y otras herramientas de administración dejarán de funcionar.
  • Si el programador falla, los pods nuevos no se asignarán a los nodos, por lo que serán inaccesibles y se mostrarán como atascados en el estado Pendiente. Esto también afectará a los pods que deben reprogramarse porque un nodo se quedó sin recursos o se envió una solicitud de escalado.
  • Cuando el administrador del controlador falla, los cambios que aplique a su clúster no se recogerán, por lo que parecerá que sus cargas de trabajo conservan su estado anterior.

Las fallas del plano de control le impiden modificar el estado del clúster de manera efectiva. Los cambios fallarán por completo o no tendrán ningún efecto dentro del clúster.

¿Qué sucede con los nodos trabajadores y los pods en ejecución?

El plano de control es una capa de administración que se encuentra arriba y se extiende a lo largo de sus nodos de trabajo y sus Pods. El plano de control y los trabajadores son independientes entre sí. Una vez que se programó un pod para un nodo, ese nodo se vuelve responsable de adquirir la imagen correcta y ejecutar una instancia de contenedor.

Esto significa que las fallas en el plano de control no eliminarán necesariamente las cargas de trabajo que ya están en buen estado. A menudo, puede continuar accediendo a los Pods existentes, incluso cuando no puede conectarse a su clúster con Kubectl. Los usuarios no notarán necesariamente una interrupción del avión de control a corto plazo.

Los períodos más largos de tiempo de inactividad aumentan la probabilidad de que los nodos trabajadores también comiencen a enfrentar problemas. Los nodos no podrán conciliar su estado, por lo que podrían producirse incoherencias. La red también puede comenzar a romperse si el DNS no funciona y el contenido de las solicitudes almacenadas en caché expira.

Una falla puede volverse más grave si un nodo trabajador comienza a experimentar problemas mientras el plano de control está inactivo. En esta situación, los pods en el nodo pueden dejar de ejecutarse, pero el resto del clúster no se dará cuenta de lo que sucede. Será imposible reprogramar los pods a otro nodo, ya que los nodos funcionan de forma independiente en ausencia del plano de control. Esto hará que su carga de trabajo se desconecte.

Evitar la falla del plano de control

Puede defenderse contra fallas en el plano de control configurando un clúster de alta disponibilidad que replique las funciones del plano de control en varias máquinas. De la misma manera que usa Kubernetes para distribuir y escalar sus propios contenedores, puede aplicar alta disponibilidad (HA) a Kubernetes para aumentar la resiliencia.

Kubernetes ofrece dos mecanismos para configurar una implementación de plano de control de alta disponibilidad:

  1. Uso de nodos de plano de control "apilados". - Este enfoque requiere menos infraestructura y funciona con un mínimo de tres máquinas. Cada máquina ejecutará su propio plano de control que replica los datos de los demás. Un anfitrión asumirá la responsabilidad del clúster al ser designado líder. Si el líder se desconecta, los otros nodos notarán su ausencia y se elegirá un nuevo líder. Idealmente, necesita una cantidad impar de hosts, como 3, 5 o 7, para optimizar el proceso de elección.
  2. Usando un almacén de datos etcd externo. - Este enfoque es similar al modelo apilado pero con una diferencia clave. Se basa en una instancia externa de etcd que será compartida por los nodos de su plano de control. Esto puede evitar la replicación de datos desperdiciada. Debería considerar configurar manualmente la replicación del clúster etcd para que no se convierta en un punto de falla separado.

Kubernetes ahora tiene un buen soporte para clústeres con varios planos de control. Si administra su propio clúster, puede agregar otro nodo del plano de control simplemente incluyendo el --control-plane marca cuando ejecuta el kubeadm join dominio:

$ kubeadm join <cluster-control-plane-leader-ip>:6443 
    --token <cluster-join-token>
    --discovery-token-ca-cert-hash sha256:<cluster-discovery-token-ca-cert-hash>  
    --certificate-key <cluster-certificate-key> 
    --control-plane

Resumen

El plano de control de Kubernetes es responsable de mantener las operaciones a nivel de clúster. Supervisa sus nodos de trabajo, maneja las solicitudes de API y aplica acciones dentro del clúster para lograr el estado deseado.

Cuando el plano de control se cae, estas funciones no estarán disponibles, pero debería poder continuar usando los Pods existentes por un período limitado. El plano de control es lo que une los nodos para formar un grupo; sin él, los nodos se ven obligados a operar de forma independiente, sin conocimiento de los demás.

Dado que el plano de control es un único punto de falla centralizado, los clústeres de misión crítica deben replicarlo en múltiples nodos maestros para maximizar la confiabilidad. Los clústeres multimaestros distribuyen las funciones de administración de clústeres de manera similar a cómo los nodos trabajadores hacen que sus contenedores estén altamente disponibles. Aunque pueden ser más complicados de configurar, la redundancia adicional vale la pena. También se ofrece un plano de control de alta disponibilidad como una característica de las ofertas de Kubernetes administrados de muchos proveedores de la nube.

Descubre más contenido

Subir Change privacy settings