Salvando las distancias: Operador autónomo 1.2 Mejoras de la red

Las versiones de Operador Autónomo anteriores a la 1.2.0 tenían una capacidad limitada para interactuar con los clientes. La plataforma de datos Couchbase solo podía ser utilizada por SDKs ubicados en el mismo clúster Kubernetes. La replicación entre centros de datos (XDCR) solo podía utilizarse dentro del mismo clúster de Kubernetes o a través de un túnel seguro. Una red privada virtual (VPN) es un ejemplo de este tipo de túnel. Además, el acceso a la interfaz de usuario (UI) tendría que realizarse con el reenvío de puertos de Kubernetes.

La versión 1.2.0 del Operador Autónomo introduce nuevas funciones de red para hacer frente a estos límites. El objetivo final es ampliar nuestra audiencia con soporte para arquitecturas de red más diversas. Tu aplicación puede ejecutarse como una función sin servidor y por lo tanto necesita hablar a través de internet con el servidor Couchbase. Este tipo de caso de uso es exactamente lo que estamos soportando.

Arquitectura de red Kubernetes

Las opciones disponibles para las redes Kubernetes son diversas. La interfaz es todo lo que proporciona Kubernetes, lo que significa que terceros proporcionan su propia implementación. El resultado es que cada solución tiene sus puntos fuertes y débiles. Las opciones de red que elijamos deben funcionar con todos los proveedores, por lo que describiremos los tipos de red comunes antes de examinar las soluciones.

Redes enrutadas

Las redes enrutadas son las más sencillas de describir en términos de Kubernetes. Los hosts pueden comunicarse entre sí porque se ejecutan dentro de la misma subred y pueden dirigirse directamente a su dirección de hardware de destino. Esto se conoce como capa 2 en red.

Los pods suelen ejecutarse en una subred separada de los hosts en los que se ejecutan. Esta subred se subdivide a su vez entre cada host.

Un mensaje de un pod en un host no tiene forma de saber cómo encontrar su pod de destino en otro host porque no existe en la misma subred. Los mensajes de una subred pueden pasar de una subred a otra a través de un enrutador. Los mensajes de un host suelen enviarse a un enrutador de una subred cuando la dirección de destino no se encuentra en una subred conectada directamente.

Enrutamiento

Los routers gestionan los mensajes de dos maneras. En el caso de subredes conectadas directamente, los mensajes pueden enviarse al puerto de red correcto y la red de capa 2 se encarga del resto. Para subredes no conectadas directamente, los mensajes pueden ser reenviados a otro router que sí tenga la subred conectada directamente. Esto se conoce como capa 3 en red.

El router gestiona esta información de enrutamiento en una tabla de enrutamiento. Una tabla de enrutamiento es simplemente una lista de asignaciones de una subred a una interfaz física o a otro enrutador en una red conectada directamente.

Un mensaje dirigido a otro pod sería captado por el host en el que se ejecuta el pod. La dirección de destino del mensaje sería desconocida, por lo que se reenviaría al enrutador. El enrutador conoce la dirección de destino en su tabla de enrutamiento, por lo que reenvía el mensaje al host correcto. Por último, el mensaje se envía al pod de destino. Los mensajes procedentes de fuera del clúster Kubernetes pueden llegar a su pod de destino simplemente enviándolos al enrutador.

Las redes enrutadas son muy sencillas. También pueden sufrir una ligera penalización de rendimiento al saltar al router y luego al host de destino. Existen soluciones más inteligentes que utilizan iBGP y reflectores de ruta para eliminar este salto adicional. El aislamiento de los pods entre sí debe hacerse con reglas de cortafuegos.

Redes superpuestas

Las redes superpuestas encapsulan los mensajes pod a pod en protocolos como GRE o VXLAN. Cada host anuncia su subred de pod. Los hosts pueden suscribirse a estos anuncios y saber a qué host enviar directamente el mensaje para llegar al pod de destino. Aunque es más rápido que enviar a un enrutador, la sobrecarga de encapsulación puede anular cualquier beneficio.

