Como certificar o operador autônomo do Couchbase no Azure AKS

Nosso objetivo na equipe de testes do Kubernetes do Couchbase é testar rigorosamente o Operador autônomo (AO) e certificar os clusters subjacentes do Couchbase Server que o AO gerencia. Testamos o AO quanto à criação, ao gerenciamento e à recuperação de falhas adequados do cluster CB gerenciado. Além disso, testamos se o cluster CB, os serviços e os próprios recursos funcionam corretamente. Anteriormente, fizemos todos os nossos testes em clusters personalizados do Kubernetes e do Openshift no local, mas agora estamos certificando o AO em vários serviços do Kubernetes na nuvem. A primeira certificação desse tipo é para o Azure Kubernetes Service (AKS). A execução de nossos testes com o AKS apresentou novos desafios na criação e configuração do ambiente de teste em comparação com os ambientes personalizados no local. As soluções para esses desafios são destacadas nesta postagem.

*Observação - O Couchbase Autonomous Operator ainda está em pré-visualização para desenvolvedores no Azure AKS, e estamos planejando o GA em nossa próxima versão 1.2, prevista para o primeiro trimestre de 2019.

Requisitos para nossa estrutura de teste do Kubernetes

Nossa estrutura de teste executa vários tipos diferentes de testes, desde a criação necessária de clusters até a recuperação de falhas em vários nós com volumes persistentes. Também testamos o XDCR em três topologias diferentes definidas pelo local onde residem os dois clusters CB: cluster K8s único, dois clusters K8s diferentes e um K8s para um não K8s. Para executar o conjunto completo de testes, precisamos (1) configurar dois clusters AKS separados que permitam o XDCR. (2) Nossa estrutura de teste deve ser capaz de interagir com cada cluster AKS pela Internet pública. (3) Também devemos ser capazes de acessar os clusters CB dentro dos clusters AKS a partir da Internet pública. (4) Pelo menos uma classe de armazenamento dinâmico deve estar presente no AKS para nossos testes de volume persistente. Na seção a seguir, serão elucidadas as etapas realizadas para atender a esses requisitos.

Criação de clusters AKS prontos para XDCR

O principal obstáculo para que o XDCR funcione entre dois clusters CB (no K8s ou não) é que deve haver uma rota de Camada 3 entre os dois clusters CB. Os nós CB usarão endereços IP internos fornecidos pela API do K8s com base na configuração de rede do cluster AKS. Por padrão, dois clusters AKS usarão os mesmos intervalos de endereços internos, o que fará com que o tráfego XDCR de saída nunca chegue ao seu destino no outro cluster AKS. A solução é configurar os dois clusters AKS de modo que suas redes internas possam se emparelhar. O emparelhamento permitirá que os clusters CB em cada cluster AKS se comuniquem corretamente usando seus endereços IP internos. Para configurar o emparelhamento de rede no AKS, precisamos determinar os prefixos de rede não sobrepostos a serem usados para cada cluster do AKS. Em seguida, com base nesses prefixos, precisamos determinar uma sub-rede de cluster para os nós do Kubernetes, uma sub-rede de serviço para os pods do Kubernetes que não se sobrepõem à sub-rede do cluster, um endereço DNS em cada sub-rede de serviço e uma rede de sobreposição do Docker. A tabela a seguir mostra a configuração de rede adequada para cada cluster AKS.

Agora que a configuração de rede adequada foi determinada, podemos criar esses dois clusters AKS no Portal do Azure. A criação de cada cluster seguirá principalmente as instruções fornecidas pelo Azure aqui, https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough-portal [1], sendo que a única diferença está na configuração da rede (etapa 3). Essas etapas serão para o AKS-cluster-1 e usarão os valores de rede correspondentes determinados anteriormente. As etapas para o AKS-cluster-2 serão as mesmas, usando os valores de rede do AKS-cluster-2. Quando a etapa de rede for alcançada, ative o roteamento de aplicativos HTTP e escolha a configuração de rede avançada.

