Siempre que oigo hablar de la primera experiencia de un cliente con el Operador autónomo de Couchbase (CAO) para Kubernetes, su primera pregunta suele ser "¿Cuánto?".
La respuesta es que ya está incluido en su suscripción Enterprise Edition. Contentos de escuchar esto, la mayoría de los clientes pasan a la siguiente etapa de realizar una pequeña Prueba de Concepto (PoC) utilizando el Operador Autónomo de Couchbase.
Si ya utiliza CouchbaseSi estás al tanto de las prácticas de mantenimiento necesarias, la gestión de los nodos de servicio, actualizaciones de versión, etc. También se requiere mantenimiento fuera de Couchbase, como actualizaciones del sistema operativo. Todos estos pasos de mantenimiento cuestan recursos de personal.
La CAO alivia esta presión de recursos de personal, permitiéndole automatizar la gestión de tareas comunes de Couchbase como la configuración, creación, escalado y recuperación de clusters de Couchbase. Al reducir la complejidad de ejecutar un clúster de Couchbase, le permite centrarse en la configuración deseada y no preocuparse por los detalles de la implementación manual y la gestión del ciclo de vida.
A menudo con las mejores intenciones, los clientes se lanzan a una PoC, y a veces es su primera experiencia con Kubernetes (o K8s si eres guay). Pero Couchbase Autonomous Operator es una herramienta compleja: Orquesta operaciones que normalmente realizaría un equipo de ingenieros cualificados gestionando constantemente tu clúster de Couchbase las 24 horas del día. Ayuda a andar con cuidado.
En este caso, es importante que tenga una comprensión básica de Kubernetes y de la CAO. A partir de ahí, construirá una Prueba de Concepto exitosa. Sin estos conocimientos básicos, será difícil (o imposible) solucionar los problemas de su nueva PoC.
Esta entrada de blog te lleva a través de cómo implementar rápidamente un Operador Autónomo Couchbase y un clúster Couchbase.
Antes de sumergirnos
Esta entrada de blog se centra en la CAO y asume un cierto nivel de conocimiento de Kubernetes. Si eres nuevo, o si estás oxidado, un repaso rápido a Kubernetes.
Debido al vasto y complejo ecosistema de Kubernetes, en este artículo vamos a facilitar al máximo la puesta en marcha de un clúster. La CAO es agnóstica a la nube y, por lo tanto, se ejecuta en una multitud de entornos de nube, ya sea su propio clúster Kubernetes o un servicio Kubernetes de su proveedor de nube pública.
En esta entrada del blog, vamos a utilizar Kubernetes en Docker, también conocido como "kind".para ejecutar nodos Kubernetes como contenedores locales, por lo que necesitará tener Docker instalado y en funcionamiento.
Usamos kind por multitud de razones:
- La instalación es rápida y sencilla
- Hay una imagen por defecto para cada versión de Kubernetes
- Podemos poner en marcha un entorno lo antes posible
Incluso amablemente (¿Lo pillas?) le indica cómo interactuar con el clúster Kubernetes y cómo eliminarlo cuando haya terminado. Todo se visualiza desde una sola página y es ideal para una variedad de casos de uso como la integración y entrega/despliegue continuos (CI/CD) y la infraestructura como código (IaC). Para los principiantes, significa que puedes aprovisionar y destruir clústeres fácilmente.
Cómo instalar el tipo
En primer lugar, asegúrate de que tienes Docker instalado. Después, para instalar kind, sigue estos pasos para tu SO:
En Linux:
|
1 2 3 |
rizo -Lo ./amable https://amable.sigs.k8s.io/dl/v0.11.0/amable-linux-amd64 chmod +x ./amable mv ./amable /algunos-dir-en-su-SENDERO/amable |
En macOS a través de Homebrew:
|
1 |
cerveza instale amable |
En Windows:
|
1 2 |
rizo.exe -Lo amable-windows-amd64.exe https://amable.sigs.k8s.io/dl/v0.11.0/amable-windows-amd64 Mover-Artículo .tipo-windows-amd64.exe c:algunos-dir-en-su-PATHkind.exe |
Creación de un clúster
Antes de empezar a crear un clúster, recuerde que kind utiliza Docker para sus nodos Kubernetes, así que asegúrese de que Docker se está ejecutando antes de empezar.
Crear un cluster en especie es sencillo, basta con ejecutar tipo crear cluster y tienen un inicio de cluster por defecto. Kind es muy personalizable, pero en este artículo utilizaremos principalmente los valores predeterminados, modificando únicamente la configuración del nodo trabajador.
¿Qué es YAML?
YAML es un lenguaje de marcado que se utiliza habitualmente en los archivos de configuración del ecosistema Kubernetes.
Si no conoces YAML, su sintaxis es intencionadamente mínima y su estructura básica es un mapa. YAML depende de su sangría para indicar anidamiento. Como en Python, el formato de esta sangría es muy importante, así que asegúrese de que su editor utiliza espacios en lugar de tabuladores.
Su primer archivo de configuración YAML: Su clúster tipo
Cree el siguiente archivo de configuración, denominado kind-config.yamlque utilizaremos para crear nuestro clúster:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
amable: Grupo apiVersion: amable.x-k8s.io/v1alfa4 # Un nodo del plano de control y tres "trabajadores". # # Aunque no añadirán más capacidad real de cálculo y # tienen un aislamiento limitado, esto puede ser útil para probar # rolling updates, etc. # # El servidor API y otros componentes del plano de control serán # en el nodo del plano de control. # # Probablemente no necesite esto a menos que esté probando Kubernetes en sí. nodos: - papel: control-avión - papel: trabajador - papel: trabajador - papel: trabajador |
Cree su clúster con el siguiente comando:
|
1 |
amable crear grupo --nombre=couchbase --config=amable-config.yaml |
Una vez creado el clúster, ejecute el siguiente comando: kubectl cluster-info --context kind-couchbase. Debería obtener una salida similar a la siguiente para saber que tiene un clúster Kubernetes en ejecución:
|
1 2 3 4 5 6 |
% kubectl grupo-información --contexto amable-couchbase Kubernetes control avión es corriendo en https://127.0.0.1:57957 KubeDNS es corriendo en https://127.0.0.1:57957/api/v1/espacios de nombres/kube-sistema/servicios/kube-dns:dns/proxy A más depurar y diagnosticar grupo problemas, utilice 'kubectl cluster-info dump'. |
"¿Qué es kubectl?" Te oigo gritar. Es el comando que se utiliza para interactuar con los clusters Kubernetes. No es algo específico de Couchbase o tipo. Interactúas con diferentes clusters cambiando el "contexto". Más información sobre kubectl en la propia Kubernetes.
Profundizando en este nuevo mundo, vamos a proponer una pregunta: Si nuestro clúster se llama couchbase en especie, entonces ¿por qué utilizamos kind-couchbase con kubectl? Eso es porque kind-couchbase es el nombre del contexto que utilizamos para interactuar con el clúster.
Ejecutando el siguiente comando le mostrará todos los contextos que ha configurado:
|
1 |
% kubectl config consiga-contextos |
Deberías tener un * en la columna actual junto al kind-couchbase entrada.
Instalación del operador autónomo Couchbase en su clúster Kubernetes
Ahora que tiene un clúster Kubernetes en ejecución, es hora de instalar el CAO.
Requisitos previos para la instalación
Ejecutar a través de los requisitos previos para descargar la CAO, navegue hasta el directorio de la descarga en su terminal, descomprimirlo, y se mueven en la carpeta.
Instalar las definiciones de recursos personalizadas
El siguiente paso en la documentación es instalar las definiciones de recursos personalizadas de Couchbase (CRD). Echemos un vistazo más de cerca a lo que son.
Echa un vistazo al archivo crd crd.yaml en la carpeta descomprimida. Verás miles de líneas de recursos Couchbase definidos. La razón por la que necesitas instalarlos es para extender la API de Kubernetes y definir recursos específicos de Couchbase para que los gestione a través de tus aplicaciones Kubernetes.
Por ejemplo, puede utilizar estos recursos para validar una configuración de implantación de CAO. Aquí está la documentación de Kubernetes sobre recursos personalizados.
Para instalar los CRD que vienen con el operador, utilice el siguiente comando:
|
1 |
$ kubectl crear -f crd.yaml |
Instalar el operador
El operador consta de dos componentes. Quiero darle un poco más de una visión general aquí para que sepa exactamente lo que está instalando y por qué.
El Controlador Dinámico de Admisión (DAC)
Debido a que estamos utilizando recursos personalizados, Kubernetes no tiene idea de qué valores son aceptables, a diferencia de los tipos de recursos nativos.
El Controlador Dinámico de Admisión (DAC) es un gatekeeper que comprueba la validez de los recursos y aplica los valores por defecto necesarios antes de ser comprometidos a etcd (un almacén de valores clave para los datos del clúster.)
El equipo de Couchbase Docs ha hecho un trabajo fantástico explicando las numerosas ventajas de utilizar el Controlador Dinámico de Admisión aquí.
Aquí hay un extracto de la documentación de Couchbase con un gráfico sobre cómo el DAC interroga a las peticiones:
- Un cliente se conecta a la API de Kubernetes y envía una solicitud para crear un recurso. La especificación del recurso se codifica como JSON.
- La API reenvía el JSON al punto final mutante del controlador dinámico de admisión. Un webhook mutante es responsable de alterar el recurso (aplicando valores por defecto, por ejemplo). Opcionalmente, puede aceptar o rechazar la solicitud de creación.
- La API reenvía el JSON al punto final de validación del controlador dinámico de admisión. Un webhook de validación es responsable de validar las restricciones de especificación más allá de las ofrecidas por la validación del esquema JSON proporcionada por la definición del recurso personalizado. Opcionalmente, puede aceptar o rechazar la solicitud de creación.
- Una vez superadas todas las comprobaciones de admisión, el recurso se mantiene en la base de datos (
etcd). - La API responde al cliente que la solicitud de creación ha sido aceptada.
Si alguna de las comprobaciones de admisión de las etapas 2 y 3 responde que el recurso no es aceptable, la API pasará directamente a la etapa 5 y devolverá cualquier error devuelto por el CAD.
Instale el Controlador Dinámico de Admisión con el siguiente comando:
|
1 |
$ papelera/cbopcfg crear admisión |
El operador
Citaré de nuevo la documentación de Couchbase, ya que no puedo expresarlo mejor:
Durante la vida útil del clúster de Couchbase, el Operador compara continuamente el estado de los recursos de Kubernetes con lo que se solicita en el archivo CouchbaseCluster recurso, conciliando en caso necesario para que la realidad coincida con lo solicitado.
Profundicemos en esto. El Operador te permite declarar el estado del cluster que quieras, y él se encargará del resto. Cuando el estado del cluster necesita cambiar, por ejemplo, añadiendo nodos Couchbase, expandiendo los servicios disponibles, etc., puedes simplemente declararlo y el Operador consigue este nuevo estado.
Se trata de operaciones complejas que requieren precisión y experiencia para gestionar todas las piezas móviles. Usted podría realizar todas estas tareas manualmente, pero el Operador automatiza todo esto y realiza todas las operaciones teniendo en cuenta las mejores prácticas de Couchbase.
Para terminar esta sección, ahora sabes un poco más sobre lo que hace un despliegue de CAO - en lugar de simplemente instalar los componentes a ciegas. Este es el conocimiento que necesitarás cuando estés ejecutando un clúster Couchbase multi-nube usando la CAO dentro de unos meses.
Ahora que sabes lo que estás instalando, utiliza el siguiente comando para instalar el operador:
|
1 |
$ papelera/cbopcfg crear operador |
Verificación del DAC
Puede comprobar el estado del Operador Autónomo Couchbase obteniendo los despliegues, y también puede comprobar específicamente el estado de su CouchbaseCluster despliegue ejecutando:
|
1 2 3 4 |
$ kubectl consiga despliegues NOMBRE LISTO UP-A-FECHA DISPONIBLE EDAD couchbase-operador 1/1 1 1 53s couchbase-operador-admisión 1/1 1 1 93s |
Deberías ver un resultado similar al anterior. Ahora puedes pasar a desplegar un clúster de Couchbase.
Métodos alternativos de despliegue
Timón es un gestor de paquetes para Kubernetes, algo similar a brew/apt, etc.
Según Matt Faina, uno de los cofundadores de Helm, un gestor de paquetes es:
"Herramientas que permiten a alguien que conoce una aplicación y una plataforma empaquetar una aplicación para que otra persona que no tiene ni amplios conocimientos de la plataforma ni de la forma en que debe ejecutarse en la plataforma pueda utilizarla".
Los paquetes en Helm se denominan gráficos. Son unidades desplegables para aplicaciones vinculadas a Kubernetes.
Puede utilice Helm para configurar fácilmente el Operador Autónomo Couchbase y despliegue clusters Couchbase siguiendo esta documentación. Por defecto, la tabla oficial de Couchbase Helm despliega el Operador Autónomo de Couchbase, el Controlador Dinámico de Admisión, y un cluster de Couchbase completamente configurado.
Despliegue de su clúster Couchbase en la CAO
Utilizaré la documentación sobre cómo crear un despliegue de Couchbase como la fuente de la verdad para esta sección, pero lo desglosaré paso a paso.
Los clusters de Couchbase se definen contra el Operador - como hemos comentado anteriormente - y esta definición se utiliza para comprobar el estado actual de los clusters de CouchbaseCluster recurso.
Esta definición YAML se deriva de los documentos, pero he hecho algunos cambios para que las cosas son un poco más fácil en sus nodos tipo. (Demasiados contenedores en un ordenador portátil conduce a Badness™.) Tenga en cuenta los cambios incluyen sólo el despliegue del servicio de datos, pero aún así mantener el recuento de nodos en tres con el fin de proporcionar una alta disponibilidad y rendimiento, y cambiar el nombre a servicio_datos para evitar la putrefacción del código.
Cree un archivo llamado data_cluster.yaml y copia este texto en él:
|
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 |
apiVersion: v1 amable: Secreto metadatos: nombre: cb-ejemplo-auth tipo: Opaco datos: nombre de usuario: QWRtaW5pc3RyYXRvcg== Administrador # contraseña: cGFzc3dvcmQ= Contraseña # --- apiVersion: couchbase.com/v2 amable: CouchbaseBucket metadatos: nombre: por defecto spec: memoryQuota: 128Mi --- apiVersion: couchbase.com/v2 amable: CouchbaseCluster metadatos: nombre: cb-ejemplo spec: imagen: couchbase/servidor:6.6.2 seguridad: adminSecret: cb-ejemplo-auth red: exposeAdminConsole: verdadero adminConsoleServices: - datos cubos: gestionado: verdadero servidores: - talla: 3 nombre: servicio_datos servicios: - datos |
Despliegue la configuración utilizando el siguiente comando:
|
1 |
$ kubectl crear -f grupo_de_datos.yaml |
Puede ver cómo el Operador crea pods y aprovisiona su cluster según sus especificaciones ejecutando lo siguiente poco después de crear su despliegue (arriba). Esto le mostrará al operador creando pods:
|
1 2 3 4 5 |
$ kubectl consiga vainas NOMBRE LISTO ESTADO RESTARTS EDAD cb-ejemplo-0000 0/1 ContenedorCrear 0 32s couchbase-operador-7df6c5fc4c-xjmlb 1/1 Ejecutar 0 9m26s couchbase-operador-admisión-7776986946-p94xr 1/1 Ejecutar 0 10m |
Tenga en cuenta que la vaina cb-ejemplo-0000 no está marcado como listo (0/1) y tiene el estado ContenedorCrear. Una vez realizada la implantación, asegúrese de verificarla.
Sigue corriendo kubectl get pods hasta que veas tres cb-ejemplo-**** pods con su estado como Ejecutar y 1/1 bajo el Listo columna. No avance hasta que se cumpla este estado. Este es el estado que has definido en tu data_cluster.yaml.
Utilice el siguiente comando para verificar aún más que su servicio de datos está disponible en su Cluster:
|
1 2 3 |
$ kubectl consiga vainas -l couchbase_cluster=cb-ejemplo,datos_servicios_de_couchbase=habilitado NOMBRE LISTO ESTADO RESTARTS EDAD cb-ejemplo-0000 1/1 Ejecutar 0 73m |
Tenga en cuenta que debería recibir una salida similar a la de este ejemplo, pero dependiendo de la implementación de su clúster, los resultados serán diferentes.
Reenvío de puertos y acceso a la GUI de Couchbase
Para acceder a otros servicios de Couchbase para tu PoC, necesitarás acceso a la GUI de Couchbase.
Esta guía explica cómo configurar el reenvío de puertos. El reenvío de puertos es útil ya que necesitarás acceder a la GUI de Couchbase en tu Prueba de Concepto. También puede ser útil cuando necesites usar cbc-pillowfight para pruebas de carga o cbimport para conseguir algunos documentos de muestra en el clúster.
Usando la salida del comando anterior se obtiene un pod que está ejecutando el servicio de datos. Este nombre de pod se puede utilizar para reenviar el puerto para la GUI de Couchbase.
Ejecute el siguiente comando:
|
1 2 3 |
$ kubectl puerto-adelante cb-ejemplo-0000 8091 Reenvío de 127.0.0.1:8091 -> 8091 Reenvío de [::1]:8091 -> 8091 |
Este comando debería proporcionarle una salida similar a la indicada anteriormente. Después de ejecutar el comando, puedes acceder a la GUI de Couchbase a través de http:localhost:8091.
Modificación del despliegue de Couchbase
Algo que sin duda querrá incluir en su PdC es la capacidad de modificar su cluster Couchbase a través del archivo YAML. Esto le da la flexibilidad para dar forma y escalar su clúster.
Tenga en cuenta que no está utilizando kubectl create más. Sustituya la definición anterior por una nueva utilizando kubectl aplicar o kubectl replace.
Una prueba a realizar sería añadir otro servicio Couchbase a tu cluster actual. Como solo estoy usando mi portátil, solo voy a añadir un servicio adicional: eventing.
|
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 |
apiVersion: v1 amable: Secreto metadatos: nombre: cb-ejemplo-auth tipo: Opaco datos: nombre de usuario: QWRtaW5pc3RyYXRvcg== Administrador # contraseña: cGFzc3dvcmQ= Contraseña # --- apiVersion: couchbase.com/v2 amable: CouchbaseBucket metadatos: nombre: por defecto spec: memoryQuota: 128Mi --- apiVersion: couchbase.com/v2 amable: CouchbaseCluster metadatos: nombre: cb-ejemplo spec: imagen: couchbase/servidor:6.6.2 seguridad: adminSecret: cb-ejemplo-auth red: exposeAdminConsole: verdadero adminConsoleServices: - datos cubos: gestionado: verdadero servidores: - talla: 3 nombre: servicio_eventos_datos servicios: - datos - concurso |
Una vez realizado el cambio, puede desplegar su configuración al operador: kubectl apply -f .. Compruebe que el nuevo servicio se ha añadido utilizando la función verbose obtener vainas listado. Finalmente sigue los pasos para reenviar de nuevo el puerto para la GUI y comprueba que el nuevo servicio está incluido en el cluster.
En este punto es importante señalar que la adición incremental de características a un operador config es una práctica recomendada. Con la adición iterativa de características y configuraciones a su despliegue, puede probar el clúster en cada etapa, confirmando que su configuración es válida.
Conclusión
Para concluir, en este artículo has aprendido más sobre la composición del Operador Autónomo Couchbase y cómo puedes orquestarlo para aprovisionar un cluster Couchbase, particularmente para un proyecto de Prueba de Concepto (PoC).
La CAO comprueba constantemente el estado de tu clúster de Couchbase asegurándose de que cumple con la especificación definida. Además, puedes desplegar la especificación CAO en cualquier entorno Kubernetes. Esto te da un fantástico nivel de libertad y elimina la dependencia del proveedor de la nube pública. Puedes confiar en el Operador para mantener la salud del clúster según tus especificaciones, y cuando necesites realizar funciones como actualizaciones del clúster, puedes hacerlo fácilmente a través de tu archivo YAML.
En el futuro, publicaré más entradas en el blog que explicarán cómo desplegar aún más casos de uso del Operador Autónomo Couchbase. Si no puedes esperar hasta entonces, profundizar en la documentación de la CAO para empezar a explorar. No puedo esperar a escuchar lo que construyes.
