O Anthos Service Mesh 1.11 chegou ao fim da vida útil e não é mais compatível. Consulte Como fazer upgrade de versões anteriores.

Veja uma mais recente ou selecione outra versão disponível:

Versões disponíveis

1.20 (mais recente)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

Como resolver problemas de compatibilidade com VM no Anthos Service Mesh

As etapas e os registros a seguir são úteis para solucionar problemas com a compatibilidade da VM do Anthos Service Mesh.

Depurar a VM

Se você vir que as instâncias de VM estão em execução, mas não podem ser acessadas a partir da malha, execute as etapas a seguir na instância de VM.

Verificar o agente

Verifique a integridade do proxy Envoy:
```
curl localhost:15000/ready -v
```
Verifique o registro de erros do Envoy
```
less /var/log/envoy/envoy.err.log
```
Verifique se há erros service-proxy-agent
```
journalctl -u service-proxy-agent
```
Verifique o syslog nos registros de observabilidade do Google Cloud da instância ou na VM em /var/log/syslog para o Debian e /var/log/messages para o Centos.

Verificar a integridade do proxy

Para depurar a configuração do proxy, execute o seguinte comando na VM:
```
curl localhost:15000/config_dump > config.out
```

Copie esse arquivo e execute o seguinte comando:

istioctl proxy-config [cluster|route|listener] --file config.out

Erros de token inválido

Talvez você veja um erro semelhante a este no registro de erros do envoy:

E0217 17:59:17.206995798    2411 oauth2_credentials.cc:152]  Call to http server ended with error 500 [{
  "error": "invalid_target",
  "error_description": "federated token response does not have access token. {\"error\":\"invalid_grant\",\"error_description\":\"JWT expired.\"}",
  "error_uri": ""
}].

Nesse caso, verifique se o token em /var/run/secrets/tokens/istio-token na VM expirou e confirme se o valor de exp (segundos de período) não foi atingido:

cat /var/run/secrets/tokens/istio-token | cut -d '.' -f2 | base64 -d | python -m json.tool
{
    ...
    "azp": "...",
    "email": "example-service-account@developer.gserviceaccount.com",
    "email_verified": true,
    "exp": 1613995395,
    "google": {
        "compute_engine": {
            "instance_creation_timestamp": 1613775765,
            "instance_id": "5678",
            "instance_name": "vm-instance-03-0mqh",
            "project_id": "...",
            "project_number": 1234,
            "zone": "us-central1-c"
        }
    },
    "iat": ...,
    "iss": "https://accounts.google.com",
    "sub": "..."
}

Informações de aviso de distribuição do SO não compatível

Em Verificar o agente, se for exibida uma mensagem de aviso semelhante à seguinte no registro do agente do proxy de serviço:

E0217 17:59:17.206995798    2021-04-09T21:21:29.6091Z service-proxy-agent Warn
Detected image is unsupported: [Ubuntu|Fedora|Suse]. Envoy may not work correctly.

Isso significa que a distribuição do Linux talvez seja incompatível, o que pode fazer com que o proxy tenha um comportamento inesperado.

Depurar o cluster

Siga as etapas abaixo para solucionar problemas com o cluster.

Verificar se o registro automático está funcionando

Verifique o WorkloadEntry que istiod gera automaticamente:
```
kubectl get workloadentry -n WORKLOAD_NAMESPACE
```
Além disso, é possível verificar a existência do navegador de objetos do Kubernetes.

Se não existir, verifique se há erros nos registros istiod, que estarão disponíveis para você na observabilidade do Google Cloud. Como alternativa, é possível recuperá-los diretamente:

kubectl -n istio-system get pods -l app=istiod

A resposta esperada é semelhante a esta:

NAME                                       READY   STATUS    RESTARTS   AGE
istiod-asm-190-1-7f6699cfb-5mzxw           1/1     Running   0          5d13h
istiod-asm-190-1-7f6699cfb-pgvpf           1/1     Running   0          5d13h

Defina a variável de ambiente do pod e use-a para exportar os registros:

export ISTIO_POD=istiod-asm-190-1-7f6699cfb-5mzxw
kubectl logs -n istio-system ${ISTIO_POD} | grep -i 'auto-register\|WorkloadEntry'

Verificar os proxies conectados

Use o comando proxy-status para listar todos os proxies conectados, incluindo os de VMs:

istioctl proxy-status

A saída deve mostrar proxies conectados semelhantes a:

