Un Operador Kubernetes es una extensión de software de Kubernetes que soporta capacidades incorporadas para gestionar sus aplicaciones Kubernetes de forma automatizada y que sigue los principios de Kubernetes - especialmente el Bucle de control patrón.
¿Por qué necesitamos un Operador de Kubernetes? Vamos Considere el ejemplo de StatefulSets.
StatefulSets son geniales para ciertos casos de uso, pero no funcionan tan bien para ejecutar software complejo como bases de datos porque se centran en la creación y gestión de pods, no en la gestión del software que se ejecuta en ellos. Así que si quisieras un cluster de cuatro nodos y desplegaras Couchbase usando StatefulSets, tendrías cuatro pods de Couchbase sin inicializar que no se conocen entre sí. Entonces dependería de ti unir los nodos en un clúster, y eso significa tareas operativas adicionales.
Al desplegar Operador autónomo de Couchbase con un exclusivo Controlador CouchbaseKubernetes obtiene el conocimiento específico de Couchbase para que, cuando se despliegue un pod de Couchbase, pueda configurarlo correctamente y unirlo con otros pods de Couchbase en el clúster.
El aprovisionamiento de clústeres, el fallo de nodos, el escalado ad-hoc y muchas otras tareas de gestión también requieren conocimientos específicos de Couchbase dentro de Kubernetes para poder automatizarse correctamente. Por lo tanto, un operador de Kubernetes es la mejor manera de hacer que la base de datos sea una opción primordial para el desarrollo nativo en la nube en Kubernetes. Sin embargo, al tratar de averiguar qué base de datos es verdaderamente nativa en la nube y se ajusta mejor a los objetivos de tu organización, debes considerar múltiples factores.
En este artículo, comparo Couchbase Autonomous Operator, una parte central del Pila Couchbase Cloud-Native contra MongoDB Enterprise Kubernetes Operador sobre varios factores que son clave para tomar la decisión correcta a la hora de seleccionar una base de datos para desarrollos nativos en la nube.
Integraciones nativas en la nube
Figura 1: Couchbase Cloud-Native Stack
Como se muestra en la figura 1, Operador autónomo de Couchbase cuenta con una estrecha integración, en algunos casos nativa, con herramientas como Prometheus Exporter, FluentBitHelm Chart, Service Broker, Operator Metering, Istio Service Mesh, CoreDNS, GlusterFS, Ceph, Portworx, CNI. Todos ellos están totalmente certificados y soportados por el producto.
MongoDB Enterprise Kubernetes Operator no soporta de forma nativa todas estas integraciones. Service Broker y Helm Chart son extensiones para MongoDB Atlas, pero no para MongoDB Kubernetes Operator.
Arquitectura
Figura 2: Arquitectura de Couchbase Autonomous Operator para Kubernetes
Couchbase Autonomous Operator es verdaderamente nativo en la nube y se basa en el marco estándar de Operator nativo en la nube. Como producto completo, todas las operaciones son realizadas por Couchbase Autonomous Operator, ya sea aprovisionamiento de bases de datos, copia de seguridad/restauración, alertas/monitorización o integraciones nativas con proyectos de código abierto como Prometheus o OSB API.
Couchbase Autonomous Operator proporciona una red de seguridad para los clientes que despliegan en Kubernetes y simplifica el despliegue de Couchbase con un controlador de admisión con control de acceso basado en funciones (RBAC).
Figura 3: Arquitectura de MongoDB Enterprise Kubernetes Operator. Fuente
MongoDB Enterprise Kubernetes Operator es una envoltura alrededor del MongoDB Ops Manager que sí mismo es una envoltura alrededor de la base de datos MongoDB. Por otro lado, Couchbase Autonomous Operator no es una envoltura, sino un producto de utilidad completo que amplía las capacidades de automatización de Couchbase en la nube para ofrecer implantaciones totalmente gestionadas.
La arquitectura de MongoDB Enterprise Kubernetes Operator no es nativa de la nube. Cada operación Day-2 no se realiza directamente por MongoDB Kubernetes Operator sino a través de MongoDB Ops Manager, incluyendo aprovisionamiento, copia de seguridad/restauración, alertas/monitorización, etc. MongoDB Enterprise Kubernetes Operator tampoco tiene un controlador de admisión.
Nivel de madurez del operador
Existen cinco niveles de madurez de cualquier operador de Kubernetes:
-
- Instalación básica
- Actualizaciones sin fisuras
- Ciclo de vida completo
- Ideas profundas
- Piloto automático
Couchbase Autonomous Operator está certificado como Operador Kubernetes de Nivel 5 que satisface los criterios de cada nivel hasta el Auto-piloto, el nivel más alto del Modelo de Madurez de Capacidades de Operadores. (Referencia.)
MongoDB Enterprise Kubernetes Operator no es un operador de nivel 5. (Referencia.)
Comparación de características: Couchbase Autonomous Operator vs. MongoDB Enterprise Kubernetes Operator
Categoría |
Couchbase Autonomous Operator (CAO) 2.2 para Kubernetes |
MongoDB Enterprise Kubernetes Operator 1.10 |
Autoescalado |
Couchbase Autonomous Operator soporta auto-escalado de todos los servicios Couchbase.
Esta característica es única en el sector de las bases de datos, ya que puede autoescalar horizontalmente un solo servicio o un grupo de servicios juntos en función de umbrales totalmente personalizados y definidos por el usuario para cualquier estadística de Couchbase según las necesidades específicas de su entorno. |
MongoDB Enterprise Kubernetes Operator no admite autoescalado.
MongoDB Atlas sólo soporta autoescalado vertical con estadísticas limitadas: utilización de memoria y CPU. Esta flexibilidad limitada puede costar muy cara en horas punta si no se configuran (o priorizan) correctamente otras operaciones durante el autoescalado. |
Hibernación de clústeres |
Couchbase Autonomous Operator soporta la hibernación del cluster con un INMEDIATO estrategia de desconexión.
Los documentos que no se vacían pueden morir, pero estableciendo un valor de DURABILIDAD puede lograr un mejor control sobre el comportamiento de apagado. |
MongoDB Enterprise Kubernetes Operator no admite la hibernación de clústeres.
La hibernación del clúster sólo se soporta a través de Atlas. La documentación de API PAUSE enumera todas las propiedades de configuración del clúster en pausa, excepto la propiedad DURABILIDAD que es el parámetro más vital para que los clientes comprendan lo que ocurre con las operaciones, consultas o documentos en vuelo. (Referencia.) |
Configuración e implantación (CI/CD) |
CAO admite integraciones nativas en la nube con Helm Charts y OSB API.
CAO puede desplegarse a través de Couchbase Helm Chart y Couchbase Service Broker. |
MongoDB Enterprise Operator no soporta integraciones nativas con Helm Charts y OSB API.
Nota: MongoDB puede admitir Helm o OSB API con otros productos como Atlas o MongoDB Ops Manager, pero MongoDB Enterprise Kubernetes Operator no. |
Mantenimiento y actualizaciones |
Las actualizaciones de clústeres de Kubernetes, las actualizaciones de CAO y las actualizaciones de clústeres de Couchbase son compatibles con Couchbase Autonomous Operator.
CAO admite actualizaciones masivas, junto con las tradicionales actualizaciones continuas sin tiempo de inactividad. Couchbase Autonomous Operator también soporta actualizaciones personalizadas, es decir, puede seleccionar el número de pods o un porcentaje de pods en un cluster para actualizar mientras que el resto de los pods continúan funcionando tal cual. |
La documentación de MongoDB Enterprise Kubernetes Operator no menciona la actualización de instancias de base de datos MongoDB a través de MongoDB Enterprise Kubernetes Operator.
MongoDB Enterprise Kubernetes Operator no admite actualizaciones masivas. Según los pasos aquí mencionados, el Operador MongoDB Enterprise Kubernetes siempre puede arrojar un error y requiere eliminar el Operador, lo que implica tiempo de inactividad. (Referencia.) |
Alta disponibilidad y recuperación en caso de catástrofe |
Couchbase Autonomous Operator soporta Alta Disponibilidad (HA), afinidad de nodos, auto-failover, tolerancia a fallos y XDCR. | MongoDB Enterprise Kubernetes Operator soporta tolerancia a fallos y auto-failover.
Sin embargo, depende internamente de MongoDB Ops Manager para las operaciones de HA y XDCR, lo que añade una capa de servicio y puede afectar al rendimiento en términos de rendimiento y latencia. |
Gestión de la seguridad |
La gestión de seguridad de Couchbase Autonomous Operator incluye soporte RBAC, LDAP y TLS. | MongoDB Enterprise Kubernetes Operator proporciona seguridad y también incluye soporte RBAC, LDAP y TLS a través de MongoDB Ops Manager. |
Gestión de copias de seguridad |
Backup y Restore se gestionan completamente a través de Couchbase Autonomous Operator de forma nativa.
También se admite la copia de seguridad en AWS S3. |
La copia de seguridad/restauración no se gestiona a través de MongoDB Enterprise Kubernetes Operator de forma nativa, sino a través de MongoDB Ops Manager. |
Análisis de observabilidad |
Couchbase Autonomous Operator tiene integración nativa con Prometheus, Grafana para monitorización y alertas con FluentBit para el reenvío centralizado de registros y el registro de auditoría automatizado. | Las alertas y la monitorización están soportadas a través de MongoDB Ops Manager.
MongoDB Enterprise Kubernetes Operator no tiene una integración empresarial nativa con Prometheus o FluentBit (Nota: la documentación de MongoDB Enterprise Kubernetes Operator no menciona estas integraciones en ninguna parte. Referencia.) |
Red |
Couchbase Autonomous Operator admite integraciones nativas en la nube con CNI, CoreDNS e Istio Service Mesh. | MongoDB Enterprise Kubernetes Operator no dispone de estas integraciones nativas.
La documentación de MongoDB Enterprise Kubernetes Operator no menciona ninguna de estas integraciones nativas de la nube. (Referencia.) |
Almacenamiento |
Couchbase Autonomous Operator admite integraciones de almacenamiento nativo en la nube para GlusterFS, Ceph y Portworx.
Couchbase Autonomous Operator también admite la ampliación en línea de volúmenes persistentes, así como el escalado en línea de volúmenes de copia de seguridad. Nota: La expansión de volúmenes persistentes en línea significa escalar volúmenes persistentes sin tener que reiniciar los pods. |
La documentación de MongoDB Enterprise Kubernetes Operator no menciona ninguna de estas integraciones nativas de la nube. (Referencia.)
MongoDB Enterprise Kubernetes Operator no admite el escalado de almacenamiento en línea. Tampoco admite el escalado de volúmenes de copia de seguridad en línea. |
Conclusión
MongoDB proporciona la mayoría de sus funciones avanzadas a través de MongoDB Ops Manager o MongoDB Atlas, pero no las admite a través de MongoDB Enterprise Kubernetes Operator. Esta capa adicional de Ops Manager aumenta el coste de los recursos y repercute en el rendimiento, además de añadir complejidades arquitectónicas innecesarias.
Por otro lado, Couchbase Autonomous Operator es un producto completo y soporta todos los servicios directamente de una manera verdaderamente nativa en la nube. CAO es más maduro que cualquier otro operador de Kubernetes en el sector de las bases de datos.
Referencias
-
- https://docs.couchbase.com
- https://docs.couchbase.com/cloud-native-database/index.html
- https://docs.couchbase.com/operator/current/overview.html
- https://docs.mongodb.com
- https://medium.com/hackernoon/getting-started-with-mongodb-enterprise-operator-for-kubernetes-bb5d5205fe02
- https://www.couchbase.com/blog/couchbase-autonomous-operator-2-1-for-kubernetes-is-now-ga/
- https://info.couchbase.com/rs/302-GJY-034/images/CBvM_Scale_out%20_High_availability.pdf
- https://www.couchbase.com/blog/couchbase-better-scale-out-agility-and-high-availability-than-mongodb/
- https://connectondemand.couchbase.com/watch/wET3Bo88agGqFCTbMWXegJ
