Recursos do Ingress

Nesta página, você encontra uma visão geral do que é compatível e configurável por meio do Ingress do Kubernetes no Google Cloud. O Ingress for Google Kubernetes Engine (GKE) e o Ingress for Anthos fornecem balanceamento de carga de classe empresarial com forte integração à sua rede VPC do Google Cloud.

Comparação do recurso

A tabela a seguir fornece uma lista de recursos compatíveis com o Ingress no Google Cloud.

Classe do Ingress Entrada externa Entrada interna Ingress em vários clusters
Controlador do Ingress GKE Ingress
(hospedado pelo GKE principal)
Anthos Ingress
(hospedado pelo Google)
Tipo de balanceador de carga do Google Cloud BC de HTTP(S) externo BC de HTTP(S) interno BC de HTTP(S) externo
Escopo do cluster Cluster único Cluster único Vários clusters
Escopo do balanceador de carga Global Discos Global
Compatibilidade das versões Tudo GKE 1.16.5+ GKE 1.14+
Suporte ao ambiente GKE GKE GKE
Suporte para VPC compartilhada Suporte Incompatível Suporte
Anotações de serviço
Balanceamento de carga nativo de contêiner (NEGs)
HTTPS do balanceador de carga para back-ends
HTTP/2
Anotações do Ingress
Endereços IP estáticos
Certificados baseados em secrets do Kubernetes
Certificados SSL autogerenciados do Google
Certificados SSL gerenciados pelo Google
FrontendConfig (Beta)
Política de SSL
1.17.6-gke.11B
BackendConfig
Tempo limite do serviço de back-end
Cloud CDN
Tempo limite de diminuição da conexão
Configuração personalizada da verificação de integridade do balanceador de carga
1.17.6-gke.11B

1.17.6-gke.11B
Política de segurança do Google Cloud Armor
Configuração da geração de registros de acesso HTTP
1.16.10-gke.6G

1.16.10-gke.6B
Identity-Aware Proxy (IAP)
Afinidade da sessão
Cabeçalhos de solicitação definidos pelo usuário
1.15.3-gke.1G

G Este recurso é compatível com o GA a partir da versão especificada.

B Esse recurso está disponível na versão Beta a partir da versão especificada. Os recursos sem uma versão listada são compatíveis com todas as versões disponíveis do GKE e Anthos.

Como configurar recursos do Ingress

Ao criar um Ingress usando o controlador padrão, você pode escolher o tipo de balanceador de carga HTTP(S) (externo ou interno) com uma anotação no objeto Ingress. Você pode escolher se o GKE cria NEGs zonais ou se usa grupos de instâncias com uma anotação em cada objeto Serviço.

As definições de recursos personalizados (CRDs) do FrontendConfig e do BackendConfig permitem personalizar ainda mais o balanceador de carga. Com essas CRDs, você define recursos adicionais do balanceador de carga de maneira mais estruturada do que as anotações. Os FrontendsConfigs são referenciados em um objeto Ingress e os BackendConfigs são referenciados por um objeto Serviço. As mesmas CRDs podem ser referenciados por vários objetos Serviço ou Ingress para consistência na configuração. As CRDs do FrontendConfig e do BackendConfig compartilham o mesmo ciclo de vida dos recursos Ingress e Serviço correspondentes e, em geral, são implantados juntos.

Veja uma ilustração no diagrama abaixo:

  • Uma anotação em um objeto Ingress ou MultiClusterIngress refere-se às CRDs do FrontendConfig. As CRDs do FrontendConfig referem-se a uma política de SSL do Google Cloud.

  • Uma anotação em um objeto Serviço ou MultiClusterService refere-se às CRDs BackendConfig. As CRDs BackendConfig especificam configurações personalizadas para a verificação de integridade do serviço de back-end correspondente.

Visão geral do BackendConfig e do FrontendConfig
Figura: visão geral do BackendConfig e do FrontendConfig

Como associar o FrontendConfig ao Ingress

