El Operador Aut\u00f3nomo Couchbase 1.0.0 fue lanzado hace s\u00f3lo 8 meses. Le sigui\u00f3 r\u00e1pidamente la versi\u00f3n 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.<\/p>\n
La versi\u00f3n 1.2.0 de Operator es la primera gran actualizaci\u00f3n y aborda un gran n\u00famero de peticiones de cambio.<\/p>\n
Este art\u00edculo examina las principales nuevas funcionalidades y mejoras de usabilidad de esta versi\u00f3n. Las nuevas opciones de red y despliegue (con Helm) merecen sus propios art\u00edculos. Los enlaces aparecen al final de la p\u00e1gina.<\/p>\n
Kubernetes es m\u00e1s que un marco de despliegue de aplicaciones, es una capa de abstracci\u00f3n. Pasar de un proveedor de nube a otro en funci\u00f3n de las necesidades de la empresa deber\u00eda 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.<\/p>\n
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.<\/p>\n
La versi\u00f3n 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\u00f3n es ahora primero en la nube. Todas las pruebas se ejecutar\u00e1n en estas plataformas principales. Esto nos proporciona a nosotros y a nuestros clientes la confianza de que Operator funcionar\u00e1 de forma predecible y fiable en cualquier entorno, independientemente de las diferencias que existan entre los proveedores de la nube.<\/p>\n
Para obtener m\u00e1s informaci\u00f3n sobre el funcionamiento en entornos de nube, consulte el sitio web correspondiente. gu\u00edas de inicio r\u00e1pido<\/a>.<\/p>\n Las plataformas Kubernetes compatibles con el Operador tambi\u00e9n se han ampliado para abarcar las versiones 1.11 a 1.13 y 3.11 para Redhat Openshift.<\/p>\n Antes de Kubernetes 1.12 hab\u00eda que tener mucho cuidado con la programaci\u00f3n de vol\u00famenes persistentes entre zonas de disponibilidad. No hab\u00eda ninguna inteligencia en la programaci\u00f3n 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\u00eda en una zona de disponibilidad diferente. Esto no funcionar\u00e1 ya que los vol\u00famenes tienen que existir en el mismo centro de datos que sus consumidores.<\/p>\n Aunque es posible crear un cluster de Couchbase que tenga en cuenta estas restricciones, esa misma configuraci\u00f3n es muy verbosa y dif\u00edcil de entender y mantener.<\/p>\n Un nuevo modo de encuadernaci\u00f3n de vol\u00famenes - WaitForFirstConsumer<\/a> - se introdujo en Kubernetes 1.12 que puede aplicarse a una clase de almacenamiento aprovisionada din\u00e1micamente. Cuando se crea una reclamaci\u00f3n de volumen persistente, no se crea el volumen persistente subyacente directamente. Cuando la reclamaci\u00f3n de volumen persistente se adjunta a un pod, entonces y s\u00f3lo entonces se crea el volumen persistente en la misma zona de disponibilidad en la que est\u00e1 programado el pod.<\/p>\n Nuestra fuerte recomendaci\u00f3n es utilizar una versi\u00f3n de Kubernetes superior a 1.12 y aprovisionar tus clusters de Couchbase con este nuevo modo de enlace perezoso. Los archivos de configuraci\u00f3n de tu cl\u00faster se simplificar\u00e1n enormemente y ser\u00e1n m\u00e1s f\u00e1ciles de gestionar y mantener. Este m\u00e9todo de volumen persistente se utiliza en todas nuestras pruebas internas, por lo que puedes estar seguro de que funciona para tu caso de uso.<\/p>\n La actualizaci\u00f3n autom\u00e1tica era una de las funciones m\u00e1s solicitadas desde el lanzamiento de Operator. Ahora est\u00e1 totalmente soportada en Operator 1.2.0.<\/p>\n El proceso de actualizaci\u00f3n sigue nuestras mejores pr\u00e1cticas est\u00e1ndar para realizar manualmente este procedimiento. Se selecciona un pod que ejecute la versi\u00f3n antigua de la plataforma de datos Couchbase para su actualizaci\u00f3n 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\u00faa hasta que todos los pods han alcanzado la versi\u00f3n objetivo.<\/p>\n Este modo de funcionamiento permite actualizaciones seguras y en l\u00ednea, sin degradaci\u00f3n del rendimiento ni interrupci\u00f3n de la actividad de los clientes.<\/p>\n Se aplican las rutas de actualizaci\u00f3n est\u00e1ndar, 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\u00e1n permitidos y se rechazan.<\/p>\n Se permite retroceder a mitad de una operaci\u00f3n de actualizaci\u00f3n, pero s\u00f3lo a la versi\u00f3n original. Si est\u00e1 realizando una actualizaci\u00f3n a 6.0.1 desde 5.5.3 y se han actualizado 3 de los 8 pods, puede volver a 5.5.3.<\/p>\n La activaci\u00f3n de una actualizaci\u00f3n se realiza editando el archivo versi\u00f3n.spec<\/i> en su recurso personalizado del cl\u00faster Couchbase.<\/p>\n Muchas plataformas en la nube proporcionan actualizaciones con un solo clic de todo el cl\u00faster Kubernetes. Esto es peligroso para una aplicaci\u00f3n con estado como la plataforma de datos Couchbase y puede resultar en la p\u00e9rdida de datos. Para evitar este escenario, la versi\u00f3n Operator 1.2.0 crea algunos recursos adicionales para gestionar cu\u00e1ndo se pueden matar los pods de forma segura. El cluster de Couchbase necesita ser actualizado primero<\/a> para aprovechar esta funci\u00f3n.<\/p>\n Para m\u00e1s informaci\u00f3n art\u00edculo anterior<\/a> sobre el tema.<\/p>\n Desde la versi\u00f3n 1.0.0 de Operator se proporciona soporte TLS. Esta caracter\u00edstica permite al administrador suministrar una cadena de certificados comod\u00edn y una clave privada para que el Operator la instale en la plataforma de datos Couchbase junto con un certificado CA ra\u00edz.<\/p>\n Aunque esto no ha cambiado, ahora soportamos la rotaci\u00f3n de certificados de servidor o incluso de toda la PKI. Esto proporciona un mecanismo para gestionar la expiraci\u00f3n de certificados o el compromiso de claves privadas. La activaci\u00f3n de una operaci\u00f3n de rotaci\u00f3n requiere una actualizaci\u00f3n de los secretos TLS y el Operador se encargar\u00e1 del resto. Consulte nuestra Documentaci\u00f3n TLS<\/a> para m\u00e1s detalles.<\/p>\n TLS no es f\u00e1cil. Es necesario tener un buen conocimiento de redes y del est\u00e1ndar X.509 para que funcione, y vemos un n\u00famero de casos en los que los clusters fallan en el aprovisionamiento debido a una mala configuraci\u00f3n de TLS. Los mensajes de error eran cr\u00edpticos en el mejor de los casos, por lo que nos hemos esforzado en mejorar la experiencia del usuario en esta \u00e1rea.<\/p>\n Ahora, cuando se crea un cl\u00faster, si existe un secreto TLS, se valida su contenido. Esto comprueba que los certificados y las claves est\u00e1n en el formato correcto, que los certificados son v\u00e1lidos para ese cl\u00faster espec\u00edfico de Couchbase y el espacio de nombres de Kubernetes, que el certificado del servidor se valida contra la CA ra\u00edz, etc. Todo esto se comunica al usuario en un mensaje sencillo y f\u00e1cil de entender. C\u00f3mo lo hace se explica en la siguiente secci\u00f3n...<\/p>\n La API de Kubernetes informar\u00e1 de errores en sus manifiestos YAML para los tipos de n\u00facleo. Antes de Operator 1.2.0 hemos empleado un esquema JSON asociado con el tipo CouchbaseCluster<\/i> para detectar errores de formato simples. Para otras validaciones m\u00e1s complejas espec\u00edficas de un despliegue de Couchbase hemos distribuido un binario independiente para validar tu YAML.<\/p>\n Aunque este m\u00e9todo funcionaba, es posible que los usuarios finales no lo emplearan. Desde luego, no encajaba bien con los flujos de trabajo existentes que utilizaban kubectl<\/i> o oc<\/i> clientes. Con los controladores de admisi\u00f3n din\u00e1micos, podemos introducir esta validaci\u00f3n en profundidad directamente en la API de Kubernetes.<\/p>\n Ahora, al crear un cl\u00faster Couchbase con kubectl,<\/i> por ejemplo, la API pasa la solicitud a un controlador din\u00e1mico de admisi\u00f3n distribuido como parte del Operator 1.2.0. El controlador de admisi\u00f3n din\u00e1mico 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\u00f3n no funciona.<\/p>\n Modificar el recurso personalizado nos da un mecanismo por el cual tambi\u00e9n podemos rellenar autom\u00e1ticamente nuevos campos requeridos por el tipo de recurso personalizado. Esto ayuda a mantener la compatibilidad con los antiguos archivos YAML del cl\u00faster de Couchbase.<\/p>\n Para m\u00e1s informaci\u00f3n sobre el funcionamiento y la instalaci\u00f3n del controlador din\u00e1mico de admisi\u00f3n, consulte la documentaci\u00f3n<\/a>.<\/p>\n Se hicieron algunas mejoras a nuestra herramienta de soporte cuando lanzamos el Operator 1.1.0. Estas mejoras fueron espec\u00edficamente para manejar el uso de vol\u00famenes de registro cuando se utiliza con pods Couchbase sin estado. La recopilaci\u00f3n de vol\u00famenes de registro presentaba al usuario un men\u00fa interactivo para permitir la selecci\u00f3n y descarga local. Aunque esto era una adici\u00f3n bienvenida, era ortogonal a c\u00f3mo se recog\u00edan los registros de los pods en ejecuci\u00f3n. Los registros de los pods en ejecuci\u00f3n se recog\u00edan incondicionalmente y se dejaban en el propio pod, siendo el usuario final el responsable de la descarga y limpieza.<\/p>\n Con la versi\u00f3n 1.2.0 del operador, todos los pods y vol\u00famenes de registro en ejecuci\u00f3n se muestran en un men\u00fa interactivo unificado. El usuario puede seleccionar exactamente los registros que desea recopilar. La herramienta de asistencia tambi\u00e9n descarga ahora autom\u00e1ticamente todos los registros solicitados a nivel local y elimina cualquier archivo intermedio de los pods en ejecuci\u00f3n.<\/p>\n Tambi\u00e9n proporcionamos la misma funcionalidad a trav\u00e9s de indicadores CLI para que los registros disponibles puedan ser sondeados y la recogida automatizada. Para m\u00e1s informaci\u00f3n, consulte el Documentaci\u00f3n de cbopinfo<\/a>.<\/p>\n Cuando el Operador intenta crear un pod y falla, borramos ese pod y volvemos a intentar crearlo por si el error que caus\u00f3 el fallo fuera transitorio. En el caso com\u00fan 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.<\/p>\n En la versi\u00f3n Operator 1.2.0 hemos ampliado los registros de Operator para atender estos casos y permitir una determinaci\u00f3n sencilla del problema. La creaci\u00f3n fallida de un pod desencadenar\u00e1 una recopilaci\u00f3n del estado del pod y de los eventos asociados y la salida al flujo de registro.<\/p>\n 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\u00edamos \"grant all permission on pods\" por ejemplo. Aunque escueto y f\u00e1cil de entender, otorgaba privilegios al Operador que no eran estrictamente necesarios para su funcionamiento.<\/p>\n A partir de la versi\u00f3n 1.2.0 de Operator, todos los roles de ejemplo de Kubernetes distribuidos por Couchbase ser\u00e1n expl\u00edcitos sobre qu\u00e9 operaciones se requieren y sobre qu\u00e9 tipos de recursos. Todos los permisos indicados son necesarios, el Operador no puede funcionar sin ellos. Para m\u00e1s detalles acerca de qu\u00e9 permisos son necesarios y por qu\u00e9, por favor consulte la secci\u00f3n Documentaci\u00f3n RBAC<\/a>.<\/p>\n La capacidad del Operador para funcionar con un rol, en contraposici\u00f3n a un rol de cl\u00faster, es ahora totalmente compatible. Las anteriores comprobaciones y verificaciones que requer\u00edan acceso a los recursos del cl\u00faster ahora son gestionadas \u00fanicamente por el controlador de admisi\u00f3n din\u00e1mico.<\/p>\n El Operador Aut\u00f3nomo Couchbase 1.2.0 es un gran lanzamiento con muchas nuevas caracter\u00edsticas. Los focos principales son la capacidad de actualizaci\u00f3n y la facilidad de uso. Esperamos que disfrutes haciendo cosas nuevas con \u00e9l tanto como nosotros hemos disfrutado cre\u00e1ndolo. Como siempre, \u00a1sus comentarios son clave!<\/p>\nMejoras en el almacenamiento<\/h3>\n
Actualizaci\u00f3n de Couchbase<\/h3>\n
Actualizaci\u00f3n de Kubernetes<\/h3>\n
Rotaci\u00f3n y verificaci\u00f3n de certificados TLS<\/h3>\n
Control din\u00e1mico de admisi\u00f3n<\/h3>\n
Mejoras en los registros<\/h3>\n
Kubernetes RBAC<\/h3>\n
Pr\u00f3ximos pasos<\/h3>\n