{"id":5093,"date":"2018-05-08T06:00:56","date_gmt":"2018-05-08T13:00:56","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=5093"},"modified":"2024-09-12T01:27:29","modified_gmt":"2024-09-12T08:27:29","slug":"certification-of-the-couchbase-autonomous-operator","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/certification-of-the-couchbase-autonomous-operator\/","title":{"rendered":"Certificaci\u00f3n del Operador Aut\u00f3nomo Couchbase"},"content":{"rendered":"

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.<\/span><\/p>\n

Ejecutar y gestionar un cl\u00faster de Couchbase es ahora mucho m\u00e1s f\u00e1cil con la introducci\u00f3n de la aplicaci\u00f3n <\/span>Operador aut\u00f3nomo de Couchbase para Kubernetes<\/span><\/a>. Ahora los usuarios pueden desplegar Couchbase sobre Kubernetes y hacer que Couchbase Autonomous Operator se encargue de gran parte de la gesti\u00f3n del cl\u00faster, como la recuperaci\u00f3n de fallos y el escalado multidimensional. Sin embargo, los usuarios pueden sentirse un poco inc\u00f3modos simplemente sent\u00e1ndose y viendo como Couchbase Autonomous Operator hace lo suyo. Para aliviar algunas de sus preocupaciones, esta serie de blog de tres partes recorrer\u00e1 las diferentes formas en que el equipo de Ingenier\u00eda de Calidad aqu\u00ed en Couchbase da a nuestros clientes la paz de la mente cuando se ejecuta Couchbase en Kubernetes.<\/span><\/p>\n

Esta serie de blogs destacar\u00e1 tres tipos de pruebas que hacemos para Couchbase en Kubernetes. El primer post de la serie se centrar\u00e1 en las pruebas manuales. El segundo post tratar\u00e1 sobre c\u00f3mo probar el Operador Aut\u00f3nomo de Couchbase. Y el tercer post mostrar\u00e1 a nuestros usuarios c\u00f3mo probar las instancias de Couchbase ellos mismos con testrunner, nuestra suite de pruebas funcionales.<\/span><\/p>\n

Fase 1: <\/b>Certificaci\u00f3n manual del operador aut\u00f3nomo Couchbase<\/b><\/h4>\n

Las pruebas manuales son a menudo aburridas en comparaci\u00f3n con la emoci\u00f3n de las pruebas automatizadas, pero con Kubernetes en realidad puede ser muy divertido. En este post vamos a caminar a trav\u00e9s de la configuraci\u00f3n de la <\/span>Aplicaci\u00f3n de ejemplo de viajes Couchbase<\/span><\/a> con un cl\u00faster Couchbase gestionado por el operador como almac\u00e9n de datos, todo en Kubernetes. Una vez que la aplicaci\u00f3n y el cl\u00faster est\u00e9n configurados en Kubernetes, probaremos algunos escenarios de escalado y fallos.<\/span><\/p>\n

En las siguientes secciones trataremos:<\/span><\/p>\n

0: Requisitos previos y configuraci\u00f3n<\/span><\/p>\n

1: Despliegue del cl\u00faster<\/span><\/p>\n

2: Configuraci\u00f3n del cl\u00faster<\/span><\/p>\n

3: Despliegue de aplicaciones<\/span><\/p>\n

4: Verificaci\u00f3n<\/span><\/p>\n

Requisitos previos y configuraci\u00f3n:<\/b><\/h5>\n

Para configurar esa aplicaci\u00f3n de ejemplo de viaje usando Couchbase en Kubernetes, usaremos minikube. Las instrucciones para configurar minikube se pueden encontrar aqu\u00ed: <\/span>https:\/\/kubernetes.io\/docs\/getting-started-guides\/minikube\/<\/span><\/a>.<\/span><\/p>\n

Una vez que minikube est\u00e1 configurado, es posible que desee aumentar el recuento de memoria y CPU. Usted tendr\u00e1 que traer el tablero de instrumentos Kubernetes para supervisar el cl\u00faster utilizando:<\/span> salpicadero minikube<\/span><\/em><\/p>\n

Despliegue de cl\u00fasteres:<\/b><\/h5>\n

Despu\u00e9s de configurar minikube, necesitaremos inicializar el Couchbase Autonomous Operator y el cluster Couchbase que el operador gestionar\u00e1. El siguiente archivo YAML le dir\u00e1 al maestro de Kubernetes que cree un despliegue de Couchbase Autonomous Operator:<\/span>
\n<\/span><\/p>\n

deployment.yaml\r\n---\r\napiVersion: extensions\/v1beta1\r\nkind: Deployment\r\nmetadata:\r\n \u00a0name: couchbase-operator\r\nspec:\r\n \u00a0replicas: 1\r\n \u00a0template:\r\n \u00a0\u00a0\u00a0metadata:\r\n \u00a0\u00a0\u00a0\u00a0\u00a0labels:\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0name: couchbase-operator\r\n \u00a0\u00a0\u00a0spec:\r\n \u00a0\u00a0\u00a0\u00a0\u00a0containers:\r\n \u00a0\u00a0\u00a0\u00a0\u00a0- name: couchbase-operator\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0image: couchbase\/k8s-operator:0.8.0-beta\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0env:\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0- name: MY_POD_NAMESPACE\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0valueFrom:\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0fieldRef:\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0fieldPath: metadata.namespace\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0- name: MY_POD_NAME\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0valueFrom:\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0fieldRef:\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0fieldPath: metadata.name\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ports:\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0- name: readiness-port\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0containerPort: 8080\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0readinessProbe:\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0httpGet:\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0path: \/readyz\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0port: readiness-port\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0initialDelaySeconds: 3\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0periodSeconds: 3\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0failureThreshold: 19<\/pre>\n
Cree un archivo llamado despliegue.yaml<\/em> y enviar este YAML a Kubernetes con: kubectl create -f ruta\/a\/deployment.yaml<\/em>. Tras un par de segundos, el despliegue del operador deber\u00eda aparecer en el panel de control de Kubernetes.<\/span><\/p>\n
\"\"<\/p>\n
Figura 1: Estado del cl\u00faster Kubernetes tras desplegar el Operador Aut\u00f3nomo Couchbase.<\/span><\/em><\/p>\n
A continuaci\u00f3n, se debe proporcionar un secreto a Kubernetes para que el Operador Aut\u00f3nomo Couchbase pueda gestionar los nodos Couchbase.<\/span><\/p>\n
secret.yaml\r\n---\r\napiVersion: v1\r\nkind: Secret\r\nmetadata:\r\n \u00a0name: cb-example-auth\r\ntype: Opaque\r\ndata:\r\n \u00a0username: QWRtaW5pc3RyYXRvcg==\r\n \u00a0password: cGFzc3dvcmQ=\r\n<\/pre>\n
Cree un archivo llamado secret.yaml y env\u00ede el secreto a Kubernetes con lo siguiente: kubectl create -f ruta\/a\/secreto.yaml.<\/em><\/span><\/p>\n
A continuaci\u00f3n, vamos a crear un cl\u00faster de 2 nodos Couchbase. El siguiente YAML especifica un cluster con dos nodos, dos buckets (default y travel-sample), y todos los servicios habilitados:<\/span><\/p>\n
cb-cluster.yaml\r\n---\r\napiVersion: couchbase.database.couchbase.com\/v1beta1\r\nkind: CouchbaseCluster\r\nmetadata:\r\n \u00a0name: cb-example\r\nspec:\r\n \u00a0baseImage: couchbase\/server\r\n \u00a0version: enterprise-5.0.1\r\n \u00a0authSecret: cb-example-auth\r\n \u00a0exposeAdminConsole: true\r\n \u00a0paused: false\r\n \u00a0cluster:\r\n \u00a0\u00a0\u00a0dataServiceMemoryQuota: 256\r\n \u00a0\u00a0\u00a0indexServiceMemoryQuota: 256\r\n \u00a0\u00a0\u00a0searchServiceMemoryQuota: 256\r\n \u00a0\u00a0\u00a0indexStorageSetting: memory_optimized\r\n \u00a0\u00a0\u00a0autoFailoverTimeout: 10\r\n \u00a0buckets:\r\n \u00a0\u00a0\u00a0- name: default\r\n \u00a0\u00a0\u00a0\u00a0\u00a0type: couchbase\r\n \u00a0\u00a0\u00a0\u00a0\u00a0memoryQuota: 128\r\n \u00a0\u00a0\u00a0\u00a0\u00a0replicas: 1\r\n \u00a0\u00a0\u00a0\u00a0\u00a0ioPriority: high\r\n \u00a0\u00a0\u00a0\u00a0\u00a0evictionPolicy: fullEviction\r\n \u00a0\u00a0\u00a0\u00a0\u00a0conflictResolution: seqno\r\n \u00a0\u00a0\u00a0\u00a0\u00a0enableFlush: true\r\n \u00a0\u00a0\u00a0\u00a0\u00a0enableIndexReplica: false\r\n \u00a0\u00a0\u00a0- name: travel-sample\r\n \u00a0\u00a0\u00a0\u00a0\u00a0type: couchbase\r\n \u00a0\u00a0\u00a0\u00a0\u00a0memoryQuota: 128\r\n \u00a0\u00a0\u00a0\u00a0\u00a0replicas: 1\r\n \u00a0\u00a0\u00a0\u00a0\u00a0ioPriority: high\r\n \u00a0\u00a0\u00a0\u00a0\u00a0evictionPolicy: fullEviction\r\n \u00a0\u00a0\u00a0\u00a0\u00a0conflictResolution: seqno\r\n \u00a0\u00a0\u00a0\u00a0\u00a0enableFlush: true\r\n \u00a0\u00a0\u00a0\u00a0\u00a0enableIndexReplica: false\r\n \u00a0servers:\r\n \u00a0\u00a0\u00a0- size: 2\r\n \u00a0\u00a0\u00a0\u00a0\u00a0name: all_services\r\n \u00a0\u00a0\u00a0\u00a0\u00a0services:\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0- data\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0- index\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0- query\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0- search\r\n \u00a0\u00a0\u00a0\u00a0\u00a0dataPath: \/opt\/couchbase\/var\/lib\/couchbase\/data\r\n \u00a0\u00a0\u00a0\u00a0\u00a0indexPath: \/opt\/couchbase\/var\/lib\/couchbase\/data<\/pre>\n
Enviar la configuraci\u00f3n del cl\u00faster con: kubectl create -f ruta\/a\/cb-cluster.yaml<\/em>.<\/span><\/p>\n
\"\"<\/p>\n
Figura 2: Estado del cl\u00faster Kubernetes tras escalar a 2 nodos Couchbase.<\/span><\/em><\/p>\n
Configuraci\u00f3n del cl\u00faster:<\/b><\/h5>\n
Ahora que tenemos un cl\u00faster de dos nodos gestionado por el Operador Aut\u00f3nomo de Couchbase, las actualizaciones de la configuraci\u00f3n del cl\u00faster deben realizarse en el archivo cb-cluster.yaml y reenviarse a Kubernetes. Si se realizan cambios manualmente a trav\u00e9s de la interfaz de usuario de Couchbase, el operador tomar\u00e1 medidas para realinear el cl\u00faster con la configuraci\u00f3n especificada en cb-cluster.yaml. Para realizar cambios en el cl\u00faster, primero realice los cambios en cb-cluster.yaml y, a continuaci\u00f3n, actualice Kubernetes con: kubectl apply -f ruta\/a\/cb-cluster.yaml<\/em><\/span><\/p>\n
El siguiente paso es cargar los datos de la muestra de viaje y las definiciones de \u00edndice en el bucket de muestra de viaje del cl\u00faster. El siguiente comando llamar\u00e1 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\u00f1a -b viaje-muestra -f muestra -d \/opt\/couchbase\/muestras\/viaje-muestra.zip \u00a0<\/em><\/span><\/p>\n
Despliegue de aplicaciones:<\/b><\/h5>\n
El cl\u00faster ya est\u00e1 configurado, pero la aplicaci\u00f3n travel-sample no. Ahora, tenemos que construir una imagen docker que Kubernetes utilizar\u00e1 para la aplicaci\u00f3n. El dockerfile a continuaci\u00f3n bajar\u00e1 la aplicaci\u00f3n travel-sample de mi fork en github, https:\/\/github.com\/korry8911\/try-cb-python, e instalar\u00e1 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\u00f3n en el mismo espacio de nombres de Kubernetes. <\/span><\/p>\n
#travel.py (modified)\r\n#https:\/\/github.com\/korry8911\/try-cb-python\/blob\/master\/travel.py#L20\r\n\r\nconfig.load_incluster_config()\r\nv1 = client.CoreV1Api()\r\nprint(\"Finding Couchbase Nodes:\")\r\nret = v1.list_pod_for_all_namespaces(watch=False)\r\ncbip = []\r\nfor i in ret.items:\r\n \u00a0\u00a0\u00a0print(\"%s\\t%s\\t%s\" % (i.status.pod_ip, i.metadata.namespace, i.metadata.name))\r\n \u00a0\u00a0\u00a0if 'cb-example' in i.metadata.name:\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0cbip.append(i.status.pod_ip)<\/pre>\n
#Dockerfile\r\nFROM ubuntu:14.04\r\nRUN apt-get update\r\nRUN apt-get install -y gcc g++ make cmake git-core libevent-dev libev-dev libssl-dev libffi-dev psmisc iptables zip unzip python-dev python-pip vim curl\r\n\r\n# build libcouchbase\r\nRUN git clone git:\/\/github.com\/couchbase\/libcouchbase.git && \\\r\n \u00a0\u00a0\u00a0mkdir libcouchbase\/build\r\n\r\nWORKDIR libcouchbase\/build\r\nRUN ..\/cmake\/configure --prefix=\/usr && \\\r\n \u00a0\u00a0\u00a0\u00a0\u00a0make && \\\r\n \u00a0\u00a0\u00a0\u00a0\u00a0make install\r\n\r\nWORKDIR \/\r\nRUN git clone https:\/\/github.com\/korry8911\/try-cb-python.git\r\n\r\nWORKDIR try-cb-python\r\nARG BRANCH=5.0\r\nRUN git checkout $BRANCH\r\nRUN cat travel.py\r\n\r\n# install python deps\r\nRUN pip2 install --upgrade packaging appdirs\r\nRUN pip install -U pip setuptools\r\nRUN pip install paramiko &&\\\r\n \u00a0\u00a0\u00a0pip install gevent &&\\\r\n \u00a0\u00a0\u00a0pip install boto &&\\\r\n \u00a0\u00a0\u00a0pip install httplib2 &&\\\r\n \u00a0\u00a0\u00a0pip install pyyaml &&\\\r\n \u00a0\u00a0\u00a0pip install couchbase\r\n\r\nRUN pip install -r requirements.txt\r\nCOPY entrypoint.sh entrypoint.sh\r\nRUN chmod +x .\/entrypoint.sh\r\nENTRYPOINT [\"sh\", \"entrypoint.sh\"]<\/pre>\n
#entrypoint.sh\r\n#!\/bin\/bash\r\npython travel.py\r\nwhile true; do sleep 1000; done<\/pre>\n
Construye la imagen docker de la aplicaci\u00f3n travel-sample con: docker build -t your-dockerhub-handle\/travel-sample:latest<\/em>.\u00a0<\/span>La imagen docker necesita ser cargada en el nodo trabajador Kubernetes. La forma m\u00e1s f\u00e1cil de hacerlo es tirando de la imagen desde dockerhub. Empuje la imagen travel-sample con:\u00a0<\/span>docker push your-dockerhub-handle\/travel-sample:latest.<\/span><\/em><\/p>\n
La configuraci\u00f3n de la aplicaci\u00f3n travel-sample se define en el siguiente archivo. Aseg\u00farate de a\u00f1adir tu docker handle.<\/span><\/p>\n
travel-sample.yaml \r\n---\r\napiVersion: extensions\/v1beta1\r\nkind: Deployment\r\nmetadata:\r\n \u00a0name: travel-sample\r\nspec:\r\n \u00a0replicas: 1\r\n \u00a0template:\r\n \u00a0\u00a0\u00a0metadata:\r\n \u00a0\u00a0\u00a0\u00a0\u00a0labels:\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0name: travel-sample\r\n \u00a0\u00a0\u00a0spec:\r\n \u00a0\u00a0\u00a0\u00a0\u00a0containers:\r\n \u00a0\u00a0\u00a0\u00a0\u00a0- name: travel-sample\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0image: your-dockerhub-handle\/travel-sample:latest<\/pre>\n
Carga la aplicaci\u00f3n de muestra de viaje con: kubectl create -f ruta\/para\/viajar-muestra.yaml.<\/em><\/span><\/p>\n
\"\"<\/p>\n
Figura 3: Estado del cl\u00faster Kubernetes tras desplegar la aplicaci\u00f3n de ejemplo de viaje.<\/span><\/em><\/p>\n
Kubernetes, por defecto, no permite el acceso a los pods desde fuera del cl\u00faster. Por lo tanto, para llegar a la aplicaci\u00f3n de muestra de viaje, se debe crear un servicio de nodo-puerto para representar el puerto en el que la aplicaci\u00f3n de muestra de viaje escucha las solicitudes entrantes.<\/span><\/p>\n
nodeport.yaml\r\n---\r\nkind: Service\r\napiVersion: v1\r\nmetadata:\r\n \u00a0name: travelsample\r\nspec:\r\n \u00a0type: NodePort\r\n  \u00a0ports:\r\n \u00a0\u00a0\u00a0- port: 8080\r\n \u00a0\u00a0\u00a0\u00a0\u00a0nodePort: 32000\r\n \u00a0selector:\r\n \u00a0\u00a0\u00a0name: travelsample<\/pre>\n
Crear el servicio de nodo-puerto para el viaje-muestra con: kubectl create -f ruta\/a\/nodeport.yaml.<\/em><\/span><\/p>\n
\"\"<\/p>\n
Figura 4: Estado del cl\u00faster Kubernetes tras a\u00f1adir un servicio nodo-puerto.<\/span><\/em><\/p>\n
Dado que estamos ejecutando la aplicaci\u00f3n en minikube, debemos acceder a la aplicaci\u00f3n de ejemplo de viaje ejecutando: servicio minikube travelsample.<\/em><\/span><\/p>\n
Verificaci\u00f3n:<\/b><\/h5>\n
Ahora que hemos jugado con la aplicaci\u00f3n travel-sample, vamos a escalar el cl\u00faster Couchbase en un nodo. Para ello, cambie el par\u00e1metro de tama\u00f1o en la secci\u00f3n del servidor del archivo cb-cluster.yaml de 2 a 3. A continuaci\u00f3n, env\u00ede los cambios a Kubernetes con: kubectl apply -f ruta\/a\/cb-cluster.yaml.<\/em><\/span><\/p>\n
\"\"<\/p>\n
Figura 5: Estado del cl\u00faster Kubernetes tras escalar a 3 nodos Couchbase.<\/span><\/p>\n
El cluster de Couchbase tiene ahora 3 nodos, que son suficientes para probar la caracter\u00edstica de autofailover de los Operadores Aut\u00f3nomos de Couchbase. Vamos a matar un nodo de Couchbase para simular un escenario de fallo y ver c\u00f3mo el Operador Aut\u00f3nomo de Couchbase reequilibra autom\u00e1ticamente un nuevo nodo en el cl\u00faster. Elimine un pod de Couchbase accediendo a Pods en el panel de control de Kubernetes y eliminando el pod cb-example-0002.<\/span><\/p>\n
Despu\u00e9s del per\u00edodo de tiempo de espera de autofailover de 10 segundos, el Operador Aut\u00f3nomo de Couchbase expulsar\u00e1 el nodo fallido del cl\u00faster, inicializar\u00e1 un nuevo nodo, y reequilibrar\u00e1 el nodo en el cl\u00faster. Durante este proceso, los usuarios pueden jugar con la aplicaci\u00f3n de ejemplo de viaje sin ninguna interrupci\u00f3n del servicio.<\/span><\/p>\n
\"\"<\/p>\n
Figura 6: Estado del cl\u00faster Kubernetes tras la recuperaci\u00f3n de un fallo en un nodo Couchbase.<\/span><\/em><\/p>\n
Conclusi\u00f3n:<\/b><\/h5>\n
El Operador Aut\u00f3nomo Couchbase elimina muchas de las molestias de ejecutar un cl\u00faster Couchbase en <\/span>Open Source Kubernetes y\/o Enterprise Red Hat OpenShift Container Platform. El estado deseado del cl\u00faster se mantiene autom\u00e1ticamente incluso ante el fallo de un nodo. La certificaci\u00f3n manual de la funci\u00f3n de recuperaci\u00f3n de nodos es divertida pero se requieren m\u00e1s pruebas. En el pr\u00f3ximo post profundizaremos en nuestro enfoque de pruebas funcionales para otras caracter\u00edsticas del Operador Aut\u00f3nomo Couchbase.<\/span><\/p>\n
\u00bfListo para comprobar la Beta?<\/h2>\n