As CRDs do FrontendConfig são referenciadas por uma anotação em um recurso Ingress ou MultiClusterIngress. O FrontendConfig corresponde a todo o recurso Ingress/MultiClusterIngress, conforme mostrado no exemplo a seguir:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    networking.gke.io/v1beta1.FrontendConfig: "frontendconfig"
...

Como associar o BackendConfig ao seu Ingress

As CRDs BackendConfig são referenciadas por uma anotação em um recurso Serviço ou MultiClusterService. O serviço ou o MultiClusterService usa a anotação cloud.google.com/backend-config para especificar o nome do BackendConfig. Quando associado a um Serviço ou MultiClusterService, o BackendConfig pode determinar as configurações do serviço de back-end do Google Cloud. O exemplo a seguir demonstra como anexar um BackendConfig a um Serviço ou MultiClusterService. A chave default significa que todas as portas dentro de Serviço estão associadas ao BackendConfig my-backendconfig quando essas portas de serviço são referenciadas por um Ingress:

1.16-gke.3+

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

Todas as versões compatíveis

apiVersion: v1
kind: Service
metadata:
  annotations:
    beta.cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

Se você precisa de configurações exclusivas do BackendConfig para diferentes portas dentro do mesmo Serviço, é possível associar recursos específicos do BackendConfig a essas portas. A chave ports no exemplo a seguir permite a vinculação explícita de portas:

1.16-gke.3+

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"ports": {
    "port-1":"backendconfig-1",
    "port-2":"backendconfig-2"
    }}'
spec:
  ports:
  - name:service-name-1
    port: 8001
    protocol: TCP
    targetPort: service-port-1
  - name: service-name-2
    port: 8002
    protocol: TCP
    targetPort: service-port-2
...

Todas as versões compatíveis

apiVersion: v1
kind: Service
metadata:
  annotations:
    beta.cloud.google.com/backend-config: '{"ports": {
    "port-1":"backendconfig-1",
    "port-2":"backendconfig-2"
    }}'
spec:
  ports:
  - name: service-name-1
    port: 8001
    protocol: TCP
    targetPort: service-port-1
  - name: service-name-2
    port: 8002
    protocol: TCP
    targetPort: >service-port-2
...

port-1 pode se referir a portas no Serviço por número, com service-port-1, ou por nome, com service-name-1 (compatível apenas com o GKE). Cada porta é mapeada para um serviço de back-end do balanceador de carga do Google Cloud. Isso permite que portas dentro do serviço tenham configurações diferentes.

Como configurar recursos do Ingress por meio de parâmetros do FrontendConfig

A seção a seguir mostra como definir seu FrontendConfig para ativar recursos específicos do Ingress.

Políticas de SSL

As políticas de SSL permitem especificar um conjunto de versões e criptografias TLS que o balanceador de carga usa para encerrar o tráfego HTTPS dos clientes. Primeiro, é necessário criar uma política de SSL fora do GKE. Depois de criá-la, você pode referir-se a ela nas CRDs FrontendConfig.

O campo sslPolicy no FrontendConfig refere-se ao nome de uma política de SSL no mesmo projeto do Google Cloud que o cluster do GKE. Ele anexa a política de SSL ao proxy HTTPS de destino, criado para o balanceador de carga HTTP(S) externo pelo Ingress. O mesmo recurso FrontendConfig e a mesma política SSL podem ser referenciados por vários recursos Ingress. Se uma política SSL referenciada for alterada, a mudança será propagada para os front-ends do Google (GFEs) que alimentam o balanceador de carga HTTP(S) externo criado pelo Ingress.

O manifesto FrontendConfig a seguir ativa uma política de SSL chamada gke-ingress-ssl-policy:

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  sslPolicy: gke-ingress-ssl-policy

Como configurar recursos do Ingress por meio de parâmetros BackendConfig

