Esta página foi traduzida pela API Cloud Translation.

Configurar a entrada para balanceadores de carga de aplicações internos

Autopilot Padrão

Esta página mostra como configurar e usar a entrada para equilibradores de carga de aplicações internos no Google Kubernetes Engine (GKE). A entrada oferece suporte integrado para o balanceamento de carga interno através do controlador de entrada do GKE.

Para saber mais sobre as funcionalidades suportadas para o Ingress para balanceadores de carga de aplicações internos, consulte o artigo Funcionalidades do Ingress. Também pode saber mais sobre como funciona a entrada para balanceadores de carga de aplicações internos em Entrada para balanceadores de carga de aplicações internos.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

Ative a API Google Kubernetes Engine.

Ative a API Google Kubernetes Engine

Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.
Nota: para instalações existentes da CLI gcloud, certifique-se de que define a compute/region propriedade. Se usar principalmente clusters zonais, defina o compute/zone. Ao definir uma localização predefinida, pode evitar erros na CLI gcloud, como os seguintes: One of [--zone, --region] must be supplied: Please specify location. Pode ter de especificar a localização em determinados comandos se a localização do seu cluster for diferente da predefinição que definiu.

Requisitos

A entrada para balanceadores de carga de aplicações internos tem os seguintes requisitos:

O seu cluster tem de usar uma versão do GKE posterior a 1.16.5-gke.10.
O cluster tem de ser nativo de VPC.
O seu cluster tem de ter o suplemento HttpLoadBalancing ativado. Este suplemento está ativado por predefinição. Não o pode desativar.
Tem de usar grupos de pontos finais da rede (NEGs) como back-ends para o seu serviço.

Implementar o Ingress para balanceadores de carga de aplicações internos

Os exercícios seguintes mostram como implementar a entrada para balanceadores de carga de aplicações internos:

Prepare o seu ambiente.
Crie um cluster.
Implemente uma aplicação.
Implemente um serviço.
Implemente o Ingress.
Valide a implementação.
Elimine recursos Ingress.

Prepare o seu ambiente

Antes de poder implementar recursos do equilibrador de carga através da API Kubernetes Ingress, tem de preparar o seu ambiente de rede para que os proxies do equilibrador de carga possam ser implementados numa determinada região.

Crie uma sub-rede só de proxy:

gcloud compute networks subnets create proxy-only-subnet \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=COMPUTE_REGION \
    --network=NETWORK_NAME \
    --range=10.129.0.0/23

Substitua o seguinte:

COMPUTE_REGION: uma região do Compute Engine.
NETWORK_NAME: o nome da rede para a sub-rede.

Para mais informações, consulte o artigo sobre como configurar a sub-rede apenas de proxy.

Crie uma regra de firewall

O controlador de entrada não cria uma regra de firewall para permitir ligações dos proxies do balanceador de carga na sub-rede de proxy. Tem de criar esta regra de firewall manualmente. No entanto, o controlador de entrada cria regras de firewall para permitir a entrada para as Google Cloud verificações de funcionamento.

Crie uma regra de firewall para permitir ligações dos proxies do balanceador de carga na sub-rede só de proxy à porta de escuta do pod:

gcloud compute firewall-rules create allow-proxy-connection \
    --allow=TCP:CONTAINER_PORT \
    --source-ranges=10.129.0.0/23 \
    --network=NETWORK_NAME

Substitua CONTAINER_PORT pelo valor da porta que o agrupamento está a ouvir, como 9376.

Criar um cluster

Nesta secção, cria um cluster nativo da VPC que pode usar com o Ingress para balanceadores de carga de aplicações internos. Pode criar este cluster através da CLI do Google Cloud ou da Google Cloud consola.

gcloud

Crie um cluster na mesma rede que a sub-rede só de proxy:

gcloud container clusters create-auto CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --network=NETWORK_NAME

Substitua o seguinte:

CLUSTER_NAME: um nome para o cluster.
COMPUTE_LOCATION: a localização do Compute Engine para o cluster. Tem de usar a mesma localização que a sub-rede do proxy que criou na secção anterior.

Consola

