Ative o redirecionamento de health check para aplicações no mesh - Alibaba Cloud Service Mesh: Central de Documentação do Alibaba Cloud

Um sidecar intercepta as requisições que uma aplicação no mesh recebe. Por isso, os health checks HTTP e TCP de uma aplicação com sidecar injetado no Alibaba Cloud Service Mesh (ASM) podem apresentar comportamentos inesperados, como falhas consistentes em health checks HTTP. Ative o redirecionamento de health check para garantir que essas verificações funcionem conforme o esperado.

Informações de contexto

A tabela a seguir descreve os comportamentos inesperados dos health checks HTTP e TCP para aplicações no mesh. Para restaurar o funcionamento correto dessas verificações, adicione uma anotação para ativar o redirecionamento de health check.

Tipo

Descrição

Health checks HTTP

Em um cluster Kubernetes, o kubelet envia as requisições de health check de todos os pods. Após a ativação do modo mutual TLS (mTLS), as aplicações no mesh precisam se comunicar via TLS. Como o kubelet não faz parte do mesh, ele não possui um certificado emitido pelo ASM para as aplicações. Consequentemente, as requisições de health check HTTP são rejeitadas e as verificações falham consistentemente.

Health checks TCP

Para interceptar requisições, o sidecar escuta todas as portas do pod de uma aplicação no mesh. Durante um health check TCP, o kubelet determina o status de integridade da aplicação verificando se há algum processo escutando na porta configurada para o pod da aplicação.

Por esse motivo, o health check sempre terá sucesso desde que um sidecar esteja injetado na aplicação e em execução, independentemente do estado real da aplicação. Por exemplo, se você configurar uma porta incorreta para a aplicação, espera-se que o health check do pod falhe sempre e mantenha o pod no status not-ready, mas a verificação acaba tendo sucesso.

Nota

Caso o modo mTLS não esteja ativado no ASM, é possível usar health checks HTTP nos pods da aplicação sem configurar o redirecionamento de health check.

Por padrão, o grafo de topologia do mesh exibe as chamadas de requisição de health check dos services da aplicação. Em muitos cenários, essas chamadas podem distorcer as estatísticas de tráfego. Ative o redirecionamento de health check para as aplicações no mesh a fim de remover essas chamadas internas de health check das estatísticas.

Como funciona o redirecionamento de health check

Uma anotação no modelo de pod de um workload controla o redirecionamento de health check. Adicione sidecar.istio.io/rewriteAppHTTPProbers: "true" em template.metadata.annotations e aplique o workload. O ASM reescreve os health checks configurados para o contêiner da aplicação como health checks HTTP na porta 15020.

Para aplicações no mesh, a porta 15020 é especial e destinada à observabilidade do mesh. O tráfego enviado para essa porta não é interceptado pelo sidecar e, portanto, não precisa atender aos requisitos do modo TLS. Após a ativação do redirecionamento de health check, o service pilot-agent em execução no contêiner sidecar passa a escutar na porta 15020 e recebe os health checks do kubelet. Com base na configuração de health check presente na variável de ambiente ISTIO_KUBE_APP_PROBERS, o service pilot-agent encaminha as requisições de health check para o contêiner da aplicação. Dessa forma, os health checks HTTP executam conforme o esperado.

No caso de health checks TCP, o redirecionamento no ASM segue o mesmo processo e os reescreve como health checks HTTP na porta 15020. Utilizando a configuração de health check TCP definida na variável de ambiente ISTIO_KUBE_APP_PROBERS, o service pilot-agent sonda a porta de health check TCP configurada para o contêiner da aplicação. Se o health check TCP real falhar, o service pilot-agent retorna o código de status 500 para indicar a falha na verificação.

Pré-requisitos

A aplicação foi adicionada ao ASM e um sidecar foi injetado nos pods da aplicação.
O kubectl está conectado ao cluster que executa a aplicação. Para obter instruções, consulte Obtain the kubeconfig file of a cluster and use kubectl to connect to the cluster.

Ative o redirecionamento de health check HTTP

O exemplo a seguir utiliza uma aplicação Nginx para ativar o redirecionamento de health check HTTP. Após a ativação do modo mTLS, o health check HTTP configurado para a aplicação Nginx falha consistentemente. Em seguida, o redirecionamento de health check é ativado para a aplicação Nginx. Se os eventos do pod não contiverem falhas de health check e o pod estiver no status ready, significa que o redirecionamento de health check HTTP foi ativado com sucesso para a aplicação.

Etapa 1: Ative o modo STRICT mTLS para um namespace

Configure o modo mTLS na página PeerAuthentication da instância ASM desejada no console ASM. O modo mTLS configurado nesta etapa se aplica ao namespace selecionado.

