Autocertificación de plataformas en Cloud-Native Operator 2.3.0

¡Todos sus entornos nos pertenecen!

Qué certifica Couchbase

Las plataformas Commodity Cloud son utilizadas por el equipo de Couchbase Autonomous Operator para probar que todo funciona. Estas plataformas se aprovechan debido a la ubicuidad dentro del ecosistema Kubernetes y su capacidad para ser aprovisionadas y desaprovisionadas de una manera simple y genérica. Amazon EKS, Google GKE, Microsoft AKS y Red Hat OpenShift (en AWS) son nuestras principales combinaciones. Estas plataformas son -en su mayoría- fácilmente creables bajo demanda con tecnologías genéricas como HashiCorp Terraform.

Un pequeño subconjunto, ¿no?

La respuesta corta es sí y no. Por un lado, la certificación de estas cuatro grandes plataformas cubre 99% de usuarios (¡una cifra inventada!). Por otra parte, la certificación de estas cuatro grandes plataformas cubre a 99% de usuarios (¡una cifra inventada!), lo que nos permite sacar el máximo partido desde un punto de vista puramente comercial, ya que las pruebas no son gratuitas, ni en tiempo ni en dinero.

Por otro lado, se pueden utilizar decenas de proveedores de plataformas diferentes, todas ellas certificadas bajo el paraguas de la Programa de conformidad del software CNCF. La conformidad con Kubernetes garantiza que un pod será un pod y se comportará como un pod dondequiera que se ejecute, rompiendo así la dependencia de un proveedor de un pod. cierto grado. De hecho, dadas estas limitaciones y si el Operador sólo utiliza recursos genéricos, existe un alto grado de certeza de que el Operador funcionará en cualquiera de estas plataformas sin necesidad de modificaciones.

Así que la autocertificación no es necesaria, ¿verdad?

Me equivoqué. Cuando antes dije "cierto grado", era deliberado. Si bien el núcleo de Kubernetes está bien definido en cuanto a formato y comportamiento, ciertas partes pueden personalizarse para una plataforma específica, a saber, el almacenamiento y la red, ambos bastante fundamentales para el funcionamiento de una base de datos distribuida.

Por lo tanto, es comprensible cuando los usuarios finales quieren que su plataforma específica sea certificada para operar con Couchbase. En el pasado, nos hemos esforzado en certificar plataformas cuando se nos ha solicitado. Para algunas plataformas, como Rancher, esto es simple. Supongamos que tenemos que tratar con un dispositivo de almacenamiento $1,000,000. En ese caso, es económicamente inviable y requiere un centro de datos, servidores, conmutadores, enrutadores, energía, refrigeración, etc. Obviamente, no es una solución práctica y escalable. Esto es especialmente grave cuando la plataforma es un barco.

Introducción de la autocertificación

La autocertificación es la respuesta a todos los problemas que plantea la certificación de plataformas. Analizando el problema, si quisiéramos certificar Acme Cloud, aprovisionaríamos Kubernetes en ella y, a continuación, ejecutaríamos nuestro conjunto de pruebas contra ella utilizando API nativas.

El siguiente paso lógico es tomar ese conjunto de pruebas y empaquetarlo como un contenedor para cualquier persona en cualquier plataforma Kubernetes. Eso es todo; lo que le proporcionamos es lo que utilizamos internamente para todos nuestros esfuerzos de certificación. Certificación distribuida.

Anecdóticamente, no fue que fácil. Tuvimos que cambiar fundamentalmente el modelo de red (haciéndolo más sencillo y rápido en el proceso). También tuvimos que tener cuidado con la utilización de la memoria, dado que Kubernetes es una plataforma con restricciones de memoria.

¿Y qué hace?

La experiencia me ha enseñado que, aunque la mayoría de la gente debe Tratar esto como una caja negra y simplemente ejecutarlo, es la naturaleza de los ingenieros informáticos para analizar las cosas y hacer un montón de (¿demasiadas?) Preguntas, así que voy a ser sincero. Es posible que este producto no satisfaga a todo el público al que va dirigido.

Desde un nivel fundamental, la autocertificación ejecuta un pod de Kubernetes que ejecuta las pruebas y almacena los resultados en un volumen persistente. Los resultados se extraen de Kubernetes para enviarlos a Couchbase para su aceptación.

Desafortunadamente, los permisos requeridos son bastante intrusivos, así que aquí es donde la autocertificación puede no funcionar para usted. Las pruebas requerirán la creación y eliminación de recursos del clúster, como espacios de nombres, definiciones de recursos personalizados, roles y vinculaciones de roles. Por este motivo, recomendamos que esta herramienta se ejecute en un clúster de Kubernetes no de producción y desechable.

Certificación de funcionamiento

Con Couchbase Autonomous Operator 2.3, hemos fusionado todas las herramientas existentes en una sola herramienta para gobernarlas a todas. Aquí es donde reside el comando de certificación. Las herramientas están disponibles en Página web de descargas de Couchbase. 

Ejecutarlo es tan sencillo como la línea de comandos:

Es posible que desee revisar la documentación para ver si es necesario modificar algún indicador para su entorno específico.

Fase de prueba previa al vuelo