As seções a seguir mostram como configurar o BackendConfig para ativar recursos específicos do Ingress. As alterações em um recurso BackendConfig são constantemente reconciliadas. Portanto, você não precisa excluir e recriar seu Ingress para ver se as alterações do BackendConfig são refletidas.

Para informações sobre as limitações do BackendConfig, consulte a seção de limitações.

Tempo limite do serviço de back-end

É possível usar um BackendConfig para definir um tempo limite do serviço de back-end em segundos. Se você não especificar um valor, o valor padrão será de 30 segundos.

O manifesto BackendConfig a seguir especifica um tempo limite de 40 segundos:

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40

Cloud CDN

É possível ativar o Cloud CDN usando um BackendConfig.

O manifesto BackendConfig a seguir mostra todos os campos disponíveis ao ativar o Cloud CDN:

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: cdnEnabled
    cachePolicy:
      includeHost: includeHost
      includeProtocol:includeProtocol
      includeQueryString: includeQueryString
      queryStringBlacklist:queryStringBlacklist
      queryStringWhitelist: queryStringWhitelist

Substitua:

  • cdnEnabled: se definido como true, o Cloud CDN estará ativado para este back-end do Ingress.
  • includeHost: se definido como true, as solicitações para hosts diferentes serão armazenadas em cache separadamente.
  • includeProtocol: se definido como true, as solicitações HTTP e HTTPS serão armazenadas em cache separadamente.
  • includeQueryString: se definido como true, os parâmetros da string de consulta serão incluídos na chave de cache de acordo com queryStringBlacklist ou queryStringWhitelist. Se nenhum dos dois estiver configurado, toda a string de consulta será incluída. Se definido como false, toda a string de consulta será excluída da chave de cache.
  • queryStringBlacklist: especifique uma matriz de strings com os nomes dos parâmetros da string de consulta a serem excluídos das chaves de cache. Todos os outros parâmetros são incluídos. Você pode especificar queryStringBlacklist ou queryStringWhitelist, mas não ambos.
  • queryStringWhitelist: especifique uma matriz de strings com os nomes dos parâmetros da string de consulta a serem incluídos nas chaves de cache. Todos os outros parâmetros são excluídos. Você pode queryStringBlacklist ou queryStringWhitelist, mas não ambos.

Expanda a seção a seguir para ver um exemplo que implanta o Cloud CDN por meio do Ingress e depois valida que o conteúdo do aplicativo está sendo armazenado em cache.

Tempo limite de diminuição da conexão

É possível configurar o tempo limite de diminuição da conexão usando um BackendConfig. O tempo limite de diminuição da conexão é o tempo, em segundos, de espera pela redução das conexões. Para a duração especificada do tempo limite, as solicitações atuais do back-end removido têm tempo para serem concluídas. O balanceador de carga não envia novas solicitações para o back-end removido. Após a duração do tempo limite, todas as conexões restantes com o back-end são fechadas. 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 BackendConfig a seguir especifica um tempo limite de diminuição de conexão de 60 segundos:

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  connectionDraining:
    drainingTimeoutSec: 60

Configuração de verificação de integridade personalizada

O GKE usa várias maneiras para configurar as verificações de integridade do balanceador de carga do Google Cloud ao implantar por meio do Ingress. Para saber mais sobre como o Ingress do GKE implanta verificações de integridade, consulte Verificações de integridade do Ingress.

Um método é configurar verificações de integridade explicitamente por meio de um BackendConfig. Se definidos, esses parâmetros substituem as configurações da sondagem de preparo do Kubernetes e os valores padrão da verificação de integridade.

É possível configurar vários serviços do GKE para referenciar o mesmo BackendConfig de um modelo reutilizável. Para os parâmetros healthCheck, uma verificação de integridade exclusiva do Google Cloud é criada para cada serviço de back-end correspondente a cada serviço do GKE.

O manifesto BackendConfig a seguir mostra todos os campos disponíveis ao se configurar uma verificação de integridade do BackendConfig:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  healthCheck:
    checkIntervalSec: interval
    timeoutSec: timeout
    healthyThreshold: health-threshold
    unhealthyThreshold: unhealthy-threshold
    type: protocol
    requestPath: path
    port: port

