Implantação de várias regiões no AKS

Neste tópico, explicamos como configurar uma implantação de várias regiões para a Apigee híbrida no Microsoft® Azure Kubernetes Service (AKS).

As topologias para implantação de várias regiões incluem:

Ativo-Ativo: quando você tem aplicativos implantados em vários locais geográficos e requer uma resposta de baixa latência da API para suas implantações. Você tem a opção de implantar a Apigee híbrida em várias localizações geográficas mais próximas de seus clientes. Por exemplo: Costa Oeste dos EUA, Costa Leste dos EUA, Europa, APAC.
Ativo-Passivo: quando você tem uma região principal e uma região de recuperação de desastres ou failover.

As regiões em uma implantação híbrida multirregional se comunicam por meio do Cassandra, como mostrado na imagem a seguir:

Pré-requisitos

Antes de configurar o híbridos para várias regiões, é preciso atender aos seguintes pré-requisitos:

Siga o guia de instalação híbrida para pré-requisitos como o Google Cloud e a configuração organizacional antes de passar para as etapas de configuração do cluster.
Requisitos da multirregião Cassandra:
- Verifique se o namespace da rede do pod tem conectividade entre as regiões, incluindo firewalls, vpn, peering vpc e vNet.
- Se o namespace da rede do pod não tiver conectividade entre pods em clusters diferentes (os clusters estão sendo executados em "modo de rede de ilha", por exemplo, na maioria das instalações de AKS), ative o recurso hostNetwork do Kubernetes definindo cassandra.hostNetwork: true no arquivo de substituições para todas as regiões na instalação multirregional da Apigee híbrida.
  Para informações sobre o recurso hostNetwork do Kubernetes, consulte Namespaces do host na documentação do Kubernetes.
- Ative o hostNetwork nos clusters atuais antes de expandir a configuração multirregional para novas regiões.
- Quando hostNetwork estiver ativado, verifique se os nós de trabalho podem realizar a busca DNS reversa. A Apigee do Cassandra usa busca DNS reversa e direta para conseguir o IP do host ao iniciar.
  Dica: se a resolução de DNS não funcionar, tente esta solução alternativa.
  Adicione uma entrada de host estática no arquivo /etc/hosts de cada nó de trabalho do Cassandra semelhante ao seguinte:
```
echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"
```
  ou
```
"\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"
```
- Abra as portas 7000 e 7001 do Cassandra entre clusters do Kubernetes em todas as regiões para permitir que os nós de trabalho entre regiões e data centers se comuniquem. Consulte Configurar portas.

Para informações detalhadas, consulte a documentação do Kubernetes.

Criar uma rede virtual em cada região

Siga as recomendações do Azure para estabelecer a comunicação entre regiões aqui: VNet-to-VNet: como conectar redes virtuais no Azure em diferentes regiões.

Criar clusters multirregionais

Configure clusters do Kubernetes em várias regiões com diferentes blocos CIDR. Consulte também a Etapa 1: criar um cluster. Use os locais e os nomes das redes virtuais que você criou anteriormente.

Abra as portas 7000 e 7001 do Cassandra entre os clusters do Kubernetes em todas as regiões (7000 pode ser usada como opção de backup durante uma solução de problemas)

Configurar o host de propagação multirregional

Esta seção descreve como expandir o cluster existente do Cassandra para uma nova região. Essa configuração permite que a nova região inicialize o cluster e participe do data center atual. Sem essa configuração, os clusters multirregionais do Kubernetes não sabem da existência uns dos outros.

Defina o contexto do kubectl como o cluster original antes de recuperar o nome da propagação:
```
kubectl config use-context original-cluster-name
```
Execute o comando kubectl a seguir para identificar um endereço do host de propagação do Cassandra na região atual.