Las primeras comprobaciones que realizarán las pruebas son una comprobación general del estado del clúster Kubernetes:

En primer lugar, se comprueban los límites de recursos de la plataforma, especificados por la directiva Guía de instalación no root de Couchbase Server. Hemos visto casos en el pasado, particularmente con CoreOS, donde el número de procesos es bajo (1024) y Couchbase Server no puede arrancar. Detectar estos errores a tiempo permite al usuario auto-servicio como beneficio añadido.

Comprobación de los recursos de memoria y CPU

A continuación, se comprueban los recursos de memoria y CPU de la plataforma. El sitio Requisitos del sistema de Couchbase Server definen el tamaño mínimo de los recursos necesarios para una única instancia de Couchbase Server. Las pruebas se ejecutarán con el valor función de reserva automática de memoria activado, lo que facilita la depuración de los problemas de programación.

Por último, se examinan los totales globales de memoria y CPU. En resumen, la autocertificación ejecuta pruebas en paralelo. Conociendo el nivel de concurrencia y los requisitos de Couchbase Server, podemos adivinar cuántos recursos son necesarios para ejecutar la prueba. El cálculo completo está documentado en el conceptos de autocertificación documentación.

Fase de preparación

El siguiente paso es la configuración del clúster Kubernetes. Esto realiza tareas de configuración únicas como la instalación de las definiciones de recursos personalizados, el controlador de admisión dinámico y cualquier otra operación de limpieza de la plataforma:

Fase de prueba

Ya lo hemos insinuado: las pruebas se ejecutan en paralelo. Si todas las pruebas se ejecutaran una detrás de otra, el tiempo necesario para ejecutarlo todo sería de varios días. Gracias a la concurrencia, ¡podemos conseguirlo en 3-4 horas!

Los maestros Jedi de la nube sabrán que tratar cualquier cosa como un copo de nieve especial es "hacerlo mal". Si te preparas para el desastre y asumes que habrá que volver a crear las cosas desde cero, volverás a estar operativo en un abrir y cerrar de ojos, mientras los demás entran en pánico intentando arreglar las cosas e interactuar con las organizaciones de apoyo.

De este modo, en lugar de gestionar el desmontaje de recursos, las pruebas utilizan los espacios de nombres de Kubernetes. Cada prueba obtiene un espacio de nombres y crea recursos sólo en ese espacio de nombres. Una vez finalizada la prueba, el espacio de nombres se elimina y todos los recursos se recuperan automáticamente.

Las pruebas suelen hacer algunas cosas para garantizarlo:

• • las API de Kubernetes funcionan como se desea
  • nuestros recursos personalizados se comportan correctamente
  • trabajos de utillaje
  • el Operador actúa correctamente durante las actualizaciones y las situaciones de recuperación
  • Couchbase Server se comporta de forma coherente en todas las versiones

Lo que usted ejecute como usuario final será un subconjunto de pruebas que cubra la gran mayoría de todas las funcionalidades soportadas.

Fase de resultados

Una vez completadas todas las pruebas, el paquete de autocertificación mostrará un resumen de los resultados:

Cuantos menos fallos, mejor. Como en todas las cosas, algunas pruebas están sujetas a condiciones de carrera inevitables. Te lo he mostrado como ejemplo, pero lo que ejecutes será una versión recortada de esto en la que sólo se incluyan pruebas estables y predecibles. Saltar suelen ser las que no pueden ejecutarse dadas las capacidades de la plataforma que se está probando o determinadas combinaciones de parámetros.

Se creará un segundo pod, montando un volumen persistente, y se copiará el archivo de resultados. Se llamará de forma similar a couchbase-operator-certification-20060102T150405-0700.tar.bz2 y contienen el resumen de los resultados de las pruebas y cualquier registro relacionado con las pruebas fallidas utilizado para depurar cualquier problema.

Fase de certificación

Aunque vea un porcentaje de aprobados del 100% y quiera seguir adelante, aún no ha terminado. Esperamos que todos los resultados de la autocertificación sean enviado a Couchbase para su aprobación. Esto nos permite saber qué plataformas Kubernetes, de almacenamiento y de red utilizan nuestros usuarios finales. Con esta información, podemos anunciar estas plataformas como probadas y comprobadas y evitar la duplicación de esfuerzos.

Aunque se produzcan algunos fallos, esto no es necesariamente un obstáculo para la aceptación de la certificación. Puede ser que ciertas características no puedan ser soportadas en plataformas específicas. Podemos utilizar esta información para anunciarlo a otros usuarios y actualizar la imagen del contenedor de autocertificación y omitir estas pruebas en determinadas circunstancias, facilitando el proceso para todos.

Resumen

La autocertificación del operador es un cambio de juego para nosotros. Nos ayuda a acceder y dar soporte a los usuarios de Couchbase en una mayor variedad de plataformas. Utilizando un enfoque colaborativo, podemos compartir la carga y anunciar la aceptación a un público aún mayor.

Estamos deseando ver sus resultados y escuchar sus comentarios.

A continuación, acceda a los recursos mencionados en el artículo:

• • Página de descargas de Couchbase
  • Conceptos de certificación de plataformas (docs)
  • Guía de instalación no root de Couchbase Server
  • Requisitos del sistema de Couchbase Server