Depurando o Ingress

Nuvem Privada Virtual Infraestrutura Clássica

Você expôs seu app criando um recurso do Ingress para seu app em seu cluster. No entanto, quando você tenta se conectar ao seu app por meio do subdomínio do Ingress ou dos endereços IP do ALB, a conexão falha ou atinge o tempo limite.

As etapas nas seções a seguir podem ajudar a depurar sua configuração do Ingress.

Antes de começar, certifique-se de ter as políticas de acesso do IBM Cloud IAM a seguir para o IBM Cloud Kubernetes Service: - A função de acesso da plataforma Editor ou Administrador para o cluster. - A função de acesso do serviço Gravador ou Gerenciador

Etapa 1: verifique a implementação do app

Antes de debug Ingress, primeiro confira Debugging app implemenments.

Os problemas do Ingress são frequentemente causados por problemas subjacentes em sua implementação de app ou no serviço ClusterIP que expõe seu app. Por exemplo, seu rótulo de app e seletor de serviço podem não corresponder ou suas portas de destino de app e de serviço podem não corresponder.

Etapa 2: Verifique as mensagens de erro em sua implementação de entrada e os logs pod ALB

Inicie verificando se há mensagens de erro nos eventos de implementação do recurso Ingress e nos logs do pod do ALB. Essas mensagens de erro podem ajudá-lo a identificar as causas principais das falhas e a depurar melhor sua configuração do Ingress nas seções a seguir.

Verifique a sua implementação de recursos do Ingress e procure por avisos ou mensagens de erro.

kubectl describe ingress <myingress>

Na seção Events da saída, é possível que você veja mensagens de aviso sobre valores inválidos em seu recurso Ingress ou em certas anotações usadas. Para ALBs baseadas em Introdução-NGINX, consulte Documentação sobre a configuração de recursos do Ingress ou documentação sobre anotações. Para ALBs baseados no Traefik, consulte a documentação sobre configuração do recurso Ingress ou a documentação sobre configuração do Ingress Controller.

NAME:             myingress
Namespace:        default
Address:          169.xx.xxx.xxx,169.xx.xxx.xxx
Default backend:  <default>
Rules:
    Host                                             Path  Backends
    ----                                             ----  --------
    mycluster-<hash>-0000.us-south.containers.appdomain.cloud
    /tea      myservice1:80 (<none>)
    /coffee   myservice2:80 (<none>)
Annotations:                                         <none>
Events:
  Type    Reason  Age                From                      Message
  ----    ------  ----               ----                      -------
  Normal  Sync    26s (x8 over 19m)  nginx-ingress-controller  Scheduled for sync
  Normal  Sync    26s (x8 over 19m)  nginx-ingress-controller  Scheduled for sync

Verifique o status de seus pods do ALB.

Obtenha os pods do ALB que estão em execução em seu cluster.

    kubectl get pods -n kube-system | grep alb
    ```
2. Certifique-se de que todos os pods estejam em execução verificando a coluna **STATUS**.

3. Se um pod não tiver um status `Running`, será possível desativar e reativar o ALB. Nos comandos a seguir, substitua `<ALB_ID>` pelo ID do ALB do pod. Por exemplo, se o pod que não está em execução tiver o nome `public-crb2f60e9735254ac8b20b9c1e38b649a5-alb1-5d6d86fbbc-kxj6z`, o ID do ALB será `public-crb2f60e9735254ac8b20b9c1e38b649a5-alb1`.
    * Clusters clássicos:
        ```sh {: pre}
        ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID>
        ```
        ```sh {: pre}
        ibmcloud ks ingress alb enable classic --alb <ALB_ID> -c <cluster_name_or_ID>
        ```
    * Clusters de VPC:
        ```sh {: pre}
        ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID>
        ```
        ```sh {: pre}
        ibmcloud ks ingress alb enable vpc-gen2 --alb <ALB_ID> -c <cluster_name_or_ID>
        ```

Verifique os logs para o seu ALB.

Obtenha os IDs dos pods do ALB que estão em execução em seu cluster.

    kubectl get pods -n kube-system | grep alb
    ```
