Rede entre kubernetes por meio de emparelhamento de VPC

1. Introdução

Muitas vezes, é desejável que os clientes corporativos tenham clusters de banco de dados em espera para localização de dados e alto desempenho, recuperação de desastres e/ou para simples backups de dados. O Couchbase Cross Data Center Replication (XDCR) dispensa apresentações, pois os clientes usam esse recurso há muito tempo para atingir esses objetivos em seus ambientes.

No entanto, com cada vez mais implementações do Couchbase na nuvem usando o Couchbase Autonomous Operator (CAO) para Kubernetes, os clientes solicitaram orientação para configurar a rede para sua plataforma de nuvem.

Este artigo aborda em detalhes a configuração de redes entre clusters do Couchbase em duas regiões diferentes, usando uma abordagem passo a passo. Usamos a plataforma Amazon AWS para implantar o cluster do Couchbase no ambiente Amazon EKS, mas acreditamos que a abordagem de alto nível seria mais ou menos a mesma, independentemente da plataforma de sua escolha.

2. Pré-requisitos

É altamente recomendável que você leia meu blog anterior sobre como implementar o cluster do Couchbase no EKS. A maioria das etapas detalhadas sobre a implantação do Couchbase Autonomous Operator será apenas referenciada neste artigo, portanto, podemos nos concentrar nos aspectos de rede para configurar a replicação entre centros de dados.

3. Implantar clusters EKS em duas regiões

Vamos começar implantando dois Amazon Elastic Container Service for Kubernetes (Amazon EKS) em duas regiões distintas (Virgínia e Ohio).

Figura 1: Cluster EKS implantado nas regiões de Ohio e Virgínia.

Cada cluster do Amazon EKS terá um mínimo de três nós de trabalho, que serão usados para hospedar pods do Couchbase, conforme descrito na seção 4. Nosso objetivo ao final deste artigo é que você tenha dois clusters do Couchbase implantados nesses dois clusters do Amazon EKS, com a rede configurada e o XDCR ativo estabelecido da origem para o cluster de destino.

3.1. Implantar o EKS na região da Virgínia

Usaremos eksctl para implantar o Amazon EKS, onde criaremos um novo nodegroup chamado grupo azul com um mínimo de três m5.large instâncias e um máximo de seis.

$ eksctl create cluster \
--name blueEKS \
--version 1.14 \
--region us-east-1 \
--zones us-east-1a,us-east-1b,us-east-1c \
--nodegroup-name bluegroup \
--node-type m5.large \
--nodes 3 \
--nodes-min 3 \
--nodes-max 6 \
--node-ami auto \
--vpc-cidr 172.16.0.0/24

[ℹ]  using region us-east-1
...
[✔]  EKS cluster "blueEKS" in "us-east-1" region is ready

Uma vez eksctl Quando terminar de implantar o cluster Kubernestes (K8s), faça login no console do AWS para anotar o VPC-ID e o bloco CIDR. Aqui estão as etapas para descobrir esses detalhes, que serão usados posteriormente na configuração do par de VPC.

Figura 2: Console EKS mostrando o painel de recursos por região.

1. Selecione Virgínia no menu suspenso.
2. Se você vir o VPC Dashboard, clique em Suas VPCs no painel esquerdo. Se você tiver uma página diferente aberta, pesquise primeiro o serviço VPC e, em seguida, clique em Suas VPCs opção.

Figura 3: Página de detalhes da VPC.

1. Como pode ser visto acima, você precisa selecionar a VPC que acabou de ser criada e, em seguida, copiar o ID DA VPC na tabela abaixo:

Tabela 1. Atributos do cluster EKS azul

Atributos	Aglomerado azul	Grupo verde
Região	Virgínia	Ohio
Bloco CIDR	172.16.0.0/24
VPC-ID	vpc-0c8d3d5919e79659d

3.2. Implantar o EKS na região de Ohio

Em seguida, implante o cluster do Kubernetes na região de Ohio com 3 nós de trabalho de m5.large tipo. O número e o tipo desses nós de trabalho podem ser diferentes, dependendo do tamanho do cluster, mas, nesta configuração, vamos implantar um cluster do Couchbase de 3 nós nesses 3 nós de trabalho.

