Bienvenido a la serie de tutoriales r谩pidos de Kubernetes. Esta es una columna regular con las preguntas m谩s interesantes que recibimos en l铆nea y en nuestros entrenamientos. El experto en Kubernetes responde.
La experta de hoy es Daniele Polencic . Daniel es instructor y desarrollador de software en Learnk8s .
Si desea responder su pregunta en la pr贸xima publicaci贸n, cont谩ctenos por correo electr贸nico o en Twitter: @ learnk8s .
驴Saltaste publicaciones anteriores? B煤scalos aqu铆 .
驴C贸mo conectar cl煤steres de Kubernetes en diferentes centros de datos?
Brevemente : Kubefed v2 llegar谩 pronto , y tambi茅n le aconsejo que lea sobre Shipper y el proyecto del planificador de m煤ltiples cl煤steres .
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 grupos por equipo, regi贸n, entorno o una combinaci贸n de estos elementos.
Sus cl煤steres se pueden alojar en diferentes nubes y en un entorno local.
Pero, 驴c贸mo planificar la infraestructura para tal extensi贸n geogr谩fica?
驴Necesita crear un gran cl煤ster en m煤ltiples entornos de nube en una sola red?
驴O iniciar muchos grupos peque帽os y encontrar una forma de controlarlos y sincronizarlos?
Un cl煤ster principal
Crear un solo cl煤ster en una sola red no es tan simple.
Imagine que tiene un accidente, perdi贸 la conectividad entre los segmentos del cl煤ster.
Si tiene un servidor maestro, la mitad de los recursos no podr谩 recibir nuevos comandos, ya que no podr谩n contactar al maestro.
Y al mismo tiempo, tiene tablas de enrutamiento antiguas ( kube-proxy no puede cargar nuevas) y no hay pods adicionales (kubelet no puede solicitar actualizaciones).
Para empeorar las cosas, si Kubernetes no ve el nodo, lo marca como perdido y distribuye las vainas faltantes a los nodos existentes.
Como resultado, tienes el doble de vainas.
Si crea un servidor maestro para cada regi贸n, habr谩 problemas con el algoritmo de consenso en la base de datos etcd. ( aprox. Ed. - En realidad, 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, recibi贸 un punto de falla del cl煤ster. Pero r谩pidamente. )
etcd utiliza el algoritmo de balsa para negociar el 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 el retraso entre instancias de etcd aumenta dram谩ticamente, como es el caso con tres instancias de etcd en diferentes regiones, lleva mucho tiempo conciliar el valor y escribirlo en el disco.
Esto 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 si el controlador no es uno, sino varios, se obtiene una reacci贸n en cadena y todo el grupo comienza a funcionar muy lentamente .
etcd es tan sensible a la latencia que la documentaci贸n oficial recomienda usar SSD en lugar de discos duros normales .
Actualmente no hay buenos ejemplos de una red grande para un solo cl煤ster.
B谩sicamente, la comunidad de desarrollo y el grupo SIG-cluster est谩n tratando de descubrir c贸mo orquestar cl煤steres de la misma manera que Kubernetes organiza los contenedores.
Opci贸n 1: federaci贸n de cl煤ster con kubefed
La respuesta oficial de SIG-cluster es kubefed2, una nueva versi贸n de la federaci贸n original de clientes y operadores de kube .
Por primera vez, intentaron administrar la colecci贸n de cl煤steres como un solo objeto utilizando la herramienta de federaci贸n de kube.
El comienzo fue bueno, pero al final, la federaci贸n de kube no se hizo popular porque no era compatible con todos los recursos.
Apoy贸 entregas y servicios conjuntos, pero, por ejemplo, no StatefulSets.
Y la configuraci贸n de la federaci贸n se transmiti贸 en forma de anotaciones y no difiri贸 en flexibilidad.
Imagine c贸mo puede describir la separaci贸n de r茅plicas para cada cl煤ster en una federaci贸n utilizando solo anotaciones.
Result贸 ser un completo desastre.
SIG-cluster hizo un gran trabajo despu茅s de kubefed v1 y decidi贸 abordar el problema desde el otro lado.
En lugar de anotaciones, decidieron lanzar un controlador que est谩 instalado en los cl煤steres. Se puede configurar mediante la Definici贸n de recursos personalizados (CRD).
Para cada recurso que formar谩 parte de la federaci贸n, tiene una definici贸n CRD personalizada de tres secciones:
- definici贸n est谩ndar de un recurso, como despliegue;
- secci贸n de
placement , donde determina c贸mo se distribuir谩 el recurso en la federaci贸n; override secci贸n, donde para un recurso en particular puede anular el peso y los par谩metros desde la ubicaci贸n.
Aqu铆 hay un ejemplo de una entrega combinada 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: 5
Como puede ver, el suministro se distribuye en dos cl煤steres: cluster2 y cluster2 .
El primer cl煤ster entrega tres r茅plicas, mientras que el segundo se establece en 5.
Si necesita m谩s control sobre el n煤mero 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: 2
La estructura CRD y la API a煤n no est谩n listas, y se est谩 trabajando activamente en el repositorio oficial del proyecto.
Tenga cuidado con kubefed2, pero recuerde que todav铆a no es adecuado para el entorno de trabajo.
Obtenga m谩s informaci贸n sobre kubefed2 en el art铆culo oficial de kubefed2 en el blog de Kubernetes y en el repositorio oficial de proyectos de kubefed .
Opci贸n 2: agrupaci贸n de cl煤steres de estilo Booking.com
Los desarrolladores de Booking.com no trataron con kubefed v2, pero se les ocurri贸 Shipper, un operador para la entrega en varios cl煤steres, en varias regiones y en varias nubes.
Shipper es algo similar a kubefed2.
Ambas herramientas le permiten configurar la estrategia de implementaci贸n para varios cl煤steres (qu茅 cl煤steres se usan y cu谩ntas r茅plicas tienen).
Pero el objetivo de Shipper es reducir el riesgo de errores de entrega.
En Shipper, puede definir una serie de pasos que describen la separaci贸n de las r茅plicas entre la implementaci贸n anterior y la actual y la cantidad de tr谩fico entrante.
Cuando env铆a un recurso a un cl煤ster, el controlador Shipper implementa este cambio paso a paso en todos los cl煤steres combinados.
Y Shipper es muy limitado.
Por ejemplo, acepta gr谩ficos Helm como entrada y no admite recursos de vainilla.
En t茅rminos generales, Shipper funciona de la siguiente manera.
En lugar de la entrega est谩ndar, debe crear un recurso de aplicaci贸n que incluya el gr谩fico 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: 3
Shipper es una buena opci贸n para administrar m煤ltiples cl煤steres, pero su estrecha relaci贸n con Helm solo interfiere.
驴Qu茅 pasa si todos pasamos de Helm a kustomize o kapitan ?
Obtenga m谩s informaci贸n sobre Shipper y su filosof铆a en este comunicado de prensa oficial .
Si desea profundizar en el c贸digo, vaya al repositorio oficial del proyecto .
Opci贸n 3: uni贸n de cl煤ster "m谩gico"
Kubefed v2 y Shipper funcionan con la federaci贸n de cl煤ster, proporcionando a los cl煤steres nuevos recursos a trav茅s de definiciones de recursos personalizadas.
Pero, 驴qu茅 sucede si no desea reescribir todos los suministros, StatefulSets, DaemonSets, etc. para combinarlos?
驴C贸mo incluir un cl煤ster existente en una federaci贸n sin cambiar YAML?
multi-cluster-Scheduler es un proyecto de Admirality que maneja las cargas de trabajo de planificaci贸n en clusters.
Pero en lugar de encontrar una nueva forma de interactuar con el cl煤ster y ajustar los recursos en definiciones definidas por el usuario, el programador de cl煤steres m煤ltiples est谩 integrado en el ciclo de vida est谩ndar de Kubernetes e intercepta todas las llamadas que crean los pods.
Cada creado bajo reemplazado inmediatamente por un maniqu铆.
El programador de cl煤ster m煤ltiple utiliza enlaces web para modificar el acceso para interceptar la llamada y crear un dispositivo inactivo.
El pod de origen pasa por otro ciclo de planificaci贸n, donde despu茅s de una encuesta de toda la federaci贸n, se toma una decisi贸n sobre la colocaci贸n.
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 tuvo que escribir nuevos recursos para combinar los suministros.
Cada recurso que crea un pod est谩 autom谩ticamente listo para fusionarse.
Esto es interesante, porque de repente tiene entregas distribuidas en varias regiones, pero no lo ha notado. Sin embargo, esto es bastante arriesgado, porque aqu铆 todo se basa en la magia.
Pero si Shipper trata principalmente de mitigar los efectos de los suministros, el programador de cl煤steres m煤ltiples realiza tareas m谩s generales y probablemente sea m谩s adecuado para trabajos por lotes.
No tiene un mecanismo avanzado de suministro gradual.
Puede obtener m谩s informaci贸n sobre el programador de cl煤steres m煤ltiples en la p谩gina del repositorio oficial .
Si desea leer sobre el planificador de m煤ltiples cl煤steres en acci贸n, Admiralty tiene un caso de uso interesante con Argo : flujos de trabajo, eventos, CI y CD de Kubernetes.
Otras herramientas y soluciones
Conectar y administrar m煤ltiples cl煤steres es una tarea compleja; no existe una soluci贸n universal.
Si desea obtener m谩s informaci贸n sobre este tema, aqu铆 hay algunos recursos:
Eso es todo por hoy
隆Gracias por leer hasta el final!
Si sabe c贸mo conectar varios cl煤steres de manera m谩s eficiente, inf贸rmenos .
Agregaremos su m茅todo a los enlaces.
Un agradecimiento especial a Chris Nesbitt-Smith y Vincent De Smet (ingeniero de confiabilidad en swatmobile.io ) por leer este art铆culo y compartir informaci贸n 煤til sobre c贸mo funciona la federaci贸n.