{"id":8269,"date":"2020-04-13T13:02:17","date_gmt":"2020-04-13T20:02:17","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=8269"},"modified":"2025-06-13T21:33:16","modified_gmt":"2025-06-14T04:33:16","slug":"why-couchbase-is-the-best-nosql-option-for-red-hat-openshift","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/why-couchbase-is-the-best-nosql-option-for-red-hat-openshift\/","title":{"rendered":"Por qu\u00e9 Couchbase es la mejor opci\u00f3n NoSQL para Red Hat OpenShift"},"content":{"rendered":"

El liderazgo de Red Hat en el espacio de orquestaci\u00f3n de contenedores con OpenShift refleja el liderazgo de Couchbase en el espacio de bases de datos en contenedores con su Autonomous Operator. Este hecho es la base de la asociaci\u00f3n entre Red Hat y Couchbase. He trabajado personalmente en la asociaci\u00f3n durante los \u00faltimos dos a\u00f1os. Quer\u00eda aprovechar esta oportunidad para discutir por qu\u00e9 ahora es un gran momento para ejecutar Couchbase en Red Hat OpenShift.<\/span><\/p>\n

El \"estado\" actual de Kubernetes<\/span><\/h2>\n

Antes de unirme a Couchbase trabaj\u00e9 en una empresa de monitorizaci\u00f3n SaaS. Trabajar en una empresa de monitorizaci\u00f3n te da una visi\u00f3n \u00fanica de las tecnolog\u00edas que utilizan tus clientes. En 2017 se pod\u00eda ver el punto de inflexi\u00f3n de Kubernetes y OpenShift en los paneles de monitorizaci\u00f3n de nuestros clientes. Estaba claro que Red Hat OpenShift estaba ganando la guerra de la orquestaci\u00f3n de contenedores entre las grandes empresas. Pero hab\u00eda algo que definitivamente no se ve\u00eda: bases de datos en Kubernetes. Especialmente en producci\u00f3n. De hecho, ejecutar cualquier carga de trabajo \"con estado\" en Kubernetes se consideraba arriesgado. La arquitectura t\u00edpica implicaba ejecutar las cargas de trabajo sin estado en Kubernetes u OpenShift y ejecutar las bases de datos en otro lugar.<\/span><\/p>\n

Como le dir\u00e1 cualquier ingeniero de bases de datos, la gesti\u00f3n del estado en un aplicaci\u00f3n distribuida<\/a> es dif\u00edcil. Cuando se a\u00f1aden m\u00faltiples capas de abstracci\u00f3n y escalado el\u00e1stico, la cosa se complica a\u00fan m\u00e1s. Kubernetes es y fue excelente en la gesti\u00f3n de recursos inform\u00e1ticos y de memoria, pero el almacenamiento no era algo gestionado directamente por Kubernetes. En otras palabras, Kubernetes y OpenShift eran geniales para gestionar cargas de trabajo sin estado, pero solo unos pocos valientes se atrevieron a ejecutar aplicaciones persistentes y con estado directamente en Kubernetes (es decir, bases de datos). <\/span>El patr\u00f3n t\u00edpico consist\u00eda en alojar la base de datos en otro lugar (v\u00e9ase \"Entonces\" en el diagrama siguiente).<\/p>\n

\"\"<\/p>\n

 <\/p>\n

Almacenamiento - Vol\u00famenes persistentes<\/h4>\n

La comunidad quer\u00eda abordar este problema y <\/span>Vol\u00famenes persistentes<\/span><\/a> fue un elemento fundamental. Persistent Volumes (PVs) proporcion\u00f3 una soluci\u00f3n a la gesti\u00f3n del almacenamiento y el aislamiento en forma de una API que permite conectar diferentes clases de almacenamiento<\/a> a los pods en ejecuci\u00f3n. Los PV tienen un ciclo de vida independiente de cualquier pod individual, lo que les permite mantener sus datos incluso despu\u00e9s de la destrucci\u00f3n de un pod. Esto significa que no tiene que preocuparse por la p\u00e9rdida de datos en un escenario de desastre cuando pierde una base de datos o un nodo OpenShift.<\/span><\/p>\n

Varios proveedores de almacenamiento han a\u00f1adido compatibilidad con Kubernetes a trav\u00e9s de la API Persistent Volumes, incluidos los proveedores de nube y el socio de Red Hat, Portworx<\/a>. Esto significa que tiene opciones a la hora de elegir su almacenamiento. Esto es fundamental desde el punto de vista de un proveedor de bases de datos, ya que elegir el almacenamiento adecuado puede tener un gran impacto en el rendimiento y la fiabilidad.<\/p>\n

 <\/p>\n

El marco del operador<\/h4>\n

La segunda gran innovaci\u00f3n y la que ha permitido a Couchbase convertirse en el l\u00edder de las bases de datos NoSQL en OpenShift, es<\/span>\u00a0el Marco para operadores<\/a>. Couchbase fue la primera empresa de bases de datos NoSQL en invertir seriamente en el desarrollo de un operador (v\u00e9ase \"Los principales operadores de Kubernetes avanzan en el modelo de capacidad del operador<\/a>\"). Colaboramos con el equipo de CoreOS desde el principio durante el desarrollo del Operator Framework. Hoy en d\u00eda, los clientes de Couchbase pueden confiar en Couchbase Autonomous Operator para gestionar muchas de las operaciones de su cl\u00faster, incluyendo el despliegue, escalado, recuperaci\u00f3n de desastres, actualizaciones y mucho m\u00e1s. Esto representa un enorme valor para los clientes de Couchbase y tambi\u00e9n est\u00e1 ayudando a impulsar la adopci\u00f3n de OpenShift.<\/span><\/p>\n

\u00bfQu\u00e9 es un Operador? Esta cita del equipo de Red Hat CoreOS lo resume mejor:<\/p>\n

\"<\/span>Conceptualmente, un Operador toma el conocimiento operativo humano y lo codifica en software que se empaqueta y comparte m\u00e1s f\u00e1cilmente con los consumidores.<\/strong>. Piense en un Operador como una extensi\u00f3n del equipo de ingenier\u00eda del proveedor de software que vigila su entorno Kubernetes y utiliza su estado actual para tomar decisiones en milisegundos. Los operadores siguen un modelo de madurez que va desde la funcionalidad b\u00e1sica hasta la l\u00f3gica espec\u00edfica de una aplicaci\u00f3n. Los Operadores avanzados est\u00e1n dise\u00f1ados para gestionar actualizaciones sin problemas, reaccionar ante fallos autom\u00e1ticamente y no tomar atajos, como saltarse un proceso de copia de seguridad del software para ahorrar tiempo.\"<\/span><\/i><\/p>\n

https:\/\/coreos.com\/blog\/introducing-operator-framework<\/span><\/i><\/a><\/p>\n

Dado que la gesti\u00f3n del estado distribuido es un reto, y los diferentes sistemas gestionan el estado de manera diferente en funci\u00f3n de detalles de implementaci\u00f3n muy espec\u00edficos, nunca fue razonable esperar que la comunidad Kubernetes codificara para cada posible escenario que todas y cada una de las aplicaciones con estado pudieran encontrar. <\/span>Operator Framework permite a los desarrolladores salvar esa distancia, y hacerlo de un modo que se ajusta al paradigma de Kubernetes. Por ejemplo: En un escenario de desastre, cuando un nodo OpenShift que ejecuta un pod de Couchbase se cae, el Operador Aut\u00f3nomo de Couchbase restaurar\u00e1 autom\u00e1ticamente y con gracia el cl\u00faster y reequilibrar\u00e1 tus datos sin ninguna interrupci\u00f3n de los servicios que utilizan Couchbase. Y si est\u00e1s usando Vol\u00famenes Persistentes, incluso volver\u00e1 a conectar el volumen de tu pod perdido a tu nuevo pod de Couchbase - acelerando enormemente el tiempo que se tarda en reequilibrar tus datos.<\/span><\/p>\n

\"\"<\/p>\n

Gestor del ciclo de vida del operador<\/h4>\n

A medida que los operadores han ido madurando, tambi\u00e9n lo han hecho las herramientas que los rodean. El mejor ejemplo es el Gestor del ciclo de vida del operador (OLM)<\/a>. OLM estaba en vista previa t\u00e9cnica desde OpenShift 3.11. A partir de OpenShift 4 es una funci\u00f3n oficialmente compatible. Normalmente, la instalaci\u00f3n de un Operator requiere privilegios de administrador de cl\u00faster y algunos pasos manuales, como la instalaci\u00f3n de un Definici\u00f3n de recursos personalizados<\/a>. OLM automatiza la tarea de instalaci\u00f3n y tambi\u00e9n puede administrar las actualizaciones por usted sin requerir privilegios de administrador de cluster. El OLM se conecta directamente al OperatorHub<\/a> lo que significa que a medida que se publiquen nuevas actualizaciones de Operator, aparecer\u00e1n en el cat\u00e1logo de OperatorHub y se podr\u00e1n instalar a trav\u00e9s del OLM. Esto permite a los usuarios encontrar el Operator que necesitan e instalarlo en un par de clics.<\/p>\n

Uno de sus principales beneficios es la productividad de los desarrolladores. Ofrece a los desarrolladores \"operadores como servicio\" dentro de sus entornos de desarrollo de OpenShift.<\/p>\n

\"\"<\/p>\n

\u00bfPor qu\u00e9 Couchbase?<\/span><\/h2>\n

En los \u00faltimos a\u00f1os, el t\u00e9rmino \"nativo de la nube\" se ha convertido en parte del lenguaje com\u00fan de la tecnolog\u00eda. Aparece con especial frecuencia en el contexto de los debates sobre Kubernetes y OpenShift. Kubernetes se presenta a menudo como la plataforma para las aplicaciones nativas de la nube. Cloud Native significa software dise\u00f1ado para aprovechar el modelo de computaci\u00f3n en nube. En la pr\u00e1ctica, esto significa aplicaciones que se ajustan m\u00e1s a un patr\u00f3n de arquitectura orientada a microservicios y servicios (en contraposici\u00f3n a una arquitectura monol\u00edtica), que pretenden escalar horizontalmente (en contraposici\u00f3n a escalar verticalmente) y que pueden ejecutarse en contenedores relativamente ligeros. Esto supone un problema para las bases de datos relacionales tradicionales (y algunas NoSQL), que siguen en gran medida patrones monol\u00edticos y no fueron dise\u00f1adas para escalar horizontalmente de la forma en que lo hizo Couchbase.<\/span><\/p>\n

Aqu\u00ed es donde Couchbase brilla en relaci\u00f3n con otras opciones. Al principio de la vida de Couchbase, fue empujado y desafiado a soportar cargas de trabajo a escala web en entornos de nube por sus mayores usuarios. Couchbase adopt\u00f3 una arquitectura desde el principio que se asemeja a lo que ahora llamamos Cloud Native. En Couchbase, esto se refleja en nuestro Escala multidimensional<\/a> capacidad.\u00a0<\/span>El escalado multidimensional permite que cada uno de los servicios de Couchbase (datos, \u00edndice, consulta, an\u00e1lisis, b\u00fasqueda de texto completo y eventos) se escale de forma independiente, mientras est\u00e1 en l\u00ednea y sirviendo tr\u00e1fico. Esto es exactamente como querr\u00edas dise\u00f1ar una aplicaci\u00f3n con la nube nativa en mente.<\/span><\/p>\n

\"\"<\/p>\n

Adem\u00e1s del escalado multidimensional, otras funciones de Couchbase, como la fragmentaci\u00f3n autom\u00e1tica y una interfaz administrativa robusta e integrada, solo ayudan a suavizar la experiencia de gestionar tus cargas de trabajo NoSQL en OpenShift.<\/p>\n

Hacia d\u00f3nde vamos<\/span><\/h2>\n

Couchbase Autonomous Operator 2.0 Beta<\/h4>\n

Nuestro objetivo es automatizar todas las mejores pr\u00e1cticas operativas de Couchbase necesarias para ejecutar cl\u00fasteres con nuestro Operador. <\/span>El objetivo final es que nuestros clientes y los clientes de Red Hat puedan operar eficientemente su propio Couchbase DBaaS ejecut\u00e1ndose en cualquier entorno OpenShift en la nube, on prem, o ambos. Incluso la propia oferta DBaaS de Couchbase se basa en gran medida en Couchbase Autonomous Operator.<\/span><\/p>\n

Recientemente hemos lanzado el Couchbase Autonomous Operator 2.0 Beta<\/a>. Aunque seguimos a\u00f1adiendo nuevas funciones al propio Operator, reconocemos que Couchbase es s\u00f3lo una pieza de la infraestructura. En la pr\u00e1ctica, hay otras funciones como la monitorizaci\u00f3n de m\u00e9tricas y registros y la seguridad que abarcan m\u00faltiples piezas de la infraestructura. Operator 2.0 incluye integraci\u00f3n con Couchbase Prometheus Exporter para recoger y exponer las m\u00e9tricas de Couchbase Server. Esto significa que puede monitorizar Couchbase junto con sus otras aplicaciones dentro de su entorno Ret Hat OpenShift.<\/p>\n

Habilitaci\u00f3n de cargas de trabajo en nubes m\u00faltiples e h\u00edbridas<\/h4>\n

Ser\u00eda negligente si no mencionara otra caracter\u00edstica clave de Couchbase - Replicaci\u00f3n entre centros de datos (XDCR)<\/a>. XDCR siempre ha sido una caracter\u00edstica popular de Couchbase. La raz\u00f3n por la que es importante en este contexto es por su papel a la hora de permitir cargas de trabajo con estado en nubes m\u00faltiples e h\u00edbridas en OpenShift. OpenShift ya facilita el despliegue de aplicaciones en diferentes nubes y on-prem. Con XDCR tambi\u00e9n se puede lograr la replicaci\u00f3n de datos a trav\u00e9s de cl\u00fasteres OpenShift. En las pr\u00f3ximas semanas nosotros (Red Had y Couchbase) planeamos proporcionar m\u00e1s contenido y actualizaciones sobre este tema en concreto. \u00a1Permanece atento!<\/p>\n

\"\"<\/p>\n

Recursos<\/h2>\n