{"id":34825,"date":"2019-10-31T22:00:35","date_gmt":"2019-10-31T19:00:35","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-soedinit-klastery-kubernetes-v-raznyh-data-tsentrah\/"},"modified":"2019-10-31T22:00:35","modified_gmt":"2019-10-31T19:00:35","slug":"kak-soedinit-klastery-kubernetes-v-raznyh-data-tsentrah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-soedinit-klastery-kubernetes-v-raznyh-data-tsentrah","title":{"rendered":"C\u00f3mo conectar cl\u00fasteres de Kubernetes en diferentes centros de datos","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"C\u00f3mo
\nBienvenido a la serie de gu\u00edas r\u00e1pidas sobre Kubernetes.<\/strong> Esta es una columna regular con las preguntas m\u00e1s interesantes que recibimos en l\u00ednea y en nuestras capacitaciones. Responde un experto en Kubernetes.<\/p>\n

<\/p>\n

El experto de hoy es Daniel Polencic (Daniele Polencic<\/a><\/noindex>). Daniel trabaja como instructor y desarrollador de software en Learnk8s<\/a><\/noindex>.<\/p><\/blockquote>\n

Si deseas obtener respuesta a tu pregunta en la siguiente publicaci\u00f3n, cont\u00e1ctanos por correo electr\u00f3nico<\/a><\/noindex> o en Twitter: @learnk8s<\/a><\/noindex>.<\/p>\n

<\/p>\n

\u00bfTe perdiste las publicaciones anteriores? B\u00fascalas aqu\u00ed<\/a><\/noindex>.<\/p>\n

<\/p>\n

\u00bfC\u00f3mo conectar cl\u00fasteres de Kubernetes en diferentes centros de datos?<\/h3>\n

<\/p>\n

Resumen<\/strong>: pronto se lanzar\u00e1 Kubefed v2<\/a><\/noindex>, y tambi\u00e9n te recomiendo leer sobre Shipper<\/a><\/noindex> y el proyecto multi-cluster-scheduler<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Con frecuencia, la infraestructura se replica y distribuye en diferentes regiones, especialmente en entornos controlados.<\/p><\/blockquote>\n

Si una regi\u00f3n no est\u00e1 disponible, el tr\u00e1fico se redirige a otra para evitar interrupciones.<\/strong><\/p>\n

<\/p>\n

Con Kubernetes se puede utilizar una estrategia similar y distribuir cargas de trabajo en diferentes regiones.<\/p>\n

<\/p>\n

Puedes tener uno o varios cl\u00fasteres por equipo, regi\u00f3n, entorno o una combinaci\u00f3n de estos elementos.<\/p>\n

<\/p>\n

Tus cl\u00fasteres pueden estar alojados en diversas nubes y en un entorno local.<\/p>\n

<\/p>\n

Pero, \u00bfc\u00f3mo planificar la infraestructura para tal dispersi\u00f3n geogr\u00e1fica?
\n\u00bfEs necesario crear un gran cl\u00faster en varias nubes a trav\u00e9s de una red unificada?
\n\u00bfO establecer muchos cl\u00fasteres peque\u00f1os y encontrar una forma de controlarlos y sincronizarlos?<\/em><\/p>\n

<\/p>\n

Un cl\u00faster de control<\/h3>\n

<\/p>\n

Crear un cl\u00faster en una red unificada no es tan sencillo.<\/em><\/p>\n

<\/p>\n

Imagina que tienes una falla, se pierde la conectividad entre los segmentos del cl\u00faster.<\/p>\n

<\/p>\n

Si tienes un servidor maestro, la mitad de los recursos no podr\u00e1n recibir nuevos comandos porque no podr\u00e1n comunicarse con el maestro.<\/p>\n

<\/p>\n

Y mientras tanto tienes tus antiguas tablas de enrutamiento (kube-proxy<\/code> no puede cargar nuevas) y no hay pods adicionales (kubelet no puede solicitar actualizaciones).<\/p>\n

<\/p>\n

Lo que es a\u00fan peor, si Kubernetes no ve un nodo, lo marca como perdido y redistribuye los pods faltantes entre los nodos existentes.<\/p>\n

<\/p>\n

Como resultado, tienes el doble de pods.<\/strong><\/p>\n

<\/p>\n

Si haces un servidor maestro por cada regi\u00f3n, habr\u00e1 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\u00f3n. Sin embargo, de esta forma se obtiene un punto de falla del cl\u00faster. Pero es r\u00e1pido.<\/em>)<\/p>\n