Na Google Cloud consola, aceda à página Criar um cluster do Autopilot.
Aceda a Crie um cluster do Autopilot
Na secção Noções básicas do cluster, conclua o seguinte:
1. Introduza o Nome do cluster.
2. Para o Tipo de localização, selecione uma região do Compute Engine para o seu cluster. Tem de usar a mesma região que a sub-rede do proxy que criou na secção anterior.
No painel de navegação, clique em Rede.
Na lista Rede, selecione a rede na qual quer criar o cluster. Esta rede tem de estar na mesma rede VPC que a sub-rede do proxy.
Na lista Sub-rede do nó, selecione a sub-rede do proxy que criou
Clique em Criar.

Implementar uma app Web

Nesta secção, cria uma Implementação.

Para criar uma implementação:

Guarde o seguinte manifesto de exemplo como web-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: hostname
  name: hostname-server
spec:
  selector:
    matchLabels:
      app: hostname
  minReadySeconds: 60
  replicas: 3
  template:
    metadata:
      labels:
        app: hostname
    spec:
      containers:
      - image: registry.k8s.io/serve_hostname:v1.4
        name: hostname-server
        ports:
        - containerPort: 9376
          protocol: TCP
      terminationGracePeriodSeconds: 90

Este manifesto descreve uma implementação que deteta um servidor HTTPS na porta 9376. Esta implementação também gere pods para a sua aplicação. Cada Pod executa um contentor de aplicação com um servidor HTTPS que devolve o nome do anfitrião do servidor de aplicações como resposta. O nome de anfitrião predefinido de um Pod é o nome do Pod. O contentor também processa o encerramento controlado.

Aplique o manifesto ao cluster:
```
kubectl apply -f web-deployment.yaml
```

Implementar um serviço como um grupo de pontos finais da rede (NEG)

Nesta secção, cria um recurso Service. O serviço seleciona os contentores de back-end pelas respetivas etiquetas para que o controlador Ingress os possa programar como pontos finais de back-end. A entrada para equilibradores de carga de aplicações internos requer que use NEGs como back-ends. A funcionalidade não suporta grupos de instâncias como back-ends. Uma vez que são necessários back-ends NEG, a seguinte anotação NEG é necessária quando implementa serviços expostos através do Ingress:

annotations:
  cloud.google.com/neg: '{"ingress": true}'

O seu serviço é automaticamente anotado com cloud.google.com/neg: '{"ingress": true}' quando todas as seguintes condições forem verdadeiras:

Está a usar clusters nativos de VPC.
Não está a usar uma VPC partilhada.
Não está a usar a Política da Rede do GKE.

A anotação é adicionada automaticamente através de um MutatingWebhookConfiguration com o nome neg-annotation.config.common-webhooks.networking.gke.io. Pode verificar se o elemento MutatingWebhookConfiguration está presente com o seguinte comando:

kubectl get mutatingwebhookconfigurations

A utilização de NEGs permite que o controlador de entrada execute o balanceamento de carga nativo do contentor. O tráfego é equilibrado a partir do proxy de entrada diretamente para o IP do pod, em vez de atravessar o IP do nó ou a rede kube-proxy. Além disso, os portões de prontidão dos pods são implementados para determinar o estado dos pods do ponto de vista do balanceador de carga e não apenas as verificações de prontidão e atividade do Kubernetes. Os gates de disponibilidade dos pods garantem que o tráfego não é ignorado durante eventos do ciclo de vida, como o arranque, a perda ou a perda de nós dos pods.

Se não incluir uma anotação NEG, recebe um aviso no objeto Ingress que impede a configuração do Application Load Balancer interno. Também é gerado um evento do Kubernetes no Ingress se a anotação NEG não estiver incluída. A mensagem seguinte é um exemplo da mensagem do evento:

Message
-------
error while evaluating the ingress spec: could not find port "8080" in service "default/no-neg-svc"

Um NEG não é criado até que um Ingress referencie o serviço. O NEG não aparece no Compute Engine até que o Ingress e o respetivo serviço referenciado existam. Os NEGs são um recurso zonal e, para clusters multizonais, é criado um por serviço por zona.

Para criar um serviço:

Guarde o seguinte manifesto de exemplo como web-service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: hostname
  namespace: default
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
spec:
  ports:
  - name: host1
    port: 80
    protocol: TCP
    targetPort: 9376
  selector:
    app: hostname
  type: ClusterIP

Aplique o manifesto ao cluster:
```
kubectl apply -f web-service.yaml
```

Implementar entrada

Nesta secção, cria um recurso Ingress que aciona a implementação de um balanceador de carga do Compute Engine através do controlador Ingress. O Ingress para balanceadores de carga de aplicações internos requer a seguinte anotação:

annotations:
    kubernetes.io/ingress.class: "gce-internal"

Não pode usar o campo ingressClassName para especificar um GKE Ingress. Tem de usar a anotação kubernetes.io/ingress.class. Para mais informações, consulte Comportamento do controlador de entrada do GKE.

Para criar um Ingress:

Guarde o seguinte manifesto de exemplo como internal-ingress.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ilb-demo-ingress
  namespace: default
  annotations:
    kubernetes.io/ingress.class: "gce-internal"
spec:
  defaultBackend:
    service:
      name: hostname
      port:
        number: 80

Aplique o manifesto ao cluster:
```
kubectl apply -f internal-ingress.yaml
```

Validar uma implementação de entrada bem-sucedida

Nesta secção, valida se a implementação foi bem-sucedida.

Pode demorar vários minutos até que o recurso Ingress seja totalmente aprovisionado. Durante este período, o controlador Ingress cria itens como regras de encaminhamento, serviços de back-end, mapas de URLs e NEGs.

Para obter o estado do recurso Ingress que criou na secção anterior, execute o seguinte comando:

kubectl get ingress ilb-demo-ingress

O resultado é semelhante ao seguinte:

NAME               HOSTS    ADDRESS            PORTS     AGE
ilb-demo-ingress   *        10.128.0.58        80        59s

Quando o campo ADDRESS estiver preenchido, o Ingress está pronto. A utilização de um endereço RFC 1918 neste campo indica um IP interno na VPC.

Uma vez que o balanceador de carga de aplicações interno é um balanceador de carga regional, o IP virtual (VIP) só é acessível a partir de um cliente na mesma região e VPC. Depois de obter o VIP do equilibrador de carga, pode usar ferramentas (por exemplo, curl) para emitir chamadas HTTP GET contra o VIP a partir do interior da VPC.

Para emitir uma chamada HTTP GET, conclua os seguintes passos:

Para aceder ao VIP de entrada a partir do interior da VPC, implemente uma VM na mesma região e rede que o cluster:
```
gcloud compute instances create l7-ilb-client \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=NETWORK_NAME \
    --subnet=SUBNET_NAME \
    --zone=COMPUTE_ZONE \
    --tags=allow-ssh
```
Substitua o seguinte:
- SUBNET_NAME: o nome de uma sub-rede na rede.
- COMPUTE_ZONE: uma zona do Compute Engine na região.
Para saber mais sobre como criar instâncias, consulte o artigo Criar e iniciar uma instância de VM.
Para aceder ao VIP interno a partir da VM, use curl:
1. SSH para a VM que criou no passo anterior:
```
gcloud compute ssh l7-ilb-client \
    --zone=COMPUTE_ZONE
```
2. Use curl para aceder ao VIP da aplicação interna:
```
curl 10.128.0.58
hostname-server-6696cf5fc8-z4788
```
  A resposta HTTP bem-sucedida e o nome do anfitrião de um dos contentores de back-end indicam que o caminho completo do balanceamento de carga está a funcionar corretamente.

Eliminar recursos Ingress

A remoção de recursos de entrada e serviço também remove os recursos do balanceador de carga do Compute Engine associados aos mesmos. Para evitar fugas de recursos, certifique-se de que os recursos de entrada são desativados quando já não precisar deles. Também tem de eliminar os recursos de entrada e de serviço antes de eliminar os clusters. Caso contrário, os recursos de equilíbrio de carga do Compute Engine ficam órfãos.

Para remover um Ingress, conclua os seguintes passos:

Elimine o Ingress. Por exemplo, para eliminar o Ingress que criou nesta página, execute o seguinte comando:
```
kubectl delete ingress ilb-demo-ingress
```
A eliminação do Ingress remove as regras de encaminhamento, os serviços de back-end e os mapas de URLs associados a este recurso do Ingress.
Eliminar o serviço. Por exemplo, para eliminar o serviço que criou nesta página, execute o seguinte comando:
```
kubectl delete service hostname
```
A eliminação do serviço remove o NEG associado ao serviço.

Para implementar uma aplicação no GKE e expô-la com um endereço IP com balanceamento de carga privado, consulte o artigo Ingress interno básico.

Endereçamento IP estático

Os recursos de entrada internos suportam o endereçamento IP estático e efémero. Se não for especificado um endereço IP, é automaticamente atribuído um endereço IP disponível da sub-rede do nó do GKE. No entanto, o recurso Ingress não aprovisiona endereços IP da sub-rede apenas de proxy, uma vez que essa sub-rede só é usada para o consumo de proxy interno. Estes endereços IP efémeros são atribuídos ao Ingress apenas para o ciclo de vida do recurso Ingress interno. Se eliminar a entrada e criar uma nova entrada a partir do mesmo ficheiro de manifesto, não tem a garantia de receber o mesmo endereço IP externo.

Se quiser um endereço IP permanente independente do ciclo de vida do recurso Ingress interno, tem de reservar um endereço IP interno estático regional. Em seguida, pode especificar um endereço IP estático através da anotação kubernetes.io/ingress.regional-static-ip-name no recurso Ingress.

O exemplo seguinte mostra como adicionar esta anotação:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.regional-static-ip-name: STATIC_IP_NAME
    kubernetes.io/ingress.class: "gce-internal"

Substitua STATIC_IP_NAME por um nome de IP estático que cumpra os seguintes critérios:

Crie o endereço IP estático antes de implementar o Ingress. Um equilibrador de carga não é implementado até o IP estático existir, e fazer referência a um recurso de endereço IP inexistente não cria um IP estático. Se modificar um Ingress existente para usar um endereço IP estático em vez de um endereço IP efémero, o GKE pode alterar o endereço IP do equilibrador de carga quando o GKE recria a regra de encaminhamento do equilibrador de carga.
O IP estático está reservado no projeto de serviço para um Ingress implementado no projeto de serviço de uma VPC partilhada.
Faça referência ao Google Cloud recurso de endereço IP pelo respetivo nome, em vez do endereço IP.
O endereço IP tem de ser de uma sub-rede na mesma região que o cluster do GKE. Pode usar qualquer sub-rede privada disponível na região (com exceção da sub-rede apenas de proxy). Os diferentes recursos Ingress também podem ter endereços de sub-redes diferentes.

HTTPS entre o cliente e o balanceador de carga

A entrada para o balanceamento de carga interno suporta a publicação de certificados TLS para clientes. Pode publicar certificados TLS através de segredos do Kubernetes ou de certificados SSL regionais partilhados previamente no Google Cloud. Também pode especificar vários certificados por recurso Ingress. A utilização simultânea de HTTPS e HTTP é suportada para o GKE 1.25 e versões posteriores. Para ativar esta funcionalidade, tem de criar um endereço IP estático com PURPOSE=SHARED_LOADBALANCER_VIP e configurá-lo na entrada. Se não for fornecido um endereço IP estático, apenas é permitido tráfego HTTPS e tem de seguir a documentação para desativar o HTTP.

Os passos seguintes detalham como criar um certificado no Google Cloud e, em seguida, publicá-lo através do Ingress para clientes internos para tráfego HTTPS e HTTP:

Crie o certificado regional:
```
gcloud compute ssl-certificates create CERT_NAME \
    --certificate CERT_FILE_PATH \
    --private-key KEY_FILE_PATH \
    --region COMPUTE_REGION
```
Substitua o seguinte:
- CERT_NAME: um nome para o seu certificado à sua escolha.
- CERT_FILE_PATH: o caminho para o ficheiro de certificado local para criar um certificado autogerido. O certificado tem de estar no formato PEM.
- KEY_FILE_PATH: o caminho para um ficheiro de chave privada local. A chave privada tem de estar no formato PEM e usar encriptação RSA ou ECDSA.
- COMPUTE_REGION: uma região do Compute Engine para o seu certificado.
Reserve e aplique um endereço IP estático seguindo o endereçamento IP estático.

