Bienvenido a la serie de guías rápidas sobre Kubernetes. Esta es una columna regular con las preguntas más interesantes que recibimos en línea y en nuestras capacitaciones. Responde un experto en Kubernetes.
El experto de hoy es Daniel Polencic (). Daniel trabaja como instructor y desarrollador de software en .
Si deseas obtener respuesta a tu pregunta en la siguiente publicación, o en .
¿Te perdiste las publicaciones anteriores? .
¿Cómo conectar clústeres de Kubernetes en diferentes centros de datos?
Resumen: , y también te recomiendo leer sobre y .
Con frecuencia, la infraestructura se replica y distribuye en diferentes regiones, especialmente en entornos controlados.
Si una región no está disponible, el tráfico se redirige a otra para evitar interrupciones.
Con Kubernetes se puede utilizar una estrategia similar y distribuir cargas de trabajo en diferentes regiones.
Puedes tener uno o varios clústeres por equipo, región, entorno o una combinación de estos elementos.
Tus clústeres pueden estar alojados en diversas nubes y en un entorno local.
Pero, ¿cómo planificar la infraestructura para tal dispersión geográfica?
¿Es necesario crear un gran clúster en varias nubes a través de una red unificada?
¿O establecer muchos clústeres pequeños y encontrar una forma de controlarlos y sincronizarlos?
Un clúster de control
Crear un clúster en una red unificada no es tan sencillo.
Imagina que tienes una falla, se pierde la conectividad entre los segmentos del clúster.
Si tienes un servidor maestro, la mitad de los recursos no podrán recibir nuevos comandos porque no podrán comunicarse con el maestro.
Y mientras tanto tienes tus antiguas tablas de enrutamiento (kube-proxy no puede cargar nuevas) y no hay pods adicionales (kubelet no puede solicitar actualizaciones).
Lo que es aún peor, si Kubernetes no ve un nodo, lo marca como perdido y redistribuye los pods faltantes entre los nodos existentes.
Como resultado, tienes el doble de pods.
Si haces un servidor maestro por cada región, habrá problemas con el algoritmo de consenso en la base de datos etcd. (Nota del editor: en realidad, la base de datos etcd no necesariamente tiene que estar en los servidores maestros. Se puede ejecutar en un grupo separado de servidores en una misma región. Sin embargo, de esta forma se obtiene un punto de falla del clúster. Pero es rápido.)
etcd utiliza , para consensuar el valor antes de escribirlo en el disco.
Es decir, la mayoría de las instancias deben alcanzar un consenso antes de que el estado pueda ser escrito en etcd.
Si la latencia entre las instancias de etcd aumenta drásticamente, como en el caso de tres instancias de etcd en diferentes regiones, se necesitará mucho tiempo para consensuar el valor y escribirlo en el disco.
Esto también afecta a los controladores de Kubernetes.
El controlador necesita más tiempo para enterarse del cambio y registrar la respuesta en la base de datos.
Y dado que no hay un solo controlador, sino varios, se genera una reacción en cadena, y todo el clúster comienza a funcionar muy lentamente..
etcd es tan sensible a la latencia que .
Actualmente no existen buenos ejemplos de una gran red para un solo clúster.
Principalmente, la comunidad de desarrolladores y el grupo SIG-cluster están tratando de entender cómo orquestar clústeres de la misma manera que Kubernetes orquesta contenedores.
Opción 1: federación de clústeres con kubefed
La respuesta oficial del SIG-cluster es .
Por primera vez, se intentó gestionar una colección de clústeres como un único objeto mediante la herramienta kube federation.
El comienzo fue prometedor, pero al final kube federation no se volvió popular porque no soportaba todos los recursos.
Soportaba implementaciones conjuntas y servicios, pero, por ejemplo, no StatefulSets.
Además, la configuración de la federación se transmitía en forma de anotaciones y carecía de flexibilidad.
Imaginen cómo se podría describir la segmentación de réplicas para cada clúster en la federación utilizando solo anotaciones.
Resultó un completo desorden.
El SIG-cluster realizó un gran trabajo después de kubefed v1 y decidieron abordar el problema desde un ángulo diferente.
En lugar de anotaciones, decidieron lanzar un controlador que se instala en los clústeres. Este se puede configurar mediante definiciones de recursos personalizadas (Custom Resource Definition, CRD).
Para cada recurso que formará parte de la federación, tienes una definición CRD personalizada compuesta por tres secciones:
- una definición de recurso estándar, como un despliegue;
- sección
placement, donde defines cómo se distribuirá el recurso en la federación; - sección
override, donde se pueden sobrescribir el peso y los parámetros del placement para un recurso específico.
Aquí tienes un ejemplo de una entrega combinada con las secciones placement y override.
apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
name: test-deployment
namespace: test-namespace
spec:
template:
metadata:
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
placement:
clusterNames:
- cluster2
- cluster1
overrides:
- clusterName: cluster2
clusterOverrides:
- path: spec.replicas
value: 5Como ves, la entrega se distribuye entre dos clústeres: cluster1 y cluster2.
El primer clúster aporta tres réplicas, mientras que al segundo se le ha asignado un valor de 5.
Si necesitas más control sobre la cantidad de réplicas, kubefed2 proporciona un nuevo objeto ReplicaSchedulingPreference, donde las réplicas se pueden distribuir por peso:
apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
name: test-deployment
namespace: test-ns
spec:
targetKind: FederatedDeployment
totalReplicas: 9
clusters:
A:
weight: 1
B:
weight: 2La estructura del CRD y la API aún no están completamente listas, y se está trabajando activamente en el repositorio oficial del proyecto.
Sigue el desarrollo de kubefed2, pero ten en cuenta que aún no es adecuado para entornos de producción.
Obtén más información sobre kubefed2 en en el blog de Kubernetes y en .
Opción 2: integración de clústeres al estilo Booking.com
Los desarrolladores de Booking.com no trabajaron en kubefed v2, pero crearon Shipper, un operador para la entrega en múltiples clústeres, en varias regiones y en varias nubes.
es algo similar a kubefed2.
Ambas herramientas permiten configurar la estrategia de despliegue en múltiples clústeres (qué clústeres se utilizan y cuántas réplicas tienen).
Pero la misión de Shipper es reducir el riesgo de errores en la entrega.
En Shipper, se puede definir una serie de pasos que describen la división de réplicas entre el despliegue anterior y el actual y el volumen de tráfico entrante.
Cuando envías un recurso a un clúster, el controlador de Shipper despliega este cambio paso a paso en todos los clústeres combinados.
Además, Shipper es muy limitado.
Por ejemplo, acepta gráficos de Helm como entrada y no soporta recursos vanilla.
En términos generales, Shipper funciona de la siguiente manera.
En lugar de la entrega estándar, debes crear un recurso de aplicación que incluya un gráfico de Helm:
apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
name: super-server
spec:
revisionHistoryLimit: 3
template:
chart:
name: nginx
repoUrl: https://storage.googleapis.com/shipper-demo
version: 0.0.1
clusterRequirements:
regions:
- name: local
strategy:
steps:
- capacity:
contender: 1
incumbent: 100
name: staging
traffic:
contender: 0
incumbent: 100
- capacity:
contender: 100
incumbent: 0
name: full on
traffic:
contender: 100
incumbent: 0
values:
replicaCount: 3Shipper es una buena opción para gestionar múltiples clústeres, pero su estrecha relación con Helm solo entorpece.
¿Y si todos cambiamos de Helm a o ?
Descubre más sobre Shipper y su filosofía en .
Si quieres profundizar en el código, .
Opción 3: la 'fusión mágica' de clústeres.
Kubefed v2 y Shipper trabajan con la federación de clústeres, proporcionando nuevos recursos a los clústeres a través de una definición de recursos personalizada.
Pero supongamos que no quieres reescribir todas las entregas, StatefulSets, DaemonSets, etc. para la fusión.
¿Cómo incluir un clúster existente en la federación sin cambiar el YAML?
, que se ocupa de las cargas de trabajo de programación en los clústeres.
Pero en lugar de idear una nueva forma de interactuar con el clúster y envolver los recursos en definiciones personalizadas, multi-cluster-scheduler se integra en el ciclo de vida estándar de Kubernetes y captura todas las llamadas que crean pods.
Cada pod creado se reemplaza inmediatamente por un marcador.
multi-cluster-scheduler utiliza , para interceptar la llamada y crear un pod vacío inactivo.
El pod original pasa por otro ciclo de programación, donde después de consultar toda la federación, se toma la decisión sobre su ubicación.
Finalmente, el pod se entrega al clúster de destino.
Al final, tienes un pod adicional que no hace nada, simplemente ocupa espacio.
La ventaja es que no tuviste que escribir nuevos recursos para fusionar las entregas.
Cada recurso que crea un pod está automáticamente listo para la fusión.
Es interesante, ya que de repente tienes entregas distribuidas en varias regiones y ni siquiera te has dado cuenta. Sin embargo, esto es bastante arriesgado, ya que aquí todo se basa en la magia.
Pero si Shipper intenta, principalmente, mitigar las consecuencias de las entregas, el multi-cluster-scheduler realiza tareas más generales y, posiblemente, es más adecuado para trabajos por lotes.
No tiene un mecanismo avanzado de entregas graduales.
Puedes aprender más sobre el multi-cluster-scheduler en .
Si deseas leer sobre el multi-cluster-scheduler en acción, Admiralty tiene un — flujos de trabajo, eventos, CI y CD de Kubernetes.
Otros herramientas y soluciones
Conectar varios clústeres y gestionarlos es una tarea compleja, no existe una solución universal.
Si deseas explorar este tema con más detalle, aquí tienes algunos recursos:
- — una herramienta que conecta redes overlay de diferentes clústeres de Kubernetes.
- La red minorista Target utiliza .
- Intenta usar IPV6 y .
- Puedes usar service mesh, como .
- Cilium, un complemento de red de contenedores, ofrece , que permite combinar varios clústeres.
Eso es todo por hoy.
¡Gracias por leer hasta el final!
Si conoces una forma más efectiva de conectar varios clústeres, .
Agregaremos tu método a los enlaces.
Un agradecimiento especial a Chris Nesbitt-Smith () y Vincent De Smet () (ingeniero de fiabilidad en ) por leer el artículo y compartir información útil sobre cómo funciona la federación.
Fuente: habr.com
