Cómo certificar Couchbase Autonomous Operator en Azure AKS

Nuestro objetivo en el equipo de pruebas de Couchbase Kubernetes es probar rigurosamente la Operador autónomo (AO) y certificamos los clusters subyacentes de Couchbase Server que gestiona el AO. Comprobamos que la AO crea, gestiona y recupera correctamente el clúster CB gestionado. Además, comprobamos que el clúster CB, los servicios y las características funcionan correctamente. Anteriormente, hemos realizado todas nuestras pruebas en clústeres personalizados de Kubernetes y Openshift on-prem, pero ahora estamos certificando el AO en múltiples servicios de Kubernetes en la nube. La primera de estas certificaciones es para Azure Kubernetes Service (AKS). La ejecución de nuestras pruebas con AKS planteó nuevos retos a la hora de crear y configurar el entorno de prueba en comparación con los entornos personalizados on-prem. Las soluciones a estos retos se destacan en este post.

*Nota - Couchbase Autonomous Operator todavía está en vista previa para desarrolladores en Azure AKS, y estamos apuntando a GA en nuestra próxima versión 1.2 prevista para el primer trimestre de 2019.

Requisitos para nuestro marco de pruebas de Kubernetes

Nuestro marco de pruebas ejecuta varios tipos diferentes de pruebas que van desde la necesaria creación de clústeres hasta la recuperación de fallos multinodo con volúmenes persistentes. También probamos XDCR en 3 topologías diferentes definidas por el lugar en el que residen los dos clústeres CB: un único clúster K8s, dos clústeres K8s diferentes y uno K8s y otro no K8s. Para ejecutar el conjunto de pruebas completo debemos (1) configurar dos clústeres AKS separados que permitan XDCR. (2) Nuestro marco de pruebas debe ser capaz de interactuar con cada clúster AKS a través de la Internet pública. (3) También debemos ser capaces de llegar a los clústeres CB dentro de los clústeres AKS desde la Internet pública. (4) Al menos una clase de almacenamiento dinámico debe estar presente en AKS para nuestras pruebas de volumen persistente. En la siguiente sección, se explicarán los pasos que se han dado para cumplir estos requisitos.

Creación de clústeres AKS listos para XDCR

El principal obstáculo para que XDCR funcione entre dos clusters CB (en K8s u otros) es que debe existir una ruta de Capa 3 entre los dos clusters CB. Los nodos CB utilizarán direcciones IP internas proporcionadas por la API K8s en función de la configuración de red del clúster AKS. Por defecto, dos clusters AKS utilizarán los mismos rangos de direcciones internas, lo que provocará que el tráfico XDCR saliente nunca llegue a su destino en el otro cluster AKS. La solución consiste en configurar los dos clusters AKS de forma que sus redes internas puedan establecer peering. El peering permitirá que los clusters CB de cada cluster AKS se comuniquen correctamente utilizando sus direcciones IP internas. Para configurar la interconexión de redes en AKS, debemos determinar los prefijos de red no superpuestos que se utilizarán para cada clúster AKS. A continuación, basándonos en estos prefijos, debemos determinar una subred de clúster para los nodos Kubernetes, una subred de servicio para los pods Kubernetes que no se solapen con la subred de clúster, una dirección DNS en cada subred de servicio y una red superpuesta Docker. La siguiente tabla muestra la configuración de red adecuada para cada clúster AKS.

Ahora que la configuración de red adecuada está determinada podemos crear estos dos clusters AKS desde el Portal Azure. La creación de cada clúster seguirá principalmente las instrucciones proporcionadas por Azure aquí, https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough-portal [1], con la única diferencia de la configuración de la red (paso 3). Estos pasos serán para AKS-cluster-1 y utilizarán los valores de red correspondientes determinados anteriormente. Los pasos para AKS-cluster-2 serán los mismos, utilizando los valores de red de AKS-cluster-2. Una vez alcanzado el paso de red, active el enrutamiento de aplicaciones HTTP y elija la configuración de red avanzada.

Cree una nueva red virtual utilizando el prefijo y la subred del clúster determinados anteriormente.

