A rede de ambiente do GKE oferece um modelo de implantação simplificado e sem sidecar para uma malha de serviço com recursos de camada 4. Ao mover a funcionalidade de proxy para componentes no nível do nó integrados ao GKE Dataplane V2 (DPv2), a rede ambiente reduz a sobrecarga de recursos, elimina as reinicializações de carga de trabalho para atualizações de proxy e simplifica o gerenciamento do ciclo de vida da malha.
Recursos
A prévia da rede de ambiente do GKE é compatível com a funcionalidade de malha de camada 4 de cluster único:
- TLS mútuo (mTLS): aplica o trânsito criptografado e a autenticação de identidade.
- Descoberta de serviços: descobre serviços e encaminha conexões automaticamente entre cargas de trabalho.
- Gerenciamento de tráfego da camada 4: balanceia a carga e roteia o tráfego TCP.
- Telemetria da camada 4: emite métricas de tráfego de rede, conexão e erro para o Cloud Observability. Para detalhes sobre como visualizar e analisar essas métricas, consulte a visão geral do Monitoramento de Serviços de Rede.
Benefícios da rede de ambiente
Em comparação com as arquiteturas de malha de serviço baseadas em sidecar, a rede de ambiente oferece várias vantagens operacionais e de recursos importantes:
Gerenciamento simplificado do ciclo de vida: elimina o modelo de destino compartilhado entre proxies sidecar e contêineres de aplicativos. É possível aplicar atualizações de proxy, patches de segurança e upgrades no nível do nó sem reiniciar os pods de carga de trabalho ou causar inatividade do aplicativo.
Consumo reduzido de recursos: consolida o proxy em instâncias compartilhadas no nível do nó, reduzindo a sobrecarga de CPU e memória em até 90% em comparação com os modelos sidecar.
Eliminação de riscos de sidecar: resolve problemas comuns de sidecar, como vulnerabilidades de desvio de proxy de contêiner, interrupção de conexão fixa e propagação de encerramento de conexão não confiável.
Integração nativa com a plataforma Google Cloud : integração nativa com o GKE Dataplane V2 (DPv2), a Identidade da carga de trabalho gerenciada, o Certificate Authority Service (CAS) e o Google Cloud Observability.
Interoperabilidade e escopo
Durante este pré-lançamento da rede de ambiente, observe as seguintes restrições de escopo e interoperabilidade:
- Requisito da API Gateway: a rede de ambiente requer a API Gateway. As APIs do Istio não são compatíveis.
- Interoperabilidade de cargas de trabalho: as cargas de trabalho registradas na rede de ambiente não podem interagir com cargas de trabalho com injeção de sidecar (no GKE, no Compute Engine ou no Cloud Run) ou com cargas de trabalho gRPC sem proxy.
Arquitetura e componentes
A rede de ambiente se integra diretamente ao GKE Dataplane V2 (DPv2) em cada nó, em vez de injetar sidecars do Envoy em pods de carga de trabalho.
Componentes do plano de controle atual
A rede de ambiente depende de componentes do plano de controle para distribuir políticas, traduzir configurações e emitir certificados:
- Traffic Director: fornece o plano de controle xDS para distribuição de políticas e configuração de roteamento.
- GKE Gateway Controller: converte recursos personalizados do Kubernetes na configuração do Traffic Director.
- Certificate Authority Service (CAS): emite certificados de identidade X.509 para cargas de trabalho usando a Identidade da carga de trabalho gerenciada.
- Plano de controle do cluster do GKE: aprova solicitações de assinatura de certificado (CSRs) e as encaminha para o CAS.
Componentes do nó
A rede de ambiente instala os seguintes componentes por nó para interceptar e fazer proxy do tráfego de carga de trabalho diretamente em cada nó do cluster:
Plug-in de NRI do GKE Ambient: plug-in da interface de recursos do nó (NRI, na sigla em inglês) que configura a rede de baixo nível para interceptar e redirecionar o tráfego do pod para o proxy.
Proxy de ambiente do GKE: proxy no nível do nó que gerencia soquetes de escuta, recebe regras xDS do Traffic Director, busca certificados de identidade X.509 sob demanda do plano de controle do GKE e faz proxy do tráfego da camada 4.
Os componentes do plano de dados de ambiente no nível do nó são executados como DaemonSets no
namespace gke-managed-ambient e são automaticamente versionados, corrigidos e
atualizados junto com o plano de controle do GKE.
Escala e limites de destino
Durante o pré-lançamento, a rede ambiente tem os seguintes limites de escopo e interoperabilidade:
| Métrica de recurso | GKE DPv2 (com ambiente) | DPv2 do GKE padrão (sem ambiente) |
|---|---|---|
| Nós por cluster | 500 | 7.500 |
| Serviços por cluster | 300 | 10.000 |
| Pods por cluster | 5.000 | 200.000 |
| Máximo de pods por nó | 256 | 256 |
Para cotas gerais cluster do GKE, consulte os limites de cluster e as especificações do GKE Dataplane V2.
Preços
Confira os detalhes a seguir sobre preços e cobranças de recursos operacionais para redes ambientais:
- Todos os pods em qualquer namespace com o rótulo de ambiente
networking.gke.io/dataplane-mode=ambientserão cobrados US $0,004 por hora (US$ 0,00006667 por minuto ou cerca de US $2,90 por mês). O faturamento não será aplicado durante o pré-lançamento. - As cobranças de uso padrão do Cloud Observability (Cloud Monitoring / Cloud Logging) e do Certificate Authority Service se aplicam.
Entender os recursos da API Gateway
Quando você usa a rede de ambiente, os recursos personalizados da API Kubernetes Gateway que você gerencia no cluster são traduzidos automaticamente em um conjunto de recursos de API Google Cloud gerenciados.
| Funcionalidade | Recurso de API Google Cloud gerenciado | Escopo | Cardinalidade |
|---|---|---|---|
| Malha | Mesh |
Regional | 1 por cluster |
| Roteamento de serviços | TCPRoute |
Regional | 1 por cluster, mais 1 por Serviço segmentado por um GCPClientTLSPolicy |
| Representação do serviço | BackendService |
Regional | 1 por cluster |
| Autenticação do cliente | ClientTlsPolicy |
Regional | 1 por cluster |
| Autenticação do servidor | ServerTlsPolicy |
Regional | 3 por cluster |
| Autenticação do servidor | EndpointPolicy |
Regional | 1 por GCPServerTLSPolicy, mais 1 por modo mTLS distinto em portOverrides |
| Autorização | AuthzPolicy |
Regional | 1 por pod targetRef em cada GCPAuthzPolicy com enforcementLevel: L4 |
| Roteamento de saída | EgressRouting |
Regional | 1 por namespace que tem um GCPEgressPolicy |
A seguir
- Preparar a rede de ambiente do GKE
- Sobre a API Gateway
- Visão geral do monitoramento de serviços de rede