<\/p>\n

etcd utiliza el algoritmo raft<\/a><\/noindex>, para consensuar el valor antes de escribirlo en el disco.
\nEs decir, la mayor\u00eda de las instancias deben alcanzar un consenso antes de que el estado pueda ser escrito en etcd.<\/p>\n

<\/p>\n

Si la latencia entre las instancias de etcd aumenta dr\u00e1sticamente, como en el caso de tres instancias de etcd en diferentes regiones, se necesitar\u00e1 mucho tiempo para consensuar el valor y escribirlo en el disco.
\nEsto tambi\u00e9n afecta a los controladores de Kubernetes.<\/p>\n

<\/p>\n

El controlador necesita m\u00e1s tiempo para enterarse del cambio y registrar la respuesta en la base de datos.<\/p>\n

<\/p>\n

Y dado que no hay un solo controlador, sino varios, se genera una reacci\u00f3n en cadena, y todo el cl\u00faster comienza a funcionar muy lentamente.<\/strong>.<\/p>\n

<\/p>\n

etcd es tan sensible a la latencia que en la documentaci\u00f3n oficial se recomienda utilizar SSD en lugar de discos duros convencionales.<\/a><\/noindex>.<\/p>\n

<\/p>\n

Actualmente no existen buenos ejemplos de una gran red para un solo cl\u00faster.<\/strong><\/p>\n

<\/p>\n

Principalmente, la comunidad de desarrolladores y el grupo SIG-cluster est\u00e1n tratando de entender c\u00f3mo orquestar cl\u00fasteres de la misma manera que Kubernetes orquesta contenedores.<\/p>\n

<\/p>\n

Opci\u00f3n 1: federaci\u00f3n de cl\u00fasteres con kubefed<\/h3>\n

<\/p>\n

La respuesta oficial del SIG-cluster es kubefed2, una nueva versi\u00f3n del cliente y operador de kube federation.<\/a><\/noindex>.<\/p>\n

<\/p>\n

Por primera vez, se intent\u00f3 gestionar una colecci\u00f3n de cl\u00fasteres como un \u00fanico objeto mediante la herramienta kube federation.<\/p>\n

<\/p>\n

El comienzo fue prometedor, pero al final kube federation no se volvi\u00f3 popular porque no soportaba todos los recursos.<\/p>\n

<\/p>\n

Soportaba implementaciones conjuntas y servicios, pero, por ejemplo, no StatefulSets.
\nAdem\u00e1s, la configuraci\u00f3n de la federaci\u00f3n se transmit\u00eda en forma de anotaciones y carec\u00eda de flexibilidad.<\/p>\n

<\/p>\n

Imaginen c\u00f3mo se podr\u00eda describir la segmentaci\u00f3n de r\u00e9plicas para cada cl\u00faster en la federaci\u00f3n utilizando solo anotaciones.<\/em><\/p>\n

<\/p>\n

Result\u00f3 un completo desorden.<\/strong><\/p>\n

<\/p>\n

El SIG-cluster realiz\u00f3 un gran trabajo despu\u00e9s de kubefed v1 y decidieron abordar el problema desde un \u00e1ngulo diferente.<\/p>\n

<\/p>\n

En lugar de anotaciones, decidieron lanzar un controlador que se instala en los cl\u00fasteres. Este se puede configurar mediante definiciones de recursos personalizadas (Custom Resource Definition, CRD).<\/strong><\/p>\n

<\/p>\n

Para cada recurso que formar\u00e1 parte de la federaci\u00f3n, tienes una definici\u00f3n CRD personalizada compuesta por tres secciones:<\/p>\n

<\/p>\n