Couchbase Autonomous Operator te permite ejecutar despliegues de Couchbase de forma nativa en Open Source Kubernetes o Enterprise Red Hat OpenShift Container Platform. Me complace anunciar la disponibilidad de Couchbase Autonomous Operator 0.8 Beta Refresh.
Ejecutar y gestionar un clúster de Couchbase es ahora mucho más fácil con la introducción de la aplicación Operador autónomo de Couchbase para Kubernetes. Ahora los usuarios pueden desplegar Couchbase sobre Kubernetes y hacer que Couchbase Autonomous Operator se encargue de gran parte de la gestión del clúster, como la recuperación de fallos y el escalado multidimensional. Sin embargo, los usuarios pueden sentirse un poco incómodos simplemente sentándose y viendo como Couchbase Autonomous Operator hace lo suyo. Para aliviar algunas de sus preocupaciones, esta serie de blog de tres partes recorrerá las diferentes formas en que el equipo de Ingeniería de Calidad aquí en Couchbase da a nuestros clientes la paz de la mente cuando se ejecuta Couchbase en Kubernetes.
Esta serie de blogs destacará tres tipos de pruebas que hacemos para Couchbase en Kubernetes. El primer post de la serie se centrará en las pruebas manuales. El segundo post tratará sobre cómo probar el Operador Autónomo de Couchbase. Y el tercer post mostrará a nuestros usuarios cómo probar las instancias de Couchbase ellos mismos con testrunner, nuestra suite de pruebas funcionales.
Fase 1: Certificación manual del operador autónomo Couchbase
Las pruebas manuales son a menudo aburridas en comparación con la emoción de las pruebas automatizadas, pero con Kubernetes en realidad puede ser muy divertido. En este post vamos a caminar a través de la configuración de la Aplicación de ejemplo de viajes Couchbase con un clúster Couchbase gestionado por el operador como almacén de datos, todo en Kubernetes. Una vez que la aplicación y el clúster estén configurados en Kubernetes, probaremos algunos escenarios de escalado y fallos.
En las siguientes secciones trataremos:
0: Requisitos previos y configuración
1: Despliegue del clúster
2: Configuración del clúster
3: Despliegue de aplicaciones
4: Verificación
Requisitos previos y configuración:
Para configurar esa aplicación de ejemplo de viaje usando Couchbase en Kubernetes, usaremos minikube. Las instrucciones para configurar minikube se pueden encontrar aquí: https://kubernetes.io/docs/getting-started-guides/minikube/.
Una vez que minikube está configurado, es posible que desee aumentar el recuento de memoria y CPU. Usted tendrá que traer el tablero de instrumentos Kubernetes para supervisar el clúster utilizando: salpicadero minikube
Despliegue de clústeres:
Después de configurar minikube, necesitaremos inicializar el Couchbase Autonomous Operator y el cluster Couchbase que el operador gestionará. El siguiente archivo YAML le dirá al maestro de Kubernetes que cree un despliegue de Couchbase Autonomous Operator:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
despliegue.yaml --- apiVersion: extensions/v1beta1 amable: Despliegue metadatos: nombre: operador couchbase spec: réplicas: 1 plantilla: metadatos: etiquetas: nombre: operador couchbase spec: contenedores: - nombre: operador couchbase imagen: couchbase/k8s-operator:0.8.0-beta env: - nombre: MY_POD_NAMESPACE valorDesde: fieldRef: fieldPath: metadata.namespace - nombre: MY_POD_NAME valorDesde: fieldRef: fieldPath: metadata.name puertos: - nombre: preparación-puerto containerPort: 8080 readinessProbe: httpGet: ruta: /readyz puerto: preparación-puerto initialDelaySeconds: 3 periodSeconds: 3 failureThreshold: 19 |
Cree un archivo llamado despliegue.yaml y enviar este YAML a Kubernetes con: kubectl create -f ruta/a/deployment.yaml. Tras un par de segundos, el despliegue del operador debería aparecer en el panel de control de Kubernetes.
Figura 1: Estado del clúster Kubernetes tras desplegar el Operador Autónomo Couchbase.
A continuación, se debe proporcionar un secreto a Kubernetes para que el Operador Autónomo Couchbase pueda gestionar los nodos Couchbase.
|
1 2 3 4 5 6 7 8 9 10 |
secreto.yaml --- apiVersion: v1 amable: Secreto metadatos: nombre: cb-example-auth tipo: Opaco datos: nombre de usuario: QWRtaW5pc3RyYXRvcg== contraseña: cGFzc3dvcmQ= |
Cree un archivo llamado secret.yaml y envíe el secreto a Kubernetes con lo siguiente: kubectl create -f ruta/a/secreto.yaml.
A continuación, vamos a crear un clúster de 2 nodos Couchbase. El siguiente YAML especifica un cluster con dos nodos, dos buckets (default y travel-sample), y todos los servicios habilitados:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
cb-cluster.yaml --- apiVersion: couchbase.database.couchbase.com/v1beta1 amable: CouchbaseCluster metadatos: nombre: cb-ejemplo spec: baseImage: couchbase/servidor versión: enterprise-5.0.1 authSecret: cb-example-auth exposeAdminConsoleVerdadero en pausa: falso grupo: dataServiceMemoryQuota: 256 indexServiceMemoryQuota: 256 searchServiceMemoryQuota: 256 indexStorageSetting: memoria_optimizada autoFailoverTimeout: 10 cubos: - nombre: por defecto tipo: couchbase memoryQuota: 128 réplicas: 1 ioPriority: alto política de desalojo: fullEviction resolución de conflictos: seqno enableFlushVerdadero enableIndexReplica: falso - nombre: viaje-muestra tipo: couchbase memoryQuota: 128 réplicas: 1 ioPriority: alto política de desalojo: fullEviction resolución de conflictos: seqno enableFlushVerdadero enableIndexReplica: falso servidores: - tamaño: 2 nombre: todos_servicios servicios: - datos - índice - consulta - busque en ruta de datos: /opt/couchbase/var/lib/couchbase/data indexPath: /opt/couchbase/var/lib/couchbase/data |
Enviar la configuración del clúster con: kubectl create -f ruta/a/cb-cluster.yaml.
Figura 2: Estado del clúster Kubernetes tras escalar a 2 nodos Couchbase.
Configuración del clúster:
Ahora que tenemos un clúster de dos nodos gestionado por el Operador Autónomo de Couchbase, las actualizaciones de la configuración del clúster deben realizarse en el archivo cb-cluster.yaml y reenviarse a Kubernetes. Si se realizan cambios manualmente a través de la interfaz de usuario de Couchbase, el operador tomará medidas para realinear el clúster con la configuración especificada en cb-cluster.yaml. Para realizar cambios en el clúster, primero realice los cambios en cb-cluster.yaml y, a continuación, actualice Kubernetes con: kubectl apply -f ruta/a/cb-cluster.yaml
El siguiente paso es cargar los datos de la muestra de viaje y las definiciones de índice en el bucket de muestra de viaje del clúster. El siguiente comando llamará a cbimport en el pod cb-example-0000: kubectl exec pod cb-example-0000 -ti /opt/couchbase/bin/cbimport json -c 127.0.0.1:8091 -u Administrador -p contraseña -b viaje-muestra -f muestra -d /opt/couchbase/muestras/viaje-muestra.zip
Despliegue de aplicaciones:
El clúster ya está configurado, pero la aplicación travel-sample no. Ahora, tenemos que construir una imagen docker que Kubernetes utilizará para la aplicación. El dockerfile a continuación bajará la aplicación travel-sample de mi fork en github, https://github.com/korry8911/try-cb-python, e instalará todas las dependencias. El archivo travel.py ha sido modificado para esta entrada de blog para utilizar el cliente python de Kubernetes para obtener las IPs de los nodos Couchbase en ejecución en el mismo espacio de nombres de Kubernetes.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
#travel.py (modificado) #https://github.com/korry8911/try-cb-python/blob/master/travel.py#L20 config.cargar_configura_incluster() v1 = cliente.CoreV1Api() imprimir("Encontrando Nodos Couchbase:") ret = v1.lista_pod_para_todos_los_espacios_de_nombre(ver=Falso) cbip = [] para i en ret.artículos: imprimir("%s\t%s\t%s" % (i.estado.pod_ip, i.metadatos.espacio de nombres, i.metadatos.nombre)) si cb-ejemplo en i.metadatos.nombre: cbip.añadir(i.estado.pod_ip) |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
#Dockerfile DESDE ubuntu:14.04 RUN apt-consiga actualización RUN apt-consiga instale -y gcc g++ escriba a cmake git-núcleo libevent-dev libev-dev libssl-dev libffi-dev psmisc iptables zip descomprimir python-dev python-pip vim rizo # build libcouchbase RUN git clonar git://github.com/couchbase/libcouchbase.git && \ mkdir libcouchbase/construya WORKDIR libcouchbase/construya RUN ../cmake/configure --prefijo=/usr && \ escriba a && \ escriba a instale WORKDIR / RUN git clonar https://github.com/korry8911/pruebe-cb-python.git WORKDIR pruebe-cb-python ARG SUCURSAL=5.0 RUN git checkout $BRANCH RUN cat viaje.py # install python deps RUN pip2 instale --actualizar envasado appdirs RUN pip instale -U pip herramientas de configuración RUN pip instale paramiko &&\ pip instale gevent &&\ pip instale boto &&\ pip instale httplib2 &&\ pip instale pyyaml &&\ pip instale couchbase RUN pip instale -r requisitos.txt COPIA punto de entrada.sh punto de entrada.sh RUN chmod +x ./punto de entrada.sh PUNTO DE ENTRADA ["sh", "entrypoint.sh"] |
|
1 2 3 4 |
#entrypoint.sh #!/bin/bash python viaje.py mientras que verdadero; do dormir 1000; hecho |
Construye la imagen docker de la aplicación travel-sample con: docker build -t your-dockerhub-handle/travel-sample:latest. La imagen docker necesita ser cargada en el nodo trabajador Kubernetes. La forma más fácil de hacerlo es tirando de la imagen desde dockerhub. Empuje la imagen travel-sample con: docker push your-dockerhub-handle/travel-sample:latest.
La configuración de la aplicación travel-sample se define en el siguiente archivo. Asegúrate de añadir tu docker handle.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
viaje-muestra.yaml --- apiVersion: extensions/v1beta1 amable: Despliegue metadatos: nombre: viaje-muestra spec: réplicas: 1 plantilla: metadatos: etiquetas: nombre: viaje-muestra spec: contenedores: - nombre: viaje-muestra imagen: tu-dockerhub-manejo/viaje-muestra:latest |
Carga la aplicación de muestra de viaje con: kubectl create -f ruta/para/viajar-muestra.yaml.
Figura 3: Estado del clúster Kubernetes tras desplegar la aplicación de ejemplo de viaje.
Kubernetes, por defecto, no permite el acceso a los pods desde fuera del clúster. Por lo tanto, para llegar a la aplicación de muestra de viaje, se debe crear un servicio de nodo-puerto para representar el puerto en el que la aplicación de muestra de viaje escucha las solicitudes entrantes.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
nodeport.yaml --- amable: Servicio apiVersion: v1 metadatos: nombre: viajesmuestra spec: tipo: PuertoNodo puertos: - puerto: 8080 nodoPuerto: 32000 selector: nombre: viajesmuestra |
Crear el servicio de nodo-puerto para el viaje-muestra con: kubectl create -f ruta/a/nodeport.yaml.
Figura 4: Estado del clúster Kubernetes tras añadir un servicio nodo-puerto.
Dado que estamos ejecutando la aplicación en minikube, debemos acceder a la aplicación de ejemplo de viaje ejecutando: servicio minikube travelsample.
Verificación:
Ahora que hemos jugado con la aplicación travel-sample, vamos a escalar el clúster Couchbase en un nodo. Para ello, cambie el parámetro de tamaño en la sección del servidor del archivo cb-cluster.yaml de 2 a 3. A continuación, envíe los cambios a Kubernetes con: kubectl apply -f ruta/a/cb-cluster.yaml.
Figura 5: Estado del clúster Kubernetes tras escalar a 3 nodos Couchbase.
El cluster de Couchbase tiene ahora 3 nodos, que son suficientes para probar la característica de autofailover de los Operadores Autónomos de Couchbase. Vamos a matar un nodo de Couchbase para simular un escenario de fallo y ver cómo el Operador Autónomo de Couchbase reequilibra automáticamente un nuevo nodo en el clúster. Elimine un pod de Couchbase accediendo a Pods en el panel de control de Kubernetes y eliminando el pod cb-example-0002.
Después del período de tiempo de espera de autofailover de 10 segundos, el Operador Autónomo de Couchbase expulsará el nodo fallido del clúster, inicializará un nuevo nodo, y reequilibrará el nodo en el clúster. Durante este proceso, los usuarios pueden jugar con la aplicación de ejemplo de viaje sin ninguna interrupción del servicio.
Figura 6: Estado del clúster Kubernetes tras la recuperación de un fallo en un nodo Couchbase.
Conclusión:
El Operador Autónomo Couchbase elimina muchas de las molestias de ejecutar un clúster Couchbase en Open Source Kubernetes y/o Enterprise Red Hat OpenShift Container Platform. El estado deseado del clúster se mantiene automáticamente incluso ante el fallo de un nodo. La certificación manual de la función de recuperación de nodos es divertida pero se requieren más pruebas. En el próximo post profundizaremos en nuestro enfoque de pruebas funcionales para otras características del Operador Autónomo Couchbase.
¿Listo para comprobar la Beta?
- Es fácil conseguir la versión beta siguiendo los siguientes pasos Requisitos previos y configuración para desplegar Couchbase Operator en la plataforma Kubernetes u OpenShift.
- Enlace a Dockerfile
- Servidor Couchbase - https://hub.docker.com/_/couchbase/
- Operador Couchbase - https://hub.docker.com/r/couchbase/k8s-operator/
Si tiene alguna pregunta, comentario u opinión adicional, deje un comentario a continuación o publíquelo en https://www.couchbase.com/forums/.
