{"id":6804,"date":"2019-05-07T10:54:05","date_gmt":"2019-05-07T17:54:05","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=6804"},"modified":"2025-06-13T21:33:45","modified_gmt":"2025-06-14T04:33:45","slug":"autonomous-operator-1-2-0-networking","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/pt\/autonomous-operator-1-2-0-networking\/","title":{"rendered":"Preenchendo lacunas: Operador Aut\u00f4nomo 1.2 Aprimoramentos de rede"},"content":{"rendered":"

As vers\u00f5es do Operador Aut\u00f4nomo anteriores \u00e0 1.2.0 tinham capacidade limitada de interagir com os clientes. A plataforma de dados do Couchbase s\u00f3 podia ser usada por SDKs localizados no mesmo cluster do Kubernetes. A replica\u00e7\u00e3o entre datacenters (XDCR) s\u00f3 podia ser usada no mesmo cluster do Kubernetes ou em um t\u00fanel seguro. Uma rede privada virtual (VPN) \u00e9 um exemplo desse tipo de t\u00fanel. Al\u00e9m disso, o acesso \u00e0 interface do usu\u00e1rio (UI) teria que ser feito com o encaminhamento de porta do Kubernetes.<\/p>\n

A vers\u00e3o 1.2.0 do Operador Aut\u00f4nomo apresenta novos recursos de rede para atender a esses limites. O objetivo final \u00e9 ampliar nosso p\u00fablico com suporte para arquiteturas de rede mais diversas. Seu aplicativo pode ser executado como uma fun\u00e7\u00e3o sem servidor e, portanto, precisa se comunicar pela Internet com o servidor Couchbase. Esse tipo de caso de uso \u00e9 exatamente o que estamos apoiando.<\/p>\n

Arquitetura de rede do Kubernetes<\/h3>\n

As op\u00e7\u00f5es dispon\u00edveis para a rede do Kubernetes s\u00e3o diversas. A interface \u00e9 tudo o que \u00e9 fornecido pelo Kubernetes, o que significa que terceiros fornecem sua pr\u00f3pria implementa\u00e7\u00e3o. O resultado \u00e9 que cada solu\u00e7\u00e3o 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\u00e7\u00f5es.<\/p>\n

Redes roteadas<\/h3>\n

As redes roteadas s\u00e3o as mais simples de descrever em termos de Kubernetes. Os hosts podem se comunicar uns com os outros porque s\u00e3o executados na mesma sub-rede e podem endere\u00e7ar diretamente o endere\u00e7o de hardware de destino. Isso \u00e9 conhecido como camada 2<\/a> rede.<\/p>\n

\"Layer<\/p>\n

Os pods geralmente s\u00e3o executados em uma sub-rede separada dos hosts em que s\u00e3o executados. Essa sub-rede \u00e9 subdividida ainda mais entre cada host.<\/p>\n

Uma mensagem de um pod em um host n\u00e3o tem como saber como encontrar seu pod de destino em outro host porque ele n\u00e3o 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\u00e3o enviadas a um roteador em uma sub-rede quando o endere\u00e7o de destino n\u00e3o est\u00e1 em uma sub-rede conectada diretamente.<\/p>\n

Roteamento<\/h3>\n

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\u00e3o conectadas diretamente, as mensagens podem ser encaminhadas a outro roteador que tenha a sub-rede conectada diretamente. Isso \u00e9 conhecido como camada 3<\/a> rede.<\/p>\n

\"Layer<\/p>\n

O roteador gerencia essas informa\u00e7\u00f5es de roteamento em uma tabela de roteamento. Uma tabela de roteamento \u00e9 simplesmente uma lista de mapeamentos de uma sub-rede para uma interface f\u00edsica ou outro roteador em uma rede diretamente conectada.<\/p>\n

Uma mensagem para outro pod seria capturada pelo host em que o pod est\u00e1 sendo executado. O endere\u00e7o de destino da mensagem seria desconhecido e, portanto, encaminhado ao roteador. O roteador sabe sobre o endere\u00e7o de destino em sua tabela de roteamento, portanto, encaminha a mensagem para o host correto. Por fim, a mensagem \u00e9 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.<\/p>\n

As redes roteadas s\u00e3o muito simples. Elas tamb\u00e9m podem sofrer uma pequena penalidade de desempenho devido ao salto para o roteador e depois para o host de destino. Existem solu\u00e7\u00f5es mais inteligentes que usam iBGP<\/a> e refletores de rota<\/a> para remover esse salto extra. O isolamento de pods uns dos outros deve ser feito com regras de firewall.<\/p>\n

Redes de sobreposi\u00e7\u00e3o<\/h3>\n

As redes de sobreposi\u00e7\u00e3o encapsulam mensagens de pod para pod em protocolos como GRE<\/a> ou VXLAN<\/a>. Cada host anuncia sua sub-rede de pod. Os hosts podem ent\u00e3o assinar esses an\u00fancios e saber para qual host devem enviar a mensagem diretamente para chegar ao pod de destino. Embora seja mais r\u00e1pido do que enviar para um roteador, a sobrecarga de encapsulamento pode anular qualquer benef\u00edcio.<\/p>\n

O encapsulamento tamb\u00e9m permite que pods diferentes sejam associados a diferentes redes virtuais<\/a>. Isso proporciona um modelo de seguran\u00e7a forte em que grupos de pods podem ser fisicamente segregados. No entanto, isso significa que voc\u00ea ainda precisa de roteadores para cruzar entre as redes de sobreposi\u00e7\u00e3o. Esses roteadores precisar\u00e3o de suas pr\u00f3prias regras de firewall.<\/p>\n

O endere\u00e7amento de um pod de fora do cluster \u00e9 muito dif\u00edcil. Com as redes roteadas, podemos simplesmente encaminhar para o roteador e ele cuidar\u00e1 do resto. Com as sobreposi\u00e7\u00f5es, n\u00e3o temos esse mecanismo simples para fazer um t\u00fanel para a sobreposi\u00e7\u00e3o.<\/p>\n

Portas de n\u00f3<\/h3>\n

O \u00fanico mecanismo comum para a comunica\u00e7\u00e3o externa com pods em ambos os tipos de rede s\u00e3o as portas de n\u00f3 do Kubernetes. Para cada pod que o Operador Aut\u00f4nomo cria, tamb\u00e9m criamos um servi\u00e7o de porta de n\u00f3 para ele. Cada porta que definirmos para o servi\u00e7o ter\u00e1 uma porta aleat\u00f3ria atribu\u00edda ao host subjacente.<\/p>\n

As portas de n\u00f3 devem ser aleat\u00f3rias, pois dois pods podem estar expondo o mesmo n\u00famero de porta. Isso levaria a um conflito se essa porta fosse usada como a porta do n\u00f3 por ambos os pods. Podemos endere\u00e7ar uma porta em um pod espec\u00edfico endere\u00e7ando o host subjacente e a porta do host. O host tratar\u00e1 a mensagem redirecionamento<\/a> para o destino correto.<\/p>\n

As portas de n\u00f3 nos fornecem um mecanismo gen\u00e9rico para endere\u00e7ar um pod, independentemente de estarmos usando uma rede de sobreposi\u00e7\u00e3o. Como estamos endere\u00e7ando o n\u00f3 subjacente, a conex\u00e3o com ele de fora do Kubernetes \u00e9 simplesmente um caso de roteamento de pacotes para a rede roteada em que os n\u00f3s do Kubernetes residem.<\/p>\n

Estabelecimento de XDCR<\/h3>\n

As portas de n\u00f3 formam a base do estabelecimento de uma conex\u00e3o XDCR entre dois clusters do Couchbase em dois clusters diferentes do Kubernetes. Quando as portas de n\u00f3 s\u00e3o alocadas, o Operador Aut\u00f4nomo informa o servidor Couchbase. Os clientes que se conectam externamente se conectam \u00e0 porta do n\u00f3 e o servidor Couchbase responde com um mapa de endere\u00e7os IP de n\u00f3 e portas de n\u00f3 por servi\u00e7o. O cliente XDCR usa esses mapas para acessar vBuckets individuais ao fazer streaming de documentos.<\/p>\n

A \u00fanica coisa que o Operador Aut\u00f4nomo n\u00e3o pode fazer \u00e9 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 \u00e9 tudo o que \u00e9 necess\u00e1rio para a maioria dos provedores de nuvem.<\/p>\n

\"IP<\/p>\n

Novos aprimoramentos do operador aut\u00f4nomo<\/h3>\n

Temos uma base s\u00f3lida, trabalhando dentro dos limites do modelo de rede do Kubernetes. Ela \u00e9 segura, com uma VPN, mas h\u00e1 melhorias que podem ser feitas.<\/p>\n

Acesso de clientes externos<\/h3>\n

A utiliza\u00e7\u00e3o de um t\u00fanel VPN para acessar uma rede de host Kubernetes remota pode ser imposs\u00edvel ou indesej\u00e1vel. Isso \u00e9 especialmente verdadeiro para servi\u00e7os gerenciados, nos quais voc\u00ea pode n\u00e3o ter controle sobre a rede.<\/p>\n

Para resolver isso, precisamos colocar os pods na Internet. As rotas do Openshift e os ingresses gen\u00e9ricos s\u00f3 funcionam para o tr\u00e1fego HTTP e s\u00e3o dif\u00edceis de configurar. Em vez disso, optamos por criar servi\u00e7os de balanceador de carga por pod do servidor Couchbase. Qualquer conex\u00e3o TCP pode ser suportada e, al\u00e9m disso, como o endere\u00e7o IP do balanceador de carga \u00e9 exclusivo por pod, podemos usar os n\u00fameros de porta padr\u00e3o. Todos os principais provedores de nuvem oferecem servi\u00e7os de balanceador de carga.<\/p>\n

As conex\u00f5es XDCR baseadas em porta de n\u00f3 existentes ainda s\u00e3o suportadas e s\u00e3o o padr\u00e3o.<\/p>\n

Acesso externo \u00e0 interface do usu\u00e1rio<\/h3>\n

A interface do usu\u00e1rio, assim como os pods individuais, agora pode ser abordada publicamente com um servi\u00e7o de balanceador de carga. Isso torna o gerenciamento das implanta\u00e7\u00f5es da plataforma de dados do Couchbase muito mais simples.<\/p>\n

Criptografia de ponta a ponta<\/h3>\n

Colocar qualquer coisa na Internet p\u00fablica n\u00e3o \u00e9 isento de riscos. Isso \u00e9 especialmente verdade com um banco de dados, por isso exigimos o uso de TLS. Nenhuma porta de texto simples pode ser exposta. Isso mant\u00e9m suas credenciais de usu\u00e1rio e dados protegidos contra espi\u00f5es.<\/p>\n

Quando um certificado de servidor \u00e9 apresentado a um cliente conectado, ele verifica se o endere\u00e7o ao qual se conectou \u00e9 v\u00e1lido para esse certificado. Isso \u00e9 feito com nomes alternativos de assuntos<\/a>. Oferecemos suporte apenas a nomes alternativos curinga baseados em DNS, e n\u00e3o em IP. Al\u00e9m disso, n\u00e3o podemos usar o endere\u00e7amento baseado em IP dos servi\u00e7os de balanceamento de carga, pois o endere\u00e7o n\u00e3o \u00e9 est\u00e1vel durante a recupera\u00e7\u00e3o.<\/p>\n

Um nome v\u00e1lido para um cluster poderia ser *.my-cluster.example.com<\/i>. Esse \u00e9 um curinga, v\u00e1lido para server0.my-cluster.example.com<\/i> e server1.my-cluster.example.com<\/i>. O certificado ser\u00e1 v\u00e1lido para todos os n\u00f3s que o Operador Aut\u00f4nomo criar no ciclo de vida do cluster.<\/p>\n

Os registros de recursos DNS precisam ser criados mapeando os nomes DNS para os endere\u00e7os IP do balanceador de carga para que fiquem vis\u00edveis para o cliente. Os nomes de DNS necess\u00e1rios s\u00e3o anotados nos servi\u00e7os de balanceador de carga pelo operador aut\u00f4nomo. Eles s\u00e3o sincronizados com um provedor de DNS em nuvem por um terceiro controlador<\/a>.<\/p>\n

Exemplo<\/h3>\n

O diagrama mostra como todos esses recursos est\u00e3o interligados.<\/p>\n

    \n
  1. Um cliente, seja ele um SDK ou XCDR, inicializa uma conex\u00e3o usando o endere\u00e7o DNS https:\/\/cb0.cb0.us-east-1.example.com:18091<\/em>. Isso \u00e9 resolvido para o endere\u00e7o IP do balanceador de carga em 185.64.232.18<\/em>. Esse endere\u00e7o DNS \u00e9 criado a partir da especifica\u00e7\u00e3o do servi\u00e7o do balanceador de carga e de seu endere\u00e7o IP p\u00fablico.<\/li>\n
  2. Em seguida, o cliente abre uma conex\u00e3o TCP com o cluster do Couchbase. Primeiro, ela atravessa a Internet at\u00e9 o roteador de borda do cliente.<\/li>\n
  3. O pacote \u00e9 ent\u00e3o encaminhado para o balanceador de carga em 185.64.232.18<\/em>.<\/li>\n
  4. Em seguida, o balanceador de carga envia o pacote para a porta do n\u00f3 correspondente \u00e0 porta 18091<\/em> no pod de destino. Em seguida, o n\u00f3 faz o SNAT do pacote para a porta 18091<\/em> no pr\u00f3prio pod.<\/li>\n
  5. Depois que a conex\u00e3o TCP \u00e9 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\u00e1lido para o destinat\u00e1rio pretendido. O endere\u00e7o cb0.cb0.us-east-1.example.com<\/em> corresponde ao nome alternativo do assunto curinga *.cb0.us-east-1.example.com<\/em>. O bootstrap do cliente continua como de costume.<\/li>\n<\/ol>\n

    \"Public<\/p>\n

    Embora n\u00e3o esteja inclu\u00eddo no diagrama, vale a pena mencionar que o servidor Couchbase se refere ao pod de destino como cb0.cb0.default.svc<\/em>seu nome DNS interno. Os clientes n\u00e3o conseguem resolver esse nome quando recebem um mapeamento de membros do cluster para endere\u00e7os de membros. O Operator preenche endere\u00e7os de membros alternativos que podem ser resolvidos.<\/p>\n

    Os clientes devem estar cientes dos endere\u00e7os alternativos. Os SDKs compat\u00edveis est\u00e3o documentados na documenta\u00e7\u00e3o do Operador. O XDCR \u00e9 compat\u00edvel com as vers\u00f5es 5.5.3+ e 6.0.1+ do servidor Couchbase.<\/p>\n

    Conclus\u00e3o<\/h3>\n

    A capacidade de endere\u00e7ar publicamente uma inst\u00e2ncia do servidor Couchbase \u00e9 uma ferramenta poderosa. Ela simplifica a configura\u00e7\u00e3o da rede. A configura\u00e7\u00e3o de um t\u00fanel VPN entre provedores de nuvem pode ser dif\u00edcil ou imposs\u00edvel, mas isso evita totalmente esse problema. Simplifica o processo de acesso ao console da interface do usu\u00e1rio e tamb\u00e9m permite que os clientes, inclusive o XDCR, se conectem de qualquer lugar do mundo.<\/p>\n

    Isso d\u00e1 origem a novas e empolgantes possibilidades de integrar suas implementa\u00e7\u00f5es do Couchbase baseadas no Kubernetes com qualquer servi\u00e7o externo. Esses exemplos podem incluir plataformas de fun\u00e7\u00e3o como servi\u00e7o em que voc\u00ea n\u00e3o tem controle sobre a arquitetura de rede subjacente.<\/p>\n