Rellene los campos restantes de la pestaña de red con los valores de subred de servicio, dirección DNS y superposición Docker.

Proceda a configurar el clúster AKS de acuerdo con la documentación. Mientras se despliega el clúster AKS-1, configure el clúster AKS-2 siguiendo los mismos pasos.

Ahora que tenemos dos clústeres AKS con la configuración de red adecuada, podemos configurar el peering de red. En la interfaz de usuario, vaya a la red virtual AKS-cluster-1-vnet creada para AKS-cluster-1, seleccione la pestaña Peerings y haga clic en Add para crear un nuevo peering.

Asigne al peering un nombre como AKS-cluster-1-AKS-cluster-2 y seleccione AKS-cluster-2-vnet como red virtual.

El peering requiere que ambas redes estén peerizadas, por lo que también debemos configurar el peering de AKS-cluster-2-vnet a AKS-cluster-1-vnet de forma similar. Una vez completado, los dos clústeres AKS pueden alojar clústeres CB con XDCR.

Acceso a la API de AKS Kubernetes a través de la Internet pública

Dado que nuestro marco de pruebas se ejecuta desde fuera de AKS, tendremos que configurar el acceso externo a la API de Kubernetes para cada clúster AKS. Este proceso es relativamente sencillo. Tenemos que modificar las reglas de entrada y salida del grupo de seguridad de red para cada clúster AKS. Vaya al grupo de seguridad de red para AKS-cluster-1, seleccione Reglas de seguridad entrantes y, a continuación, Agregar para crear una nueva regla. Para simplificar la configuración, cree esta regla permitiendo cualquier IP/puerto de origen e IP/puerto de destino. Asigne a esta regla el número de prioridad 102.

Ahora, haga lo mismo para las reglas de seguridad de salida. A continuación, modifique las reglas de seguridad de entrada y salida para AKS-cluster-2 de forma similar.

El siguiente paso es obtener el archivo kubeconfig (credenciales) para cada clúster AKS. El marco de pruebas utiliza estos archivos para acceder a la API de Kubernetes e interactuar con ella. Asegúrese de tener Azure CLI instalado localmente, como se indica aquí: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli?view=azure-cli-latest [2]. También necesitará tener kubectl instalado localmente, como se indica aquí: https://kubernetes.io/docs/tasks/tools/install-kubectl/ [3]. Una vez que ambos estén instalados y funcionando, ejecuta los siguientes comandos para extraer el archivo kubeconfig para AKS-cluster-1 y AKS-cluster-2:

Las credenciales del cluster se almacenarán en el archivo ~/.kube/config. Para nuestro marco de pruebas, separamos las credenciales de cada clúster en sus propios archivos: ~/.kube/config_aks_cluster_1 y ~/.kube/config_aks_cluster_2.

Acceso a los CB Pods en AKS

En este punto, nuestro marco de pruebas puede interactuar con la API de Kubernetes de dos clústeres AKS. Esto permite que el marco de pruebas instale el AO y cree clústeres CB gestionados por AO para nuestras pruebas. El marco de pruebas, sin embargo, necesita interactuar con los pods CB a través de llamadas REST para la mayoría de nuestras pruebas. Anteriormente, el marco de prueba tendría el AO exponer la API REST CB como un servicio Kubernetes nodeport. Este servicio crearía un puerto en el nodo Kubernetes, que reenviaría el tráfico al puerto de la API REST del pod CB dentro del nodo Kubernetes. Estos servicios eran accesibles a través de la dirección IP privada del nodo Kubernetes. Esto no era un problema, ya que nuestro clúster Kubernetes on-prem y el marco de pruebas vivían en la misma red privada. Con AKS, sin embargo, nuestro marco de pruebas no está colocado con los nodos AKS Kubernetes y no puede acceder a un servicio de puerto de nodo que utiliza las IP privadas de estos nodos. La solución a esto es simple: una vez que el AO crea el cluster CB y el servicio nodeport, haga que el framework de pruebas cambie el campo Spec. Type a LoadBalancer. Esto se logra en el siguiente trozo de código Go:

Cuando el Tipo de servicio nodeport se cambia a LoadBalancer, AKS asignará una IP pública al servicio. Utilizando esta nueva IP pública, el marco de pruebas puede realizar con éxito llamadas a la API REST de CB, incluso desde fuera de AKS. En la próxima versión importante, Autonomous Operator 1.2, el AO tendrá la opción de exponer un servicio nodeport o un servicio load balancer y cualquier cambio en los servicios desplegados por el AO hará que el AO vuelva a reconciliar el servicio. Por lo tanto, la solución que utilizamos en nuestro marco de pruebas es sólo temporal, y en el futuro, pasaremos a crear servicios de equilibrador de carga independientes y a utilizar el AO creado el equilibrador de carga.

Activación de Volúmenes Persistentes Dinámicos

La OA permite que un clúster CB se vincule a volúmenes persistentes aprovisionados dinámicamente. Esto hace que el clúster CB sea muy resistente a la pérdida de datos en caso de que uno o más pods CB se caigan. Nuestro marco de pruebas tiene muchos escenarios de fallo complejos que implican pods CB que almacenan datos en volúmenes persistentes. En algunos escenarios de fallo, la OA reiniciará el pod fallido en un nodo Kubernetes diferente utilizando el volumen persistente de los pods fallidos. Por lo tanto, debemos utilizar volúmenes persistentes que se puedan mover de un nodo Kubernetes a otro. En AKS se pueden utilizar dos tipos de clases de almacenamiento para volúmenes persistentes: AzureDisk y AzureFile. La clase de almacenamiento por defecto que AKS proporciona es AzureDisk, pero esta clase de almacenamiento no puede crear volúmenes persistentes movibles. AzureFile está implementado de una forma que permite volúmenes persistentes móviles y será la solución de clase de almacenamiento con la que probaremos en AKS. Azure proporciona instrucciones para configurar la clase de almacenamiento AzureFile aquí:

https://docs.microsoft.com/en-us/azure/aks/azure-files-dynamic-pv [4].

La configuración implica crear primero una cuenta de almacenamiento con:

A continuación, envíe una clase de almacenamiento, un rol de clúster y una especificación de vinculación de rol de clúster a Kubernetes:

Ahora tenemos nuestra clase de almacenamiento AzureFile configurada y lista para su uso en AKS-cluster-1. Debemos hacer el mismo proceso para AKS-cluster-2.

Comprobación del operador

En este punto, tenemos todo lo que necesitamos para ejecutar el conjunto completo de pruebas para el AO: 2 clústeres Kubernetes listos para XDCR, accesibles desde Internet público (API Kubernetes y API REST CB), con volúmenes persistentes dinámicos habilitados. Durante la prueba inicial, observamos algunos fallos extraños. Estos fueron causados principalmente por los tiempos de espera en nuestro marco de prueba, y hemos sido capaces de identificar la causa: AKS es extremadamente lento en comparación con el clúster Kubernetes on-prem. El tiempo que se tarda en poner en marcha un pod CB puede ser hasta 5 veces mayor. Para resolver este problema, tuvimos que crear tiempos de espera variables en función del tipo de clúster Kubernetes utilizado. Después de eso, todas las pruebas se ejecutaron correctamente, y no se encontraron problemas significativos con el clúster AO o CB.

Conclusión

Recientemente, el equipo de pruebas de Couchbase se ha centrado en certificar la OA para su uso en servicios primarios de Kubernetes proporcionados por la nube, como AKS, EKS y GCP. La primera nube en la que nos centramos fue AKS, y supuso varios retos específicos de la plataforma, como la configuración de red específica de la nube, la accesibilidad y la creación de clases de almacenamiento. Sin embargo, resolvimos estos problemas y ahora podemos ejecutar nuestro marco de pruebas automatizado utilizando clústeres AKS. Seguiremos trabajando en la certificación de otras nubes en los próximos meses, pero mientras tanto, diviértete en AKS.

Referencias:

[1] https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough-portal

[2] https://docs.microsoft.com/en-us/cli/azure/install-azure-cli?view=azure-cli-latest

[3] https://kubernetes.io/docs/tasks/tools/install-kubectl/

[4] https://docs.microsoft.com/en-us/azure/aks/azure-files-dynamic-pv