Bienvenido a la serie de inicio rápido de Kubernetes. Esta es una columna regular con las preguntas más interesantes que recibimos en línea y en nuestras capacitaciones. Respuestas de expertos en Kubernetes.
El experto de hoy es Daniel Polenchik (). Daniel trabaja como instructor y desarrollador de software en .
Si quieres una respuesta a tu pregunta en el siguiente post, o .
¿Te perdiste publicaciones anteriores? .
¿Cómo conectar clústeres de Kubernetes en diferentes centros de datos?
En pocas palabras: , y también te aconsejo que leas sobre и .
Muy a menudo, 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, puede usar una estrategia similar y distribuir cargas de trabajo en diferentes regiones.
Puede tener uno o más clústeres por equipo, región, entorno o una combinación de estos.
Sus clústeres se pueden alojar en varias nubes y en las instalaciones.
Pero, ¿cómo planificar la infraestructura para tal extensión geográfica?
¿Necesita crear un clúster grande para varios entornos de nube en una sola red?
¿O tiene muchos clústeres pequeños y encuentra una forma de controlarlos y sincronizarlos?
Un clúster de liderazgo
Crear un clúster en una sola red no es tan fácil.
Imagine que tiene un accidente, se pierde la conectividad entre los segmentos del clúster.
Si tiene un servidor maestro, la mitad de los recursos no podrán recibir nuevos comandos porque no podrán comunicarse con el maestro.
Y al mismo tiempo tiene tablas de enrutamiento antiguas (kube-proxy no se pueden descargar nuevos) ni pods adicionales (kubelet no puede consultar actualizaciones).
Peor aún, si Kubernetes no puede ver un nodo, lo marca como huérfano y distribuye los pods faltantes a los nodos existentes.
Como resultado, tiene el doble de pods.
Si crea un servidor maestro por región, habrá problemas con el algoritmo de consenso en la base de datos etcd. (aprox. edición - De hecho, la base de datos etcd no tiene que estar ubicada en los servidores maestros. Se puede ejecutar en un grupo separado de servidores en la misma región. Sin embargo, habiendo recibido al mismo tiempo un punto de falla de un clúster. Pero rápidamente.)
usos etcd acordar un valor antes de escribirlo en el disco.
Es decir, la mayoría de las instancias deben llegar a un consenso antes de que el estado pueda escribirse en etcd.
Si la latencia entre instancias de etcd se dispara, como es el caso de tres instancias de etcd en diferentes regiones, lleva mucho tiempo acordar un valor y escribirlo en el disco.
Esto también se refleja en los controladores de Kubernetes.
El administrador del controlador necesita más tiempo para conocer el cambio y escribir la respuesta en la base de datos.
Y como el controlador no es uno, sino varios, se obtiene una reacción en cadena, y todo el grupo comienza a trabajar muy lentamente.
etcd es tan sensible a la latencia que .
Actualmente no hay buenos ejemplos de una gran red para un solo clúster.
Básicamente, la comunidad de desarrolladores y el grupo SIG-cluster están tratando de descubrir cómo organizar los clústeres de la misma manera que Kubernetes organiza los contenedores.
Opción 1: federar clústeres con kubefed
Respuesta oficial de SIG-cluster - .
Por primera vez, intentamos administrar una colección de clústeres como un solo objeto mediante la herramienta de federación kube.
El comienzo fue bueno, pero al final, la federación kube no se volvió popular porque no admitía todos los recursos.
Admitía suministros y servicios federados, pero no StatefulSets, por ejemplo.
Además, la configuración de la federación se pasaba en forma de anotaciones y no era flexible.
Imagine cómo puede describir la división de réplicas para cada clúster en una federación usando una sola anotación.
Resultó ser un completo desastre.
SIG-cluster hizo un gran trabajo después de kubefed v1 y decidió abordar el problema desde un ángulo diferente.
En lugar de anotaciones, decidieron lanzar un controlador que se instala en los clústeres. Se puede configurar mediante definiciones de recursos personalizadas (Definición de recursos personalizados, CRD).
Para cada recurso que se federará, tiene una definición de CRD personalizada en tres secciones:
- una definición estándar de un recurso, como desplegar;
- sección
placement, donde se define cómo se distribuirá el recurso en la federación; - sección
override, donde para un recurso específico puede anular el peso y los parámetros de la ubicación.
Este es un ejemplo de una entrega agrupada con secciones de ubicación y anulación.
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 puede ver, la oferta se divide en dos grupos: cluster1 и cluster2.
El primer clúster proporciona tres réplicas y el segundo tiene un valor de 5.
Si necesita más control sobre la cantidad de réplicas, kubefed2 proporciona un nuevo objeto ReplicaSchedulingPreference donde se pueden ponderar las réplicas:
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 CRD y la API aún no están listas y se está trabajando activamente en el repositorio oficial del proyecto.
Esté atento a kubefed2, pero tenga en cuenta que aún no es lo suficientemente bueno para un entorno de producción.
Más información sobre kubefed2 en en el blog de Kubernetes y .
Opción 2: agrupamiento al estilo de Booking.com
Los desarrolladores de Booking.com no trabajaron con kubefed v2, pero se les ocurrió Shipper, un operador de entrega en múltiples clústeres, múltiples regiones y múltiples nubes.
algo similar a kubefed2.
Ambas herramientas le permiten personalizar su estrategia de implementación de varios clústeres (qué clústeres se utilizan y cuántas réplicas tienen).
Sino El trabajo del remitente es reducir el riesgo de errores en la entrega.
En Shipper, puede definir una serie de pasos que describen la división de réplicas entre las implementaciones anteriores y actuales y la cantidad de tráfico entrante.
Cuando envía un recurso a un clúster, el controlador Shipper implementa de forma incremental ese cambio en todos los clústeres federados.
También Shipper es muy limitado.
Por ejemplo, toma gráficos de Helm como entrada y no admite recursos de vainilla.
En términos generales, Shipper funciona de la siguiente manera.
En lugar de una distribución estándar, debe 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 administrar varios clústeres, pero su estrecha relación con Helm solo se interpone en el camino.
¿Qué pasa si todos cambiamos de Helm a o ?
Obtenga más información sobre Shipper y su filosofía en .
Si quieres profundizar en el código, .
Opción 3: fusión de clústeres "mágica"
Kubefed v2 y Shipper funcionan 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, ¿qué sucede si no desea volver a escribir todos los suministros, StatefulSets, DaemonSets, etc. para fusionarlos?
¿Cómo incluir un clúster existente en la federación sin cambiar YAML?
, que se ocupa de la programación de cargas de trabajo en clústeres.
Pero en lugar de inventar una nueva forma de interactuar con el clúster y envolver los recursos en definiciones personalizadas, el programador de clústeres múltiples se inyecta en el ciclo de vida estándar de Kubernetes e intercepta todas las llamadas que crean pods.
Cada pod creado se reemplaza inmediatamente con un dummy.
usos del planificador de clústeres múltiples para interceptar la llamada y crear un módulo ficticio inactivo.
El pod original pasa por otro ciclo de programación donde, después de sondear a toda la federación, se toma una decisión de hospedaje.
Finalmente, el pod se entrega al clúster de destino.
Como resultado, tiene una cápsula adicional que no hace nada, solo ocupa espacio.
La ventaja es que no tiene que escribir nuevos recursos para combinar suministros.
Cada recurso que crea un pod está automáticamente listo para federarse.
Esto es interesante, porque de repente tienes suministros distribuidos en varias regiones y no te diste cuenta. Sin embargo, esto es bastante arriesgado, porque aquí todo se basa en la magia.
Pero mientras que Shipper trata principalmente de mitigar los efectos de los envíos, el programador de clústeres múltiples es más general y quizás más adecuado para trabajos por lotes.
No tiene un mecanismo de entrega gradual avanzado.
Puede encontrar más información sobre el planificador de clústeres múltiples en .
Si desea leer sobre el programador de clústeres múltiples en acción, Admiralty tiene - flujos de trabajo, eventos, CI y CD Kubernetes.
Otras herramientas y soluciones
Conectar y administrar varios clústeres es una tarea compleja y no existe una solución única para todos.
Si desea obtener más información sobre este tema, aquí hay algunos recursos:
- es una herramienta que conecta redes superpuestas de diferentes clústeres de Kubernetes.
- La cadena minorista Target utiliza .
- Intente usar IPV6 y .
- Puede usar una malla de servicios, por ejemplo .
- Cilium, un complemento de interfaz de red de contenedores, ofrece , que le permite combinar varios clústeres
Eso es todo por hoy
¡Gracias por leer hasta el final!
Si sabe cómo conectar varios clústeres de manera más eficiente, .
Agregaremos su método a los enlaces.
Un agradecimiento especial a Chris Nesbitt-Smith () y Vicente de Sme () (al ingeniero de confiabilidad en ) por leer el artículo y compartir información útil sobre cómo funciona la federación.
Fuente: habr.com