As versões do Operador Autônomo anteriores à 1.2.0 tinham capacidade limitada de interagir com os clientes. A plataforma de dados do Couchbase só podia ser usada por SDKs localizados no mesmo cluster do Kubernetes. A replicação entre datacenters (XDCR) só podia ser usada no mesmo cluster do Kubernetes ou em um túnel seguro. Uma rede privada virtual (VPN) é um exemplo desse tipo de túnel. Além disso, o acesso à interface do usuário (UI) teria que ser feito com o encaminhamento de porta do Kubernetes.
A versão 1.2.0 do Operador Autônomo apresenta novos recursos de rede para atender a esses limites. O objetivo final é ampliar nosso público com suporte para arquiteturas de rede mais diversas. Seu aplicativo pode ser executado como uma função sem servidor e, portanto, precisa se comunicar pela Internet com o servidor Couchbase. Esse tipo de caso de uso é exatamente o que estamos apoiando.
Arquitetura de rede do Kubernetes
As opções disponíveis para a rede do Kubernetes são diversas. A interface é tudo o que é fornecido pelo Kubernetes, o que significa que terceiros fornecem sua própria implementação. O resultado é que cada solução tem seus pontos fortes e fracos. As escolhas de rede que fazemos devem funcionar em todos os provedores, portanto, descreveremos os tipos de rede comuns antes de analisar as soluções.
Redes roteadas
As redes roteadas são as mais simples de descrever em termos de Kubernetes. Os hosts podem se comunicar uns com os outros porque são executados na mesma sub-rede e podem endereçar diretamente o endereço de hardware de destino. Isso é conhecido como camada 2 rede.
Os pods geralmente são executados em uma sub-rede separada dos hosts em que são executados. Essa sub-rede é subdividida ainda mais entre cada host.
Uma mensagem de um pod em um host não tem como saber como encontrar seu pod de destino em outro host porque ele não existe na mesma sub-rede. As mensagens de uma sub-rede podem ser movidas de uma sub-rede para outra por meio de um roteador. Normalmente, as mensagens de um host são enviadas a um roteador em uma sub-rede quando o endereço de destino não está em uma sub-rede conectada diretamente.
Roteamento
Os roteadores tratam as mensagens de duas maneiras. Para sub-redes conectadas diretamente, as mensagens podem ser enviadas apenas para a porta de rede correta e a rede de camada 2 cuida do resto. Para sub-redes não conectadas diretamente, as mensagens podem ser encaminhadas a outro roteador que tenha a sub-rede conectada diretamente. Isso é conhecido como camada 3 rede.
O roteador gerencia essas informações de roteamento em uma tabela de roteamento. Uma tabela de roteamento é simplesmente uma lista de mapeamentos de uma sub-rede para uma interface física ou outro roteador em uma rede diretamente conectada.
Uma mensagem para outro pod seria capturada pelo host em que o pod está sendo executado. O endereço de destino da mensagem seria desconhecido e, portanto, encaminhado ao roteador. O roteador sabe sobre o endereço de destino em sua tabela de roteamento, portanto, encaminha a mensagem para o host correto. Por fim, a mensagem é enviada para o pod de destino. As mensagens de fora do cluster do Kubernetes podem chegar ao pod de destino simplesmente sendo enviadas ao roteador.
As redes roteadas são muito simples. Elas também podem sofrer uma pequena penalidade de desempenho devido ao salto para o roteador e depois para o host de destino. Existem soluções mais inteligentes que usam iBGP e refletores de rota para remover esse salto extra. O isolamento de pods uns dos outros deve ser feito com regras de firewall.
Redes de sobreposição
As redes de sobreposição encapsulam mensagens de pod para pod em protocolos como GRE ou VXLAN. Cada host anuncia sua sub-rede de pod. Os hosts podem então assinar esses anúncios e saber para qual host devem enviar a mensagem diretamente para chegar ao pod de destino. Embora seja mais rápido do que enviar para um roteador, a sobrecarga de encapsulamento pode anular qualquer benefício.
O encapsulamento também permite que pods diferentes sejam associados a diferentes redes virtuais. Isso proporciona um modelo de segurança forte em que grupos de pods podem ser fisicamente segregados. No entanto, isso significa que você ainda precisa de roteadores para cruzar entre as redes de sobreposição. Esses roteadores precisarão de suas próprias regras de firewall.
O endereçamento de um pod de fora do cluster é muito difícil. Com as redes roteadas, podemos simplesmente encaminhar para o roteador e ele cuidará do resto. Com as sobreposições, não temos esse mecanismo simples para fazer um túnel para a sobreposição.
Portas de nó
O único mecanismo comum para a comunicação externa com pods em ambos os tipos de rede são as portas de nó do Kubernetes. Para cada pod que o Operador Autônomo cria, também criamos um serviço de porta de nó para ele. Cada porta que definirmos para o serviço terá uma porta aleatória atribuída ao host subjacente.
As portas de nó devem ser aleatórias, pois dois pods podem estar expondo o mesmo número de porta. Isso levaria a um conflito se essa porta fosse usada como a porta do nó por ambos os pods. Podemos endereçar uma porta em um pod específico endereçando o host subjacente e a porta do host. O host tratará a mensagem redirecionamento para o destino correto.
As portas de nó nos fornecem um mecanismo genérico para endereçar um pod, independentemente de estarmos usando uma rede de sobreposição. Como estamos endereçando o nó subjacente, a conexão com ele de fora do Kubernetes é simplesmente um caso de roteamento de pacotes para a rede roteada em que os nós do Kubernetes residem.
Estabelecimento de XDCR
As portas de nó formam a base do estabelecimento de uma conexão XDCR entre dois clusters do Couchbase em dois clusters diferentes do Kubernetes. Quando as portas de nó são alocadas, o Operador Autônomo informa o servidor Couchbase. Os clientes que se conectam externamente se conectam à porta do nó e o servidor Couchbase responde com um mapa de endereços IP de nó e portas de nó por serviço. O cliente XDCR usa esses mapas para acessar vBuckets individuais ao fazer streaming de documentos.
A única coisa que o Operador Autônomo não pode fazer é fornecer conectividade de camada 3 entre as duas redes de host do Kubernetes. Criar um peering (VPN) entre as duas redes, adicionar rotas e regras de firewall é tudo o que é necessário para a maioria dos provedores de nuvem.
Novos aprimoramentos do operador autônomo
Temos uma base sólida, trabalhando dentro dos limites do modelo de rede do Kubernetes. Ela é segura, com uma VPN, mas há melhorias que podem ser feitas.
Acesso de clientes externos
A utilização de um túnel VPN para acessar uma rede de host Kubernetes remota pode ser impossível ou indesejável. Isso é especialmente verdadeiro para serviços gerenciados, nos quais você pode não ter controle sobre a rede.
Para resolver isso, precisamos colocar os pods na Internet. As rotas do Openshift e os ingresses genéricos só funcionam para o tráfego HTTP e são difíceis de configurar. Em vez disso, optamos por criar serviços de balanceador de carga por pod do servidor Couchbase. Qualquer conexão TCP pode ser suportada e, além disso, como o endereço IP do balanceador de carga é exclusivo por pod, podemos usar os números de porta padrão. Todos os principais provedores de nuvem oferecem serviços de balanceador de carga.
As conexões XDCR baseadas em porta de nó existentes ainda são suportadas e são o padrão.
Acesso externo à interface do usuário
A interface do usuário, assim como os pods individuais, agora pode ser abordada publicamente com um serviço de balanceador de carga. Isso torna o gerenciamento das implantações da plataforma de dados do Couchbase muito mais simples.
Criptografia de ponta a ponta
Colocar qualquer coisa na Internet pública não é isento de riscos. Isso é especialmente verdade com um banco de dados, por isso exigimos o uso de TLS. Nenhuma porta de texto simples pode ser exposta. Isso mantém suas credenciais de usuário e dados protegidos contra espiões.
Quando um certificado de servidor é apresentado a um cliente conectado, ele verifica se o endereço ao qual se conectou é válido para esse certificado. Isso é feito com nomes alternativos de assuntos. Oferecemos suporte apenas a nomes alternativos curinga baseados em DNS, e não em IP. Além disso, não podemos usar o endereçamento baseado em IP dos serviços de balanceamento de carga, pois o endereço não é estável durante a recuperação.
Um nome válido para um cluster poderia ser *.my-cluster.example.com. Esse é um curinga, válido para server0.my-cluster.example.com e server1.my-cluster.example.com. O certificado será válido para todos os nós que o Operador Autônomo criar no ciclo de vida do cluster.
Os registros de recursos DNS precisam ser criados mapeando os nomes DNS para os endereços IP do balanceador de carga para que fiquem visíveis para o cliente. Os nomes de DNS necessários são anotados nos serviços de balanceador de carga pelo operador autônomo. Eles são sincronizados com um provedor de DNS em nuvem por um terceiro controlador.
Exemplo
O diagrama mostra como todos esses recursos estão interligados.
- Um cliente, seja ele um SDK ou XCDR, inicializa uma conexão usando o endereço DNS https://cb0.cb0.us-east-1.example.com:18091. Isso é resolvido para o endereço IP do balanceador de carga em 185.64.232.18. Esse endereço DNS é criado a partir da especificação do serviço do balanceador de carga e de seu endereço IP público.
- Em seguida, o cliente abre uma conexão TCP com o cluster do Couchbase. Primeiro, ela atravessa a Internet até o roteador de borda do cliente.
- O pacote é então encaminhado para o balanceador de carga em 185.64.232.18.
- Em seguida, o balanceador de carga envia o pacote para a porta do nó correspondente à porta 18091 no pod de destino. Em seguida, o nó faz o SNAT do pacote para a porta 18091 no próprio pod.
- Depois que a conexão TCP é estabelecida, o cliente inicia um handshake TLS com o servidor. O servidor retorna seu certificado para o cliente. O cliente valida o certificado como válido para o destinatário pretendido. O endereço cb0.cb0.us-east-1.example.com corresponde ao nome alternativo do assunto curinga *.cb0.us-east-1.example.com. O bootstrap do cliente continua como de costume.
Embora não esteja incluído no diagrama, vale a pena mencionar que o servidor Couchbase se refere ao pod de destino como cb0.cb0.default.svcseu nome DNS interno. Os clientes não conseguem resolver esse nome quando recebem um mapeamento de membros do cluster para endereços de membros. O Operator preenche endereços de membros alternativos que podem ser resolvidos.
Os clientes devem estar cientes dos endereços alternativos. Os SDKs compatíveis estão documentados na documentação do Operador. O XDCR é compatível com as versões 5.5.3+ e 6.0.1+ do servidor Couchbase.
Conclusão
A capacidade de endereçar publicamente uma instância do servidor Couchbase é uma ferramenta poderosa. Ela simplifica a configuração da rede. A configuração de um túnel VPN entre provedores de nuvem pode ser difícil ou impossível, mas isso evita totalmente esse problema. Simplifica o processo de acesso ao console da interface do usuário e também permite que os clientes, inclusive o XDCR, se conectem de qualquer lugar do mundo.
Isso dá origem a novas e empolgantes possibilidades de integrar suas implementações do Couchbase baseadas no Kubernetes com qualquer serviço externo. Esses exemplos podem incluir plataformas de função como serviço em que você não tem controle sobre a arquitetura de rede subjacente.
- Experimente: https://www.couchbase.com/downloads
- Fóruns de suporte: https://www.couchbase.com/forums/c/couchbase-server/Kubernetes
- Documentação: https://docs.couchbase.com/operator/1.2/whats-new.html
Leia mais
Operador autônomo 1.2.0 Deep Dive: https://www.couchbase.com/blog/deep-dive-couchbase-autonomous-operator-1-2-0
Circuito Vpn