{"id":6804,"date":"2019-05-07T10:54:05","date_gmt":"2019-05-07T17:54:05","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=6804"},"modified":"2025-06-13T21:33:45","modified_gmt":"2025-06-14T04:33:45","slug":"autonomous-operator-1-2-0-networking","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/autonomous-operator-1-2-0-networking\/","title":{"rendered":"Salvando las distancias: Operador aut\u00f3nomo 1.2 Mejoras de la red"},"content":{"rendered":"

Las versiones de Operador Aut\u00f3nomo anteriores a la 1.2.0 ten\u00edan una capacidad limitada para interactuar con los clientes. La plataforma de datos Couchbase solo pod\u00eda ser utilizada por SDKs ubicados en el mismo cl\u00faster Kubernetes. La replicaci\u00f3n entre centros de datos (XDCR) solo pod\u00eda utilizarse dentro del mismo cl\u00faster de Kubernetes o a trav\u00e9s de un t\u00fanel seguro. Una red privada virtual (VPN) es un ejemplo de este tipo de t\u00fanel. Adem\u00e1s, el acceso a la interfaz de usuario (UI) tendr\u00eda que realizarse con el reenv\u00edo de puertos de Kubernetes.<\/p>\n

La versi\u00f3n 1.2.0 del Operador Aut\u00f3nomo introduce nuevas funciones de red para hacer frente a estos l\u00edmites. El objetivo final es ampliar nuestra audiencia con soporte para arquitecturas de red m\u00e1s diversas. Tu aplicaci\u00f3n puede ejecutarse como una funci\u00f3n sin servidor y por lo tanto necesita hablar a trav\u00e9s de internet con el servidor Couchbase. Este tipo de caso de uso es exactamente lo que estamos soportando.<\/p>\n

Arquitectura de red Kubernetes<\/h3>\n

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\u00f3n. El resultado es que cada soluci\u00f3n tiene sus puntos fuertes y d\u00e9biles. 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.<\/p>\n

Redes enrutadas<\/h3>\n

Las redes enrutadas son las m\u00e1s sencillas de describir en t\u00e9rminos de Kubernetes. Los hosts pueden comunicarse entre s\u00ed porque se ejecutan dentro de la misma subred y pueden dirigirse directamente a su direcci\u00f3n de hardware de destino. Esto se conoce como capa 2<\/a> en red.<\/p>\n

\"Layer<\/p>\n

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.<\/p>\n

Un mensaje de un pod en un host no tiene forma de saber c\u00f3mo 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\u00e9s de un enrutador. Los mensajes de un host suelen enviarse a un enrutador de una subred cuando la direcci\u00f3n de destino no se encuentra en una subred conectada directamente.<\/p>\n

Enrutamiento<\/h3>\n

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\u00ed tenga la subred conectada directamente. Esto se conoce como capa 3<\/a> en red.<\/p>\n

\"Layer<\/p>\n

El router gestiona esta informaci\u00f3n de enrutamiento en una tabla de enrutamiento. Una tabla de enrutamiento es simplemente una lista de asignaciones de una subred a una interfaz f\u00edsica o a otro enrutador en una red conectada directamente.<\/p>\n

Un mensaje dirigido a otro pod ser\u00eda captado por el host en el que se ejecuta el pod. La direcci\u00f3n de destino del mensaje ser\u00eda desconocida, por lo que se reenviar\u00eda al enrutador. El enrutador conoce la direcci\u00f3n de destino en su tabla de enrutamiento, por lo que reenv\u00eda el mensaje al host correcto. Por \u00faltimo, el mensaje se env\u00eda al pod de destino. Los mensajes procedentes de fuera del cl\u00faster Kubernetes pueden llegar a su pod de destino simplemente envi\u00e1ndolos al enrutador.<\/p>\n

Las redes enrutadas son muy sencillas. Tambi\u00e9n pueden sufrir una ligera penalizaci\u00f3n de rendimiento al saltar al router y luego al host de destino. Existen soluciones m\u00e1s inteligentes que utilizan iBGP<\/a> y reflectores de ruta<\/a> para eliminar este salto adicional. El aislamiento de los pods entre s\u00ed debe hacerse con reglas de cortafuegos.<\/p>\n

Redes superpuestas<\/h3>\n

Las redes superpuestas encapsulan los mensajes pod a pod en protocolos como GRE<\/a> o VXLAN<\/a>. Cada host anuncia su subred de pod. Los hosts pueden suscribirse a estos anuncios y saber a qu\u00e9 host enviar directamente el mensaje para llegar al pod de destino. Aunque es m\u00e1s r\u00e1pido que enviar a un enrutador, la sobrecarga de encapsulaci\u00f3n puede anular cualquier beneficio.<\/p>\n

La encapsulaci\u00f3n tambi\u00e9n permite asociar diferentes pods con diferentes redes virtuales<\/a>. Esto proporciona un modelo de seguridad s\u00f3lido en el que los grupos de pods pueden segregarse f\u00edsicamente. Sin embargo, esto significa que a\u00fan se necesitan enrutadores para cruzar entre redes superpuestas. Estos enrutadores necesitar\u00e1n sus propias reglas de cortafuegos.<\/p>\n

Direccionar un pod desde fuera del cluster es muy dif\u00edcil. Con las redes enrutadas, podemos simplemente reenviar al enrutador y \u00e9ste se encargar\u00e1 del resto. Con las superposiciones, no disponemos de un mecanismo tan sencillo para crear un t\u00fanel hacia la superposici\u00f3n.<\/p>\n

Puertos de nodo<\/h3>\n

El mecanismo com\u00fan 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\u00f3nomo, tambi\u00e9n creamos un servicio de puerto de nodo para \u00e9l. Cada puerto que definamos para el servicio tendr\u00e1 un puerto aleatorio asignado al host subyacente.<\/p>\n

Los puertos de nodo deben ser aleatorios ya que dos pods pueden estar exponiendo el mismo n\u00famero de puerto. Esto provocar\u00eda un conflicto si este puerto fuera utilizado como puerto de nodo por ambos pods. Podemos dirigirnos a un puerto en un pod espec\u00edfico dirigi\u00e9ndonos al host subyacente y al puerto del host. El host gestionar\u00e1 los mensajes redirecci\u00f3n<\/a> al destino correcto.<\/p>\n

Los puertos de nodo nos proporcionan un mecanismo gen\u00e9rico para dirigirnos a un pod independientemente de si estamos utilizando una red superpuesta. Como nos estamos dirigiendo al nodo subyacente, la conexi\u00f3n 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.<\/p>\n

Establecer XDCR<\/h3>\n

Los puertos de nodo forman la base para establecer una conexi\u00f3n XDCR entre dos cl\u00fasteres Couchbase en dos cl\u00fasteres Kubernetes diferentes. Cuando se asignan puertos de nodo, el Operador Aut\u00f3nomo 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.<\/p>\n

Lo \u00fanico que el Operador Aut\u00f3nomo 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\u00f1adir rutas y reglas de firewall es todo lo que necesitan la mayor\u00eda de los proveedores de nube.<\/p>\n

\"IP<\/p>\n

Nuevas mejoras para el operador aut\u00f3nomo<\/h3>\n

Tenemos una base s\u00f3lida, trabajando dentro de los confines del modelo de red Kubernetes. Es segura, con una VPN, pero se pueden introducir mejoras.<\/p>\n

Acceso de clientes externos<\/h3>\n

Utilizar un t\u00fanel 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.<\/p>\n

Para solucionar esto necesitamos colocar los pods en Internet. Las rutas de Openshift y las entradas gen\u00e9ricas solo funcionan para tr\u00e1fico HTTP y son dif\u00edciles de configurar. En su lugar, optamos por crear servicios de balanceador de carga por pod de servidor Couchbase. Se puede admitir cualquier conexi\u00f3n TCP y, adem\u00e1s, como la direcci\u00f3n IP del equilibrador de carga es \u00fanica por pod, podemos utilizar los n\u00fameros de puerto predeterminados. Todos los principales proveedores de cloud proporcionan servicios de balanceador de carga.<\/p>\n

Las conexiones XDCR basadas en puertos de nodo existentes siguen siendo compatibles y son las predeterminadas.<\/p>\n

Acceso a interfaz de usuario externa<\/h3>\n

La interfaz de usuario, al igual que los pods individuales, ahora se puede dirigir p\u00fablicamente con un servicio de equilibrador de carga. Esto hace que la gesti\u00f3n de tus despliegues de la plataforma de datos Couchbase sea mucho m\u00e1s sencilla.<\/p>\n

Cifrado de extremo a extremo<\/h3>\n

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

Cuando se presenta un certificado de servidor a un cliente que se conecta, \u00e9ste verificar\u00e1 que la direcci\u00f3n a la que se ha conectado es v\u00e1lida para ese certificado. Esto se hace con nombres alternativos<\/a>. S\u00f3lo admitimos nombres alternativos comod\u00edn basados en DNS, y no basados en IP. Adem\u00e1s, no podemos utilizar el direccionamiento basado en IP de los servicios del equilibrador de carga, ya que la direcci\u00f3n no es estable a lo largo de la recuperaci\u00f3n.<\/p>\n

Un nombre v\u00e1lido para un cluster podr\u00eda ser *.mi-cluster.ejemplo.com<\/i>. Esto es un comod\u00edn, es v\u00e1lido para servidor0.mi-cluster.ejemplo.com<\/i> y servidor1.mi-cluster.ejemplo.com<\/i>. El certificado ser\u00e1 v\u00e1lido para cualquier nodo que el Operador Aut\u00f3nomo cree en el ciclo de vida del cluster.<\/p>\n

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\u00f3nomo 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<\/a>.<\/p>\n

Ejemplo<\/h3>\n

El diagrama muestra c\u00f3mo se interrelacionan todas estas caracter\u00edsticas.<\/p>\n

    \n
  1. Un cliente, ya sea un SDK o un XCDR, inicializa una conexi\u00f3n utilizando la direcci\u00f3n DNS https:\/\/cb0.cb0.us-east-1.example.com:18091<\/em>. Esto se resuelve con la direcci\u00f3n IP del equilibrador de carga en 185.64.232.18<\/em>. Esta direcci\u00f3n DNS se crea a partir de la especificaci\u00f3n del servicio del balanceador de carga y su direcci\u00f3n IP p\u00fablica.<\/li>\n
  2. A continuaci\u00f3n, el cliente abre una conexi\u00f3n TCP con el cl\u00faster de Couchbase. Esta conexi\u00f3n atraviesa Internet hasta el router del cliente.<\/li>\n
  3. A continuaci\u00f3n, el paquete se reenv\u00eda al equilibrador de carga en 185.64.232.18<\/em>.<\/li>\n
  4. A continuaci\u00f3n, el equilibrador de carga SNAT env\u00eda el paquete al puerto del nodo correspondiente al puerto 18091<\/em> en el pod de destino. A continuaci\u00f3n, el nodo SNAT env\u00eda el paquete al puerto 18091<\/em> en la propia c\u00e1psula.<\/li>\n
  5. Una vez establecida la conexi\u00f3n 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\u00e1lido para el destinatario. La direcci\u00f3n cb0.cb0.us-east-1.example.com<\/em> coincide con el nombre alternativo del tema comod\u00edn *.cb0.us-east-1.ejemplo.com<\/em>. El arranque del cliente contin\u00faa como de costumbre.<\/li>\n<\/ol>\n

    \"Public<\/p>\n

    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.svc<\/em>su nombre DNS interno. Los clientes no pueden resolver este nombre cuando reciben una asignaci\u00f3n de los miembros del cl\u00faster a las direcciones de los miembros. El Operador rellena direcciones de miembros alternativas que son resolubles.<\/p>\n

    Los clientes deben conocer las direcciones alternativas. Los SDKs compatibles est\u00e1n documentados en la documentaci\u00f3n del Operador. XDCR es compatible con las versiones 5.5.3+ y 6.0.1+ del servidor Couchbase.<\/p>\n

    Conclusi\u00f3n<\/h3>\n

    La capacidad de direccionar p\u00fablicamente una instancia del servidor Couchbase es una herramienta poderosa. Simplifica la configuraci\u00f3n de la red. Configurar un t\u00fanel VPN entre proveedores de nube puede ser dif\u00edcil o imposible, esto lo evita por completo. Simplifica el proceso de acceso a la consola UI, tambi\u00e9n permite a los clientes, incluyendo XDCR, conectarse desde cualquier parte del mundo.<\/p>\n

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