Substitua:

  • interval: especifique o check-interval, em segundos, para cada sonda de verificação de integridade. Esse é o momento entre o início da verificação de uma sonda e o começo da próxima verificação. Se você omitir esse parâmetro, será usado o padrão de cinco segundos do Google Cloud. Para mais detalhes sobre a implementação, consulte Várias sondagens e frequência.
  • timeout: especifique o tempo que o Google Cloud aguarda por uma resposta a uma sondagem. O valor de timeout precisa ser menor ou igual ao valor de interval. As unidades são informadas em segundos. Cada sondagem requer que um código de resposta HTTP 200 (OK) seja entregue antes do tempo limite da sondagem.
  • health-threshold e unhealthy-threshold: especifique o número de tentativas de conexão sequencial que precisam ser bem-sucedidas ou reprovadas em pelo menos uma sondagem para alterar o estado de integridade de íntegra para não íntegra ou vice-versa. Se você omitir um desses parâmetros, o Google Cloud usará o valor padrão 2.
  • protocol: especifique um protocolo usado pelos sistemas de sondagem para verificação de integridade. O BackendConfig só permite a criação de verificações de integridade usando os protocolos HTTP, HTTPS ou HTTP2. Para mais informações, consulte os critérios de sucesso para HTTP, HTTPS e HTTP/2. Não é possível omitir esse parâmetro.
  • path: para verificações de integridade HTTP, HTTPS ou HTTP2, especifique o request-path ao qual o sistema de sondagem precisa se conectar. Se você omitir esse parâmetro, o Google Cloud usará o padrão /.
  • port: especifica a porta usando um número de porta. Se você omitir esse parâmetro, o Google Cloud usará o padrão 80. Ao usar o balanceamento de carga nativo de contêiner, os sistemas de sondagem se conectam ao endereço IP de um pod de exibição. Caso contrário, as sondagens de verificação de integridade se conectam ao endereço IP do nó em que o pod de veiculação está sendo executado.

Política de segurança do Google Cloud Armor

As políticas de segurança do Google Cloud Armor ajudam a proteger seus aplicativos com balanceamento de carga contra ataques baseados na Web. Depois de configurar uma política de segurança do Google Cloud Armor, você pode referenciá-la usando um BackendConfig.

Adicione o nome da política de segurança ao BackendConfig. O manifesto BackendConfig a seguir especifica uma política de segurança chamada example-security-policy:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  namespace: cloud-armor-how-to
  name: my-backendconfig
spec:
  securityPolicy:
    name: "example-security-policy"

Geração de registros de acesso HTTP

O Ingress pode registrar todas as solicitações HTTP de clientes no Cloud Logging. É possível ativar e desativar a geração de registros de acesso usando BackendConfig, além de definir a taxa de amostragem da geração de registros de acesso.

Para configurar a geração de registros de acesso, use o campo logging no BackendConfig. Se logging for omitido, a geração de registros de acesso adotará o comportamento padrão. Isso depende da versão do GKE. A geração de registros de acesso é padronizada como "ativada" em todas as versões anteriores ao GKE 1.18, mas é configurável a partir da versão 1.16.8-gke.10.

É possível configurar os seguintes campos:

  • enable: se for definido como true, a geração de registros de acesso será ativada para este Ingress e os registros estarão disponíveis no Cloud Logging. Caso contrário, a geração de registros de acesso será desativada para este Ingress.
  • sampleRate: especifique um valor de 0,0 a 1,0, em que 0,0 significa que nenhum pacote é registrado e 1,0 significa que 100% dos pacotes são registrados. Este campo só é relevante se enable estiver definido como true. sampleRate é um campo opcional, mas se estiver configurado, enable: true também precisará ser definido. Caso contrário, ele será interpretado como enable: false.