$ eksctl create cluster \
--name greenEKS \
--version 1.14 \
--region us-east-2 \
--zones us-east-2a,us-east-2b,us-east-2c \
--nodegroup-name greengroup \
--node-type m5.large \
--nodes 3 \
--nodes-min 3 \
--nodes-max 6 \
--node-ami auto \
--vpc-cidr 10.0.0.0/24

[ℹ]  using region us-east-2
...
[✔]  EKS cluster "greenEKS" in "us-east-2" region is ready

Depois que o cluster Green estiver pronto, abra uma nova guia do navegador e faça login no console do AWS.

Figura 4: Console do AWS conectado à região de Ohio.

• Alterar a região para Ohio

Figura 5: Página de detalhes do VPC mostrando os detalhes do cluster de Ohio.

• No painel de controle da VPC, selecione Suas VPCs guia.
• Copie e cole o ID do VPC do Green Cluster na tabela abaixo para o registro:

Tabela 2. Atributos do cluster EKS verde

Atributos	Aglomerado azul	Grupo verde
Região	Virgínia	Ohio
Bloco CIDR	172.16.0.0/24	10.0.0.0/24
VPC-ID	vpc-0c8d3d5919e79659d	vpc-08d025c8ae697bf34

Neste ponto, temos o cluster Kubernetes implantado nas regiões da Virgínia e de Ohio e temos detalhes de VPC que serão usados no emparelhamento de VPC.

3.3. Trocar o contexto do cluster

Antes de prosseguirmos com a implantação de clusters do Couchbase nessas duas regiões, é preciso lembrar de um comando útil para alternar facilmente os contextos de cluster:

$ kubectl config get-contexts

CURRENT   NAME                                                    CLUSTER                        AUTHINFO                                                NAMESPACE
*         x.y@domain.com@blueEKS.us-east-1.eksctl.io    blueEKS.us-east-1.eksctl.io    x.y@domain.com@blueEKS.us-east-1.eksctl.io
          x.y@domain.com@greenEKS.us-east-2.eksctl.io   greenEKS.us-east-2.eksctl.io   x.y@domain.com@greenEKS.us-east-2.eksctl.io

Como pode ser visto acima, haverá dois clusters diferentes registrados em kubectl config. Atualmente, o contexto está definido como blueEKS.us-east-1.eksctl.io e se quisermos mudar para o cluster greenEKS.us-east-2.eksctl.io podemos simplesmente fazer isso:

$ kubectl config use-context x.y@domain.com@greenEKS.us-east-2.eksctl.io

Switched to context "x.y@domain.com@greenEKS.us-east-2.eksctl.io".

$ kubectl get nodes
NAME                                      STATUS    ROLES     AGE       VERSION
ip-10-0-0-11.us-east-2.compute.internal   Ready     <none>    20m      v1.14.8-eks-b8860f
ip-10-0-0-61.us-east-2.compute.internal   Ready     <none>    20m      v1.14.8-eks-b8860f
ip-10-0-0-72.us-east-2.compute.internal   Ready     <none>    20m      v1.14.8-eks-b8860f

A partir daí, qualquer kubectl que executamos, ele estará no contexto de greenEKS.us-east-2.eksctl.io que está em leste-2 (Ohio) região.

4. Implantar o cluster do Couchbase em duas regiões

Em meu último blog sobre Como implantar o cluster do Couchbase no EKS usando volumes persistentesNa seção "Como fazer o download", abordei cada etapa em detalhes. Portanto, em vez de repetir as etapas, aqui novamente, vou apenas segui-las para manter as coisas simples.

4.1 Configuração do Green Cluster

Vamos começar a implementar nosso primeiro cluster do Couchbase em leste-2 região também conhecida como verde neste caso. Portanto, seguindo as etapas do último blog, nós o faremos:

• Implante o Couchbase Autonomous Operator seguindo as etapas de 2.1 a 2.8.
• Crie o segredo e a classe de armazenamento executando as etapas 3.1 a 3.2

Não usaremos o script de implantação de cluster, conforme mencionado aqui; em vez disso, usaremos couchbase-green-cluster.yaml que criará um cluster do Couchbase de três nós espalhados em três zonas de disponibilidade diferentes (east-2a/2b/2c).

$ kubectl create -f couchbase-green-cluster.yaml -n emart --save-config

