El Operador Autónomo Couchbase 1.0.0 fue lanzado hace sólo 8 meses. Le siguió rápidamente la versión 1.1.0. Durante este periodo hemos recibido un enorme feedback de nuestra comunidad de usuarios. En primer lugar, gracias a todos los que han ayudado y siguen dando forma a este producto.
La versión 1.2.0 de Operator es la primera gran actualización y aborda un gran número de peticiones de cambio.
Este artículo examina las principales nuevas funcionalidades y mejoras de usabilidad de esta versión. Las nuevas opciones de red y despliegue (con Helm) merecen sus propios artículos. Los enlaces aparecen al final de la página.
Certificación en la nube
Kubernetes es más que un marco de despliegue de aplicaciones, es una capa de abstracción. Pasar de un proveedor de nube a otro en función de las necesidades de la empresa debería ser sencillo y rentable. Como dicta el viejo adagio "no pongas todos los huevos en la misma cesta", en realidad es prudente adoptar una estrategia de despliegue en varias nubes. Kubernetes es el medio perfecto para facilitarla.
Sin embargo, existen diferencias sutiles entre los proveedores de nube. El almacenamiento y las redes son las principales. Donde hay diferencias, hay incertidumbre e imprevisibilidad.
La versión Operator 1.2.0 es la primera totalmente certificada en Amazon EKS, Google GKE y Microsoft Azure AKS. Nuestro conjunto interno de pruebas de regresión es ahora primero en la nube. Todas las pruebas se ejecutarán en estas plataformas principales. Esto nos proporciona a nosotros y a nuestros clientes la confianza de que Operator funcionará de forma predecible y fiable en cualquier entorno, independientemente de las diferencias que existan entre los proveedores de la nube.
Para obtener más información sobre el funcionamiento en entornos de nube, consulte el sitio web correspondiente. guías de inicio rápido.
Mejoras en el almacenamiento
Las plataformas Kubernetes compatibles con el Operador también se han ampliado para abarcar las versiones 1.11 a 1.13 y 3.11 para Redhat Openshift.
Antes de Kubernetes 1.12 había que tener mucho cuidado con la programación de volúmenes persistentes entre zonas de disponibilidad. No había ninguna inteligencia en la programación por lo que era posible tener un volumen persistente creado en una zona de disponibilidad, mientras que un pod tratando de acceder a ese volumen se crearía en una zona de disponibilidad diferente. Esto no funcionará ya que los volúmenes tienen que existir en el mismo centro de datos que sus consumidores.
Aunque es posible crear un cluster de Couchbase que tenga en cuenta estas restricciones, esa misma configuración es muy verbosa y difícil de entender y mantener.
Un nuevo modo de encuadernación de volúmenes - WaitForFirstConsumer - se introdujo en Kubernetes 1.12 que puede aplicarse a una clase de almacenamiento aprovisionada dinámicamente. Cuando se crea una reclamación de volumen persistente, no se crea el volumen persistente subyacente directamente. Cuando la reclamación de volumen persistente se adjunta a un pod, entonces y sólo entonces se crea el volumen persistente en la misma zona de disponibilidad en la que está programado el pod.
Nuestra fuerte recomendación es utilizar una versión de Kubernetes superior a 1.12 y aprovisionar tus clusters de Couchbase con este nuevo modo de enlace perezoso. Los archivos de configuración de tu clúster se simplificarán enormemente y serán más fáciles de gestionar y mantener. Este método de volumen persistente se utiliza en todas nuestras pruebas internas, por lo que puedes estar seguro de que funciona para tu caso de uso.
Actualización de Couchbase
La actualización automática era una de las funciones más solicitadas desde el lanzamiento de Operator. Ahora está totalmente soportada en Operator 1.2.0.
El proceso de actualización sigue nuestras mejores prácticas estándar para realizar manualmente este procedimiento. Se selecciona un pod que ejecute la versión antigua de la plataforma de datos Couchbase para su actualización y se crea una nueva instancia de Couchbase. Un intercambio de datos de alto rendimiento traslada los datos existentes al nuevo nodo y se elimina el antiguo. Esto continúa hasta que todos los pods han alcanzado la versión objetivo.
Este modo de funcionamiento permite actualizaciones seguras y en línea, sin degradación del rendimiento ni interrupción de la actividad de los clientes.
Se aplican las rutas de actualización estándar, por lo que se permiten las actualizaciones de versiones puntuales (de 5.5.3 a 5.5.4) y de versiones principales (de 5.5.3 a 6.0.1). Las actualizaciones que se saltan las versiones principales (5.5.3 a 7.0.0) y los downgrades no están permitidos y se rechazan.
Se permite retroceder a mitad de una operación de actualización, pero sólo a la versión original. Si está realizando una actualización a 6.0.1 desde 5.5.3 y se han actualizado 3 de los 8 pods, puede volver a 5.5.3.
La activación de una actualización se realiza editando el archivo versión.spec en su recurso personalizado del clúster Couchbase.
Actualización de Kubernetes
Muchas plataformas en la nube proporcionan actualizaciones con un solo clic de todo el clúster Kubernetes. Esto es peligroso para una aplicación con estado como la plataforma de datos Couchbase y puede resultar en la pérdida de datos. Para evitar este escenario, la versión Operator 1.2.0 crea algunos recursos adicionales para gestionar cuándo se pueden matar los pods de forma segura. El cluster de Couchbase necesita ser actualizado primero para aprovechar esta función.
Para más información artículo anterior sobre el tema.
Rotación y verificación de certificados TLS
Desde la versión 1.0.0 de Operator se proporciona soporte TLS. Esta característica permite al administrador suministrar una cadena de certificados comodín y una clave privada para que el Operator la instale en la plataforma de datos Couchbase junto con un certificado CA raíz.
Aunque esto no ha cambiado, ahora soportamos la rotación de certificados de servidor o incluso de toda la PKI. Esto proporciona un mecanismo para gestionar la expiración de certificados o el compromiso de claves privadas. La activación de una operación de rotación requiere una actualización de los secretos TLS y el Operador se encargará del resto. Consulte nuestra Documentación TLS para más detalles.
TLS no es fácil. Es necesario tener un buen conocimiento de redes y del estándar X.509 para que funcione, y vemos un número de casos en los que los clusters fallan en el aprovisionamiento debido a una mala configuración de TLS. Los mensajes de error eran crípticos en el mejor de los casos, por lo que nos hemos esforzado en mejorar la experiencia del usuario en esta área.
Ahora, cuando se crea un clúster, si existe un secreto TLS, se valida su contenido. Esto comprueba que los certificados y las claves están en el formato correcto, que los certificados son válidos para ese clúster específico de Couchbase y el espacio de nombres de Kubernetes, que el certificado del servidor se valida contra la CA raíz, etc. Todo esto se comunica al usuario en un mensaje sencillo y fácil de entender. Cómo lo hace se explica en la siguiente sección...
Control dinámico de admisión
La API de Kubernetes informará de errores en sus manifiestos YAML para los tipos de núcleo. Antes de Operator 1.2.0 hemos empleado un esquema JSON asociado con el tipo CouchbaseCluster para detectar errores de formato simples. Para otras validaciones más complejas específicas de un despliegue de Couchbase hemos distribuido un binario independiente para validar tu YAML.
Aunque este método funcionaba, es posible que los usuarios finales no lo emplearan. Desde luego, no encajaba bien con los flujos de trabajo existentes que utilizaban kubectl o oc clientes. Con los controladores de admisión dinámicos, podemos introducir esta validación en profundidad directamente en la API de Kubernetes.
Ahora, al crear un clúster Couchbase con kubectl, por ejemplo, la API pasa la solicitud a un controlador dinámico de admisión distribuido como parte del Operator 1.2.0. El controlador de admisión dinámico puede entonces validar y modificar el recurso personalizado antes de responder si admite o no la solicitud. Si se rechaza la solicitud, el motivo se transmite directamente al cliente. Ya no es necesario buscar en los archivos de registro las razones por las que la implantación no funciona.
Modificar el recurso personalizado nos da un mecanismo por el cual también podemos rellenar automáticamente nuevos campos requeridos por el tipo de recurso personalizado. Esto ayuda a mantener la compatibilidad con los antiguos archivos YAML del clúster de Couchbase.
Para más información sobre el funcionamiento y la instalación del controlador dinámico de admisión, consulte la documentación.
Mejoras en los registros
Se hicieron algunas mejoras a nuestra herramienta de soporte cuando lanzamos el Operator 1.1.0. Estas mejoras fueron específicamente para manejar el uso de volúmenes de registro cuando se utiliza con pods Couchbase sin estado. La recopilación de volúmenes de registro presentaba al usuario un menú interactivo para permitir la selección y descarga local. Aunque esto era una adición bienvenida, era ortogonal a cómo se recogían los registros de los pods en ejecución. Los registros de los pods en ejecución se recogían incondicionalmente y se dejaban en el propio pod, siendo el usuario final el responsable de la descarga y limpieza.
Con la versión 1.2.0 del operador, todos los pods y volúmenes de registro en ejecución se muestran en un menú interactivo unificado. El usuario puede seleccionar exactamente los registros que desea recopilar. La herramienta de asistencia también descarga ahora automáticamente todos los registros solicitados a nivel local y elimina cualquier archivo intermedio de los pods en ejecución.
También proporcionamos la misma funcionalidad a través de indicadores CLI para que los registros disponibles puedan ser sondeados y la recogida automatizada. Para más información, consulte el Documentación de cbopinfo.
Cuando el Operador intenta crear un pod y falla, borramos ese pod y volvemos a intentar crearlo por si el error que causó el fallo fuera transitorio. En el caso común de que la imagen del contenedor se haya especificado incorrectamente o el programador no pueda encontrar un nodo en el que ejecutar el pod, no tenemos nada que indique que este sea el caso.
En la versión Operator 1.2.0 hemos ampliado los registros de Operator para atender estos casos y permitir una determinación sencilla del problema. La creación fallida de un pod desencadenará una recopilación del estado del pod y de los eventos asociados y la salida al flujo de registro.
Kubernetes RBAC
El Operador funciona creando y manipulando recursos de Kubernetes. Para ello, es necesario conceder permisos al Operador. En versiones anteriores a la 1.2.0 simplemente decíamos "grant all permission on pods" por ejemplo. Aunque escueto y fácil de entender, otorgaba privilegios al Operador que no eran estrictamente necesarios para su funcionamiento.
A partir de la versión 1.2.0 de Operator, todos los roles de ejemplo de Kubernetes distribuidos por Couchbase serán explícitos sobre qué operaciones se requieren y sobre qué tipos de recursos. Todos los permisos indicados son necesarios, el Operador no puede funcionar sin ellos. Para más detalles acerca de qué permisos son necesarios y por qué, por favor consulte la sección Documentación RBAC.
La capacidad del Operador para funcionar con un rol, en contraposición a un rol de clúster, es ahora totalmente compatible. Las anteriores comprobaciones y verificaciones que requerían acceso a los recursos del clúster ahora son gestionadas únicamente por el controlador de admisión dinámico.
Próximos pasos
El Operador Autónomo Couchbase 1.2.0 es un gran lanzamiento con muchas nuevas características. Los focos principales son la capacidad de actualización y la facilidad de uso. Esperamos que disfrutes haciendo cosas nuevas con él tanto como nosotros hemos disfrutado creándolo. Como siempre, ¡sus comentarios son clave!
- Pruébalo: https://www.couchbase.com/downloads
- Foros de apoyo: https://www.couchbase.com/forums/c/couchbase-server/Kubernetes
- Documentación: https://docs.couchbase.com/operator/1.2/whats-new.html
Seguir leyendo
- Operador autónomo 1.2.0 Trabajo en red: https://www.couchbase.com/blog/autonomous-operator-1-2-0-networking