O manifesto BackendConfig a seguir ativa a geração de registros de acesso e define a taxa de amostra como 50% das solicitações HTTP para um determinado recurso Ingress:

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  logging:
    enable: true
    sampleRate: 0.5

Identity-Aware Proxy

Se quiser configurar o BackendConfig para Identity-Aware Proxy IAP, você precisa especificar os valores enabled e secretName para seu bloco iap no BackendConfig. Para especificar esses valores, verifique se você tem a permissão compute.backendServices.update.

O manifesto BackendConfig a seguir ativa o Identity-Aware Proxy:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name:  my-backendconfig
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: my-secret

Para instruções completas, consulte Como ativar o IAP para o GKE na documentação do IAP.

Afinidade da sessão

É possível usar um BackendConfig para definir a afinidade da sessão como IP do cliente ou cookie gerado.

Afinidade de IP do cliente

Se quiser usar um BackendConfig para definir a afinidade de IP do cliente, defina affinityType como "CLIENT_IP". Veja no exemplo a seguir:

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "CLIENT_IP"

Se quiser usar um BackendConfig para configurar a afinidade de cookie gerado, defina affinityType como GENERATED_COOKIE no manifesto do BackendConfig. Também é possível usar affinityCookieTtlSec para definir o período de tempo que o cookie permanece ativo.

O seguinte manifesto define o tipo de afinidade para cookie gerado e dá aos cookies um TTL de 50 segundos:

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "GENERATED_COOKIE"
    affinityCookieTtlSec: 50

Cabeçalhos de solicitação definidos pelo usuário

É possível usar um BackendConfig para configurar cabeçalhos de solicitação definidos pelo usuário. O balanceador de carga adiciona os cabeçalhos especificados às solicitações que ele encaminha para os back-ends.

Para ativá-los, especifique uma lista de cabeçalhos na propriedade customRequestHeaders do recurso BackendConfig. Especifique cada cabeçalho como uma string header-name:header-value.

O manifesto BackendConfig a seguir adiciona três cabeçalhos de solicitação:

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  customRequestHeaders:
    headers:
    - "X-Client-Region:{client_region}"
    - "X-Client-City:{client_city}"
    - "X-Client-CityLatLong:{client_city_lat_long}"

Exercício: como definir tempos limite de entrada usando um serviço de back-end

O exercício a seguir mostra as etapas necessárias para configurar tempos limite e diminuição da conexão usando um Ingress com um recurso BackendConfig.

Para configurar as propriedades de back-end de um Ingress, conclua as tarefas a seguir:

  1. Crie uma implantação.
  2. Crie um BackendConfig.
  3. Crie um serviço e associe uma das respectivas portas ao BackendConfig.
  4. Crie um objeto Ingress e associe-o ao par (serviço, porta).
  5. Valide as propriedades do serviço de back-end.
  6. Limpeza.

Como criar uma implantação

Antes de criar um BackendConfig e um serviço, você precisa criar uma implantação.

O exemplo de manifesto a seguir é para uma implantação chamada my-deployment.yaml:

# my-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      purpose: bsc-config-demo
  replicas: 2
  template:
    metadata:
      labels:
        purpose: bsc-config-demo
    spec:
      containers:
      - name: hello-app-container
        image: gcr.io/google-samples/hello-app:1.0

Crie a implantação executando o seguinte comando:

kubectl apply -f my-deployment.yaml

Como criar um BackendConfig

Use o BackendConfig para especificar os recursos do Ingress que você quer usar.

Esse manifesto BackendConfig, chamado my-backendconfig.yaml, especifica:

  • um tempo limite de 40 segundos;
  • um tempo limite de drenagem de conexão de 60 segundos.
# my-backendconfig.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40
  connectionDraining:
    drainingTimeoutSec: 60

Para a lista completa de recursos que podem ser definidos usando um BackendConfig, consulte a seção BackendConfig da tabela de recursos.

Crie o BackendConfig executando o seguinte comando:

kubectl apply -f my-backendconfig.yaml

Crie um serviço

Um BackendConfig corresponde a uma única combinação Service-Port, mesmo que um serviço tenha várias portas. Cada porta pode ser associada a uma única CRD BackendConfig. Se uma porta do serviço for referenciada por um Ingress, e se ela estiver associada a um BackendConfig, o serviço de back-end de balanceamento de carga HTTP(S) fará parte da configuração a partir do BackendConfig.

Veja a seguir um exemplo de manifesto de serviço chamado my-service.yaml:

# my-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    purpose: bsc-config-demo
  annotations:
    cloud.google.com/backend-config: '{"ports": {"80":"my-backendconfig"}}'
    cloud.google.com/neg: '{"ingress": true}'
spec:
  type: ClusterIP
  selector:
    purpose: bsc-config-demo
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080

A anotação cloud.google.com/backend-config especifica um mapeamento entre portas e objetos BackendConfig. Em my-service.yaml:

  • Qualquer pod que tenha o rótulo purpose: bsc-config-demo é um membro do serviço.
  • A porta TCP 80 do Serviço está associada a um BackendConfig chamado my-backendconfig. A anotação cloud.google.com/backend-config especifica isso.
  • Uma solicitação enviada para a porta 80 do serviço é encaminhada para um dos pods de membro na porta 8080.

Para criar o Serviço, execute este comando:

kubectl apply -f my-service.yaml

Como criar um Ingress

Veja a seguir um manifesto de entrada chamado my-ingress.yaml. Neste exemplo, as solicitações recebidas são roteadas para a porta 80 do serviço chamada my-service.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: my-service
          servicePort: 80

Para criar o Ingress, execute o seguinte comando:

kubectl apply -f my-ingress.yaml

Aguarde alguns minutos até que o controlador do Ingress configure um balanceamento de carga HTTP(S) e um serviço de back-end associado. Quando isso for concluído, você configurou o Ingress para usar um tempo limite de 40 segundos e um tempo limite de diminuição de conexão de 60 segundos.

Como validar as propriedades do serviço de back-end

Você pode validar se as configurações do balanceador de carga foram aplicadas corretamente por meio do BackendConfig. Para fazer isso, identifique o serviço de back-end que o Ingress implantou e inspecione as configurações para confirmar se eles correspondem aos manifestos de implantação.

Primeiro, descreva o recurso my-ingress e filtre a anotação que lista os serviços de back-end associados ao Ingress. Exemplo:

kubectl describe ingress my-ingress | grep ingress.kubernetes.io/backends

A resposta será assim:

ingress.kubernetes.io/backends: '{"k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY","k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY"}

A saída fornece informações sobre os serviços de back-end. Por exemplo, essa anotação contém dois serviços de back-end:

  • "k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY" fornece informações sobre o serviço de back-end associado ao serviço my-service do Kubernetes.
    • k8s1-27fde173 é um hash usado para descrever o cluster;
    • default é o namespace do Kubernetes;
    • HEALTHY indica que o back-end está íntegro;
  • "k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY" fornece informações sobre o serviço de back-end associado ao back-end padrão (Servidor 404);
    • k8s1-27fde173 é um hash usado para descrever o cluster;
    • kube-system é o namespace;
    • default-http-backend é o nome do serviço do Kubernetes;
    • 80 é a porta do host;
    • HEALTHY indica que o back-end está íntegro.

Em seguida, inspecione o serviço de back-end associado a my-service usando gcloud. Filtre por "drainingTimeoutSec" e "timeoutSec" para confirmar se eles foram definidos no plano de controle do balanceador de carga do Google Cloud. Exemplo:

# Optionally, set a variable
export BES=k8s1-27fde173-default-my-service-80-8d4ca500

# Filter for drainingTimeoutSec and timeoutSec
gcloud compute backend-services describe ${BES} --global | grep -e "drainingTimeoutSec" -e "timeoutSec"