La encapsulación también permite asociar diferentes pods con diferentes redes virtuales. Esto proporciona un modelo de seguridad sólido en el que los grupos de pods pueden segregarse físicamente. Sin embargo, esto significa que aún se necesitan enrutadores para cruzar entre redes superpuestas. Estos enrutadores necesitarán sus propias reglas de cortafuegos.

Direccionar un pod desde fuera del cluster es muy difícil. Con las redes enrutadas, podemos simplemente reenviar al enrutador y éste se encargará del resto. Con las superposiciones, no disponemos de un mecanismo tan sencillo para crear un túnel hacia la superposición.

Puertos de nodo

El mecanismo común para comunicarse externamente con los pods en ambos tipos de red son los puertos de nodo de Kubernetes. Para cada pod que crea el Operador Autónomo, también creamos un servicio de puerto de nodo para él. Cada puerto que definamos para el servicio tendrá un puerto aleatorio asignado al host subyacente.

Los puertos de nodo deben ser aleatorios ya que dos pods pueden estar exponiendo el mismo número de puerto. Esto provocaría un conflicto si este puerto fuera utilizado como puerto de nodo por ambos pods. Podemos dirigirnos a un puerto en un pod específico dirigiéndonos al host subyacente y al puerto del host. El host gestionará los mensajes redirección al destino correcto.

Los puertos de nodo nos proporcionan un mecanismo genérico para dirigirnos a un pod independientemente de si estamos utilizando una red superpuesta. Como nos estamos dirigiendo al nodo subyacente, la conexión a este desde fuera de Kubernetes es simplemente un caso de enrutamiento de paquetes en la red enrutada en la que residen los nodos Kubernetes.

Establecer XDCR

Los puertos de nodo forman la base para establecer una conexión XDCR entre dos clústeres Couchbase en dos clústeres Kubernetes diferentes. Cuando se asignan puertos de nodo, el Operador Autónomo informa al servidor Couchbase. Los clientes que se conectan externamente se conectan al puerto de nodo y el servidor Couchbase responde con un mapa de direcciones IP de nodo y puertos de nodo por servicio. El cliente XDCR utiliza estos mapas para acceder a los vBuckets individuales cuando transmite documentos.

Lo único que el Operador Autónomo no puede hacer es proporcionar conectividad de capa 3 entre las dos redes de host Kubernetes. Crear un peering (VPN) entre las dos redes, añadir rutas y reglas de firewall es todo lo que necesitan la mayoría de los proveedores de nube.

Nuevas mejoras para el operador autónomo

Tenemos una base sólida, trabajando dentro de los confines del modelo de red Kubernetes. Es segura, con una VPN, pero se pueden introducir mejoras.

Acceso de clientes externos

Utilizar un túnel VPN para acceder a una red host Kubernetes remota puede ser imposible o indeseable. Esto es especialmente cierto en el caso de los servicios gestionados, en los que es posible que no tenga control sobre la red.

Para solucionar esto necesitamos colocar los pods en Internet. Las rutas de Openshift y las entradas genéricas solo funcionan para tráfico HTTP y son difíciles de configurar. En su lugar, optamos por crear servicios de balanceador de carga por pod de servidor Couchbase. Se puede admitir cualquier conexión TCP y, además, como la dirección IP del equilibrador de carga es única por pod, podemos utilizar los números de puerto predeterminados. Todos los principales proveedores de cloud proporcionan servicios de balanceador de carga.

Las conexiones XDCR basadas en puertos de nodo existentes siguen siendo compatibles y son las predeterminadas.

Acceso a interfaz de usuario externa

La interfaz de usuario, al igual que los pods individuales, ahora se puede dirigir públicamente con un servicio de equilibrador de carga. Esto hace que la gestión de tus despliegues de la plataforma de datos Couchbase sea mucho más sencilla.

Cifrado de extremo a extremo

Colocar cualquier cosa en la Internet pública no está exento de riesgos. Esto es especialmente cierto en el caso de una base de datos, por lo que exigimos el uso de TLS. Ningún puerto de texto plano puede ser expuesto. Esto mantiene sus credenciales de usuario y los datos a salvo de los fisgones.