Um endereço de host de propagação permite que uma nova instância regional encontre o cluster original na primeira inicialização para aprender a topologia do cluster. O endereço do host de propagação é designado como o ponto de contato no cluster.
```
kubectl get pods -o wide -n apigee | grep apigee-cassandra

apigee-cassandra-default-0  1/1   Running   0   4d17h   120.38.1.9  aks-agentpool-21207753-vmss000000
```
Decida quais dos IPs retornados do comando anterior serão o host de propagação multirregional. Neste exemplo, em que apenas um cluster do Cassandra está sendo executado, o host de propagação é 120.38.1.9.
No data center 2, copie o arquivo de modificações para um novo arquivo com o nome do cluster. Por exemplo, overrides_your_cluster_name.yaml
No data center 2, configure cassandra.multiRegionSeedHost e cassandra.datacenter em overrides_your_cluster_name.yaml, em que multiRegionSeedHost é um dos IPs retornados pelo comando anterior:
```
cassandra:
  multiRegionSeedHost: seed_host_IP
  datacenter: data_center_name
  rack: rack_name
```
Exemplo:
```
cassandra:
  multiRegionSeedHost: 120.38.1.9
  datacenter: "centralus"
  rack: "ra-1"
```
No novo data center/região, antes de instalar a Apigee híbrida, defina os mesmos certificados e credenciais TLS em overrides_your_cluster_name.yaml, conforme definido na primeira região.
OBSERVAÇÃO: use os mesmos certificados e credenciais TLS do Cassandra no segundo data center, conforme definido no data center original. As credenciais definidas no arquivo de modificações no primeiro data center precisam corresponder àquelas especificadas no arquivo de modificações no segundo data center. Para detalhes, consulte Como configurar o TLS para o Cassandra.

Configurar a nova região

Depois de configurar o host de propagação, será possível configurar a nova região.

Para configurar a nova região:

Copie o certificado do cluster atual para o novo cluster. A nova raiz da CA é usada pelo Cassandra e outros componentes híbridos para mTLS. Portanto, é essencial ter certificados consistentes em todo o cluster.
1. Defina o contexto como o namespace original:
```
kubectl config use-context original-cluster-name
```
2. Exporte a configuração atual do namespace para um arquivo:
```
$ kubectl get namespace namespace -o yaml > apigee-namespace.yaml
```
3. Exporte o secret apigee-ca para um arquivo:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Defina o contexto para o nome do cluster da nova região:
```
kubectl config use-context new-cluster-name
```
5. Importe a configuração do namespace para o novo cluster. Certifique-se de atualizar o "namespace" no arquivo se você estiver usando um namespace diferente na nova região:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importe o secret para o novo cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Instale a Apigee híbrida na nova região. Certifique-se de que o arquivo overrides_your_cluster_name.yaml inclua os mesmos certificados TLS configurados na primeira região, conforme explicado na seção anterior.
Execute os dois comandos a seguir para instalar a Apigee híbrida na nova região:
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Execute nodetool rebuild sequencialmente em todos os nós no novo data center. Isso pode levar de alguns minutos a algumas horas, dependendo do tamanho dos dados.
```
kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password rebuild -- dc-1
```
Em que JMX_user e JMX_password são o nome de usuário e a senha do usuário do Cassandra JMX.

Verifique os processos de recompilação nos registros. Além disso, verifique o tamanho dos dados usando o comando nodetool status:

kubectl logs apigee-cassandra-default-0 -f -n apigee

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status

O exemplo a seguir mostra entradas de registro de exemplo:

INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

Atualize os hosts de propagação. Remova multiRegionSeedHost: 10.0.0.11 de overrides-DC_name.yaml e aplique novamente.
Os hosts de propagação são membros do cluster local. Para inicializar uma nova região, é necessário um host de propagação externo. Quando uma região for inicializada, você precisará alterar os hosts de propagação para os clusters locais em overrides.yaml e reaplicar a configuração.
```
apigeectl apply -f overrides-DC_name.yaml
```