couchbasecluster.couchbase.com/green created

Observação: É uma prática recomendada permitir spec.antiAffinity em couchbase-green-cluster.yaml para garantir que cada nó do Kubernetes receba um e somente um pod. Isso garante que, se um nó falhar, apenas um pod do Couchbase será desativado.

$ kubectl logs couchbase-operator-7654d844cb-tz7k5 -n emart -f

time="2020-02-22T08:22:02Z" level=info msg="Node status:" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="┌────────────┬──────────────────┬──────────────┬────────────────┐" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="│ Server     │ Version          │ Class        │ Status         │" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="├────────────┼──────────────────┼──────────────┼────────────────┤" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="│ green-0000 │ enterprise-6.0.3 │ data-east-2a │ managed+active │" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="└────────────┴──────────────────┴──────────────┴────────────────┘" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="Scheduler status:" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="┌──────────────┬────────────┬────────────┐" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="│ Class        │ Zone       │ Server     │" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="├──────────────┼────────────┼────────────┤" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="│ data-east-2a │ us-east-2a │ green-0000 │" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="└──────────────┴────────────┴────────────┘" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info cluster-name=green module=cluster
time="2020-02-22T08:22:08Z" level=info msg="Creating a pod (green-0001) running Couchbase enterprise-6.0.3" cluster-name=green module=cluster
time="2020-02-22T08:23:21Z" level=info msg="added member (green-0001)" cluster-name=green module=cluster
time="2020-02-22T08:23:21Z" level=info msg="Creating a pod (green-0002) running Couchbase enterprise-6.0.3" cluster-name=green module=cluster
time="2020-02-22T08:24:31Z" level=info msg="added member (green-0002)" cluster-name=green module=cluster
time="2020-02-22T08:24:39Z" level=info msg="Rebalance progress: 0.000000" cluster-name=green module=cluster
time="2020-02-22T08:24:43Z" level=info msg="reconcile finished" cluster-name=green module=cluster

Agora podemos fazer o port forward para visualizar o console de administração do Couchbase:

$ kubectl port-forward green-0000 8092:8091 -n emart

Forwarding from 127.0.0.1:8092 -> 8091
Forwarding from [::1]:8092 -> 8091

Em seguida, abra um navegador e digite: https://localhost:8092/ para se conectar ao Console da Web do Couchbase de Verde agrupamento:

Figura 6: Três nós: cluster verde distribuído em três zonas de disponibilidade (AZs)

Criar um balde vazio padrãoque será usado posteriormente como o bucket de destino durante a configuração do XDCR.

Figura 7: Compartimento de destino sem documentos nele

4.2 Configuração do cluster azul

Precisamos mudar o contexto de kubectl config para trabalhar com o cluster blueEKS.

$ kubectl config use-context x.y@domain.com@blueEKS.us-east-1.eksctl.io

Switched to context "x.y@domain.com@blueEKS.us-east-1.eksctl.io".

$ kubectl get nodes
NAME                          STATUS    ROLES     AGE       VERSION
ip-172-16-0-25.ec2.internal   Ready     <none>    2h       v1.14.8-eks-b8860f
ip-172-16-0-42.ec2.internal   Ready     <none>    2h       v1.14.8-eks-b8860f
ip-172-16-0-76.ec2.internal   Ready     <none>    2h       v1.14.8-eks-b8860f

Depois de mudar o contexto, seguiremos as mesmas etapas descritas acima. Usaremos o couchbase-blue-cluster.yaml para finalmente implementar um cluster de três nós.

$ kubectl create -f couchbase-blue-cluster.yaml -n emart --save-config

couchbasecluster.couchbase.com/green created

Agora vamos dar uma olhada nos logs do operador para verificar o progresso:

$ kubectl get pods -n emart
NAME                                            READY     STATUS    RESTARTS   AGE
couchbase-operator-7654d844cb-58gch             1/1       Running   0          4m22s
couchbase-operator-admission-7ff868f54c-57rhc   1/1       Running   0          5m21s

$ kubectl logs couchbase-operator-7654d844cb-58gch -n emart -f