1. Para ALBs baseados no Ingress ( NGINX ), obtenha os logs do contêiner `nginx-ingress` em cada pod do ALB. Para ALBs baseados no Traefik, obtenha os logs do contêiner `traefik` em cada pod do ALB.
```sh {: pre}
    kubectl logs <ingress_pod_ID> <nginx-ingress/traefik> -n kube-system
    ```
1. Procure mensagens de erro nos logs do ALB.

Etapa 3: Executar ping do subdomínio ALB e endereços IP públicos

Verifique a disponibilidade de seu subdomínio do Ingress e endereços IP públicos do ALB. Além disso, certifique-se de que o IBM NS1 possa acessar seus ALBs para realizar verificações de integridade.

Obtenha os endereços IP (clássico) ou o nome do host (VPC) nos quais seus ALBs públicos estão atendendo.

ibmcloud ks ingress alb ls --cluster <cluster_name_or_ID>

Saída de exemplo para um cluster multizona clássico com os nós do trabalhador em dal10 e dal13:

ALB ID                                            Enabled   Status     Type      ALB IP          Zone    Build                          ALB VLAN ID   NLB Version
private-cr24a9f2caf6554648836337d240064935-alb1   false     disabled   private   -               dal13   ingress:1.1.2_2507_iks   2294021       -
private-cr24a9f2caf6554648836337d240064935-alb2   false     disabled   private   -               dal10   ingress:1.1.2_2507_iks   2234947       -
public-cr24a9f2caf6554648836337d240064935-alb1    true      enabled    public    169.62.196.238  dal13   ingress:1.1.2_2507_iks   2294019       -
public-cr24a9f2caf6554648836337d240064935-alb2    true      enabled    public    169.46.52.222   dal10   ingress:1.1.2_2507_iks   2234945       -

Se um ALB público não tiver um endereço IP (clássico) ou um nome do host (VPC), consulte O ALB do Ingress não é implementado em uma zona.

Verifique se os seus endereços IP do ALB podem ser acessados pela verificação de funcionamento do ALB.
- Clássico: Se você utilizar políticas de rede pré-DNAT do Calico ou outro firewall personalizado para bloquear o tráfego de entrada no seu cluster, será necessário permitir o acesso de entrada nas portas 80 ou 443 a partir do plano de controle Kubernetes e dos endereços IP IBM, NS1 e IPv4 para os endereços IP dos seus ALBs, de modo que o plano de controle Kubernetes possa verificar a integridade dos seus ALBs. Por exemplo, se você utilizar políticas do tipo “ Calico ”, crie uma política de pré-DNAT do tipo “ Calico ” para permitir o acesso de entrada aos endereços IP do seu ALB a partir dos endereços IP de origem IBM e NS1 na porta 80, bem como das sub-redes do plano de controle da região onde seu cluster está localizado.
- VPC: Se você tiver um grupo de segurança personalizado na VPC LBaaS ( LoadBalancer-as-a-Service ) para as instâncias de entrada do cluster, certifique-se de que as regras do grupo de segurança permitam o tráfego necessário para a verificação de integridade proveniente dos endereços IP do plano de controle Kubernetes para a porta 443.

Verifique o funcionamento de seus IPs do ALB (clássico) ou do nome do host (VPC).