Saída:

  drainingTimeoutSec: 60
  timeoutSec: 40

Ver drainingTimeoutSec e timeoutSec na saída confirma que os valores foram definidos corretamente por meio do BackendConfig.

Limpar

Para evitar cobranças indesejadas na sua conta, exclua os objetos do Kubernetes que você criou para este exercício:

kubectl delete ingress my-ingress
kubectl delete service my-service
kubectl delete backendconfig my-backendconfig
kubectl delete deployment my-deployment

Limitações do BackendConfig

O BackendConfigs tem as seguintes limitações:

  • Um par (serviço, port) pode consumir apenas um BackendConfig, mesmo que vários objetos Ingress façam referência ao (serviço, port). Isso significa que todos os objetos Entrada que se referem ao mesmo serviço ou porta precisam usar a mesma configuração para o Google Cloud Armor, o IAP e o Cloud CDN.

  • O IAP e o Cloud CDN não podem ser ativados para o mesmo serviço de back-end de balanceamento de carga HTTP(S). Isso significa que o IAP e o Cloud CDN não podem ser configurados no mesmo BackendConfig.

  • Você precisa usar o kubectl 1.7 ou posterior para interagir com o BackendConfig.

Como remover a configuração especificada em um front-end ou BackendConfig

Para revogar um recurso do Ingress, desative explicitamente a configuração do recurso nas CRDs do FrontendConfig ou BackendConfig. O controlador do Ingress reconcilia apenas as configurações especificadas nessas CRDs.

Para limpar ou desativar uma configuração ativada anteriormente, defina o valor do campo como uma string vazia ("") ou um valor booleano false, dependendo do tipo de campo.

O manifesto BackendConfig a seguir desativa uma política de segurança do Google Cloud Armor e o Cloud CDN:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: false
  securityPolicy:
    name: ""

Como excluir um FrontendConfig ou BackendConfig

FrontendConfig

Para excluir um FrontendConfig, siga estas etapas:

  1. Remova o nome do front-end da anotação networking.gke.io/v1beta1.FrontendConfig no manifesto do Ingress.

  2. Aplique o manifesto do Ingress alterado ao cluster. Por exemplo, use kubectl apply.

  3. Exclua o FrontendConfig. Por exemplo, use kubectl delete frontendconfig config my-frontendconfig.

BackendConfig

Para excluir um BackedConfig, siga estas etapas:

  1. Remova o nome do BackendConfig da anotação cloud.google.com/backend-config no manifesto Serviço.

  2. Aplique o manifesto Serviço alterado ao cluster. Por exemplo, use kubectl apply.

  3. Exclua o BackendConfig. Por exemplo, use kubectl delete backendconfig my-backendconfig.

Resolver problemas

BackendConfig não encontrado

Este erro ocorre quando um BackendConfig para uma porta de serviço é especificado na anotação do serviço, mas o recurso BackendConfig real não é encontrado. Isso pode ocorrer se você não criou o recurso BackendConfig, se ele foi criado no namespace errado ou se digitou incorretamente a referência na anotação Serviço.

Para avaliar um evento do Kubernetes, execute o seguinte comando:

kubectl get event

O seguinte tipo de saída indica que seu BackendConfig não foi encontrado:

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: error getting BackendConfig for port 80 on service "default/my-service":
no BackendConfig for service port exists

Política de segurança não encontrada

Depois que o objeto de Entrada for criado, se a política de segurança não estiver adequadamente associada ao serviço de balanceador de carga, avalie o evento do Kubernetes para ver se há um erro de configuração. Se o BackendConfig especificar uma política inexistente, um evento de alerta será emitido periodicamente. Para corrigir esse problema, especifique a política de segurança correta, por nome, no BackendConfig.

Para avaliar um evento do Kubernetes, execute o seguinte comando:

kubectl get event

O seguinte tipo de saída indica que sua política de segurança não foi encontrada:

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: The given security policy "my-policy" does not exist.

A seguir