time="2020-02-22T08:52:07Z" level=info msg="┌───────────┬──────────────────┬──────────────┬────────────────┐" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="│ Server    │ Version          │ Class        │ Status         │" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="├───────────┼──────────────────┼──────────────┼────────────────┤" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="│ blue-0000 │ enterprise-6.0.3 │ data-east-1a │ managed+active │" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="└───────────┴──────────────────┴──────────────┴────────────────┘" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="Scheduler status:" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="┌──────────────┬────────────┬───────────┐" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="│ Class        │ Zone       │ Server    │" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="├──────────────┼────────────┼───────────┤" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="│ data-east-1a │ us-east-1a │ blue-0000 │" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="└──────────────┴────────────┴───────────┘" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info cluster-name=blue module=cluster
time="2020-02-22T08:52:13Z" level=info msg="Creating a pod (blue-0001) running Couchbase enterprise-6.0.3" cluster-name=blue module=cluster
time="2020-02-22T08:53:27Z" level=info msg="added member (blue-0001)" cluster-name=blue module=cluster
time="2020-02-22T08:53:27Z" level=info msg="Creating a pod (blue-0002) running Couchbase enterprise-6.0.3" cluster-name=blue module=cluster
time="2020-02-22T09:00:45Z" level=info msg="added member (blue-0002)" cluster-name=blue module=cluster
time="2020-02-22T09:00:54Z" level=info msg="Rebalance progress: 0.000000" cluster-name=blue module=cluster
time="2020-02-22T09:00:58Z" level=info msg="reconcile finished" cluster-name=blue module=cluster

Encaminhe o console de administração do Couchbase para a porta 8091:

$ kubectl port-forward green-0000 8091:8091 -n emart

Forwarding from 127.0.0.1:8091 -> 8091
Forwarding from [::1]:8091 -> 8091

Abra outra guia em seu navegador e digite: https://localhost:8091/ para se conectar ao Console da Web do Couchbase de Azul agrupamento:

Figura 8: Cluster azul de três nós distribuído em três zonas de disponibilidade (AZs)

4.2.1 Criar um bucket de amostras de viagem

Vamos usar amostra de viagem como os dados de origem, que serão replicados para o destino verde cluster. Para criar um bucket de amostra, acesse Configurações > Buckets de amostra e clique na caixa de seleção ao lado de amostra de viagem. Isso criará o compartimento necessário e preencherá vários documentos no compartimento.

Figura 9: Balde de origem com alguns dados de amostra

Vamos replicar esse conjunto de amostras de viagem para o cluster de destino na região de Green (também conhecida como Ohio).

5. Configuração de rede

A diversão começa com a seção de configuração de rede. Se você já usou o Console do AWS para configurar o emparelhamento de VPC entre duas regiões ou dois VPCs separados, esta seção será muito fácil. E se você quiser aprender a configurar o emparelhamento de VPC, esta será uma ótima experiência de aprendizado.

5.1 Configuração de emparelhamento de VPC

A primeira etapa do processo de três etapas é estabelecer o peering de VPC da VPC solicitante para a VPC aceitante. Nesta etapa, faremos login na região da Virgínia usando o console do AWS e iniciaremos a solicitação de emparelhamento. Em seguida, faremos login na região de Ohio para aceitar essa solicitação.

5.1.1 Iniciar solicitação de VPC da região Azul

Vamos começar o processo de iniciação de emparelhamento da VPC conectando-nos à região da Virgínia.

Figura 10: Console da AWS exibindo o resumo dos recursos na região da Virgínia

1. Certifique-se de ter selecionado a região do solicitante no console do AWS, que, no nosso caso, é a Virgínia.
2. Abra a página do painel do VPC.

Figura 11: Opção de emparelhamento de VPC no painel de controle de VPC

1. Selecione o Conexões de peering no painel esquerdo.
2. Clique em Criar conexão de peering da página.

Depois de clicar no botão, você verá uma página de diálogo em que é necessário:

1. Forneça um nome exclusivo para essa conexão de emparelhamento. Vamos usar peering de azul para verde porque a região da Virgínia está hospedando nosso cluster Azul e Ohio está hospedando nosso cluster Verde.

Figura 12: Configuração de solicitante e aceitador de peering VPC.