Faça login no console ASM.
No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.
Na página Mesh Management, localize a instância ASM que deseja configurar. Clique em no nome da instância ASM ou clique em Manage na coluna Actions.
Na página de detalhes da instância ASM, escolha Mesh Security Center > PeerAuthentication no painel de navegação à esquerda.
No topo da página PeerAuthentication, selecione um namespace e clique em Configure Global mTLS Mode.
No painel Configure Global mTLS Mode, defina mTLS Mode (Namespace-wide) como STRICT - Strictly Enforce mTLS e clique em Create.

Etapa 2: Implante a aplicação Nginx

Implante a aplicação Nginx.

Crie um arquivo chamado http-liveness.yaml com o conteúdo a seguir.

http-liveness.yaml: configuração inicial

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /index.html
            port: 80
            httpHeaders:
            - name: X-Custom-Header
              value: hello
          initialDelaySeconds: 5
          periodSeconds: 3

Sob o parâmetro readinessProbe, o campo httpGet define um health check HTTP para a aplicação.

Execute o comando a seguir para implantar a aplicação Nginx.
```
kubectl apply -f http-liveness.yaml
```

Verifique o status do health check da aplicação.
1. Execute o comando a seguir para visualizar o nome do pod da aplicação Nginx.
```
kubectl get pod | grep nginx
```
2. Execute o comando a seguir para visualizar os eventos do pod.
```
kubectl describe pod <pod_name>
```
  Saída esperada:
```
Warning  Unhealthy  45s               kubelet            Readiness probe failed: Get "http://172.23.64.22:80/index.html": read tcp 172.23.64.1:54130->172.23.64.22:80: read: connection reset by peer
```
  A saída mostra que o health check HTTP do pod falhou, o que mantém o pod no status not-ready.

Etapa 3: Ative o redirecionamento de health check para a aplicação Nginx

Execute o comando a seguir para editar o arquivo http-liveness.yaml.

vim http-liveness.yaml

Adicione o conteúdo a seguir sob o parâmetro template:

annotations:
  sidecar.istio.io/rewriteAppHTTPProbers: "true"

O código a seguir mostra o arquivo http-liveness.yaml após a adição da anotação:

http-liveness.yaml: após a adição da anotação

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        sidecar.istio.io/rewriteAppHTTPProbers: "true"
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /index.html
            port: 80
            httpHeaders:
            - name: X-Custom-Header
              value: hello
          initialDelaySeconds: 5
          periodSeconds: 3

Execute o comando a seguir para implantar a aplicação Nginx.
```
kubectl apply -f http-liveness.yaml
```

Etapa 4: Verifique o resultado do health check

Visualize o status do health check do pod.
1. Execute o comando a seguir para visualizar o nome do pod da aplicação Nginx.
```
kubectl get pod | grep nginx
```
2. Execute o comando a seguir para visualizar os eventos do pod.
```
kubectl describe pod <pod_name>
```
  A saída não inclui nenhum evento de falha de health check e o pod está no status ready. O health check HTTP funciona conforme o esperado.

Execute o comando a seguir para visualizar o arquivo YAML do pod após o redirecionamento de health check.

kubectl get pod <pod_name> -o yaml

Saída esperada

apiVersion: v1
kind: Pod
metadata:
  ...
  name: nginx-deployment-676f85f66b-cbzsx
  namespace: default
  ...
spec:
  containers:
    - args:
        - proxy
        - sidecar
        - '--domain'
        - $(POD_NAMESPACE).svc.cluster.local
        - '--proxyLogLevel=warning'
        - '--proxyComponentLogLevel=misc:error'
        - '--log_output_level=default:info'
        - '--concurrency'
        - '2'
      env:
        ...
        - name: ISTIO_KUBE_APP_PROBERS
          value: >-
            {"/app-health/nginx/readyz":{"httpGet":{"path":"/index.html","port":80,"scheme":"HTTP","httpHeaders":[{"name":"X-Custom-Header","value":"hello"}]},"timeoutSeconds":1}}
      ...
    - image: nginx
      imagePullPolicy: IfNotPresent
      name: nginx
      ports:
        - containerPort: 80
          protocol: TCP
      readinessProbe:
        failureThreshold: 3
        httpGet:
          httpHeaders:
            - name: X-Custom-Header
              value: hello
          path: /app-health/nginx/readyz
          port: 15020
          scheme: HTTP
        initialDelaySeconds: 5
        periodSeconds: 3
        successThreshold: 1
        timeoutSeconds: 1

Após a ativação do redirecionamento de health check, a porta de health check muda de 80 para 15020, e o caminho do health check muda de /index.html para /app-health/nginx/readyz. A variável de ambiente ISTIO_KUBE_APP_PROBERS também é adicionada ao contêiner sidecar no pod. O valor da variável corresponde à serialização JSON da configuração de health check antes da reescrita.

Ative o redirecionamento de health check TCP