Cuando se presenta un certificado de servidor a un cliente que se conecta, éste verificará que la dirección a la que se ha conectado es válida para ese certificado. Esto se hace con nombres alternativos. Sólo admitimos nombres alternativos comodín basados en DNS, y no basados en IP. Además, no podemos utilizar el direccionamiento basado en IP de los servicios del equilibrador de carga, ya que la dirección no es estable a lo largo de la recuperación.

Un nombre válido para un cluster podría ser *.mi-cluster.ejemplo.com. Esto es un comodín, es válido para servidor0.mi-cluster.ejemplo.com y servidor1.mi-cluster.ejemplo.com. El certificado será válido para cualquier nodo que el Operador Autónomo cree en el ciclo de vida del cluster.

Es necesario crear registros de recursos DNS que asignen los nombres DNS a las direcciones IP del equilibrador de carga para que sean visibles para el cliente. El operador autónomo anota los nombres DNS necesarios en los servicios del equilibrador de carga. Un tercero los sincroniza con un proveedor de DNS en la nube. controlador.

Ejemplo

El diagrama muestra cómo se interrelacionan todas estas características.

1. Un cliente, ya sea un SDK o un XCDR, inicializa una conexión utilizando la dirección DNS https://cb0.cb0.us-east-1.example.com:18091. Esto se resuelve con la dirección IP del equilibrador de carga en 185.64.232.18. Esta dirección DNS se crea a partir de la especificación del servicio del balanceador de carga y su dirección IP pública.
2. A continuación, el cliente abre una conexión TCP con el clúster de Couchbase. Esta conexión atraviesa Internet hasta el router del cliente.
3. A continuación, el paquete se reenvía al equilibrador de carga en 185.64.232.18.
4. A continuación, el equilibrador de carga SNAT envía el paquete al puerto del nodo correspondiente al puerto 18091 en el pod de destino. A continuación, el nodo SNAT envía el paquete al puerto 18091 en la propia cápsula.
5. Una vez establecida la conexión TCP, el cliente inicia un protocolo TLS con el servidor. El servidor devuelve su certificado al cliente. El cliente valida que el certificado es válido para el destinatario. La dirección cb0.cb0.us-east-1.example.com coincide con el nombre alternativo del tema comodín *.cb0.us-east-1.ejemplo.com. El arranque del cliente continúa como de costumbre.

Aunque no se incluye en el diagrama, vale la pena mencionar que el servidor Couchbase se refiere al pod de destino como cb0.cb0.default.svcsu nombre DNS interno. Los clientes no pueden resolver este nombre cuando reciben una asignación de los miembros del clúster a las direcciones de los miembros. El Operador rellena direcciones de miembros alternativas que son resolubles.

Los clientes deben conocer las direcciones alternativas. Los SDKs compatibles están documentados en la documentación del Operador. XDCR es compatible con las versiones 5.5.3+ y 6.0.1+ del servidor Couchbase.

Conclusión

La capacidad de direccionar públicamente una instancia del servidor Couchbase es una herramienta poderosa. Simplifica la configuración de la red. Configurar un túnel VPN entre proveedores de nube puede ser difícil o imposible, esto lo evita por completo. Simplifica el proceso de acceso a la consola UI, también permite a los clientes, incluyendo XDCR, conectarse desde cualquier parte del mundo.

Esto da lugar a nuevas y emocionantes posibilidades de integrar tus despliegues de Couchbase basados en Kubernetes con cualquier servicio externo. Estos ejemplos podrían incluir plataformas de función como servicio en las que no se tiene control sobre la arquitectura de red subyacente.

• Pruébalo: https://www.couchbase.com/downloads
• Foros de apoyo: https://www.couchbase.com/forums/c/couchbase-server/Kubernetes
• Documentación: https://docs.couchbase.com/operator/1.2/whats-new.html

Seguir leyendo

Operador autónomo 1.2.0 Deep Dive: https://www.couchbase.com/blog/deep-dive-couchbase-autonomous-operator-1-2-0