1. Selecione o ID de VPC do cluster Blue, pois esse é o solicitante.
2. Nosso cluster de destino está em uma região diferente, portanto, vamos selecionar Outra região como a opção para Região.
3. Em seguida, selecione a região de destino, que é Ohio.
4. Anotamos as IDs de VPC de ambas as VPCs na tabela 2. Portanto, usaremos o ID de VPC do cluster Green.
5. Acertar Criar conexão de peering botão.

Figura 13: Solicitação de peering estabelecida.

Isso exibirá a página de confirmação. Basta clicar em OK e isso lhe mostrará que a solicitação foi iniciada.

5.1.2 Aceitar solicitação de VPC da região verde

Agora, no console da AWS, altere a região para Ohio (também conhecida como região verde) e selecione VPC Dashboard.

Figura 14: Selecione a região us-east-2 (Ohio)

• O mesmo que antes de selecionar o Conexões de peering no painel esquerdo, para que possamos concluir a solicitação de peering aceitando-a.

Figura 15: Selecionar Conexões de peering opções do painel de controle da VPC

• Como pode ser visto acima, há uma solicitação pendente na lista. Selecionaremos essa solicitação primeiro.

Figura 16: Aceitar solicitação de emparelhamento de VPC

• Então, a partir do Ações selecionaremos Aceitar solicitação.

Figura 17: Confirmar a solicitação de emparelhamento de VPC na janela pop-up

• Será exibida uma página de confirmação. Selecione Sim, aceitar botão.

Figura 18: A conexão de emparelhamento VPC de origem-destino é estabelecida

Isso conclui a etapa 1 do emparelhamento da VPC, pois o status do emparelhamento é Ativo.

5.2 Atualizar tabelas de roteamento

A segunda etapa é estabelecer o canal de comunicação adicionando o bloco CIDR do cluster de destino às tabelas de rotas. Para fazer isso, precisamos descobrir em quais sub-redes cada uma das três instâncias do EC2 reside.

Quando tivermos a lista de sub-redes em cada uma das três AZs (1a, 1b, 1c) em que temos nós de trabalho do Kubernetes em execução, precisaremos descobrir a tabela de roteamento associada a cada uma das três sub-redes. Para essas tabelas de roteamento, gostaríamos de adicionar uma entrada de tabela de roteamento para permitir o tráfego proveniente de outra VPC por meio de peering de VPC. Vamos dar uma olhada passo a passo.

5.2.1 Sub-redes usadas no Blue Cluster

1. Faça login no console do AWS e selecione a região da Virgínia (também conhecida como região azul). Depois disso, selecione o serviço EC2 para exibir todas as instâncias do EC2 usadas como nós do Kubernetes.

Figura 19: Sub-rede associada a cada uma das instâncias do EC2.

1. Em seguida, selecione uma das instâncias do EC2. Na imagem acima, selecionei instâncias na região us-east-1a e a guia de descrição exibirá todos os detalhes sobre essa instância.
2. Anote o nome da sub-rede (mencionado entre parênteses) em que essa instância está residindo. Por exemplo, a instância acima está implementada em eksctl-blueEKS-cluster/SubnetPublicUSEAST1A sub-rede.
3. Repita o mesmo processo até obter a lista de todas as sub-redes usadas em seu cluster. No nosso caso, temos essas três sub-redes usadas em nosso cluster:

Atributos	us-east-1a	us-east-1b	us-east-1c
Nome da sub-rede	eksctl-blueEKS-cluster/SubnetPublicUSEAST1A	eksctl-blueEKS-cluster/SubnetPublicUSEAST1B	eksctl-blueEKS-cluster/SubnetPublicUSEAST1C

5.2.2 Tabela de roteamento associada a sub-redes

A próxima etapa seria descobrir a tabela de roteamento associada a cada uma das sub-redes, para que possamos adicionar a regra de roteamento a ela para permitir o tráfego do cluster Green.

Figura 20: Tabelas de roteamento associadas a cada sub-rede no cluster

1. Para localizar a tabela de roteamento usada, clique em Sub-redes à esquerda.
2. Em seguida, selecione uma das sub-redes da lista eksctl-blueEKS-cluster/SubnetPublicUSEAST1A
3. Anote a tabela de roteamento usada procurando na seção Descrição guia.
4. Repita as três etapas acima para cada uma das sub-redes e anote a tabela de roteamento usada:

Atributos	us-east-1a	us-east-1b	us-east-1c
Nome da sub-rede	eksctl-blueEKS-cluster/SubnetPublicUSEAST1A	eksctl-blueEKS-cluster/SubnetPublicUSEAST1B	eksctl-blueEKS-cluster/SubnetPublicUSEAST1C
Nome da tabela de rotas	eksctl-blueEKS-cluster/PublicRouteTable	eksctl-blueEKS-cluster/PublicRouteTable	eksctl-blueEKS-cluster/PublicRouteTable

Como se pode notar, em nosso caso temos uma tabela de rotas eksctl-blueEKS-cluster/PublicRouteTable associada a todas as três sub-redes, portanto, atualizaremos apenas uma tabela de rotas.

5.2.3 Adicionar regra de roteamento

Agora vamos adicionar 10.0.0.0/24 Bloco CIDR da região de destino no roteamento permitido Rotas da tabela de roteamento de origem.

Figura 21: A guia Route Tables mostra a lista de tabelas de roteamento existentes na região azul

1. Clique no botão Tabelas de roteamento no menu esquerdo do console do AWS.
2. Selecione a tabela de rotas à qual gostaríamos de adicionar a entrada de rota, ou seja eksctl-blueEKS-cluster/PublicRouteTable.
3. Em seguida, clique no botão Rotas ao lado da guia de resumo, onde você veria apenas duas entradas de rota.
4. Para permitir 10.0.0.0/24 Bloco CIDR clique no botão Editar rotas botão.

Figura 22: Página de diálogo Edit Routes (Editar rotas).

1. Na caixa de diálogo acima, adicione o bloco CIDR do cluster GREEN e selecione VPC-Peering como o destino. Em seguida, clique em salvar rotas botão.
2. Você verá o bloco CIDR de destino 10.0.0.0/24 agora faz parte do Rotas disponíveis para a tabela de rotas selecionada: eksctl-blueEKS-cluster/PublicRouteTable

Figura 23: Tabela de rotas mostrando o bloco CIDR de destino como a rota permitida.

Observação: Repita o mesmo processo para o cluster de Ohio (também conhecido como Green) e adicione o bloco CIDR de Virginia (também conhecido como Blue) à tabela de rotas.

Figura 24: Tabela de rotas mostrando o bloco CIDR do cluster azul na tabela de rotas do cluster verde.

5.3 Atualizar o grupo de segurança

A última etapa da configuração da rede no cluster de origem e de destino é abrir um intervalo de portas nas quais os nós de trabalho do K8s se comunicarão entre si. Essas portas serão usadas para Comunicação XDCR Portanto, ou abrimos a porta que vai de 30000 a 32767 ou restringimos a uma única porta que será usada para a rede de sobreposição, conforme descrito na seção 6.0.

5.3.1 Configurações de regras de entrada

Para simplificar, permitiremos que o intervalo de portas seja aberto no NodeGroup usado como nós de trabalho do K8s. Para alterar as configurações do firewall, siga estas etapas:

Figura 25: Configure um grupo de segurança no cluster Virginia (também conhecido como Blue).

1. Clique no botão Grupos de segurança no painel esquerdo do seu Console da AWS para a região da Virgínia.
2. Em seguida, localize o grupo de segurança (SG) com -nodegroup-bluegroup como a cadeia de caracteres. Esse SG é usado como a configuração de firewall para todos os nós de trabalho em seu nodegroup do Kubernetes.
3. Clique em Regras de entrada que exibe um intervalo de portas abertas para o respectivo recurso.
4. Próximo clique Editar regras para adicionar a nova regra à lista.

Figura 26: Adicione uma regra de firewall para que o cluster de origem e o de destino possam se comunicar entre si.

1. Conforme descrito na imagem acima, adicione uma nova regra TCP para o intervalo de portas 30000-32767 e use o bloco CIDR 10.0.0.0/24 do cluster de destino, ou seja, o cluster de Ohio (também conhecido como Green). Isso conclui a configuração do tráfego de entrada.

5.3.2 Configurações de regras de saída

1. Agora vamos criar uma regra semelhante para a comunicação de saída também. Para fazer isso, clique no ícone Regras de saída conforme descrito abaixo.

Figura 27: Configurações de regras de saída para o grupo de segurança selecionado.

