Nesta página, mostramos como configurar o balanceador de carga que o Google Kubernetes Engine (GKE) cria quando você implanta um gateway em um cluster do GKE.
Quando você implanta um gateway, a configuração GatewayClass determina qual balanceador de carga o GKE cria. Esse balanceador de carga gerenciado é pré-configurado com configurações padrão que podem ser modificadas por uma política.
Para personalizar os recursos de gateway de acordo com os requisitos da sua infraestrutura ou aplicativo, anexe políticas a gateways, serviços ou ServiceImports. Depois de aplicar ou modificar uma política, não é preciso excluir ou recriar os recursos de gateway, rota ou serviço. A política é processada pelo controlador de gateway, e o recurso do balanceador de carga subjacente é (re)configurada de acordo com a (nova) política.
Antes de começar
Antes de começar, verifique se você realizou as tarefas a seguir:
- Ativar a API Google Kubernetes Engine. Ativar a API Google Kubernetes Engine
- Se você quiser usar a Google Cloud CLI para essa tarefa,
instale e, em seguida,
inicialize a
CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão
mais recente executando
gcloud components update
.
Requisitos do GKE Gateway Controller
- Para o Standard, o GKE versão 1.24 ou posterior.
- Para o Autopilot, o GKE versão 1.26 ou posterior.
- Google Cloud CLI versão 407.0.0 ou mais recente.
- A API Gateway é compatível apenas com clusters nativos da VPC.
- Se você estiver usando o GatewayClasses interno, ative uma sub-rede somente proxy.
- O cluster precisa ter o complemento
HttpLoadBalancing
ativado. - Se você estiver usando o Istio, será necessário fazer upgrade do Istio para uma das seguintes versões:
- 1.15.2 ou mais recente
- 1.14.5 ou mais recente
- 1.13.9 ou mais recente
- Se você estiver usando a VPC compartilhada, será necessário atribuir o papel
Compute Network User
à conta de serviço do GKE referente ao projeto de serviço no projeto host.
Restrições e limitações
Além das restrições e limitações do controlador de gateway do GKE, as seguintes limitações se aplicam especificamente às políticas aplicadas aos recursos de gateway:
Os recursos
GCPGatewayPolicy
só podem ser anexados a umgateway.networking.k8s.io
Gateway
.Os recursos
GCPGatewayPolicy
precisam existir no mesmo namespace que oGateway
de destino.Ao usar um único gateway de cluster, os recursos
GCPBackendPolicy
eHealthCheckPolicy
precisam se referir a um recursoService
.
- Ao usar um
gateway de vários clusters, os recursos
GCPBackendPolicy
eHealthCheckPolicy
devem se referir a um recursoServiceImport
.
Apenas um
GCPGatewayPolicy
pode ser anexado a um serviço por vez. Quando duas políticasGCPGatewayPolicy
são criadas e segmentam a mesmaService
ouServiceImport
, a política mais antiga tem precedência e a segunda falha ao ser anexada.As políticas hierárquicas não são compatíveis com o gateway do GKE.
Os recursos
HealthCheckPolicy
eGCPBackendPolicy
precisam estar no mesmo namespace que o recurso de destinoService
ouServiceImport
.Os recursos
GCPBackendPolicy
eHealthCheckPolicy
são estruturados para referenciar apenas um serviço de back-end.
Configurar o acesso global para seu gateway interno regional
Nesta seção, descrevemos uma funcionalidade disponível nos clusters do GKE que executam a versão 1.24 ou posterior.
Para permitir o acesso global com seu gateway interno, anexe uma política ao recurso de gateway.
O manifesto GCPGatewayPolicy
a seguir ativa o gateway interno regional para
acesso global:
apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
name: my-gateway-policy
namespace: default
spec:
default:
allowGlobalAccess: true
targetRef:
group: gateway.networking.k8s.io
kind: Gateway
name: my-gateway
Configurar políticas de SSL para proteger o tráfego do cliente para o balanceador de carga
Nesta seção, descrevemos uma funcionalidade disponível nos clusters do GKE que executam a versão 1.24 ou posterior.
Para proteger o tráfego do cliente para o balanceador de carga, configure a política de SSL adicionando
o nome da política a GCPGatewayPolicy
. Por padrão, o gateway não
tem nenhuma política de SSL definida e anexada.
Crie uma política de SSL
antes de referenciar a política em GCPGatewayPolicy
.
O manifesto GCPGatewayPolicy
a seguir especifica uma política de segurança chamada
gke-gateway-ssl-policy
:
apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
name: my-gateway-policy
namespace: team1
spec:
default:
sslPolicy: gke-gateway-ssl-policy
targetRef:
group: gateway.networking.k8s.io
kind: Gateway
name: my-gateway
Configurar verificações de integridade
Nesta seção, descrevemos uma funcionalidade disponível nos clusters do GKE que executam a versão 1.24 ou posterior.
É possível usar uma HealthCheckPolicy
para controlar as configurações de verificação de integridade
do balanceador de carga. Cada tipo de verificação de integridade (http
, https
, grpc
e http2
) tem parâmetros que podem ser definidos. O Google Cloud cria uma verificação de integridade
exclusiva para cada serviço de back-end em cada serviço do GKE.
O manifesto HealthCheckPolicy
a seguir mostra todos os campos disponíveis ao
configurar uma política de verificação de integridade:
Serviço
apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
name: lb-healthcheck
namespace: lb-service-namespace
spec:
default:
checkIntervalSec: INTERVAL
timeoutSec: TIMEOUT
healthyThreshold: HEALTHY_THRESHOLD
unhealthyThreshold: UNHEALTHY_THRESHOLD
logConfig:
enabled: ENABLED
config:
type: PROTOCOL
httpHealthCheck:
portSpecification: PORT_SPECIFICATION
port: PORT
portName: PORT_NAME
host: HOST
requestPath: REQUEST_PATH
response: RESPONSE
proxyHeader: PROXY_HEADER
httpsHealthCheck:
portSpecification: PORT_SPECIFICATION
port: PORT
portName: PORT_NAME
host: HOST
requestPath: REQUEST_PATH
response: RESPONSE
proxyHeader: PROXY_HEADER
grpcHealthCheck:
grpcServiceName: GRPC_SERVICE_NAME
portSpecification: PORT_SPECIFICATION
port: PORT
portName: PORT_NAME
http2HealthCheck:
portSpecification: PORT_SPECIFICATION
port: PORT
portName: PORT_NAME
host: HOST
requestPath: REQUEST_PATH
response: RESPONSE
proxyHeader: PROXY_HEADER
targetRef:
group: ""
kind: Service
name: lb-service
Serviço em vários clusters
apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
name: lb-healthcheck
namespace: lb-service-namespace
spec:
default:
checkIntervalSec: INTERVAL
timeoutSec: TIMEOUT
healthyThreshold: HEALTHY_THRESHOLD
unhealthyThreshold: UNHEALTHY_THRESHOLD
logConfig:
enabled: ENABLED
config:
type: PROTOCOL
httpHealthCheck:
portSpecification: PORT_SPECIFICATION
port: PORT
portName: PORT_NAME
host: HOST
requestPath: REQUEST_PATH
response: RESPONSE
proxyHeader: PROXY_HEADER
httpsHealthCheck:
portSpecification: PORT_SPECIFICATION
port: PORT
portName: PORT_NAME
host: HOST
requestPath: REQUEST_PATH
response: RESPONSE
proxyHeader: PROXY_HEADER
grpcHealthCheck:
grpcServiceName: GRPC_SERVICE_NAME
portSpecification: PORT_SPECIFICATION
port: PORT
portName: PORT_NAME
http2HealthCheck:
portSpecification: PORT_SPECIFICATION
port: PORT
portName: PORT_NAME
host: HOST
requestPath: REQUEST_PATH
response: RESPONSE
proxyHeader: PROXY_HEADER
targetRef:
group: net.gke.io
kind: ServiceImport
name: lb-service
Substitua:
INTERVAL
: especifica o intervalo de verificação, em segundos, para cada sondagem de verificação de integridade. Esse é o momento entre o início da verificação de uma sondagem e o começo da próxima verificação. Se você omitir esse parâmetro, o padrão do Google Cloud será de cinco segundos. Para mais informações, consulte Várias sondagens e frequências.TIMEOUT
: especifica o tempo pelo qual o Google Cloud aguarda uma resposta para uma sondagem. O valor deTIMEOUT
precisa ser menor ou igual aoINTERVAL
. As unidades são informadas em segundos. Cada sondagem exige que um código de resposta HTTP 200 (OK) seja entregue antes do tempo limite da sondagem.HEALTHY_THRESHOLD
eUNHEALTHY_THRESHOLD
: especifica o número de tentativas de conexão sequenciais que precisam ser realizadas ou falhar, para pelo menos uma sondagem, para alterar o estado de integridade de íntegro para não íntegro ou de não íntegro para íntegro. Se você omitir um desses parâmetros, o padrão do Google Cloud será 2.PROTOCOL
: especifica um protocolo usado pelos sistemas de sondagem para verificação de integridade. Para mais informações, consulte Critérios de sucesso para HTTP, HTTPS e HTTP/2 e Critérios de sucesso para gRPC. Este parâmetro é obrigatório.ENABLED
: especifica se a geração de registros está ativada ou desativada.PORT_SPECIFICATION
: especifica se a verificação de integridade usa uma porta fixa (USE_FIXED_PORT
), uma porta nomeada (USE_NAMED_PORT
) ou uma porta de serviço (USE_SERVING_PORT
). Se não for especificada, a verificação de integridade seguirá o comportamento especificado nos camposport
eportName
. Seport
eportName
não forem especificados, o padrão do campo seráUSE_SERVING_PORT
.PORT
: uma HealthCheckPolicy só permite a especificação da porta de verificação de integridade do balanceador de carga usando um número de porta. Se você omitir esse parâmetro, o padrão do Google Cloud será 80. Como o balanceador de carga envia sondagens para o endereço IP do pod diretamente, selecione uma porta que corresponda a umcontainerPort
de pods de exibição, mesmo que ocontainerPort
seja indicado por umtargetPort
do serviço. Você não fica limitado aocontainerPorts
indicado pelotargetPort
de um serviço.PORT_NAME
: especifica o nome da porta, conforme definido em InstanceGroup.NamedPort.name. Seport
eportName
estiverem definidos, o Google Cloud considera o valorport
primeiro.HOST
: o valor do cabeçalho do host na solicitação de verificação de integridade. Esse valor usa a definição RFC 1123 de um nome de host, exceto endereços IP numéricos não permitidos. Se não for especificado ou deixado em branco, esse valor será o padrão para o endereço IP da verificação de integridade.REQUEST_PATH
: especifica o caminho da solicitação de verificação de integridade. Se não for especificado ou ficar em branco, o padrão será/
.RESPONSE
: especifica os bytes que serão comparados com o início dos dados da resposta. Se não for especificado ou deixado em branco, o GKE interpretará qualquer resposta como íntegra. Os dados de resposta só podem ser ASCII.PROXY_HEADER
: especifica o tipo de cabeçalho do proxy. É possível usarNONE
ouPROXY_V1
. O padrão éNONE
.GRPC_SERVICE_NAME
: um nome opcional do serviço gRPC. Omita esse campo para especificar todos os Serviços.
Para mais informações sobre os campos de HealthCheckPolicy, consulte a
referência de healthChecks
.
Configurar a política de segurança do back-end do Google Cloud Armor para proteger seus serviços de back-end
Nesta seção, descrevemos uma funcionalidade disponível nos clusters do GKE que executam a versão 1.24 ou posterior.
Configure a política de segurança do back-end do Google Cloud Armor adicionando o nome da política
de segurança a GCPBackendPolicy
para proteger os serviços de back-end.
Por padrão,
o gateway não tem nenhuma política de segurança do back-end do Google Cloud Armor definida e anexada.
Crie uma política de segurança do back-end do Google Cloud Armor
antes de referenciar a política na GCPBackendPolicy
.
O manifesto GCPBackendPolicy
a seguir especifica uma política de segurança de back-end
chamada example-security-policy
:
Serviço
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
securityPolicy: example-security-policy
targetRef:
group: ""
kind: Service
name: lb-service
Serviço em vários clusters
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
securityPolicy: example-security-policy
targetRef:
group: net.gke.io
kind: ServiceImport
name: lb-service
Configurar o IAP
Nesta seção, descrevemos uma funcionalidade disponível nos clusters do GKE que executam a versão 1.24 ou posterior.
O Identity-Aware Proxy (IAP) impõe políticas de controle de acesso a serviços de back-end associados a uma HTTPRoute. Com essa aplicação, somente usuários ou aplicativos autenticados com o papel correto do Identity and Access Management (IAM) atribuído podem acessar esses serviços de back-end.
Por padrão, não há IAP aplicado aos serviços de back-end. Você
precisa configurar explicitamente o IAP em GCPBackendPolicy
.
Para configurar o IAP com o gateway, faça o seguinte:
Ative o IAP para GKE Não configure o back-end (Como configurar o BackendConfig) porque
BackendConfig
só é válido no caso de uma implantação do Ingress.Crie um secret para o IAP:
No console do Google Cloud, acesse a página Credenciais:
Clique no nome do cliente e faça o download do arquivo do cliente OAuth.
No arquivo do cliente OAuth, copie a chave secreta OAuth na área de transferência.
Crie um arquivo chamado
iap-secret.txt
.Cole a chave secreta OAuth no arquivo
iap-secret.txt
usando o seguinte comando:echo -n CLIENT_SECRET > iap-secret.txt kubectl create secret generic SECRET_NAME --from-file=key=iap-secret.txt
Para especificar a política do IAP que faz referência a um secret:
Crie o manifesto
GCPBackendPolicy
a seguir, substituindoSECRET_NAME
eCLIENT_ID
, respectivamente. Salve o manifesto comobackend-policy.yaml
:Serviço
apiVersion: networking.gke.io/v1 kind: GCPBackendPolicy metadata: name: backend-policy spec: default: iap: enabled: true oauth2ClientSecret: name: SECRET_NAME clientID: CLIENT_ID targetRef: group: "" kind: Service name: lb-service
Serviço em vários clusters
apiVersion: networking.gke.io/v1 kind: GCPBackendPolicy metadata: name: backend-policy spec: default: iap: enabled: true oauth2ClientSecret: name: SECRET_NAME clientID: CLIENT_ID targetRef: group: net.gke.io kind: ServiceImport name: lb-service
Aplique o manifesto
backend-policy.yaml
:kubectl apply -f backend-policy.yaml
Verifique a configuração:
Confirme se a política foi aplicada depois de criar
GCPBackendPolicy
com o IAP:kubectl get gcpbackendpolicy
O resultado será assim:
NAME AGE backend-policy 45m
Para ver mais detalhes, use o comando "describe":
kubectl describe gcpbackendpolicy
O resultado será assim:
Name: backend-policy Namespace: default Labels: <none> Annotations: <none> API Version: networking.gke.io/v1 Kind: GCPBackendPolicy Metadata: Creation Timestamp: 2023-05-27T06:45:32Z Generation: 2 Resource Version: 19780077 UID: f4f60a3b-4bb2-4e12-8748-d3b310d9c8e5 Spec: Default: Iap: Client ID: 441323991697-luotsrnpboij65ebfr13hlcpm5a4heke.apps.googleusercontent.com Enabled: true oauth2ClientSecret: Name: my-iap-secret Target Ref: Group: Kind: Service Name: lb-service Status: Conditions: Last Transition Time: 2023-05-27T06:48:25Z Message: Reason: Attached Status: True Type: Attached Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ADD 46m sc-gateway-controller default/backend-policy Normal SYNC 44s (x15 over 43m) sc-gateway-controller Application of GCPGatewayPolicy "default/backend-policy" was a success
Configurar o tempo limite do serviço de back-end
Nesta seção, descrevemos uma funcionalidade disponível nos clusters do GKE que executam a versão 1.24 ou posterior.
O manifesto GCPBackendPolicy
a seguir especifica um
tempo limite do serviço de back-end
de 40 segundos. O campo timeoutSec
tem como padrão 30 segundos.
Serviço
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
timeoutSec: 40
targetRef:
group: ""
kind: Service
name: lb-service
Serviço em vários clusters
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
timeoutSec: 40
targetRef:
group: net.gke.io
kind: ServiceImport
name: lb-service
Configurar a afinidade da sessão
Nesta seção, descrevemos uma funcionalidade disponível nos clusters do GKE que executam a versão 1.24 ou posterior.
É possível configurar a afinidade da sessão com base nos seguintes critérios:
- Endereço IP do cliente
- Cookie gerado
Quando você define a afinidade da sessão
para o serviço, a configuração localityLbPolicy
do gateway é definida como MAGLEV
.
Quando você remove uma configuração de afinidade da sessão de GCPBackendPolicy
,
o gateway reverte a configuração localityLbPolicy
para o valor padrão, ROUND_ROBIN
.
Esse valor é definido silenciosamente no serviço de back-end gerenciado pelo GKE
(anexado ao balanceador de carga) e não é refletido na saída de um comando da gcloud CLI, na interface ou com o Terraform.
O manifesto GCPBackendPolicy
a seguir especifica uma afinidade de sessão com base no
endereço IP do cliente:
Serviço
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
sessionAffinity:
type: CLIENT_IP
targetRef:
group: ""
kind: Service
name: lb-service
Serviço em vários clusters
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
sessionAffinity:
type: CLIENT_IP
targetRef:
group: net.gke.io
kind: ServiceImport
name: lb-service
O manifesto GCPBackendPolicy
a seguir especifica uma afinidade de sessão com base em um
cookie gerado
e configura o TTL de cookies como 50 segundos:
Serviço
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
sessionAffinity:
type: GENERATED_COOKIE
cookieTtlSec: 50
targetRef:
group: ""
kind: Service
name: lb-service
Serviço em vários clusters
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
sessionAffinity:
type: GENERATED_COOKIE
cookieTtlSec: 50
targetRef:
group: net.gke.io
kind: ServiceImport
name: lb-service
É possível usar as seguintes opções para sessionAffinity.type
: CLIENT_IP
,
CLIENT_IP_PROTO
, CLIENT_IP_PORT_PROTO
, GENERATED_COOKIE
, HEADER_FIELD
,
HTTP_COOKIE
, NONE
.
Configurar o tempo limite de diminuição da conexão
Nesta seção, descrevemos uma funcionalidade disponível nos clusters do GKE que executam a versão 1.24 ou posterior.
É possível configurar o
tempo limite de diminuição da conexão
usando GCPBackendPolicy
. O tempo limite de diminuição da conexão é o tempo, em segundos, de
espera pela redução das conexões. A duração do tempo limite pode ser de 0 a 3.600 segundos.
O valor padrão é 0, o que também desativa a diminuição da conexão.
O manifesto GCPBackendPolicy
a seguir especifica um tempo limite de diminuição da conexão
de 60 segundos:
Serviço
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
connectionDraining:
drainingTimeoutSec: 60
targetRef:
group: ""
kind: Service
name: lb-service
Serviço em vários clusters
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
connectionDraining:
drainingTimeoutSec: 60
targetRef:
group: net.gke.io
kind: ServiceImport
name: lb-service
Durante o tempo limite especificado, o GKE aguarda a conclusão das solicitações existentes para o back-end removido. O balanceador de carga não envia novas solicitações para o back-end removido. Depois que o tempo limite é alcançado, o GKE fecha todas as conexões restantes com o back-end.
Geração de registros de acesso HTTP
Nesta seção, descrevemos uma funcionalidade disponível nos clusters do GKE que executam a versão 1.24 ou posterior.
Por padrão:
- O controlador de gateway registra todas as solicitações HTTP de clientes para o Cloud Logging.
- A taxa de amostragem é 1.000.000, o que significa que todas as solicitações são registradas.
É possível desativar a geração de registros de acesso no gateway usando um GCPBackendPolicy
de três maneiras:
- Você pode deixar a seção
GCPBackendPolicy
semlogging
. - Você também pode definir
logging.enabled
comofalse
. - Você pode definir
logging.enabled
comotrue
elogging.sampleRate
como0
Também é possível configurar a taxa de amostragem da geração de registros de acesso.
O manifesto GCPBackendPolicy
a seguir modifica a taxa de amostragem padrão da geração de registros de acesso e a define como 50% das solicitações HTTP para um determinado recurso de serviço:
Serviço
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
logging:
enabled: true
sampleRate: 500000
targetRef:
group: ""
kind: Service
name: lb-service
Serviço em vários clusters
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
logging:
enabled: true
sampleRate: 500000
targetRef:
group: net.gke.io
kind: ServiceImport
name: lb-service
Esse manifesto tem os seguintes campos:
enable: true
: ativa explicitamente a geração de registros de acesso. Os registros ficam disponíveis no Logging.sampleRate: 500000
: especifica que 50% dos pacotes são registrados. É possível usar um valor entre 0 e 1.000.000. O GKE converte esse valor em um valor com ponto flutuante no intervalo [0, 1] ao dividir por 1.000.000. Esse campo só é relevante seenable
estiver definido comotrue
.sampleRate
é um campo opcional, mas, se configurado,enable: true
também precisa ser definido. Seenable
estiver definido comotrue
esampleRate
não for informado, o GKE defineenable
comofalse
.
Solução de problemas
Vários GCPBackendPolicy
anexados ao mesmo Service
Sintoma:
A condição de status a seguir pode ocorrer quando você anexa um GCPBackendPolicy
a um Service
ou um ServiceImport
:
status:
conditions:
- lastTransitionTime: "2023-09-26T20:18:03Z"
message: conflicted with GCPBackendPolicy "[POLICY_NAME]" of higher precedence, hence not applied
reason: Conflicted
status: "False"
type: Attached
Motivo:
Essa condição de status indica que você está tentando aplicar um segundo GCPBackendPolicy
a um Service
ou ServiceImport
que já tem um GCPBackendPolicy
anexado.
Vários GCPBackendPolicy
anexados ao mesmo Service
ou ServiceImport
não são compatíveis com o gateway do GKE. Consulte Restrições e limitações para mais detalhes.
Alternativa:
Defina um único GCPBackendPolicy
que inclua todas as configurações personalizadas e
anexe-o ao seu Service
ou ServiceImport
.
A seguir
- Saiba mais sobre o controlador de gateway.
- Saiba como fazer referência a um gateway em um recurso.