Brant Burnett é um Especialista em Couchbase, arquiteto de sistemas e desenvolvedor .NET com experiência em desenvolvimento full-stack para desktop e web. Nos últimos 12 anos, ele tem trabalhado com a CenterEdge Software, uma empresa de software de entretenimento familiar com sede em Roxboro, NC. Brant tem experiência no desenvolvimento de aplicativos para todos os segmentos de seu pacote de software. Nos últimos quatro anos, ele trabalhou na transição da infraestrutura de nuvem da empresa de uma plataforma Microsoft SQL para uma plataforma de dados NoSQL Couchbase pura. Com seu trabalho na CenterEdge, Brant pôde se concentrar na criação de soluções de software sérias para empresas divertidas.
O Couchbase é um excelente armazenamento de dados para aplicativos de nuvem dimensionáveis, incluindo aplicativos criados usando um arquitetura de microsserviços. Kubernetes é uma plataforma incrivelmente poderosa para executar microsserviços em contêineres, facilitando o gerenciamento de DevOps e reduzindo o atrito do desenvolvedor. Mas como podemos usá-los juntos, reduzindo o atrito e a sobrecarga de gerenciamento em todo o sistema?
Uma opção é executar o Couchbase no Kubernetes como um StatefulSet. No entanto, os StatefulSets ainda estão na versão beta. Além disso, um cluster de produção do Couchbase cria uma carga considerável, portanto, é altamente recomendável executar em nós dedicados. Isso poderia ser feito no Kubernetes usando taints, mas em Software CenterEdge decidimos manter a simplicidade e executar o cluster do Couchbase em instâncias autônomas do EC2.
Esta postagem tem como objetivo ser um tutorial sobre a configuração do Kubernetes no Amazon Web Services (AWS) para se conectar perfeitamente a um cluster do Couchbase em execução no EC2 no AWS. Além disso, a abordagem é flexível o suficiente para permitir a troca de clusters ou a execução de clusters menores no Kubernetes para ambientes de desenvolvimento ou controle de qualidade.
TL;DR
Essa abordagem para configurar o acesso ao Couchbase no Kubernetes tem várias vantagens importantes:
- Facilidade para configurar seus microsserviços com um URL único e simples
- Faça alterações em sua infraestrutura sem precisar reconfigurar cada microsserviço
- Suporte para trocar o cluster de forma transparente durante as atualizações do Couchbase
- Aponte facilmente o mesmo URL em um cluster Kubernetes de desenvolvimento ou QA para um cluster Couchbase diferente
Passos:
- Certifique-se de que os clusters do Couchbase e do Kubernetes possam se comunicar pela rede
- Criar um Balanceador de carga de aplicativos (ALB) para a inicialização usando um único URL
- Crie um serviço Kubernetes do tipo ExternalName para resolver o cluster de seus microsserviços
Pré-requisitos
Esta postagem pressupõe que os seguintes pré-requisitos tenham sido cumpridos:
- Você tem um cluster do Kubernetes em execução no AWS. Implantamos nosso cluster usando o kops utilitário. Há um bom guia aqui.
- Você tem um cluster do Couchbase em execução no AWS em instâncias do EC2. Nós usamos esse script de dados do usuário para configurar as instâncias na inicialização, usando tipos de instância i3 com armazenamento de instância SSD NVMe. Isenção de responsabilidade: este script userdata não foi totalmente aprovado para uso em produção.
- Esses dois clusters estão na mesma região da AWS.
- A VPC em que o Couchbase reside deve ter sub-redes em pelo menos duas zonas de disponibilidade (mesmo que o Couchbase esteja usando apenas uma).
Configuração de emparelhamento de VPC
Emparelhamento de VPC permitirá que as instâncias em um VPC para conversar com instâncias em outro VPC na mesma região do AWS de forma transparente, como se estivessem na mesma LAN.
Observação: Esta etapa só é necessária se a VPC do Couchbase for separada da VPC do Kubernetes. Se estiver usando o mesmo VPC para ambos, você pode pular esta etapa.
Observação: As VPCs devem estar usando sub-redes privadas diferentes para evitar conflitos de endereços IP.
- Aberto Conexões de peering dentro da VPC no console do AWS
- Criar conexão de peering
- Para o solicitante, selecione sua VPC do Kubernetes
- Para o Aceitador, selecione sua VPC do Couchbase
- Quando a conexão estiver no estado "Pending-acceptance", clique com o botão direito do mouse e selecione Accept Request (Aceitar solicitação)
Agora que a conexão de peering foi criada, precisamos configurar as VPCs para rotear o tráfego entre elas. Isso deve ser feito atualizando a variável Tabelas de rotas para ambas as VPCs para rotear o tráfego para o outro para as sub-redes corretas.
Para este exemplo, assumiremos que o Kubernetes está sendo executado em 10.100.0.0/16 e que o Couchbase está sendo executado em 10.200.0.0/16.
- Para cada tabela de rotas no Kubernetes VPC:
- Vá para a guia Routes (Rotas) e clique em Edit (Editar)
- Clique em Add Another Route (Adicionar outra rota)
- Digite a sub-rede do Couchbase (10.200.0.0/16)
- Selecione a conexão de emparelhamento como o destino (começa com pcx-)
- Clique em Salvar
- Agora repita na direção oposta para cada Route Table na VPC do Couchbase:
- Vá para a guia Routes (Rotas) e clique em Edit (Editar)
- Clique em Add Another Route (Adicionar outra rota)
- Insira a sub-rede do Kubernetes (10.100.0.0/16)
- Selecione a conexão de emparelhamento como o destino (começa com pcx-)
- Clique em Salvar
- Além disso, verifique se o grupo de segurança do EC2 para suas instâncias do Couchbase está permitindo as portas corretas da sub-rede do Kubernetes. As portas necessárias são as portas Node-to-client listadas em este documento.
Criação de um Application Load Balancer para bootstrapping
Os SDKs do cliente Couchbase são capazes de fazer o bootstrapping da conexão com o servidor por meio de vários protocolos diferentes. Para facilitar o uso do cluster a partir do Kubernetes, vamos nos concentrar no bootstrapping por meio do protocolo HTTP na porta 8091. Se você quiser usar o TLS para proteger o processo de bootstrapping, isso pode ser feito usando a porta 18091.
Para dar suporte a esse tipo de bootstrap, criaremos um Application Load Balancer (ALB) no AWS. Isso fornecerá um único endpoint que pode ser reutilizado independentemente de qualquer alteração no cluster do Couchbase. Ele também pode ajudar na troca de um cluster para outro durante as atualizações do cluster.
- No EC2, vá para Load Balancers e clique em Create Load Balancer.
- Selecione Application Load Balancer e clique em Continue.
- Para a "Etapa 1: Configurar o balanceador de carga":
- Digite um nome para seu balanceador de carga, ou seja, "couchbase-primary".
- O esquema deve ser "interno". Observação: A seleção interna é muito importante para a segurança.
- Altere a porta de 80 para 8091.
- Selecione a VPC e as sub-redes em que o Couchbase está sendo executado. Se o Couchbase estiver apenas em uma única zona de disponibilidade, selecione uma AZ adicional para atender ao requisito do ALB.
- Clique em "Next: Configure Security Settings".
- Não há configurações na Etapa 2. Clique em "Next: Configure Security Groups" (Configurar grupos de segurança).
- Crie um novo grupo de segurança para o ALB, com a porta TCP 8091 aberta para o tráfego de entrada, e clique em "Next" (Avançar): Configure Routing" (Configurar roteamento).
- Talvez você precise editar o grupo de segurança do EC2 do Couchbase para abrir a porta 8091 para o tráfego do novo grupo de segurança do EC2 criado para o ALB.
- Crie um novo Target Group com esses valores:
- Nome: "couchbase-primary"
- Protocolo: "HTTP"
- Porta: "8091"
- Protocolo de verificação de integridade: "HTTP"
- Caminho do exame de saúde: "/ui/index.html"
- Clique em "Next: Registrar alvos"
- Para "Etapa 5: registrar alvos":
- Selecione todas as instâncias do Couchbase no cluster.
- Clique em "Add To Registered" para adicioná-los à lista na parte superior.
- Clique em "Next: Review".
- Clique em Create.
- Depois que o ALB for criado, poderemos obter seu "Nome DNS", que usaremos posteriormente.
Mas e quanto ao custo e ao desempenho dos ALBs?
O fato é que o custo dessa configuração é insignificante em termos de despesa e desempenho. O balanceador de carga é usado somente para comunicar a configuração do cluster ao cliente. Essa configuração inclui informações sobre todos os nós do cluster e como se conectar a eles.
Após a conclusão do bootstrapping, o cliente é conectado diretamente aos nós do cluster. Todas as operações de chave/valor e de consulta passarão diretamente para os nós, ignorando o balanceador de carga. Isso significa que não há custo financeiro nem de desempenho para essas operações.
Tornando a inicialização a partir do Kubernetes ainda mais fácil
Neste ponto, agora podemos inicializar nossos microsserviços usando um único URL de servidor na configuração. Isso é muito mais fácil do que listar vários servidores em nossa configuração, cada um dos quais pode mudar com o tempo à medida que o cluster sofre mutações.
Mas o URL que precisamos usar ainda é complicado, algo como: internal-couchbase-123456789.us-east-1.elb.amazonaws.com. Existe uma maneira de simplificar isso ainda mais? A resposta é sim!
O Kubernetes também pode ajudar na descoberta de serviços usando o DNS. Nesse caso, adicionaremos um Serviço do tipo ExternalName. Isso cria efetivamente um registro CNAME que encaminha o tráfego para um nome DNS externo. Esse registro só existe para Pods dentro do cluster do Kubernetes, portanto, não afetará nada fora do nosso cluster.
- Crie um arquivo chamado "couchbase-primary.yaml" com o seguinte conteúdo:kind: Service
apiVersion: v1
metadados:
# esse será o nome DNS para acessar o cluster
nome: couchbase-primary
espec:
tipo: ExternalName
# substitua o nome DNS do ALB abaixo
externalName: internal-couchbase-123456789.us-east-1.elb.amazonaws.com - Crie o serviço a partir do arquivo yaml:kubectl apply -f couchbase-primary.yaml
Tudo pronto! Agora, podemos inicializar qualquer microsserviço em execução em nosso cluster com um único e simples URL:
http://couchbase-primary:8091/. Se precisarmos acessá-lo a partir de um pod em um namespace diferente, basta acrescentar o namespace, por exemplo http://couchbase-primary.default:8091/. Também é possível registrar quantos clusters forem necessários usando nomes de domínio diferentes.