Crie uma nova rede virtual usando o prefixo e a sub-rede do cluster determinados anteriormente.

Preencha os campos restantes na guia de rede com a sub-rede de serviço, o endereço DNS e os valores de sobreposição do Docker.

Prossiga com a configuração do cluster AKS de acordo com a documentação. Enquanto o AKS-cluster-1 estiver sendo implantado, configure o AKS-cluster-2 usando as mesmas etapas.

Agora que temos dois clusters AKS com a configuração de rede adequada, podemos configurar o emparelhamento de rede. Na interface do usuário, navegue até a rede virtual AKS-cluster-1-vnet criada para o AKS-cluster-1, selecione a guia Peerings e clique em Add (Adicionar) para criar um novo peering.

Dê ao emparelhamento um nome como AKS-cluster-1-AKS-cluster-2 e selecione AKS-cluster-2-vnet como a rede virtual.

O emparelhamento exige que ambas as redes sejam emparelhadas, portanto, também devemos configurar o emparelhamento do AKS-cluster-2-vnet para o AKS-cluster-1-vnet de maneira semelhante. Depois de concluídos, os dois clusters AKS podem hospedar clusters CB com XDCR.

Acesso à API do AKS Kubernetes pela Internet pública

Como nossa estrutura de teste é executada de fora do AKS, precisaremos configurar o acesso externo à API do Kubernetes para cada cluster do AKS. Esse processo é relativamente simples. Precisamos modificar as regras de entrada e saída do grupo de segurança de rede para cada cluster AKS. Navegue até o Grupo de segurança de rede do AKS-cluster-1, selecione Regras de segurança de entrada e, em seguida, Adicionar para criar uma nova regra. Para simplificar a configuração, crie essa regra permitindo qualquer IP/porta de origem e IP/porta de destino. Dê a essa regra o número de prioridade 102.

Agora, faça o mesmo para as regras de segurança de saída. Em seguida, modifique as regras de segurança de entrada e saída do AKS-cluster-2 de forma semelhante.

A próxima etapa é extrair o arquivo kubeconfig (credenciais) para cada cluster AKS. Esses arquivos são usados pela estrutura de teste para acessar e interagir com a API do Kubernetes. Certifique-se de que você tenha a CLI do Azure instalada localmente, conforme descrito aqui: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli?view=azure-cli-latest [2]. Você também precisará ter o kubectl instalado localmente, conforme descrito aqui: https://kubernetes.io/docs/tasks/tools/install-kubectl/ [3]. Depois que ambos estiverem instalados e funcionando, execute os seguintes comandos para extrair o arquivo kubeconfig do AKS-cluster-1 e do AKS-cluster-2:

As credenciais do cluster serão armazenadas no arquivo ~/.kube/config. Para nossa estrutura de teste, separamos as credenciais de cada cluster em seus próprios arquivos: ~/.kube/config_aks_cluster_1 e ~/.kube/config_aks_cluster_2.

Acesso a pods CB no AKS

Nesse ponto, nossa estrutura de teste pode interagir com a API Kubernetes de dois clusters AKS. Isso permite que a estrutura de teste instale o AO e crie clusters CB gerenciados pelo AO para nossos testes. No entanto, a estrutura de teste precisa interagir com os pods CB por meio de chamadas REST para a maioria dos nossos testes. Anteriormente, a estrutura de teste faria com que o AO expusesse a API REST do CB como um serviço nodeport do Kubernetes. Esse serviço criava uma porta no nó do Kubernetes, que encaminhava o tráfego para a porta da API REST do pod CB dentro do nó do Kubernetes. Esses serviços eram acessíveis por meio do endereço IP privado do nó do Kubernetes. Isso não era um problema, pois nosso cluster do Kubernetes no local e a estrutura de teste viviam na mesma rede privada. Com o AKS, no entanto, nossa estrutura de teste não está localizada nos nós do Kubernetes do AKS e não pode acessar um serviço de porta de nó que usa os IPs privados desses nós. A solução para isso é simples: depois que o AO criar o cluster CB e o serviço nodeport, faça com que a estrutura de teste altere o campo Spec. Type do serviço nodeport para LoadBalancer. Isso é feito na seguinte parte do código Go:

Quando o tipo de serviço nodeport for alterado para LoadBalancer, o AKS atribuirá um IP público ao serviço. Usando esse novo IP público, a estrutura de teste pode fazer chamadas com êxito para a API REST do CB, mesmo de fora do AKS. Na próxima versão principal, Autonomous Operator 1.2, o AO terá a opção de expor um serviço nodeport ou um serviço de balanceador de carga, e qualquer alteração nos serviços implantados pelo AO fará com que o AO reconcilie o serviço novamente. Portanto, a solução que usamos em nossa estrutura de teste é apenas temporária e, no futuro, passaremos a criar serviços de balanceador de carga autônomos e usaremos o AO para criar o balanceador de carga.

Habilitação de volumes persistentes dinâmicos

O AO permite que um cluster CB se vincule a volumes persistentes provisionados dinamicamente. Isso torna o cluster CB muito resistente à perda de dados no caso de um ou mais pods CB ficarem inoperantes. Nossa estrutura de testes tem muitos cenários de falha complexos que envolvem pods CB que armazenam dados em volumes persistentes. Em alguns cenários de falha, o AO reiniciará o pod com falha em um nó diferente do Kubernetes usando o volume persistente dos pods com falha. Portanto, devemos usar volumes persistentes que possam ser movidos de um nó do Kubernetes para outro. No AKS, dois tipos de classes de armazenamento podem ser usados para volumes persistentes: AzureDisk e AzureFile. A classe de armazenamento padrão que o AKS fornece é o AzureDisk, mas essa classe de armazenamento não pode criar volumes persistentes móveis. O AzureFile é implementado de forma a permitir volumes persistentes móveis e será a solução de classe de armazenamento que testaremos no AKS. O Azure fornece instruções para configurar a classe de armazenamento AzureFile aqui:

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

A configuração envolve primeiro a criação de uma conta de armazenamento com:

Em seguida, envie uma classe de armazenamento, uma função de cluster e uma especificação de vinculação de função de cluster para o Kubernetes:

Agora temos nossa classe de armazenamento AzureFile configurada e pronta para uso no AKS-cluster-1. Devemos fazer o mesmo processo para o AKS-cluster-2.

Teste do operador

Neste ponto, temos tudo o que precisamos para executar o conjunto completo de testes para o cluster do Kubernetes AO: 2 XDCR-ready, acessível pela Internet pública (API do Kubernetes e API REST do CB), com volumes persistentes dinâmicos ativados. Durante o teste inicial, notamos algumas falhas estranhas. Elas foram causadas principalmente por timeouts em nossa estrutura de teste, e conseguimos identificar a causa: O AKS é extremamente lento em comparação com o cluster Kubernetes local. O tempo necessário para ativar um pod CB pode levar até cinco vezes mais. Para resolver esse problema, tivemos que criar tempos limite variáveis, dependendo do tipo de cluster do Kubernetes que está sendo usado. Depois disso, todos os testes foram bem executados e não foram encontrados problemas significativos com o cluster AO ou CB.

Conclusão

Recentemente, a equipe de testes do Couchbase tem se concentrado em certificar o AO para uso nos principais serviços Kubernetes fornecidos pela nuvem, como AKS, EKS e GCP. A primeira nuvem em que nos concentramos foi a AKS, e ela trouxe vários desafios específicos da plataforma, como configuração de rede específica da nuvem, acessibilidade e criação de classe de armazenamento. No entanto, resolvemos esses problemas e agora podemos executar nossa estrutura de teste automatizada usando clusters de AKS. Continuaremos trabalhando na certificação de outras nuvens nos próximos meses, mas, enquanto isso, divirta-se com o AKS.

Referências:

[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