Execute um ping no endereço IP (clássico) ou no nome de host (VPC) de cada ALB público para garantir que cada ALB consiga receber pacotes com sucesso. Se você estiver usando ALBs privados, será possível efetuar ping de seus endereços IP (clássico) ou de seu nome do host (VPC) somente na rede privada.

    ping <ALB_IP>
    ```
    * Se a CLI retornar um tempo limite e você tiver um firewall personalizado que está protegendo os nós do trabalhador, certifique-se de permitir o ICMP em seu firewall.
    * Se você não tiver um firewall ou seu firewall não bloquear os pings e os pings ainda atingirem o tempo limite, [verifique o status de seus pods do ALB](#check_pods).

* Somente clusters multizona: é possível usar a verificação de funcionamento do MZLB para determinar o status de seus IPs do ALB (clássico) ou de seu nome do host (VPC). O comando HTTP cURL a seguir usa o host `albhealth`, que é configurado pelo IBM Cloud Kubernetes Service para retornar o status `healthy` ou `unhealthy` para um IP do ALB.
```sh {: pre}
    curl -X GET http://<ALB_IP>/ -H "Host: albhealth.<ingress_subdomain>"
    ```
    Exemplo de comando:
    ```sh {: pre}
    curl -X GET http://169.62.196.238/ -H "Host: albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud"
    ```
    Exemplo de saída
    ```sh {: screen}
    healthy
    ```
    Se um ou mais IPs retornarem `unhealthy`, [verifique o status de seus pods do ALB](#check_pods).

Obtenha o subdomínio do Ingresso fornecido pela IBM.

ibmcloud ks cluster get --cluster <cluster_name_or_ID> | grep Ingress

Exemplo de saída

Ingress Subdomain:      mycluster-<hash>-0000.us-south.containers.appdomain.cloud
Ingress Secret:         mycluster-<hash>-0000

Assegure-se de que os IPs (clássico) ou o nome do host (VPC) para cada ALB público que você obteve na etapa 1 desta seção sejam registrados com o subdomínio do Ingress fornecido pela IBM de seu cluster. Por exemplo, em um cluster multizona clássico, o IP do ALB público em cada zona na qual você tem nós do trabalhador deve ser registrado no mesmo subdomínio.
```
kubectl get ingress -o wide
```
Exemplo de saída
```
NAME                HOSTS                                                    ADDRESS                        PORTS     AGE
myingressresource   mycluster-<hash>-0000.us-south.containers.appdomain.cloud      169.46.52.222,169.62.196.238   80        1h
```

Etapa 4: Verificar os mapeamentos de domínio e a configuração do recurso Ingress

Se você usar um domínio customizado, verifique se usou seu provedor DNS para mapear o domínio customizado para o subdomínio fornecido pela IBM ou o endereço IP público do ALB. Observe que usar um CNAME é preferencial porque a IBM fornece verificações automáticas de funcionamento no subdomínio IBM e remove os IPs com falha da resposta de DNS.

CNAME de subdomínio fornecido pela IBM: verifique se o seu domínio customizado é mapeado para o subdomínio fornecido pela IBM do cluster no registro de Nome canônico (CNAME).

    host www.my-domain.com
    ```
    Exemplo de saída
    ```sh {: screen}
    www.my-domain.com is an alias for mycluster-<hash>-0000.us-south.containers.appdomain.cloud
    mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.46.52.222
    mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.62.196.238
    ```