Guarde o seguinte manifesto de exemplo como ingress-pre-shared-cert.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ilb-demo-ing
  namespace: default
  annotations:
    ingress.gcp.kubernetes.io/pre-shared-cert: "CERT_NAME"
    kubernetes.io/ingress.regional-static-ip-name: STATIC_IP_NAME
    kubernetes.io/ingress.class: "gce-internal"
spec:
  rules:
  - host: DOMAIN
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: SERVICE_NAME
            port:
              number: 80

Substitua o seguinte:

DOMAIN: o seu domínio.
CERT_NAME: o nome do certificado que criou na secção anterior.
SERVICE_NAME: o nome do seu serviço.

Aplique o manifesto ao cluster:

kubectl apply -f ingress-pre-shared-cert.yaml

HTTPS entre o balanceador de carga e a aplicação

Se a sua aplicação for executada num pod do GKE e puder receber pedidos HTTPS, pode configurar o balanceador de carga para usar HTTPS quando encaminha pedidos para a sua aplicação. Para mais informações, consulte o artigo HTTPS (TLS) entre o balanceador de carga e a sua aplicação.

VPC partilhada

Adicione manualmente a anotação NEG

Se o GKE no qual está a implementar os recursos do Ingress estiver num projeto de serviço de VPC partilhada, os serviços não são automaticamente anotados com a anotação cloud.google.com/neg: '{"ingress": true}' porque o MutatingWebhookConfiguration responsável por injetar a anotação nos serviços não está instalado.

Tem de adicionar a anotação NEG ao manifesto dos serviços que são expostos através do Ingress para equilibradores de carga de aplicações internos.

Regras de firewall da VPC

Se o cluster do GKE no qual está a implementar os recursos do Ingress estiver num projeto de serviço de VPC partilhada e quiser que o plano de controlo do GKE faça a gestão dos recursos da firewall no seu projeto anfitrião, tem de conceder as autorizações do IAM adequadas à conta de serviço do GKE do projeto de serviço no projeto anfitrião, conforme descrito no artigo Gerir recursos da firewall para clusters com VPC partilhada. Isto permite que o controlador de entrada crie regras de firewall para permitir o tráfego de entrada para Google Cloud verificações de funcionamento.

Segue-se um exemplo de um evento que pode estar presente nos registos de recursos de entrada. Este erro ocorre quando o controlador de entrada não consegue criar uma regra de firewall para permitir o tráfego de entrada para as verificações de funcionamento se as autorizações não estiverem configuradas corretamente. Google Cloud

