Nesta página, descrevemos os principais recursos e a arquitetura de rede do Ingress do GKE, especificamente a proteção de conexões do cliente com o balanceador de carga e com os pods de aplicativos, o gerenciamento de roteamento complexo em vários serviços de back-end e o entendimento de como as verificações de integridade do balanceador de carga são organizadas em um cluster.
Esta página se baseia nos conceitos fundamentais descritos na Visão Entrada GKE. Para instruções detalhadas e exemplos de implementação usando recursos personalizados, como FrontendConfig e BackendConfig, consulte Configurar recursos do Ingress para aplicativos do GKE.
Esta página é destinada a especialistas em redes que projetam e arquitetam a rede para a organização e instalam, configuram e oferecem suporte a equipamentos de rede. Para saber mais sobre papéis comuns e tarefas de exemplo que mencionamos no conteúdo doGoogle Cloud , consulte Funções e tarefas comuns do usuário do GKE.
Como proteger a entrada com HTTPS
A entrada do GKE protege o tráfego entre o cliente e o balanceador de carga de aplicativo, e do balanceador de carga para os pods do aplicativo.
Como configurar o TLS entre o cliente e o balanceador de carga
Um balanceador de carga HTTP(S) atua como um proxy entre seus clientes e o aplicativo. Se você quiser aceitar solicitações HTTPS dos seus clientes, o balanceador de carga precisará ter um certificado para provar sua identidade a eles. Além disso, ele precisa ter uma chave privada para concluir o handshake HTTPS.
Quando o balanceador de carga aceita uma solicitação HTTPS de um cliente, o tráfego entre o cliente e o balanceador de carga é criptografado usando TLS. No entanto, o balanceador de carga encerra a criptografia TLS e encaminha a solicitação sem criptografia para o aplicativo. Para mais informações, consulte Configurar a criptografia entre o balanceador de carga e o aplicativo.
Métodos para fornecer certificados SSL
É possível fornecer certificados SSL a um balanceador de carga HTTP(S) usando os seguintes métodos:
Certificados gerenciados pelo Google: são certificados de validação de domínio (DV) que o Google provisiona, renova e gerencia para seus nomes de domínio. Esses certificados não demonstram sua identidade individual ou organizacional. Os certificados gerenciados pelo Google aceitam até 100 domínios não curingas. Para mais informações, consulte Usar certificados gerenciados pelo Google.
Certificados autogerenciados compartilhados com Google Cloud: é possível provisionar seu próprio certificado SSL e criar um recurso de certificado no projeto Google Cloud . Em seguida, liste o recurso de certificado em uma anotação em um Entrada para criar um balanceador de carga HTTP(S) que use o certificado. Para mais informações, consulte Usar certificados pré-compartilhados.
Certificados autogerenciados que usam secrets do Kubernetes: é possível provisionar seu próprio certificado SSL e criar um secret para mantê-lo. Em seguida, consulte o secret no campo
tlsde um manifesto do Entrada para criar um balanceador de carga HTTP(S). Para mais informações, consulte Usar secrets do Kubernetes.
Veicular tráfego HTTPS com vários certificados
É possível configurar o balanceador de carga de aplicativo para apresentar até 15 certificados TLS a um cliente. Usar vários certificados é essencial quando você precisa veicular conteúdo de vários nomes de host, cada um exigindo um certificado diferente (por exemplo, certificados separados para your-store.example e your-experimental-store.example). Você especifica esses vários certificados no manifesto do Entrada.
Seleção e prioridade de certificados
Para determinar qual certificado apresentar ao cliente, o balanceador de carga usa a indicação de nome do servidor (SNI, na sigla em inglês).
Se o cliente usar a SNI ou um nome de domínio que corresponda ao nome comum (CN) em um dos certificados disponíveis, o balanceador de carga usará o certificado cujo CN seja a correspondência mais próxima do nome de host solicitado pelo cliente.
Se o cliente não oferecer suporte à SNI ou se o nome de domínio solicitado não corresponder ao CN de nenhum certificado disponível, o balanceador de carga usará o primeiro certificado listado no manifesto do Entrada como padrão. O balanceador de carga escolhe esse certificado de acordo com estas regras:
- Para os secrets listados no bloco
tls, o certificado principal é o primeiro secret no blocotls. - Para certificados pré-compartilhados na anotação
pre-shared-cert, o certificado principal é o primeiro certificado listado na anotação. - para certificados gerenciados pelo Google na anotação
managed-certificates: todos os certificados gerenciados são classificados em ordem alfabética por nome. O certificado principal é o primeiro na lista alfabética. Para definir um certificado específico como principal, nomeie os objetosManagedCertificatede acordo para controlar a ordem de classificação. Por exemplo, para tornarmy-default-certo principal em vez deanother-cert, você pode nomeá-los como0-my-default-certe1-another-cert.
- Para os secrets listados no bloco
Quando o balanceador de carga apresenta vários certificados por diferentes métodos do GKE, os certificados pré-compartilhados têm prioridade sobre os secrets listados no bloco tls do Entrada.
O diagrama a seguir mostra o tráfego de envio do balanceador de carga para diferentes back-ends, dependendo do nome de domínio usado na solicitação:
Práticas recomendadas de rotação de certificados
Se você quiser alternar o conteúdo do secret ou do certificado pré-compartilhado, veja algumas práticas recomendadas:
- Crie um novo Secret ou certificado pré-compartilhado com um nome diferente que contenha os novos dados do certificado. Atualize o Entrada para usar o novo recurso de certificado.
- Se você não se importar de interromper o tráfego, poderá remover o recurso antigo da entrada, provisionar um novo recurso com o mesmo nome, mas com conteúdo diferente, e anexá-lo novamente à Entrada.
Para evitar gerenciar a rotação de certificados por conta própria, use certificados SSL gerenciados pelo Google.
Forçar o tráfego somente HTTPS
Se quiser que todo o tráfego entre o cliente e o balanceador de carga HTTP(S) use HTTPS, desative o HTTP. Basta incluir a anotação kubernetes.io/ingress.allow-http no manifesto da Entrada e definir o valor como "false". Para mais informações, consulte Como desativar o HTTP.
Como configurar a criptografia entre o balanceador de carga e o aplicativo
Esta seção explica como proteger a conexão do balanceador de carga com os pods de aplicativos.
Como ativar o protocolo de back-end HTTPS ou HTTP/2
O balanceador de carga de aplicativo externo atua como um proxy entre seus clientes e o aplicativo do GKE. Embora os clientes possam se conectar ao balanceador de carga usando HTTPS (para criptografia) e vários protocolos (HTTP/1.1 ou HTTP/2), a conexão do balanceador de carga com os pods de back-end usa HTTP/1.1 não criptografado por padrão.
Se o aplicativo for capaz de processar configurações mais avançadas, você poderá atualizar manualmente o balanceador de carga de aplicativo externo para usar:
- HTTP/2: para otimizar o desempenho se os pods forem compatíveis.
- HTTPS (TLS): para aplicar a criptografia de ponta a ponta no tráfego entre o proxy do balanceador de carga e seus pods.
Você controla o protocolo (HTTP ou HTTPS) e a versão HTTP (HTTP/1.1 ou
HTTP/2) usados para a conexão de back-end usando a
anotação cloud.google.com/app-protocols no manifesto do serviço do Kubernetes.
Esse manifesto de Serviço precisa incluir type: NodePort, a menos que você esteja usando o
balanceamento de carga nativo do contêiner. Se você usa o balanceamento de carga nativo de contêiner, use o type: ClusterIP.
Endereços IP estáticos para balanceadores de carga HTTPS
Ao criar um objeto Entrada para um balanceador de carga de aplicativo externo, você recebe um endereço IP externo estável que os clientes podem usar para acessar seus serviços e, por sua vez, os contêineres em execução. O endereço IP é estável porque ele dura por toda a vida útil do objeto Entrada. Se você excluir a Entrada e criar uma nova no mesmo arquivo de manifesto, pode ser que não receba o mesmo endereço IP externo.
Caso queira um endereço IP permanente que se mantenha estável depois de excluir sua Entrada e criar uma nova, reserve um endereço IP externo estático global. Em seguida, no manifesto da entrada, inclua uma anotação que forneça o nome do endereço IP estático reservado. Se você modificar uma entrada atual para usar um endereço IP estático em vez de um endereço IP temporário, o GKE poderá alterar o endereço IP do balanceador de carga quando o GKE recriar a regra de encaminhamento do balanceador de carga de dados.
Roteamento de tráfego
O GKE Ingress usa mapas de URL para definir como as solicitações recebidas são encaminhadas para serviços de back-end específicos. É possível configurar regras de roteamento com base em nomes de host, caminhos de URL ou uma combinação dos dois para gerenciar o tráfego de vários aplicativos por um único balanceador de carga.
Vários serviços de back-end
Cada balanceador de carga de aplicativo externo ou interno usa um único mapa de URL, que faz referência a um ou mais serviços de back-end. Um serviço de back-end corresponde a cada Serviço referenciado pelo Ingress.
Por exemplo, você pode configurar o balanceador de carga para rotear solicitações para diferentes serviços de back-end dependendo do caminho do URL. As solicitações enviadas para "your-store.example" podem ser encaminhadas para um serviço de back-end que exibe itens com preço integral. Já as enviadas para "your-store.example/discounted" podem ser encaminhadas para um serviço de back-end que exibe itens com desconto.
Também é possível configurar o balanceador de carga para encaminhar solicitações de acordo com o nome do host. As solicitações enviadas para your-store.example poderiam ir para um serviço de back-end e as enviadas para your-experimental-store.example para outro.
Para criar e configurar um balanceador de carga HTTP(S), crie um objeto Ingress do Kubernetes em um cluster do GKE. O objeto Ingress precisa estar associado a um ou mais objetos de serviço, e cada um deles associado a um conjunto de pods.
Se você quiser configurar o GKE Ingress com vários back-ends para o mesmo host, será necessário ter uma única regra com um único host e vários caminhos. Caso contrário, o controlador de entrada do GKE provisiona apenas um serviço de back-end.
Veja um manifesto para um Ingress chamado my-ingress:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules: - host: your-store.example http: paths: - path: /products pathType: ImplementationSpecific backend: service: name: my-products port: number: 60000 - path: /discounted pathType: ImplementationSpecific backend: service: name: my-discounted-products port: number: 80
Quando você cria o Ingress, o controlador do Ingress do GKE cria e configura um balanceador de carga de aplicativo externo ou interno de acordo com as informações no Ingress e nos serviços associados. Além disso, o balanceador de carga recebe um endereço IP estável que pode ser associado a um nome de domínio.
No exemplo anterior, imagine que você associou o endereço IP
do balanceador de carga ao nome de domínio your-store.example Quando um cliente envia uma solicitação para your-store.example/products, ela é roteada para um serviço do Kubernetes chamado my-products na porta 60000. Quando um cliente envia uma solicitação para your-store.example/discounted, ela é roteada para um serviço do Kubernetes chamado my-discounted-products na porta 80.
O único caractere curinga aceito no campo path de uma entrada é *. O caractere * precisa vir depois de uma barra (/) e
ser o último caractere no padrão. Por exemplo, /*, /foo/* e
/foo/bar/* são padrões válidos, ao contrário de *, /foo/bar* e /foo/*/bar.
Um padrão mais específico tem precedência sobre um menos específico. Se você tiver os padrões /foo/* e /foo/bar/*, /foo/bar/bat será usado na correspondência com /foo/bar/*.
Para mais informações sobre limitações de caminho e correspondência de padrões, consulte a documentação dos mapas de URL.
O manifesto do serviço my-products ficaria da seguinte maneira:
apiVersion: v1 kind: Service metadata: name: my-products spec: type: NodePort selector: app: products department: sales ports: - protocol: TCP port: 60000 targetPort: 50000
Observe o seguinte no manifesto anterior:
O campo
spec.typedepende do método de balanceamento de carga usado:- Se você usa o balanceamento de carga nativo de contêiner, use
type: ClusterIP. - Se você usa grupos de instâncias, use
type: NodePort.
- Se você usa o balanceamento de carga nativo de contêiner, use
O campo
selectordiz que qualquer pod que tenha os rótulosapp: productsedepartment: salesé membro deste serviço.Quando uma solicitação chega ao serviço na porta 60000, ela é roteada para um dos pods de membro na porta TCP 50000.
Cada pod de membro precisa ter um contêiner escutando a porta TCP 50000.
O manifesto do serviço my-discounted-products ficaria da seguinte maneira:
apiVersion: v1 kind: Service metadata: name: my-discounted-products spec: type: NodePort selector: app: discounted-products department: sales ports: - protocol: TCP port: 80 targetPort: 8080
Observe o seguinte no manifesto anterior:
O campo
selectordiz que qualquer pod que tenha os rótulosapp: discounted-productsedepartment: salesé membro deste serviço.Quando uma solicitação chega ao serviço na porta 80, ela é roteada para um dos pods de membro na porta TCP 8080.
Todo pod membro precisa ter um contêiner escutando a porta TCP 8080.
Back-end padrão
Especifique um back-end padrão para o Ingress fornecendo um campo spec.defaultBackend
no manifesto dele. Isso vai processar as solicitações que não corresponderem
aos caminhos definidos no campo rules. Por exemplo, no Ingress a seguir, todas as solicitações que não correspondem a /discounted foram enviadas para um serviço chamado my-products na porta
60001.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
defaultBackend:
service:
name: my-products
port:
number: 60001
rules:
- http:
paths:
- path: /discounted
pathType: ImplementationSpecific
backend:
service:
name: my-discounted-products
port:
number: 80
Se você não especificar um back-end padrão, o GKE fornecerá um back-end padrão que retorna 404. Ele é criado como um serviço NodePort default-http-backend
no cluster no namespace kube-system.
A resposta HTTP 404 é semelhante a esta:
response 404 (backend NotFound), service rules for the path non-existent
Para configurar a Entrada do GKE com um back-end padrão personalizado, consulte Entrada do GKE com back-end padrão personalizado.
Verificações de integridade
Quando você expõe um ou mais serviços por meio de um Ingress usando o controlador padrão do Ingress, o GKE cria um balanceador de carga de aplicativo clássico ou um balanceador de carga de aplicativo interno. Esses dois balanceadores de carga são compatíveis com vários serviços de back-end em um único mapa de URLs. Cada um dos serviços de back-end corresponde a um serviço do Kubernetes, e cada serviço de back-end precisa fazer referência a uma Google Cloud verificação de integridade. Essa verificação de integridade é diferente de uma sondagem de atividade ou prontidão do Kubernetes porque a verificação de integridade é implementada fora do cluster.
As verificações de integridade do balanceador de carga são especificadas por serviço de back-end. Embora seja possível usar a mesma verificação de integridade em todos os serviços de back-end do balanceador de carga, a referência da verificação de integridade não é especificada para o balanceador de carga como um todo (no objeto Ingress).
O GKE cria verificações de integridade com base em um dos seguintes métodos:
- CRD
BackendConfig: uma definição de recurso personalizada (CRD) que oferece controle preciso sobre como os serviços interagem com o balanceador de carga. As CRDsBackendConfigpermitem especificar configurações personalizadas para a verificação de integridade associada ao serviço de back-end correspondente. Essas configurações personalizadas oferecem mais flexibilidade e controle sobre as verificações de integridade do balanceador de carga de aplicativo clássico e do balanceador de carga de aplicativo interno criados por um Entrada. - Sondagem de prontidão: uma verificação de diagnóstico que determina se um contêiner em um pod está pronto para veicular tráfego. O controlador de entrada do GKE cria a verificação de integridade para o serviço de back-end do Serviço com base na sondagem de prontidão usada pelos pods de exibição desse Serviço. É possível derivar os parâmetros de verificação de integridade, como caminho, porta e protocolo, da definição de sondagem de prontidão.
- Valores padrão: os parâmetros usados quando você não configura um CRD
BackendConfigou define atributos para a sondagem de prontidão.
Use um CRD BackendConfig para ter mais controle sobre as configurações de verificação de integridade do balanceador de carga.
O GKE usa o procedimento a seguir para criar uma verificação de integridade para cada serviço de back-end correspondente a um serviço do Kubernetes:
Se o serviço referir-se a uma CRD
BackendConfigcom informações dehealthCheck, o GKE usará isso para criar a verificação de integridade. Tanto o controlador do Ingress do GKE Enterprise quanto o controlador do Ingress do GKE dão suporte à criação de verificações de integridade dessa maneira.Se o Serviço não referenciar um CRD
BackendConfig:O GKE poderá inferir alguns ou todos os parâmetros de uma verificação de integridade. Para isso, os pods de exibição precisam usar um modelo com um contêiner em que a sondagem de prontidão tenha atributos que possam ser interpretados como parâmetros de verificação de integridade. Consulte Parâmetros de uma sondagem de prontidão para ver detalhes de implementação e Parâmetros padrão e inferidos para ver uma lista de atributos que podem ser usados para criar parâmetros de verificações de integridade. Somente o controlador de Ingress do GKE tem suporte para inferência de parâmetros de uma sondagem de prontidão.
Se o modelo dos pods de exibição do Serviço não tiver um contêiner com uma sondagem de prontidão que tenha atributos que possam ser interpretados como parâmetros de verificação de integridade, os valores padrão serão usados para criar a verificação de integridade. O controlador do Ingress do GKE Enterprise e o controlador do Ingress do GKE podem criar uma verificação de integridade usando apenas os valores padrão.
Parâmetros padrão e inferidos
Os parâmetros a seguir são usados quando você não especificar os parâmetros da verificação de integridade
do Serviço correspondente com um CRD BackendConfig.
| Parâmetro de verificação de integridade | Valor padrão | Valor inferido |
|---|---|---|
| Protocolo | HTTP | se estiver presente na anotação Service cloud.google.com/app-protocols
|
| Caminho da solicitação | / |
se estiver presente no pod de exibição spec:containers[].readinessProbe.httpGet.path
|
| Cabeçalho do host da solicitação | Host: backend-ip-address |
se estiver presente no pod de exibição spec:containers[].readinessProbe.httpGet.httpHeaders
|
| Resposta esperada | HTTP 200 (OK) | HTTP 200 (OK) não pode ser alterado |
| Intervalo de verificação |
|
se estiver presente no pod de exibição spec:
|
| Tempo limite da verificação | 5 segundos | se estiver presente no pod de exibição spec:containers[].readinessProbe.timeoutSeconds |
| Limite íntegro | 1 | 1 não pode ser alterado |
| Limite não íntegro |
|
o mesmo que o padrão:
|
| Especificação da porta |
|
As sondagens de verificação de integridade são enviadas para o número da porta especificado por spec.containers[].readinessProbe.httpGet.port, desde que todas as condições a seguir também sejam verdadeiras:
|
| Endereço IP de destino |
|
o mesmo que o padrão:
|
Parâmetros de uma sondagem de prontidão
Quando o GKE cria a verificação de integridade para o serviço de back-end do Serviço, ele pode copiar determinados parâmetros da sondagem de prontidão de um contêiner usada pelos pods de exibição desse Serviço. Essa opção tem suporte somente com o controlador de Ingress do GKE.
Os atributos de sondagem de prontidão compatíveis que podem ser interpretados como parâmetros de verificação de integridade são listados com os valores padrão em Parâmetros padrão e inferidos. Os valores padrão serão usados para quaisquer atributos não especificados na sondagem de prontidão ou se você não especificar nenhuma sondagem.
Se os pods de disponibilização do serviço tiverem vários contêineres ou você
estiver usando o controlador do Ingress do GKE Enterprise, use um CRD BackendConfig
para definir os parâmetros da verificação de integridade. Para mais informações, consulte Quando usar um
CRD BackendConfig.
Quando usar os CRDs BackendConfig
Em vez de depender de parâmetros das sondagens de prontidão do pod, defina
explicitamente os parâmetros de verificação de integridade em um serviço de back-end. Para isso, crie um
CRD BackendConfig para o Serviço nestas situações:
Ao usar o GKE Enterprise: o controlador do Ingress não dá suporte à coleta de parâmetros de verificação de integridade das sondagens de prontidão dos pods de disponibilização. Só é possível criar verificações de integridade por meio e parâmetros implícitos ou definidos em um CRD
BackendConfig.Se você tiver mais de um contêiner nos pods de exibição: o GKE não tem como selecionar a sondagem de prontidão de um contêiner específico em que inferir parâmetros da verificação de integridade. Como cada contêiner pode ter a própria sondagem de prontidão e uma sondagem de prontidão não é um parâmetro obrigatório para um contêiner, você precisa definir a verificação de integridade para o serviço de back-end correspondente mencionando uma consulta
BackendConfigCRD no serviço correspondente.Se você precisar de controle sobre a porta usada para as verificações de integridade do balanceador de carga: o GKE só usará o
containers[].readinessProbe.httpGet.portda sondagem de prontidão para a verificação de integridade do serviço de back-end quando essa porta corresponder à porta de serviço no Serviço mencionado no Ingressspec.rules[].http.paths[].backend.servicePort.
Parâmetros de um CRD BackendConfig
É possível especificar os parâmetros da verificação de integridade do serviço de back-end
usando o parâmetro healthCheck de um
CRD BackendConfig referenciado
pelo Serviço correspondente. Isso proporciona mais flexibilidade e controle sobre
as verificações de integridade de um balanceador de carga de aplicativo clássico ou interno
criado por um Ingress. Consulte Configurações
do Ingress para ver
a compatibilidade da versão do GKE.
Este exemplo e CRD BackendConfig define o protocolo de verificação de integridade (tipo), um
caminho de solicitação, uma porta e um intervalo de verificação no atributo spec.healthCheck:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: http-hc-config
spec:
healthCheck:
checkIntervalSec: 15
port: 15020
type: HTTPS
requestPath: /healthz
Para definir todos os campos disponíveis ao configurar uma verificação de integridade
BackendConfig, use o
exemplo de
configuração de verificação de integridade personalizada.
Para configurar a Entrada do GKE com uma verificação de integridade HTTP personalizada, consulte Entrada do GKE com verificação de integridade HTTP personalizada.
Prontidão do pod
Depois que as verificações de integridade do balanceador de carga são configuradas usando um dos métodos anteriores, o controlador de entrada do GKE usa o status de integridade dos endpoints de back-end para determinar a prontidão do pod, o que é fundamental para gerenciar atualizações graduais e a estabilidade geral do tráfego.
Para os pods relevantes, o controlador de entrada correspondente gerencia um portão de prontidão do tipo cloud.google.com/load-balancer-neg-ready. O controlador de entrada pesquisa o status de verificação de integridade do balanceador de carga, que inclui a integridade de todos os endpoints no NEG. Ao indicar que o endpoint correspondente a um pod específico está íntegro, o controlador de entrada define o valor do portão de prontidão do pod como True.
O kubelet em execução em cada nó calcula então a prontidão efetiva do pod, considerando o valor deste portão de prontidão e, se definida, a sondagem de prontidão do pod.
Os portões de prontidão do pod são ativados automaticamente ao usar o balanceamento de carga nativo de contêiner por meio do Ingress.
Os gates de prontidão controlam a taxa de uma atualização gradual. Ao iniciar uma
atualização gradual, conforme o GKE cria novos pods, um endpoint para cada
novo pod é adicionado a um NEG. Quando o endpoint é íntegro na perspectiva do balanceador de carga, o controlador Entrada define o gate de prontidão como True. Um pod recém-criado precisa pelo menos passar pelo portão de prontidão antes que o GKE remova um pod antigo. Isso garante que o endpoint correspondente do pod já tenha passado pela verificação de integridade do balanceador de carga e que a capacidade do back-end seja mantida.
Se o portão de prontidão de um pod não indicar que o pod está pronto, devido a uma imagem ruim do contêiner ou uma verificação de integridade do balanceador de carga configurada incorretamente, o balanceador de carga não direcionará tráfego para o novo pod. Se isso ocorrer durante o lançamento de uma implantação atualizada, o lançamento será interrompido após tentar criar um novo pod porque o portão de prontidão desse pod nunca será "True". Veja a seção de solução de problemas (em inglês) para mais informações sobre como detectar e corrigir esta situação.
Sem portões de prontidão e balanceamento de carga nativos de contêiner, o GKE não consegue detectar se os endpoints de um balanceador de carga estão íntegros antes de marcar os pods como prontos. Nas versões anteriores do Kubernetes, você controla a taxa de remoção e de substituição dos pods, especificando um período de atraso (minReadySeconds na especificação de implantação).
O GKE define o valor de cloud.google.com/load-balancer-neg-ready de um pod como True se alguma das seguintes condições for atendida:
- Nenhum dos endereços IP do pod são endpoints em um
GCE_VM_IP_PORTNEG gerenciado pelo plano de controle do GKE. - Um ou mais endereços IP do pod são endpoints em um NEG
GCE_VM_IP_PORTgerenciado pelo plano de controle do GKE. O NEG está anexado a um serviço de back-end. O serviço de back-end tem uma verificação de integridade do balanceador de carga bem-sucedida. - Um ou mais endereços IP do pod são endpoints em um NEG
GCE_VM_IP_PORTgerenciado pelo plano de controle do GKE. O NEG é anexado a um serviço de back-end. A verificação de integridade do balanceador de carga para o serviço de back-end expira. - Um ou mais endereços IP do pod são endpoints em um ou mais
NEGs
GCE_VM_IP_PORT. Nenhum dos NEGs está anexado a um serviço de back-end. Não há dados de verificação de integridade do balanceador de carga disponíveis.
Suporte para WebSocket
Com os balanceadores de carga de aplicativo externos, o protocolo WebSocket funciona sem qualquer configuração.
Se você pretende usar o protocolo WebSocket, use um valor de tempo limite maior que o padrão de 30 segundos. Para o tráfego WebSocket enviado por um balanceador de carga de aplicativo externo doGoogle Cloud , o tempo limite do serviço de back-end é interpretado como o tempo máximo em que uma conexão WebSocket pode permanecer aberta, seja ela ociosa ou não.
Para definir o valor de tempo limite para um serviço de back-end, consulte Tempo limite de resposta do back-end.
Cenários avançados de rede
O GKE Ingress é compatível com configurações de rede avançadas, como compartilhamento de recursos de rede entre projetos e uso de controladores Entrada personalizados.
VPC compartilhada
Os recursos de entrada e MultiClusterIngress são compatíveis com a
VPC compartilhada, mas exigem preparação adicional.
O controlador de Ingress é executado no plano de controle do GKE e faz chamadas de API para Google Cloud usando a conta de serviço do GKE do projeto do cluster. Por padrão, quando um cluster localizado em um projeto de serviço de VPC compartilhada usa uma rede VPC compartilhada, o controlador de Ingress não pode usar a conta de serviço do GKE do projeto de serviço para criar e atualizar regras de firewall de permissão de Ingress em projeto host.
É possível conceder permissões da conta de serviço do GKE do projeto de serviço para criar e gerenciar regras de firewall da VPC no projeto host. Ao conceder essas permissões, o GKE cria regras de permissão de entrada de firewall para:
Os sistemas de verificação de integridade e proxies do Google Front End (GFE) usados por balanceadores de carga de aplicativo externos para o Ingress externo. Para mais detalhes, consulte a Visão geral do balanceador de carga de aplicativo externo.
Sistemas de verificação de integridade para balanceadores de carga de aplicativo internos usados pelo Ingress interno.
Provisionar manualmente as regras de firewall do projeto host
Se suas políticas de segurança permitirem apenas o gerenciamento de firewall pelo projeto host, será possível provisionar essas regras de firewall manualmente. Ao implantar Entrada em uma VPC compartilhada, o evento de recurso do Entrada fornece a regra de firewall específica necessária para conceder acesso.
Para provisionar uma regra manualmente:
Visualize o evento do recurso do Ingress:
kubectl describe ingress INGRESS_NAMESubstitua INGRESS_NAME pelo nome do seu Ingress.
O resultado será semelhante a:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Sync 9m34s (x237 over 38h) loadbalancer-controller Firewall change required by security admin: `gcloud compute firewall-rules update k8s-fw-l7--6048d433d4280f11 --description "GCE L7 firewall rule" --allow tcp:30000-32767,tcp:8080 --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags gke-l7-ilb-test-b3a7e0e5-node --project <project>`A regra de firewall necessária sugerida aparece na coluna
Message.Copie e aplique as regras de firewall sugeridas do projeto host. A aplicação da regra concede acesso aos seus pods a partir do balanceador de carga e dos verificadores de integridade doGoogle Cloud .
Como conceder permissão ao controlador de Entrada para gerenciar as regras de firewall do projeto host
Se você quer que um cluster do GKE em um projeto de serviço crie e gerencie os recursos de firewall no seu projeto host, a conta de serviço do GKE do projeto de serviço precisa receber as permissões de IAM apropriadas usando uma das estratégias a seguir:
Conceda à conta de serviço do GKE do projeto de serviço o papel de Administrador de segurança do Compute ao projeto host. O exemplo a seguir demonstra essa estratégia.
Para uma abordagem mais precisa, crie um papel de IAM personalizado que inclua apenas as seguintes permissões:
compute.networks.updatePolicy,compute.firewalls.list,compute.firewalls.get,compute.firewalls.create,compute.firewalls.update,compute.firewalls.deleteecompute.subnetworks.list. Conceda à conta de serviço do GKE do projeto de serviço esse papel personalizado no projeto host.
Se você tiver clusters em mais de um projeto de serviço, precisará escolher uma das estratégias e repeti-la para cada conta de serviço do GKE do projeto de serviço.
gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
--member=serviceAccount:service-SERVICE_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
--role=roles/compute.securityAdmin
Substitua:
HOST_PROJECT_ID: o ID do projeto do projeto host da VPC compartilhada.SERVICE_PROJECT_NUMBER: número do projeto do projeto de serviço que contenha seu cluster.
Usar um controlador de Entrada personalizado
É possível executar um controlador de entrada personalizado desativando
o complemento HttpLoadBalancing. Isso impede que o controlador de
entrada do GKE processe recursos de entrada.
Se você quiser executar um controlador de Entrada personalizado com o complemento HttpLoadBalancing
ativado, por exemplo, para usar recursos como
subagrupamento
e
Private Service Connect,
é possível usar uma das seguintes abordagens:
- No manifesto da Entrada, defina a
anotação
kubernetes.io/ingress.class. Essa configuração é compatível com clusters que executam todas as versões do GKE. - Configure o campo
ingressClassName. - Configurar uma classe de Entrada padrão.
Garanta que spec.ingressClassName não seja substituído acidentalmente por
nenhum processo. Uma operação de atualização que altera spec.IngressClassName de um
valor válido para uma string vazia ("") faz com que o controlador de entrada do GKE
processe a entrada.
Configurar o campo ingressClassName
É possível usar um controlador de entrada personalizado definindo o campo ingressClassName
no manifesto de entrada. O manifesto a seguir descreve uma entrada que
especifica o
controlador cilium de entrada (em inglês):
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: cafe-ingress
spec:
ingressClassName: cilium
tls:
- hosts:
- cafe.example.com
secretName: cafe-secret
rules:
- host: cafe.example.com
Configurar uma classe de Entrada padrão
É possível configurar uma classe Entrada padrão para todos os recursos Ingress em um
cluster criando um recurso
IngressClass
com a anotação ingressclass.kubernetes.io/is-default-class definida como
true:
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: gce
annotations:
ingressclass.kubernetes.io/is-default-class: "true"
spec:
controller: k8s.io/ingress-gce
Resumo do comportamento do controlador de Entrada do GKE
Para clusters que executam as versões 1.18 e posteriores do GKE,
se o controlador de Entrada do GKE processa uma Entrada depende do valor
da anotação kubernetes.io/ingress.class e do campo
ingressClassName no manifesto da Entrada: Para mais informações, consulte
Comportamento do controlador de entrada do GKE.
Modelos para a configuração da Entrada
- Em Roteiros de rede do GKE, é possível encontrar modelos fornecidos pelo GKE em muitos usos comuns da Entrada na seção Entrada.