* **Registro A do endereço IP público**: verifique se o seu domínio customizado é mapeado para o endereço IP público móvel do ALB no registro A. Os IPs devem corresponder aos IPs públicos do ALB que você obteve na etapa 1 da [seção anterior](#ping).
```sh {: pre}
    host www.my-domain.com
    ```
    Exemplo de saída
    ```sh {: screen}
    www.my-domain.com has address 169.46.52.222
    www.my-domain.com has address 169.62.196.238
    ```

Verifique os arquivos de configuração do recurso Ingress para seu cluster.
```
kubectl get ingress -o yaml
```
1. Assegure-se de definir um host em apenas um recurso do Ingress. Se um host for definido em diversos recursos do Ingress, o ALB poderá não encaminhar o tráfego corretamente e poderá haver erros.
2. Verifique se o subdomínio e o certificado TLS estão corretos. Para localizar o certificado TLS e o subdomínio do Ingress fornecido pela IBM, execute ibmcloud ks cluster get --cluster <cluster_name_or_ID>.
3. Certifique-se de que seu app atenda no mesmo caminho configurado na seção de caminho de seu Ingresso. Se seu app estiver configurado para atender no caminho raiz, use / como o caminho. Se o tráfego recebido nesse caminho precisar ser redirecionado para um caminho diferente, no qual seu aplicativo esteja escutando, use a anotação “rewrite paths” do Ingress — NGINX. Para o Traefik, use o middleware “ ReplacePath ”.
4. Edite seu YAML de configuração de recurso, conforme necessário. Quando você fecha o editor, suas mudanças são salvas e aplicadas automaticamente.
```
    kubectl edit ingress <myingressresource>
    ```
```

Removendo um ALB do DNS para depuração no Classic

Caso não seja possível acessar seu app por meio de um IP específico do ALB, será possível remover temporariamente o ALB da produção desativando seu registro de DNS. Em seguida, será possível usar o endereço IP do ALB para executar testes de depuração nesse ALB.

Por exemplo, vamos supor que você tenha um cluster de diversas zonas em 2 zonas e os 2 ALBs públicos tenham endereços IP 169.46.52.222 e 169.62.196.238. Embora a verificação de funcionamento esteja retornando como funcional para o ALB da segunda zona, seu app não pode ser atingido diretamente por meio dele. Você decide remover o endereço IP do ALB, 169.62.196.238, da produção para depuração. O IP do ALB da primeira zona, 169.46.52.222, é registrado com seu domínio e continua a rotear o tráfego enquanto você depura o ALB da segunda zona.

Use o comando a seguir para remover o endereço IP do nome de domínio. O comando de atualização substitui totalmente os endereços IP registrados; portanto, você deve definir apenas os endereços IP ativos no comando:
```
ibmcloud ks ingress domain update --cluster <cluster_name> --domain <cluster domain> --ip 169.46.52.222
```
Verifique se o endereço IP do ALB foi removido do registro DNS do seu domínio, consultando o servidor IBM NS1. Observe que o registro de DNS pode levar alguns minutos para ser atualizado.
```
host mycluster-<hash>-0000.us-south.containers.appdomain.cloud dns1.p02.nsone.net
```
Saída de exemplo que confirma que somente o IP do ALB funcional, 169.46.52.222, permanece no registro de DNS e que o IP ALB não funcional, 169.62.196.238, foi removido:
```
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.46.52.222
```
Agora que o IP do ALB foi removido da produção, é possível executar testes de depuração com relação ao seu app por meio dele. Para testar a comunicação com seu app por meio desse IP, é possível executar o comando cURL a seguir, substituindo os valores de exemplo por seus próprios valores:
```
curl -X GET --resolve mycluster-<hash>-0000.us-south.containers.appdomain.cloud:443:169.62.196.238 https://mycluster-<hash>-0000.us-south.containers.appdomain.cloud/
```
- Se tudo estiver configurado corretamente, você obterá de volta a resposta esperada de seu app.
- Se você obtiver um erro em resposta, poderá haver um erro em seu app ou em uma configuração que se aplique somente a esse ALB específico. Verifique o código do seu aplicativo, os arquivos de configuração de recursos do Ingress ( **Ingress- NGINX **) ou a documentação de configuração do Ingress Controller para o Traefik, bem como quaisquer outras configurações que você tenha aplicado exclusivamente a este ALB.

Após concluir a depuração, restaure o registro DNS do ALB usando o seguinte comando:

ibmcloud ks ingress domain update --cluster <cluster_name> --domain <cluster domain> --ip 169.46.52.222 --ip 169.62.196.238

Verifique se o endereço IP do ALB foi restaurado no registro DNS do seu domínio, consultando o servidor IBM NS1. Observe que o registro de DNS pode levar alguns minutos para ser atualizado.

host mycluster-<hash>-0000.us-south.containers.appdomain.cloud dns1.p02.nsone.net

Exemplo de saída

mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.46.52.222
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.62.196.238