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 GCP e a configuração organizacional antes de passar para as etapas de configuração do cluster.

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

Criar uma rede virtual em cada região

Crie uma rede virtual para a implantação de várias regiões. Por exemplo, os comandos de exemplo a seguir criam redes nas regiões Central dos EUA e Leste dos EUA.

Execute este comando para criar uma rede virtual na região Leste dos EUA, com o nome my-hybrid-rg-vnet:

az network vnet create \
 --name my-hybrid-rg-vnet \
 --location eastus \
 --resource-group my-hybrid-rg \
 --address-prefixes 120.38.1.0/24 \
 --subnet-name my-hybrid-rg-vnet-subnet \
 --subnet-prefix 120.38.1.0/26

Execute este comando para criar uma rede virtual na região Central dos EUA, com o nome my-hybrid-rg-vnet-ext01:

az network vnet create \
 --name my-hybrid-rg-vnet-ext01 \
 --location centralus \
 --resource-group my-hybrid-rg \
 --address-prefixes 192.138.0.0/24 \
 --subnet-name my-hybrid-rg-vnet-ext01-subnet \
 --subnet-prefix 192.138.0.0/26

Criar peering de rede

Crie um peering de rede entre as redes virtuais.

Acessar os IDs de rede virtual

Os peerings são estabelecidos entre os IDs de rede virtual. Consiga o ID de cada rede virtual com o comando az network vnet show e armazene o ID em uma variável.

Encontre o ID da primeira rede virtual, chamada my-hybrid-rg-vnet:

vNet1Id=$(az network vnet show \
 --resource-group my-hybrid-rg \
 --name my-hybrid-rg-vnet \
 --query id --out tsv)

Consiga o ID da segunda rede virtual, chamada my-hybrid-rg-vnet-ext01:

vNet2Id=$(az network vnet show \
 --resource-group my-hybrid-rg \
 --name my-hybrid-rg-vnet-ext01 \
 --query id \
 --out tsv)

Criar peering da primeira rede virtual com a segunda

Com os IDs de rede virtual, é possível criar um peering da primeira rede virtual (my-hybrid-rg-vnet) para a segunda (my-hybrid-rg-vnet-ext01), conforme mostrado nos exemplos a seguir:

Se você não especificar o parâmetro --allow-vnet-access, um peering será estabelecido, mas nenhuma comunicação poderá passar por ele.

az network vnet peering create \
 --name my-hybrid-rg-vnet1-peering \     # The name of the virtual network peering.
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet \         # The virtual network name.
 --remote-vnet $vNet2Id \                # Resource ID of the remote virtual network.
 --allow-vnet-access

Na saída do comando, observe que peeringState foi Iniciado. O peering permanece no estado Iniciado até que você crie o peering da segunda rede virtual de volta com a primeira.

{
  ...
  "peeringState": "Initiated",
  ...
}

Criar um peering da segunda rede virtual com a primeira

Exemplo de comando:

az network vnet peering create \
 --name my-hybrid-rg-vnet2-peering \        # The name of the virtual network peering.
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet-ext01 \      # The virtual network name.
 --remote-vnet $vNet1Id \                   # Resource ID of the remote virtual network.
 --allow-vnet-access

Na saída do comando, observe que peeringState está Conectado. O Azure também altera o estado do peering da primeira com a segunda rede virtual para Conectado.

{
  ...
  "peeringState": "Connected",
  ...
}

Também é possível confirmar o estado do peering de my-hybrid-rg-vnet1-peering como my-hybrid-rg-vnet2-peering: o peering foi alterado para Conectado com o seguinte comando:

az network vnet peering show \
 --name my-hybrid-rg-vnet1-peering \
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet \
 --query peeringState

Resposta esperada:

Connected

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
```