Cormac Hogan es Director y Jefe de Tecnología en la Oficina del Director de Tecnología de la Unidad de Negocio de Almacenamiento y Disponibilidad (SABU) de VMware.
Bio: Me incorporé a VMware en abril de 2005 y anteriormente he desempeñado funciones en las organizaciones de ingeniería, marketing técnico y soporte técnico de VMware. He escrito una serie de libros blancos relacionados con el almacenamiento y he dado numerosas presentaciones sobre las mejores prácticas de almacenamiento y las características de almacenamiento de vSphere. También soy coautor de los libros "Essential Virtual SAN" y "vSAN 6.7 Deep Dive".
Un primer vistazo al Operador Autónomo Couchbase
Hace unas semanas, He echado un vistazo a Heptio Velero, antes conocido como Ark. Velero proporciona capacidades de copia de seguridad y restauración para aplicaciones nativas de la nube. Durante esa investigación, he utilizado una base de datos Couchbase como mi aplicación de elección para la copia de seguridad / restauración. Después de hablar con el equipo de Couchbase en relación con esa entrada de blog, me recomendaron encarecidamente que probara el nuevo Couchbase Autonomous Operator en lugar del método StatefulSet que estaba utilizando para la aplicación. Couchbase habla de las ventajas del enfoque del operador sobre StatefulSets aquí.
Ahora bien, aunque Couchbase proporciona pasos sobre cómo desplegar Couchbase con su operador, lo crean en el espacio de nombres por defecto de K8s. En mi prueba, quiero poner Couchbase en su propio espacio de nombres. Los pasos proporcionados aquí se proporcionan para comenzar con el nuevo operador Couchbase, que se ejecuta en la infraestructura vSphere y vSAN, en su propio espacio de nombres de Kubernetes. También hablo de algunos problemas con la herramienta de generación de carga incluida, llamada pillowfight.
Couchbase proporciona instrucciones preceptivas sobre cómo empezar con su operador aquí. Incluye todos los archivos de configuración necesarios. Algunas cosas sobre el operador:
- Cuando se carga, descarga la imagen Docker Operator especificada en el archivo operador.yaml archivo. Utiliza una construcción de despliegue para que pueda reiniciarse si el pod en el que se está ejecutando muere.
- Crea la definición personalizada de recursos (CRD) de CouchbaseCluster.
- Comienza a escuchar eventos de CouchbaseCluster.
Hice algunas modificaciones para permitir que Couchbase se ejecute en su propio espacio de nombres:
- En primer lugar he creado un nuevo espacio de nombres (obviamente) llamado couchbase.
- Cuando se creó el rol de clúster, creé la cuenta de servicio en el nuevo espacio de nombres de couchbase y luego asigné el rol de clúster a esa cuenta de servicio utilizando un enlace de rol de clúster.
- He modificado el operador.yaml para incluir un metadata.namespace=couchbase para que se aplique al espacio de nombres couchbase
Monitorizando los logs del pod operador couchbase, podemos observar los siguientes mensajes de inicio:
|
1 2 3 4 5 6 7 8 9 10 |
$ kubectl logs couchbase-operator-6fcfbd8599-zqsh2 -n couchbase time="2019-03-20T09:27:41Z" level=info msg="couchbase-operator v1.1.0 (release)" module=main time="2019-03-20T09:27:41Z" level=info msg="Obtaining resource lock" module=main time="2019-03-20T09:27:41Z" level=info msg="Starting event recorder" module=main time="2019-03-20T09:27:41Z" level=info msg="Attempting to be elected the couchbase-operator leader" module=main time="2019-03-20T09:27:41Z" level=info msg="Event(v1.ObjectReference{Kind:\"Endpoints\", Namespace:\"couchbase\", Name:\"couchbase-operator\", UID:\"68fece18-4af2-11e9-be9b-005056a24d92\", APIVersion:\"v1\", ResourceVersion:\"1596774\", FieldPath:\"\"}): type: 'Normal' reason: 'LeaderElection' couchbase-operator-6fcfbd8599-zqsh2 became leader" module=event_recorder time="2019-03-20T09:27:41Z" level=info msg="I'm the leader, attempt to start the operator" module=main time="2019-03-20T09:27:41Z" level=info msg="Creating the couchbase-operator controller" module=main time="2019-03-20T09:27:46Z" level=info msg="CRD initialized, listening for events..." module=controller time="2019-03-20T09:27:46Z" level=info msg="starting couchbaseclusters controller" |
- Lo coloqué en el espacio de nombres de couchbase con la etiqueta metadatos.namespace entrada
- He puesto spec.disableBucketManagement a true, lo que me permite hacer cambios en los cubos a través de UI/CLI (de lo contrario tengo que hacer todos los cambios a través de ediciones en el archivo YAML).
- Añadí Volúmenes Persistentes para los montajes por defecto y de datos (tuve que crear una nueva StorageClass para el volumeClaimTemplate a utilizar para esto - ver más abajo)
|
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 48 49 50 51 52 53 54 55 56 57 58 59 60 |
apiVersion: couchbase.com/v1 kind: CouchbaseCluster metadata: name: cb-example namespace: couchbase spec: securityContext: fsGroup: 1000 baseImage: couchbase/server version: enterprise-5.5.2 authSecret: cb-example-auth exposeAdminConsole: true disableBucketManagement: true adminConsoleServices: - data cluster: dataServiceMemoryQuota: 256 indexServiceMemoryQuota: 256 searchServiceMemoryQuota: 256 eventingServiceMemoryQuota: 256 analyticsServiceMemoryQuota: 1024 indexStorageSetting: memory_optimized autoFailoverTimeout: 120 autoFailoverMaxCount: 3 autoFailoverOnDataDiskIssues: true autoFailoverOnDataDiskIssuesTimePeriod: 120 autoFailoverServerGroup: false buckets: - name: default type: couchbase memoryQuota: 128 replicas: 1 ioPriority: high evictionPolicy: fullEviction conflictResolution: seqno enableFlush: true enableIndexReplica: false servers: - size: 3 name: all_services services: - index - query - search - eventing - analytics - <strong>data pod: volumeMounts: default: couchbase data: couchbase volumeClaimTemplates: - metadata: name: couchbase spec: storageClassName: "couchbasesc" resources: requests: storage: 1Gi </strong> |
Me estoy saltando los requisitos de autenticación y de usuario que están todos documentados en el sitio de Couchbase. Sin embargo, una vez que la aplicación se ha desplegado, usted debería ser capaz de ver lo siguiente en el operador couchbase pod logs:
|
1 2 3 4 5 6 7 8 9 10 |
$ kubectl logs couchbase-operator-6fcfbd8599-zqsh2 -n couchbase . . time="2019-03-20T09:48:34Z" level=info msg="Watching new cluster" cluster-name=cb-example module=cluster time="2019-03-20T09:48:34Z" level=info msg="Janitor process starting" cluster-name=cb-example module=cluster time="2019-03-20T09:48:34Z" level=info msg="Setting up client for operator communication with the cluster" cluster-name=cb-example module=cluster time="2019-03-20T09:48:34Z" level=info msg="Cluster does not exist so the operator is attempting to create it" cluster-name=cb-example module=cluster time="2019-03-20T09:48:34Z" level=info msg="Creating headless service for data nodes" cluster-name=cb-example module=cluster time="2019-03-20T09:48:34Z" level=info msg="Creating NodePort UI service (cb-example-ui) for data nodes" cluster-name=cb-example module=cluster time="2019-03-20T09:48:34Z" level=info msg="Creating a pod (cb-example-0000) running Couchbase enterprise-5.5.2" cluster-name=cb-example module=cluster |
Y si todo funciona correctamente, puede consultar los pods, los volúmenes persistentes y los servicios a medida que se inicializan.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
$ kubectl get po -n couchbase NAME READY STATUS RESTARTS AGE cb-example-0000 1/1 Running 0 7m8s cb-example-0001 1/1 Running 0 6m7s cb-example-0002 1/1 Running 0 5m14s couchbase-operator-6fcfbd8599-zqsh2 1/1 Running 0 28m $ kubectl get pv -n couchbase NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-100e3c17-40e3-11e9-be9b-005056a24d92 10Gi RWO Delete Bound velero/minio-pv-claim-1 minio-sc 12d pvc-53c6962f-4af5-11e9-be9b-005056a24d92 1Gi RWO Delete Bound couchbase/pvc-couchbase-cb-example-0000-00-default couchbasesc 7m51s pvc-5b30f298-4af5-11e9-be9b-005056a24d92 1Gi RWO Delete Bound couchbase/pvc-couchbase-cb-example-0000-01-data couchbasesc 7m44s pvc-795bcf7b-4af5-11e9-be9b-005056a24d92 1Gi RWO Delete Bound couchbase/pvc-couchbase-cb-example-0001-00-default couchbasesc 6m51s pvc-7edc6a4d-4af5-11e9-be9b-005056a24d92 1Gi RWO Delete Bound couchbase/pvc-couchbase-cb-example-0001-01-data couchbasesc 6m43s pvc-97e9f6a9-4af5-11e9-be9b-005056a24d92 1Gi RWO Delete Bound couchbase/pvc-couchbase-cb-example-0002-00-data couchbasesc 6m2s pvc-9bcc3d4d-4af5-11e9-be9b-005056a24d92 1Gi RWO Delete Bound couchbase/pvc-couchbase-cb-example-0002-01-default couchbasesc 5m50s $ kubectl get svc -n couchbase NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cb-example ClusterIP None 8091/TCP,18091/TCP 8m55s |
- Siga los pasos documentados para configurar el ClusterRole de couchbase
- Crear el espacio de nombres couchbase - kubectl create ns couchbase
- Crear la cuenta de servicio de operador couchbase en el espacio de nombres couchbase - kubectl create serviceaccount couchbase-operator -namespace couchbase
- Crear el operador (modificado para el espacio de nombres couchbase) - kubectl create -f operador.yaml
- Crear los secretos necesarios (modificados para el namespac de couchbase) - kubectl create -f secreto.yaml
- Crear el cluster couchbase usando cbopctl -. cbopctl create -f couchbase-cluster-sc.yaml
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
apiVersion: batch/v1 kind: Job metadata: name: pillowfight namespace: couchbase spec: template: metadata: name: pillowfight spec: containers: - name: pillowfight image: couchbaseutils/pillowfight:v2.9.3 command: ["cbc-pillowfight", "-U", "couchbase://cb-example-0000.cb-example.couchbase.svc.cluster.local/default?select_bucket=true", "-I", "10000", "-B", "1000", "-c", "10", "-t", "1", "-P", "password"] restartPolicy: Never |
La única diferencia para el cormac cubo es la sintaxis del comando es ligeramente diferente:
|
1 2 3 4 5 6 7 8 9 |
$ kubectl get po -n couchbase NAME READY STATUS RESTARTS AGE cb-example-0000 1/1 Running 0 20m cb-example-0001 1/1 Running 0 19m cb-example-0002 1/1 Running 0 18m couchbase-operator-6fcfbd8599-ggv98 1/1 Running 0 24m create-user-dk6xg 0/1 Completed 0 89s pillowfight-fqvgp 0/1 Completed 0 70s pillowfightcormac-dmqnf 0/1 Completed 0 7s |
Y lo que es más importante, si echamos un vistazo a la interfaz de usuario de Couchbase, veremos que ahora tenemos 1.000 elementos en cada cubo:
Y ya está. Estás listo y funcionando con tu operador Couchbase. Y para terminar, esto se aprovisionó en un clúster K8s sobre una infraestructura VMware PKS, vSphere y vSAN. BTW, el problema con pillowfight fue reportado aquí (el problema está resuelto).
