Uso de Couchbase Autonomous Operator en GKE

Nos complace anunciar el lanzamiento de Couchbase Autonomous Operator 1.2. Se trata de una versión histórica que incluye varias características solicitadas por los clientes, principalmente

• Actualización automatizada de clusters Couchbase
• Validación integrada de recursos CouchbaseCluster a través de Adminission Controller
• Soporte de timón
• Conectividad pública para clientes Couchbase
• Actualización continua de clústeres Kubernetes
• Rotación de certificados TLS x509
• Experiencia unificada de recopilación de registros para implantaciones con y sin estado

• Soporte para Servicios Públicos de Kubernetes en GKE, AKS y EKS. Kubernetes funcionando en la nube pública ya estaba funcionando desde el día 1, pero con Autonomous Operator 1.2, lo estamos soportando de manera oficial. Desde la perspectiva de este blog, utilizaremos GKE para configurar el clúster de Kubernetes en GKE con la versión 1.12, luego desplegaremos Autonomous Operator y finalmente desplegaremos Couchbase Cluster con Server Groups, con volúmenes persistentes y con certificados x509 TLS.

Los pasos generales que daremos en este blog son los siguientes:

1. Inicializar gcloud utils

2. Despliegue un clúster kubernetes (v1.12+) con 2 nodos en cada zona de disponibilidad

3. Despliegue del Operador Autónomo 1.2

4. Despliegue del clúster Couchbase

5. Realizar Autofailover de Grupo de Servidores

Requisitos previos

• kubectl (gcloud components install kubectl)
• Cuenta GCP con las credenciales correctas

Inicializar gcloud utils

Descargar gcloud sdk para la versión del sistema operativo de su elección de este URL.

Se necesitarían credenciales de google cloud para inicializar el gcloud cli

Despliegue el clúster kubernetes (v1.12) con 2 nodos en cada zona de disponibilidad

El despliegue de clústeres kubernetes en GKE es un trabajo bastante sencillo. Para desplegar clústeres kubernetes resistentes, es buena idea desplegar nodos en todas las zonas disponibles dentro de una región determinada. Hacerlo de tal manera que podamos hacer uso de los grupos de servidores o Zona Rack o Zona de Disponibilidad (AZ) dentro del servidor Couchbase, significa que si perdemos toda AZ, couchbase puede conmutar por error toda AZ y la aplicación estará activa, ya que todavía tiene el conjunto de datos de trabajo.

Más tipos de máquinas pueden ser aquí

En este punto, el cluster k8s con el número requerido de nodos debería estar en funcionamiento

Los detalles del clúster k8s se encuentran a continuación

Despliegue del Operador Autónomo 1.2

GKE soporta RBAC para limitar los permisos. Dado que el Operador Couchbase crea recursos en nuestro clúster GKE, tendremos que concederle el permiso para hacerlo.

Descargar el paquete adecuado para desplegar kubernetes en su entorno. Descomprima el paquete y despliegue el controlador de admisión.

Comprobar el estado del controlador de admisión

Para visualizar cómo funciona el controlador de admisión en sincronía con el operador y el cluster couchbase, se puede ilustrar mejor con el siguiente diagrama

Los siguientes pasos son crear crd, rol de operador y operador 1.2

Una vez desplegado, el operador está listo y disponible en cuestión de segundos.

Despliegue del clúster Couchbase

El clúster Couchbase se desplegará con las siguientes características

• Certificados TLS

• Grupos de servidores (cada grupo de servidores en una AZ)

• Volúmenes persistentes (que son conscientes de AZ)

• Recuperación automática de grupos de servidores

Certificados TLS

Es bastante fácil de generar certificados tls, los pasos detallados se encuentran aquí

Una vez desplegados, los secretos tls se pueden encontrar con el comando kubectl secret de la siguiente manera

Grupos de servidores

Configurar grupos de servidores también es sencillo, lo que se discutirá en las siguientes secciones cuando despleguemos el archivo yaml del clúster couchbase.

Volúmenes persistentes