Firewall change required by security admin: `gcloud compute firewall-rules update <RULE_NAME> --description "GCE L7 firewall rule" --allow tcp:<PORT> --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags <TARGET_TAG> --project <HOST_PROJECT>

Se preferir aprovisionar manualmente regras de firewall a partir do projeto anfitrião, pode desativar os eventos firewallXPNError adicionando a anotação networking.gke.io/suppress-firewall-xpn-error: "true" ao recurso de entrada.

Resumo das anotações Ingress internas

As tabelas seguintes mostram as anotações que pode adicionar quando cria recursos de entrada e serviço para a entrada para equilibradores de carga de aplicações internos.

Anotações de entrada

Anotação	Descrição
`kubernetes.io/ingress.class`	Pode definir como `"gce-internal"` para o Ingress interno. Se a classe não for especificada, um recurso Ingress é interpretado por predefinição como um Ingress externo. Para mais informações, consulte o artigo Comportamento do controlador de entrada do GKE.
`kubernetes.io/ingress.allow-http`	Pode permitir o tráfego HTTP entre o cliente e o balanceador de carga HTTP(S). Os valores possíveis são `true` e `false`. O valor predefinido é `true`. Para mais informações, consulte o artigo Desativar HTTP.
`ingress.gcp.kubernetes.io/pre-shared-cert`	Pode carregar certificados e chaves para o seu projeto do Google Cloud . Use esta anotação para fazer referência aos certificados e às chaves. Para mais informações, consulte o artigo Usar vários certificados SSL com balanceadores de carga de aplicações externos.
`networking.gke.io/suppress-firewall-xpn-error`	No GLBC 1.4 e posterior, pode desativar o som do evento `firewallXPNError`. Para equilibradores de carga de entrada, se o Kubernetes não conseguir alterar as regras da firewall devido a autorização insuficiente, é criado um evento `firewallXPNError` a cada vários minutos. Adicione a anotação `networking.gke.io/suppress-firewall-xpn-error: "true"` ao recurso de entrada. O valor predefinido é `false`. Pode remover esta anotação para ativar o som.
`kubernetes.io/ingress.regional-static-ip-name`	Pode especificar um endereço IP estático para aprovisionar o seu recurso Ingress interno. Para mais informações, consulte o artigo Endereçamento IP estático.

Anotações de serviço relacionadas com o Ingress

Anotação	Descrição
`cloud.google.com/backend-config`	Use esta anotação para configurar o serviço de back-end associado a um servicePort. Para mais informações, consulte o artigo Configuração de entrada.
`cloud.google.com/neg`	Use esta anotação para especificar que o equilibrador de carga deve usar grupos de pontos finais de rede. Para mais informações, consulte o artigo Usar o balanceamento de carga nativa do contentor.

Resolução de problemas

Compreender e observar o estado do Ingress envolve normalmente inspecionar os recursos associados. Os tipos de problemas encontrados incluem frequentemente recursos de equilíbrio de carga que não estão a ser criados corretamente, tráfego que não chega aos back-ends ou back-ends que não parecem estar em bom estado de funcionamento.

Seguem-se alguns passos de resolução de problemas comuns:

Verificar se o tráfego do cliente tem origem na mesma região e VPC que o balanceador de carga.
Verificar se os pods e os back-ends estão em bom estado.
Validar o caminho do tráfego para o VIP e para as verificações de estado do Compute Engine para garantir que não está bloqueado por regras de firewall.
Verificar se existem erros nos eventos de recursos de entrada.
Descrever o recurso Ingress para ver o mapeamento para recursos do Compute Engine.
Validar se os recursos de equilíbrio de carga do Compute Engine existem, têm as configurações corretas e não têm erros comunicados.

Filtragem de eventos de entrada

Os seguintes filtros de consulta para erros em todos os eventos de entrada no seu cluster:

kubectl get events --all-namespaces --field-selector involvedObject.kind=Ingress

Também pode filtrar por objetos ou nomes de objetos:

kubectl get events --field-selector involvedObject.kind=Ingress,involvedObject.name=hostname-internal-ingress

No erro seguinte, pode ver que o serviço referenciado pelo Ingress não existe:

LAST SEEN   TYPE      REASON      OBJECT                              MESSAGE
0s          Warning   Translate   ingress/hostname-internal-ingress   error while evaluating the ingress spec: could not find service "default/hostname-invalid"

Inspecionar recursos do balanceador de carga do Compute Engine

O comando seguinte apresenta o resultado completo do recurso Ingress para que possa ver os mapeamentos para os recursos do Compute Engine criados pelo controlador Ingress:

kubectl get ing INGRESS_FILENAME -o yaml

Substitua INGRESS_FILENAME pelo nome do ficheiro do recurso Ingress.

O resultado é semelhante ao seguinte:

apiVersion: v1
items:
- apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    annotations:
      ingress.kubernetes.io/backends: '{"k8s1-241a2b5c-default-hostname-80-29269aa5":"HEALTHY"}'
      ingress.kubernetes.io/forwarding-rule: k8s-fw-default-ilb-demo-ingress--241a2b5c94b353ec
      ingress.kubernetes.io/target-proxy: k8s-tp-default-ilb-demo-ingress--241a2b5c94b353ec
      ingress.kubernetes.io/url-map: k8s-um-default-ilb-demo-ingress--241a2b5c94b353ec
      kubectl.kubernetes.io/last-applied-configuration: |
       {"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"kubernetes.io/ingress.class":"gce-internal"},"name":"ilb-demo-ingress","namespace":"default"},"spec":{"defaultBackend":{"service":{"name":"hostname"},"port":{"number":80}}}}
      kubernetes.io/ingress.class: gce-internal
    creationTimestamp: "2019-10-15T02:16:18Z"
    finalizers:
    - networking.gke.io/ingress-finalizer
    generation: 1
    name: ilb-demo-ingress
    namespace: default
    resourceVersion: "1538072"
    selfLink: /apis/networking.k8s.io/v1/namespaces/default/ingresses/ilb-demo-ingress
    uid: 0ef024fe-6aea-4ee0-85f6-c2578f554975
  spec:
    defaultBackend:
      service:
        name: hostname
        port:
          number: 80
  status:
    loadBalancer:
      ingress:
      - ip: 10.128.0.127
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

As anotações ingress.kubernetes.io/backends listam os backends e o respetivo estado. Certifique-se de que os seus backends estão listados como HEALTHY.

Os recursos do Compute Engine criados pelo Ingress podem ser consultados diretamente para compreender o respetivo estado e configuração. A execução destas consultas também pode ser útil na resolução de problemas.

Para apresentar uma lista de todas as regras de encaminhamento do Compute Engine:

gcloud compute forwarding-rules list

O resultado é semelhante ao seguinte:

NAME                                                        REGION       IP_ADDRESS      IP_PROTOCOL  TARGET
k8s-fw-default-hostname-internal-ingress--42084f6a534c335b  REGION_NAME  10.128.15.225   TCP          REGION_NAME/targetHttpProxies/k8s-tp-default-hostname-internal-ingress--42084f6a534c335b

Para listar o estado de um serviço de back-end, comece por listar os serviços de back-end e faça uma cópia do nome do serviço de back-end que quer inspecionar:

gcloud compute backend-services list

O resultado é semelhante ao seguinte:

NAME                                         BACKENDS                                                                       PROTOCOL
k8s1-42084f6a-default-hostname-80-98cbc1c1   REGION_NAME/networkEndpointGroups/k8s1-42084f6a-default-hostname-80-98cbc1c1 HTTP

Agora, pode usar o nome do serviço de back-end para consultar o respetivo estado:

gcloud compute backend-services get-health k8s1-42084f6a-default-hostname-80-98cbc1c1 \
    --region COMPUTE_REGION

Substitua COMPUTE_REGION pela região do Compute Engine do serviço de back-end.

O resultado é semelhante ao seguinte:

backend: https://www.googleapis.com/compute/v1/projects/user1-243723/zones/ZONE_NAME/networkEndpointGroups/k8s1-42084f6a-default-hostname-80-98cbc1c1
status:
  healthStatus:
  - healthState: HEALTHY

O que se segue?

Saiba mais sobre a entrada do GKE para balanceadores de carga de aplicações externos.
Leia uma vista geral conceptual dos serviços no GKE.
Saiba como criar um balanceador de carga de rede de encaminhamento interno no GKE.
Implemente uma entrada interna básica.

Configurar a entrada para balanceadores de carga de aplicações internos Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Antes de começar

Requisitos

Implementar o Ingress para balanceadores de carga de aplicações internos

Prepare o seu ambiente

Crie uma regra de firewall

Criar um cluster

gcloud

Consola

Implementar uma app Web

Implementar um serviço como um grupo de pontos finais da rede (NEG)

Implementar entrada

Validar uma implementação de entrada bem-sucedida

Eliminar recursos Ingress

Endereçamento IP estático

HTTPS entre o cliente e o balanceador de carga

HTTPS entre o balanceador de carga e a aplicação

VPC partilhada

Adicione manualmente a anotação NEG

Regras de firewall da VPC

Resumo das anotações Ingress internas

Anotações de entrada

Anotações de serviço relacionadas com o Ingress

Resolução de problemas

Filtragem de eventos de entrada

Inspecionar recursos do balanceador de carga do Compute Engine

O que se segue?

Configurar a entrada para balanceadores de carga de aplicações internos