NAME                                                    CDS        LDS        EDS        RDS          ISTIOD                               VERSION
details-v1-5f449bdbb9-bhl8d.default                     SYNCED     SYNCED     SYNCED     SYNCED       istiod-asm-190-1-7f6699cfb-5mzxw     1.9.0-asm.1
httpbin-779c54bf49-647vd.default                        SYNCED     SYNCED     SYNCED     SYNCED       istiod-asm-190-1-7f6699cfb-pgvpf     1.9.0-asm.1
istio-eastwestgateway-5b6d4ddd9d-5rzx2.istio-system     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-asm-190-1-7f6699cfb-pgvpf     1.9.0-asm.1
istio-ingressgateway-66b6ddd7cb-ctb6b.istio-system      SYNCED     SYNCED     SYNCED     SYNCED       istiod-asm-190-1-7f6699cfb-pgvpf     1.9.0-asm.1
istio-ingressgateway-66b6ddd7cb-vk4bb.istio-system      SYNCED     SYNCED     SYNCED     SYNCED       istiod-asm-190-1-7f6699cfb-5mzxw     1.9.0-asm.1
vm-instance-03-39b3.496270428946                        SYNCED     SYNCED     SYNCED     SYNCED       istiod-asm-190-1-7f6699cfb-pgvpf     1.9.0
vm-instance-03-nh5k.496270428946                        SYNCED     SYNCED     SYNCED     SYNCED       istiod-asm-190-1-7f6699cfb-pgvpf     1.9.0
vm-instance-03-s4nl.496270428946                        SYNCED     SYNCED     SYNCED     SYNCED       istiod-asm-190-1-7f6699cfb-5mzxw     1.9.0

Para saber mais sobre as opções de comando, consulte istioctl proxy-config.

Verificar a configuração de identidade da carga de trabalho

Verifique o estado mesh para possíveis erros no cluster. A versão mais recente da gcloud é obrigatória. Para mais informações, consulte Atualizar para o mais recente.

gcloud alpha container hub mesh describe --project=PROJECT_ID

Uma configuração válida terá um código de status OK para o cluster de membro:

createTime: '2021-06-15T21:56:10.221032150Z'
featureState:
  detailsByMembership:
    projects/<your project number>/locations/global/memberships/<your cluster name>:
      code: OK
      description: Revision(s) ready for use: istiod-asm-195-2.
      updateTime: 2021-06-15T21:56:10.221032402Z
  lifecycleState: ENABLED
name: projects/<your project name>/locations/global/features/servicemesh
servicemeshFeatureSpec: {}
updateTime: '2021-06-15T21:56:10.221032402Z'

Se a VM estiver configurada incorretamente, o código de status será WARNING com mais detalhes na descrição:

createTime: '2021-06-15T22:56:10.227167202Z'
featureState:
  detailsByMembership:
    projects/<your project number>/locations/global/memberships/<your cluster name>:
      code: WARNING
      description: |-
        Revision(s) ready for use: istiod-asm-195-2.
        WorkloadGroup <namespace>/<workloadgroup name> missing ServiceAccount field, please see https://cloud.google.com/service-mesh/v1.11/docs/troubleshooting/troubleshoot-vms#verify_the_workloadgroup_is_set_up_correctly.
      servicemeshFeatureState: {}
      updateTime: '2021-06-15T22:56:00.220164192Z'
  lifecycleState: ENABLED
name: projects/<your project name>/locations/global/features/servicemesh
servicemeshFeatureSpec: {}
updateTime: '2021-06-15T22:56:10.227167402Z'

Verifique se o provedor de identidade está configurado corretamente

Verifique os campos de recursos IdentityProvider:

 kubectl describe identityprovider

Verifique se os campos atendem a estes requisitos:

O campo serviceAccount está definido como request.auth.claims["email"].
O campo issuerURI está definido como https://accounts.google.com. No momento, oferecemos suporte apenas ao Google, como issuerURI.

O campo name do provedor em metadados precisa ser definido como google, que é o único provedor compatível no momento.

Um exemplo válido de resposta automática IdentityProvider:

apiVersion: security.cloud.google.com/v1alpha1
kind: IdentityProvider
metadata:
  name: google
spec:
  authentication:
    oidc:
      issuerUri: https://accounts.google.com
  serviceAccount: request.auth.claims["email"]

Verifique se o `WorkloadGroup` está configurado corretamente

Verifique o WorkloadGroup:

 kubectl get workloadgroup -n WORKLOAD_NAMESPACE

Verifique se os resultados atendem a estes requisitos:

O campo serviceAccount está definido corretamente, por exemplo, 373206437219-compute@developer.gserviceaccount.com, em que a conta é a mesma conta de serviço usada pela instância de VM
O security.cloud.google.com/IdentityProvider no campo de anotação está definido. Por exemplo, security.cloud.google.com/IdentityProvider: google

O grupo de carga de trabalho refere-se a um IdentityProvider válido, que pode ser verificado checando o provedor de identidade atual:

kubectl describe identityprovider

A saída será uma lista de provedores existentes como esta:

 NAME     AGE
 google   39m

Verifique o campo security.cloud.google.com/IdentityProvider no WorkloadGroup se o provedor existir na lista de provedores existentes.

Um exemplo válido de resposta automática WorkloadGroup:

apiVersion: networking.istio.io/v1alpha3
kind: WorkloadGroup
metadata:
name: wg-a
namespace: foo
spec:
metadata:
  annotations:
    security.cloud.google.com/IdentityProvider: google
  labels:
    app: wg-a
template:
  ports:
    grpc: 3550
    http: 8080
  serviceAccount: 373206437219-compute@developer.gserviceaccount.com

Erro interno encontrado

Se você receber a mensagem Internal Error Found, consulte Como receber suporte.

Guia de solução de problemas da VM do Istio

Para mais etapas de solução de problemas, consulte Como depurar máquinas virtuais.