Los volúmenes persistentes ofrecen una forma fiable de ejecutar aplicaciones con estado. Su creación en la nube pública se realiza con un solo clic.

Primero podemos comprobar qué storageclass está disponible para su uso

Todos los nodos trabajadores disponibles en el cluster k8s deben tener etiquetas de dominio de fallo como las siguientes

NOTA: No tengo que añadir ninguna etiqueta de dominio de fallo, GKE añade automáticamente.

Crear PV para cada AZ

El archivo yaml svrgp-pv.yaml, se puede encontrar aquí.

Crear secreto para acceder a la interfaz de usuario de couchbase

Por último, despliegue el clúster couchbase con soporte TLS, junto con grupos de servidores (que son conscientes de Az) y en volúmenes persistentes (que también son conscientes de AZ).

El archivo yaml couchbase-persistent-tls-svrgps.yaml, se puede encontrar aquí

Dale unos minutos, y el cluster de couchbase aparecerá, y debería verse así

La comprobación rápida de las reclamaciones de volúmenes persistentes puede hacerse como se indica a continuación

Para acceder a la interfaz de usuario de Couchbase Cluster, podemos hacer un port-foward al puerto 8091 de cualquier pod o servicio en sí, en el portátil local, o máquina local, o puede ser expuesto a través de lb.

port-forward cualquier pod como el siguiente

En este punto el servidor couchbase está funcionando y tenemos forma de acceder a él.

Realizar Autofailover de Grupo de Servidores

Recuperación automática de grupos de servidores

Cuando un nodo del cluster couchbase falla, entonces puede auto-failover y sin ninguna intervención del usuario TODO el conjunto de trabajo está disponible, no es necesaria la intervención del usuario y la aplicación no verá el tiempo de inactividad.

Si Couchbase cluster está configurado para ser Server Group(SG) o AZ o Rack Zone(RZ) aware, entonces incluso si perdemos todo SG entonces todo el grupo de servidores falla y el conjunto de trabajo está disponible, no es necesaria la intervención del usuario y la aplicación no verá el tiempo de inactividad.

Con el fin de tener la recuperación de desastres, XDCR se puede utilizar para replicar los datos Couchbase a otro clúster Couchbase. Esto ayuda en el caso de que se pierda todo el centro de datos o región de origen, las aplicaciones se pueden transferir al sitio remoto y la aplicación no sufrirá tiempo de inactividad.

Vamos a desmontar el Grupo de Servidores. Antes de eso, vamos a ver cómo se ve el clúster

Borrar todos los pods del grupo us-east1-b, una vez borrados los pods, el cluster Couchbase verá que los nodos están

El operador está constantemente observando la definición del cluster y verá que el grupo de servidores se ha perdido, y hace girar los 3 pods, restablece las reclamaciones en los PVs y realiza la recuperación del nodo delta, y finalmente realiza la operación de reequilibrio y el cluster vuelve a estar sano. Todo ello sin intervención del usuario.

Después de algún tiempo, el clúster está de vuelta y en funcionamiento.

De los registros del operador,

podemos ver que el clúster se reequilibra automáticamente.

Epílogo

La diferenciación sostenida es clave para nuestra tecnología. Hemos añadido un buen número de nuevas características de soporte. Con todas estas características de soporte de grado empresarial, permiten al usuario final encontrar los problemas más rápido y ayudar a poner en funcionamiento el Operador Couchbase en sus entornos de una manera más rápida y eficiente. Estamos muy entusiasmados con esta versión, ¡pruébala!

Referencias:

https://docs.couchbase.com/operator/1.2/whats-new.html

https://www.couchbase.com/downloads

https://docs.couchbase.com/server/6.0/manage/manage-groups/manage-groups.html

Libro del Operador Autónomo K8s de @AnilKumar

https://info.couchbase.com/rs/302-GJY-034/images/Kubernetes_ebook.pdf

https://docs.couchbase.com/operator/1.2/tls.html

Todos los archivos yaml y archivos de ayuda utilizados para este blog se pueden encontrar aquí