1. Clique no botão Editar regras para adicionar uma nova regra.

Figura 28: Rota de saída atualizada com regra adicional.

1. Assim como antes, adicionaremos um novo Regra TCP personalizada e permitir portas que variam de 30000-32767 para poder se comunicar com o bloco CIDR de destino 10.0.0.0/24.

Observação: Assim como adicionamos a regra de firewall no Nodegroup do cluster Blue, precisamos fazer o mesmo no Nodegroup do cluster Green.

Depois de concluir a configuração de rede da origem e do destino, os clusters devem ser capazes de se comunicar nos intervalos de portas que usamos e podemos ir para a próxima etapa de configuração real do XDCR para que os dados possam ser replicados da origem para o bucket de destino em toda a região.

6.0 Replicação de XDCR com rede de sobreposição

Dê uma olhada no diagrama abaixo, que pressupõe que dois nós em clusters separados do Kubernetes podem se comunicar entre si. O roteador descrito pode ser um switch, roteador, conexão VPN ou qualquer outra infraestrutura que permita a comunicação de camada 3.

Figura 29: XDCR para um cluster diferente do Kubernetes por meio de rede de sobreposição

No diagrama, o pod no Cluster 1 só é capaz de se conectar à porta do nó (31202) exposta no Cluster 2. Além disso, essa porta só é exposta ao nó no qual o pod está sendo executado. Para determinar a string de conexão correta no cluster de destino do XDCR, siga o procedimento:

• Listar os pods do Couchbase implantados no cluster de destino. Se quisermos configurar a replicação do XDCR no cluster Blue, execute este comando no diretório Verde agrupamento:

$ kubectl get pods -n emart

NAME                                            READY     STATUS    RESTARTS   AGE
green-0000                                      1/1       Running   0          7m39s
green-0001                                      1/1       Running   0          6m19s
green-0002                                      1/1       Running   0          5m8s

• Escolha um dos pods do Couchbase e obtenha o endereço IP do nó GKE subjacente:

$ kubectl get pod green-0000 -o yaml -n emart | grep hostIP

hostIP: 10.0.0.5

• Obtenha o número da porta que mapeia a porta de administração (8091).

$ kubectl get service green-0000-exposed-ports -n emart

NAME                       TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)                                                                                                                        AGE
green-0000-exposed-ports   NodePort   172.20.55.204   <none>        11210:32262/TCP,11207:31500/TCP,8093:32209/TCP,18093:31965/TCP,8091:30964/TCP,18091:30093/TCP,8092:31555/TCP,18092:30041/TCP   7m3s

Se você estivesse conectado ao Console da Web do Couchbase Server no cluster Blue e estabelecendo a conexão XDCR com o cluster Green, usaria a string de conexão 10.0.0.5:30964 com base no exemplo acima.

6.1. XDCR do cluster azul para o verde

Vamos configurar uma replicação unidirecional a partir do Azul para o Verde cluster. Você pode encontrar mais detalhes sobre o Documentação do XDCR.

Vamos primeiro nos conectar ao Console da Web do Couchbase do Azul cluster usando o método de encaminhamento de porta.

Observação: Já temos o encaminhamento de porta em execução para o Green cluster usando a porta 8092 e o cluster Blue usando uma porta 8091.

No cluster Azul https://localhost:8091:

• Adicionar referência de cluster do verde agrupamento.

Figura 30: Conexão XDCR do cluster azul para o verde.

• Referência de cluster remoto adicionada.

Figura 31: Replicação estabelecida.

• Adicionar replicação de bucket de amostra de viagem balde para padrão no cluster Green.

Figura 32: Configuração da replicação de bucket de origem para destino.

• Seu bucket agora está replicando a partir de Azul para Verde agrupamento.

Figura 33: Replicação ativa de buckets do cluster da Virgínia para o de Ohio.

7. Conclusão

Neste artigo, desvendamos os detalhes da rede para mostrar a você como é fácil configurar Emparelhamento de VPC entre regiões no contexto do Operador Autônomo do Couchbase. Usamos uma das plataformas de nuvem para conduzir a implantação dos clusters geodistribuídos do Couchbase, mas o que queremos destacar é que, depois que você entender os conceitos, aplicá-los em qualquer outra plataforma de nuvem será uma progressão simples.