O exemplo a seguir utiliza uma aplicação Nginx para ativar o redirecionamento de health check TCP. O procedimento é idêntico ao do redirecionamento de health check HTTP. Apenas a configuração da sonda e os resultados esperados diferem. Uma porta incorreta foi configurada para a aplicação Nginx, mas o health check TCP ainda tem sucesso no pod da aplicação, o que não corresponde ao comportamento esperado. Após a ativação do redirecionamento de health check para a aplicação Nginx, o health check TCP falha no pod da aplicação. Esse comportamento atende às expectativas e indica que o redirecionamento de health check TCP foi ativado corretamente para a aplicação.

Etapa 1: Implante a aplicação Nginx

Implante a aplicação Nginx.
1. Crie um arquivo chamado tcp-liveness.yaml com o conteúdo a seguir.
  
  O conteúdo a seguir configura a porta 2940 como porta de health check, o que está incorreto. A aplicação Nginx não escuta na porta 2940. Portanto, espera-se que o health check falhe sempre após a implantação da aplicação, mantendo o pod no status not-ready.
  tcp-liveness.yaml: configuração inicial
  apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: selector: matchLabels: app: nginx replicas: 1 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent ports: - containerPort: 80 readinessProbe: tcpSocket: port: 2940 initialDelaySeconds: 5 periodSeconds: 3
  Sob o parâmetro readinessProbe, o campo tcpSocket define um health check TCP para a aplicação.
2. Execute o comando a seguir para implantar a aplicação Nginx.
```
kubectl apply -f tcp-liveness.yaml
```
Verifique o status do health check da aplicação.
1. Execute o comando a seguir para visualizar o nome do pod da aplicação Nginx.
```
kubectl get pod | grep nginx
```
2. Execute o comando a seguir para visualizar os eventos do pod.
```
kubectl describe pod <pod_name>
```
  A saída não inclui nenhum evento de falha de health check e o pod está no status ready, o que não corresponde ao comportamento esperado.

Etapa 2: Ative o redirecionamento de health check para a aplicação Nginx

Execute o comando a seguir para editar o arquivo tcp-liveness.yaml.

vim tcp-liveness.yaml

No arquivo tcp-liveness.yaml, adicione o conteúdo a seguir sob o parâmetro template:

annotations:
  sidecar.istio.io/rewriteAppHTTPProbers: "true"

O código a seguir mostra o arquivo tcp-liveness.yaml após a adição da anotação:

tcp-liveness.yaml: após a adição da anotação

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        sidecar.istio.io/rewriteAppHTTPProbers: "true"
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        readinessProbe:
          tcpSocket:
            port: 2940
          initialDelaySeconds: 5
          periodSeconds: 3

Execute o comando a seguir para implantar a aplicação Nginx.
```
kubectl apply -f tcp-liveness.yaml
```

Etapa 3: Verifique o resultado do health check

Verifique o status do health check da aplicação.
1. Execute o comando a seguir para visualizar o nome do pod da aplicação Nginx.
```
kubectl get pod | grep nginx
```
2. Execute o comando a seguir para visualizar os eventos do pod.
```
kubectl describe pod <pod_name>
```
  Saída esperada:
```
Warning  Unhealthy  45s               kubelet            Readiness probe failed: HTTP probe failed with statuscode: 500
```
  A saída indica que o health check falhou, o que corresponde ao comportamento esperado.

Execute o comando a seguir para visualizar o conteúdo YAML do pod da aplicação após o redirecionamento de health check.

kubectl get pod <pod_name> -o yaml

Saída esperada

apiVersion: v1
kind: Pod
metadata:
  ...
  name: nginx-deployment-746458cdc9-m9t9q
  namespace: default
  ...
spec:
  containers:
    - args:
        - proxy
        - sidecar
        - '--domain'
        - $(POD_NAMESPACE).svc.cluster.local
        - '--proxyLogLevel=warning'
        - '--proxyComponentLogLevel=misc:error'
        - '--log_output_level=default:info'
        - '--concurrency'
        - '2'
      env:
        ...
        - name: ISTIO_KUBE_APP_PROBERS
          value: >-
            {"/app-health/nginx/readyz":{"tcpSocket":{"port":2940},"timeoutSeconds":1}}
      ...
    - image: nginx
      imagePullPolicy: IfNotPresent
      name: nginx
      ports:
        - containerPort: 80
          protocol: TCP
      readinessProbe:
        failureThreshold: 3
        httpGet:
          path: /app-health/nginx/readyz
          port: 15020
          scheme: HTTP
        initialDelaySeconds: 5
        periodSeconds: 3
        successThreshold: 1
        timeoutSeconds: 1
      ...

Após a ativação do redirecionamento de health check, o health check TCP original é reescrito como um health check HTTP. A porta de health check muda de 2940 para 15020, e o caminho do health check HTTP é definido como /app-health/nginx/readyz. A variável de ambiente ISTIO_KUBE_APP_PROBERS também é adicionada ao contêiner sidecar no pod. O valor da variável corresponde à serialização JSON da configuração de health check TCP antes da reescrita.