A camada de rede virtual no appliance isolado do Google Distributed Cloud (GDC) controla a conectividade, os firewalls, a descoberta de serviços, o balanceamento de carga e a capacidade de observação entre máquinas virtuais e pods em execução em uma organização do GDC.
Modelo de rede do GDC
O GDC consiste em um nível de locação: projetos.
Rede de projetos
Você implanta todas as máquinas virtuais (VMs) e cargas de trabalho em contêineres em um projeto. Os projetos fornecem um limite de segmentação de rede na organização.
As cargas de trabalho em um projeto podem se comunicar diretamente entre si. No entanto, a política de rede padrão impede a comunicação entre cargas de trabalho em projetos diferentes. Se a política de rede do projeto permitir, as cargas de trabalho na organização poderão se comunicar na camada de rede L3 usando os respectivos endereços IP. É necessário ativar explicitamente as restrições de entrada e saída para e da organização em cada carga de trabalho que exige tráfego de entrada ou saída.
Configurar balanceadores de carga
Os balanceadores de carga distribuem o tráfego entre as cargas de trabalho de back-end do aplicativo, garantindo estabilidade e disponibilidade. Crie balanceadores de carga externos e internos para cargas de trabalho de pods e VMs. O GDC oferece três métodos para configurar balanceadores de carga. Para mais informações, consulte Gerenciar balanceadores de carga.
Restrições de entrada
O mecanismo usado para expor cargas de trabalho fora da organização varia dependendo de elas serem baseadas em VMs ou contêineres.
Você expõe cargas de trabalho baseadas em VM fora da organização usando a capacidade de acesso externo da VM. Você ativa esse recurso para cada VM. Cada VM recebe um endereço IP do intervalo externo da organização.
Por outro lado, você expõe cargas de trabalho em contêineres fora da organização usando o recurso de balanceador de carga externo. Você pode criar um balanceador de carga externo, e o GDC atribui um endereço IP externo. Em seguida, o tráfego pode ser balanceado por carga em um conjunto de cargas de trabalho de pods de back-end.
Restrições de saída
Você precisa ativar explicitamente o tráfego de saída para cada projeto e carga de trabalho se quiser se comunicar fora da organização. Ao ativar o tráfego de saída, o IP das cargas de trabalho muda para um IP externo usando a conversão de endereços de rede (NAT) ao se conectar fora da organização. Para mais informações sobre como permitir o tráfego de saída, consulte Gerenciar o tráfego de saída de uma organização.
Modelo de aplicação da política de rede
A postura de segurança para cargas de trabalho em uma organização é a união das políticas de rede padrão e criadas pelo usuário.
A aplicação de políticas é baseada em fluxos de tráfego das camadas 3 e 4. Um fluxo descreve uma conexão de 5 tuplas da seguinte maneira:
- Endereço IP de origem
- Endereço IP de destino
- Porta de origem
- Porta de destino
- Protocolo, como
TCPouUDP
As políticas de rede aplicam o tráfego de saída no nó que hospeda a carga de trabalho de origem e o tráfego de entrada quando o tráfego chega ao nó que hospeda a carga de trabalho de destino. Portanto, para estabelecer uma conexão, você precisa permitir que a política saia da origem para o destino e chegue ao destino da origem.
O tráfego de resposta, como o segmento SYN-ACK (sincronizar-reconhecer) que responde a um segmento SYN, não está sujeito à aplicação. Portanto, o tráfego de resposta é sempre permitido se o tráfego inicial for permitido. Por isso, você só vai observar tempos limite de conexão devido à aplicação de políticas do cliente que inicia a conexão. O tráfego negado é descartado durante a transferência de dados de saída do nó de origem ou a transferência de dados de entrada no nó de destino. A carga de trabalho receptora nunca observa a conexão.
A imposição é baseada em regras de política de permissão que são cumulativas. A aplicação resultante para uma carga de trabalho é uma "correspondência de qualquer tipo" para o fluxo de tráfego em relação à união de todas as políticas aplicadas a essa carga de trabalho. Quando há várias políticas, as regras aplicadas a cada carga de trabalho são combinadas de forma aditiva, permitindo o tráfego se ele corresponder a pelo menos uma das regras. Você não tem regras de negação, apenas de permissão.
Quando uma política de rede nega um fluxo, você não recebe um pacote de resposta e observa um tempo limite de conexão. Por isso, conexões recusadas ou redefinidas no nível do protocolo ou erros HTTP não são resultado direto da imposição de rede.
Para mais informações sobre políticas de rede do Kubernetes, consulte https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-two-sorts-of-pod-isolation.