COCHERA AUTOGESTIONADA EN KUBERNETES
Operador Couchbase Kubernetes
El operador de Kubernetes despliega, escala, restaura y actualiza Couchbase por usted. Su equipo de plataforma administra la base de datos como cualquier otro trabajo, con la excepción de las páginas que se actualizan a las 2 de la mañana.
Kubernetes conoce los pods. Nosotros conocemos Couchbase.
Kubernetes es excelente para reemplazar los pods. Una base de datos también necesita un rebalanceamiento, la colocación de réplicas y actualizaciones seguras. Nuestro operador se encarga de eso por usted.
Trabaje más rápido en la plataforma que ya utiliza
Cuando la base de datos se encuentra fuera de tu plataforma, cada cambio se registra en un ticket. Aquí se utiliza YAML en Git, revisado y enviado como código.
Manténgase actualizado sin ventanas de mantenimiento durante los fines de semana
Las actualizaciones se aplazan y el riesgo de seguridad aumenta. Las actualizaciones se aplican una por una mientras las aplicaciones se ejecutan, y puedes volver atrás en cualquier momento.
Menos interrupciones, menos páginas a las 2 a.m.
Cuando un pod o un nodo falla, el operador lo reemplaza, reutiliza su almacenamiento y vuelve a equilibrar los datos. Solo alerta de lo que requiere una intervención humana.
Mantenga el control de sus datos y de sus gastos
Utilice la capacidad de Kubernetes que ya tiene en sus instalaciones o en cualquier nube. Cumplirá con las normas de residencia de los datos y cumplimiento de la normativa, según sus propios términos.
¿Qué es el operador Couchbase Kubernetes?
Couchbase Server lo ejecuta en Kubernetes en tu nombre. Digas lo que quieras en YAML y el operador configurará el cluster de acuerdo con eso, y luego lo mantendrá así.
El operador añade tipos de Couchbase a Kubernetes, como CouchbaseCluster, CouchbaseBucket y CouchbaseBackup. Escribes lo que quieres y el operador compara eso con lo que está funcionando y corrige la diferencia, todo el día. Un controlador de admitencias rechaza la configuración incorrecta antes de que se guarde, por lo que los errores se muestran en el terminal, no en el canal de incidentes.
Un StatefulSet genérico reinicia los pods. El operador entiende Couchbase. Equilibra los datos antes de continuar, coloca réplicas en zonas diferentes y reutiliza los volúmenes persistentes para que el pod reemplazado se actualice solo con los cambios recientes. Durante las actualizaciones de Kubernetes, solo se permite que un único pod de Couchbase se active a la vez, para que los flujos de trabajo de los nodos no pierdan datos.
La versión 2.9 admite Kubernetes 1.31 a 1.36, Red Hat OpenShift 4.18 a 4.20, Amazon EKS, Google GKE, Microsoft AKS, K3s y Bottlerocket OS, en x86 o ARM. ¿Está ejecutando algo más? Una herramienta de autoevaluación prueba su plataforma, almacenamiento y red, y Couchbase revisa los resultados. También funciona en la empresa, con imágenes de su propio registro de máquinas virtuales.
El operador utiliza la versión Enterprise Edition de Couchbase Server, de las versiones 7.2 a 8.0. Este es el mismo motor que se encuentra detrás de Capella, por lo que sus SDK, consultas SQL++ y modelo de datos funcionan en todas las plataformas. La replicación cruzada de centros de datos (XDCR) enlaza los clústeres en Kubernetes, VMs y Capella, por lo que pasar a un modelo híbrido o cambiar entre ellos es una modificación de la configuración, no un proyecto de migración.
Se ejecuta en modo automático, una cápsula a la vez
5 de 5
Nivel de capacidad del operador Kubernetes: Auto Pilot, el nivel más alto
1 pod
La mayoría de los operadores permiten que Kubernetes elimine los nodos de forma simultánea durante las actualizaciones.
RESULTADOS DEL CLIENTE DE COUCHBASE SERVER
Diseñado para aplicaciones que no pueden suspenderse
DEBAJO DE LA ROPA
Todo lo que las operaciones del día 2 necesitan, gestionado en YAML
Cómo opera, escala, actualiza, protege y securiza el sistema Couchbase, para que tu equipo no tenga que hacerlo manualmente.
- Operar
- Escala
- Actualización
- Protección
- Asegure
Instala con Helm, gestiona a través de Git y ve todo lo que ya utiliza tu equipo de plataforma con las herramientas.
Características clave, incluyendo lo nuevo en Operator 2.9
Helm, GitOps y la CLI
Un diagrama Helm oficial instala el operador, el controlador de admisión, un clúster e incluso Sync Gateway. Mantenga todos los cambios en Git.
La mala configuración nunca tiene éxito
El controlador de acceso comprueba cada recurso de Couchbase antes de que Kubernetes lo guarde, incluyendo secretos, certificados y clases de almacenamiento.
Alertas cuando se necesita una persona
Un sistema de monitoreo alerta sobre lo que el operador no puede solucionar solo, como certificados caducados o un quorum perdido, a través de eventos y métricas de Kubernetes.
Ajuste cada servicio de Couchbase por separado, automáticamente si lo desea, y desactive los clústeres inactivos.
Características clave, incluyendo lo nuevo en Operator 2.9
Escala multidimensional
Ofrezca a los servicios de datos, índice, consulta, búsqueda y análisis sus propios pods y hardware. Añada pods de búsqueda sin tener que pagar por más pods de datos.
Autoscaling con el HPA de Kubernetes
Ajuste la escala de cada servicio en función de las métricas de CPU, memoria o Couchbase a través del Horizontal Pod Autoscaler. Sin tiempo de inactividad cuando los pods entran y salen.
Hibernate los clusters inactivos
Desconecta los clústeres de desarrollo y de prueba con un solo campo. El cálculo vuelve al pool, los volúmenes se mantienen en su lugar y el clúster se vuelve a encender como antes.
Actualice Couchbase y Kubernetes sin interrupciones en el servicio y desplácese los clústeres existentes a Kubernetes mientras estos permanezcan en línea.
Características clave, incluyendo lo nuevo en Operator 2.9
Actualizaciones automáticas que usted controla
Modifique la etiqueta de imagen y el operador actualizará el pod uno por uno. Configure la orden por zona, clase o servicio y dé un descanso entre las etapas.
Actualizaciones de Kubernetes sin pérdida de datos
Los presupuestos de disrupción y las puertas de preparación permiten que los nodos descarguen una pod de Couchbase a la vez, y solo una vez que los datos se hayan reequilibrado de forma segura.
Mover los clústeres de VM a Kubernetes
Dirija el operador hacia un clúster de VMs o EC2. Esto cambia los nodos en Kubernetes uno por uno mientras las aplicaciones continúan ejecutándose.
Cargos de trabajo de backup planificados en almacenamiento de objetos, replicación entre clústeres y replicas distribuidas en varias zonas.
Características clave, incluyendo lo nuevo en Operator 2.9
Cargando y restaurando de forma programada
Configure los cronogramas como recursos de Kubernetes. Las copias de seguridad se ejecutan desde los nodos de Couchbase y pueden almacenarse en S3, Azure Blob o Google Cloud Storage.
XDCR entre los grupos
Replicar a otro clúster, región o nube Kubernetes, de una manera o de las dos. Nuevo en 2.9: registro de conflictos para configuraciones activas-activas.
Placamiento consciente de la zona
Los grupos de servidores se asignan a zonas de disponibilidad, por lo que las copias de seguridad se alojan en una zona diferente a la que protegen los datos. Si pierdes una zona, conservas tus datos.
TLS que se rota automáticamente, cifrado en reposo con sus propias claves, y los usuarios y roles guardados en el código.
Características clave, incluyendo lo nuevo en Operator 2.9
TLS que se rota a sí mismo
Utilice los secretos TLS estándar de Kubernetes o el programa cert-manager. Rotule los certificados del servidor, del cliente o de la CA y requiera un TLS mutuo si así lo desea.
Encriptación en reposo, tus claves
Para el servidor 8.0: cifrar los buckets, la configuración y los registros de auditoría con claves de AWS KMS, un gestor de claves KMIP o directamente de Couchbase.
Usuarios, roles y LDAP como código
Defina los usuarios, grupos y vínculos de roles de Couchbase como recursos de Kubernetes, vincule grupos LDAP y rote el password del administrador de forma segura.
- Producción
- Híbrido
- Migrar
ARQUITECTURA
Un clúster productivo en 3 zonas
Una interrupción en una zona no debería provocar la caída de tu aplicación. Cada zona se convierte en un grupo de servidores Couchbase en nodos reservados para Couchbase, por lo que las copias de seguridad se alojan en otro lugar. Cada servicio recibe sus propios pods y almacenamiento en su propia zona. cert-manager rota el TLS y los backups se ejecutan desde los nodos de la base de datos.
ARQUITECTURA
Una topología uniforme en todos los sitios
Algunos datos deben permanecer en la empresa. Algunas aplicaciones se alojan en la nube. Ejecute el mismo YAML de operador en OpenShift en su centro de datos y en EKS, AKS o GKE, luego vincule los dos con XDCR en ambas direcciones. Los filtros mantienen los documentos regulados en el país. Adicione Capella en regiones donde prefiera no ejecutar nada.
ARQUITECTURA
Desinstalar máquinas virtuales sin desconectar del sistema
Describe tu clúster existente en YAML y apunta el operador hacia él. Esto agrega un pod, rebalancea los datos en él y luego elimina un nodo de VM, uno por vez, mientras que las aplicaciones permanecen conectadas a un único clúster. Puedes elegir el orden y el ritmo y puedes detener la operación en cualquier momento para configurar una configuración híbrida.
PRIMEROS PASOS
Desde la instalación de Helm hasta el primer clúster
Añade el repositorio de Helm de Couchbase y instala un gráfico. Obtienes el operador, el controlador de admisión y un clúster de Couchbase funcional, listo para conectarse desde la consola web o un SDK. ¿Prefieres seguir el paso a paso? La CLI instala cada componente por separado, en Kubernetes o OpenShift. Lee la guía de mejores prácticas antes de ponerla en producción. Aborda el almacenamiento, la programación y los errores que vale la pena omitir.
El mismo motor, tres formas de funcionar
AUTONOMÍA
Servidor Couchbase
El motor que utiliza el operador: JSON, clave-valor, SQL++, búsqueda, búsqueda de vectores y almacenamiento en caché en una misma base de datos. Ejecúelo en Kubernetes con el operador, o en máquinas virtuales y hardware sin procesador cuando sea más conveniente.
CLOUDS ADMINISTRADOS
Couchbase Capella
¿Quieres tener Couchbase sin tener que usar Kubernetes? Capella es el mismo motor, totalmente administrado en AWS, Google Cloud y Azure. Couchbase se encarga del setup, de los backups, del escalamiento y de las actualizaciones.
MÓVIL Y EDGE
Couchbase Mobile
Couchbase Lite mantiene las aplicaciones funcionando en teléfonos y dispositivos de gama baja sin conexión. El mismo helm chart puede implementar Sync Gateway junto a tu clúster para mantener esos dispositivos sincronizados.
Preguntas frecuentes sobre el operador Couchbase Kubernetes
Respondiendo a preguntas comunes sobre la ejecución de Couchbase en Kubernetes y OpenShift.
Nuestro operador de Kubernetes, también conocido como Couchbase Autonomous Operator (CAO), despliega, escala, restaura, realiza copias de seguridad y actualiza el servidor Couchbase autogestionado en Kubernetes y OpenShift.
La versión 2.9 soporta Kubernetes 1.31 a 1.36, OpenShift 4.18 a 4.20, Amazon EKS, Google GKE, Microsoft AKS, K3s y Bottlerocket OS en nodos x86 y ARM.
Gestiona las versiones 7.2 a 8.0 de Couchbase Server Enterprise Edition. El operador 2.9 también configura las funciones de la versión 8.0, como la cifrado en reposo. La versión Community Edition no está soportada.
El Framework de Operadores define cinco niveles de funcionalidad, desde el Instalación Básica hasta el Autopilot. El operador de Couchbase se encuentra en el nivel 5, Autopilot. Los proveedores evalúan a sí mismos, así que ¡prueba y juzga!.
Sí. Dirija el operador hacia un clúster de VMs o EC2 y el sistema lo rebalancea automáticamente los nodos a Kubernetes uno por uno. Los apps se mantienen conectados y ambos lados necesitan acceso a la red.
Ambos utilizan el mismo motor de Couchbase. Con el operador, tu equipo ejecuta Couchbase en tu propio Kubernetes. Con Capella, Couchbase lo ejecuta en tu nombre en AWS, Google Cloud o Azure.
Sigue explorando
-
Arquitectura de referencia de producción
YAML listo para copiado para un cluster de Couchbase seguro y con conocimiento de zonas en Kubernetes.
-
Cómo probamos al operador en todas las plataformas
Dentro del pipeline CI que comprueba las versiones de operador, Server y Kubernetes.
-
¿Interesado? Comienza hoy mismo.
Hablemos de cómo podemos ser más inteligentes hoy en día para un futuro con inteligencia artificial.