Como resolver problemas gerenciados do Cloud Service Mesh
Neste documento, explicamos problemas comuns do Cloud Service Mesh e como resolvê-los
como quando um pod é injetado com istio.istio-system
, a instalação
ferramenta gera erros, como códigos de status HTTP 400
e associação de cluster
erros.
Se você precisar de mais ajuda para resolver problemas do Cloud Service Mesh, consulte Como receber suporte.
O status das revisões é considerado não íntegros
Talvez você veja um erro Revision(s) reporting unhealthy
genérico se o serviço
para o Cloud Service Mesh gerenciado não tem o
Cloud Identity and Access Management (IAM). Geralmente, isso ocorre quando o papel é revogado.
pelo Terraform, Puppet ou reconfiguração de CI/CD.
As etapas necessárias para solucionar esse erro dependem do uso do console do Google Cloud ou da Google Cloud CLI.
Console do Google Cloud
No console do Google Cloud, acesse o IAM e administrador > IAM.
Selecione Incluir concessões de papel fornecidas pelo Google.
Revise a lista Principal.
Se o agente de serviço com o papel do IAM necessário aparecer na lista, ele estará configurado corretamente.
Se a lista não incluir o agente de serviço e o papel necessário, siga para a próxima etapa.
Conceda o papel de agente de serviço do Anthos Service Mesh (
roles/anthosservicemesh.serviceAgent
) ao agente de serviço do Cloud Service Mesh no projeto. Para instruções, consulte Gerenciar o acesso a projetos, pastas e organizações.
Google Cloud CLI
Na Google Cloud CLI, execute o comando a seguir para verificar se o papel do IAM necessário foi concedido:
gcloud projects get-iam-policy PROJECT_ID \ --flatten="bindings[].members" \ --filter="bindings.members:serviceAccount:service-PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com AND bindings.role:roles/anthosservicemesh.serviceAgent" \ --format='table(bindings.role)'
Revise a
ROLE
lista.Se visualizar um papel na lista, ele está configurado corretamente.
Se nenhum papel for exibido na lista, o papel necessário foi revogado.
Para conceder o papel necessário ao agente de serviço, execute o seguinte comando:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --role="roles/anthosservicemesh.serviceAgent"
A ferramenta de instalação gera erros HTTP 400
A ferramenta de instalação pode gerar erros HTTP 400
como este:
HealthCheckContainerError, message: Cloud Run error: Container failed to start.
Failed to start and then listen on the port defined by the PORT environment
variable. Logs for this revision might contain more information.
Isso pode ocorrer se você não tiver ativado a identidade da carga de trabalho no cluster do Kubernetes, o que pode ser feito usando o seguinte comando:
export CLUSTER_NAME=...
export PROJECT_ID=...
export LOCATION=...
gcloud container clusters update $CLUSTER_NAME --zone $LOCATION \
--workload-pool=$PROJECT_ID.svc.id.goog
Estado do plano de dados gerenciado
O comando a seguir exibe o status do plano de dados gerenciado:
gcloud container fleet mesh describe --project PROJECT_ID
A tabela a seguir lista todos os estados possíveis do plano de dados gerenciados:
Estado | Code | Descrição |
---|---|---|
ACTIVE |
OK |
O plano de dados gerenciado está em execução normalmente. |
DISABLED |
DISABLED |
O plano de dados gerenciado se encontra nesse estado se nenhum namespace ou revisão
está configurado para usá-lo. Siga as instruções para
ativar o Cloud Service Mesh gerenciado pela API Fleet ou
ativar o plano de dados gerenciado após o provisionamento do Cloud Service Mesh gerenciado com asmcli .
Os relatórios de status do plano de dados gerenciado só estarão disponíveis se você
tiver ativado o plano de dados gerenciado anotando um namespace ou revisão.
Inserir
anotações individuais faz com que esses pods sejam gerenciados, mas com um estado de recurso
DISABLED se nenhum namespace ou revisão for anotado. |
FAILED_PRECONDITION |
MANAGED_CONTROL_PLANE_REQUIRED |
O plano de dados gerenciado exige um controle ativo e gerenciado do Cloud Service Mesh de controle. |
PROVISIONING |
PROVISIONING |
O plano de dados gerenciado está sendo provisionado. Se esse estado persistir por mais de 10 minutos, é provável que tenha ocorrido um erro. Entre em contato com o suporte. |
STALLED |
INTERNAL_ERROR |
O plano de dados gerenciado está impedido de operar devido a uma condição de erro interna. Se o problema persistir, entre em contato com o suporte. |
NEEDS_ATTENTION |
UPGRADE_FAILURES |
O plano de dados gerenciado exige intervenção manual para que o
serviço volte ao estado normal. Para mais informações e como resolver esse problema, consulte o
estado NEEDS_ATTENTION . |
NEEDS_ATTENTION
estado
Se o comando gcloud container fleet mesh describe
mostrar que o estado do plano de dados gerenciado está no estado NEEDS_ATTENTION
e o código é
UPGRADE_FAILURES
, significa que o plano de dados gerenciado não fez o upgrade de determinadas cargas
de trabalho. Essas cargas de trabalho serão rotuladas com dataplane-upgrade: failed
pelo
serviço do plano de dados gerenciado para uma análise mais detalhada. Os proxies precisam ser reiniciados manualmente para serem atualizados. Para ver a lista de pods que exigem
a atenção, execute o seguinte comando:
kubectl get pods --all-namespaces -l dataplane-upgrade=failed
Erro de associação do cluster (nenhum provedor de identidade especificado)
A ferramenta de instalação pode falhar com erros de associação de cluster, como:
asmcli: [ERROR]: Cluster has memberships.hub.gke.io CRD but no identity
provider specified. Please ensure that an identity provider is available for the
registered cluster.
O erro pode ocorrer se você não tiver a identidade da carga de trabalho do GKE ativada
antes de registrar o cluster. É possível registrar novamente o cluster na linha de comando
usando o
comando gcloud container fleet memberships register --enable-workload-identity
.
Verificar o status do plano de controle gerenciado
Para verificar o status do plano de controle gerenciado, execute
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
.
Na resposta, o
campo membershipStates[].servicemesh.controlPlaneManagement.details
pode
explicar o erro específico.
Se você precisar de mais detalhes, verifique o recurso personalizado ControlPlaneRevision
no cluster, que é atualizado quando o plano de controle gerenciado é provisionado
ou falha no provisionamento.
Para inspecionar o status do recurso, substitua NAME pelo valor
correspondente a cada canal: asm-managed
, asm-managed-stable
ou
asm-managed-rapid
.
kubectl describe controlplanerevision NAME -n istio-system
A resposta é semelhante a:
Name: asm-managed … Status: Conditions: Last Transition Time: 2021-08-05T18:56:32Z Message: The provisioning process has completed successfully Reason: Provisioned Status: True Type: Reconciled Last Transition Time: 2021-08-05T18:56:32Z Message: Provisioning has finished Reason: ProvisioningFinished Status: True Type: ProvisioningFinished Last Transition Time: 2021-08-05T18:56:32Z Message: Provisioning has not stalled Reason: NotStalled Status: False Type: Stalled
A condição Reconciled
determina se o plano de controle gerenciado está em execução
corretamente. Se true
, o plano de controle está sendo executado.
Stalled
determina se o processo de provisionamento do plano de controle gerenciado
encontrou um erro. Se Stalled
, o campo Message
conterá mais
informações sobre o erro específico. Consulte
Códigos interrompidos
para ver mais informações sobre possíveis erros.
Códigos interrompidos da ControlPlaneRevision
Há vários motivos para a condição Stalled
se tornar verdadeira no
status ControlPlaneRevisions
.
Motivo | Message | Descrição |
---|---|---|
PreconditionFailed | Só é possível usar assinaturas do GKE, mas ${CLUSTER_NAME} não é um cluster do GKE. | O cluster atual não parece ser um cluster do GKE. O plano de controle gerenciado só funciona em clusters do GKE. |
Nome de ControlPlaneRevision incompatível: ${NAME} | O nome do ControlPlaneRevision precisa ser um dos seguintes:
|
|
Namespace de ControlPlaneRevision incompatível: ${NAMESPACE} | O namespace de ControlPlaneRevision precisa ser istio-system . |
|
O canal ${CHANNEL} não é compatível com a versão ControlPlaneRevision com o nome${NAME}. Esperados ${OTHER_CHANNEL} | O nome do ControlPlaneRevision precisa corresponder ao canal do ControlPlaneRevision com o seguinte:
|
|
O canal não pode ser omitido ou ficar em branco | Channel é um campo obrigatório no ControlPlaneRevision. Ele não foi encontrado ou está em branco no recurso personalizado. |
|
Tipo de revisão do plano de controle incompatível: ${TYPE} | managed_service é o único campo de permissão para o campo ControlPlaneRevisionType. |
|
Versão incompatível do Kubernetes: ${VERSION} | As versões 1.15+ do Kubernetes são compatíveis. | |
A identidade da carga de trabalho não está ativada | Ative a identidade da carga de trabalho no cluster. | |
Pool de carga de trabalho incompatível: ${POOL} | O pool de carga de trabalho precisa estar no formato ${PROJECT_ID}.svc.id.goog . |
|
ProvisioningFailed | Ocorreu um erro ao atualizar os recursos do cluster | O Google não conseguiu atualizar os recursos no cluster, como CRDs e webhooks. |
MutatingWebhookConfiguration "istiod-asm-managed" contém um webhook com o URL ${EXISTING_URL}, mas é esperado ${PENDING_URL} | O Google não substituirá os webhooks atuais para evitar falhas na instalação. Atualize manualmente se for o comportamento desejado. | |
ValidatingWebhookConfiguration ${NAME} contém um webhook com o URL ${EXISTING_URL}, mas é esperado ${PENDING_URL} | O Google não substituirá os webhooks atuais para evitar falhas na instalação. Atualize manualmente se for o comportamento desejado. |
O Cloud Service Mesh gerenciado não consegue se conectar ao cluster do GKE
Entre junho e setembro de 2022, O Google concluiu o trabalho de segurança relacionadas às redes autorizadas, funções do Cloud Run e do Cloud Run no Google Kubernetes Engine (GKE). Projetos que anteriormente usavam o Cloud Service Mesh gerenciado mas parou de usá-la antes da migração não têm a API necessária para a comunicação entre o Cloud Run e o GKE.
Nesse cenário, o provisionamento gerenciado do Cloud Service Mesh falhará e o Cloud Logging exibirá a seguinte mensagem de erro:
Connect Gateway API has not been used in project [*PROJECT_NUMBER*] before or it is disabled.
Enable it by visiting https://console.developers.google.com/apis/api/connectgateway.googleapis.com/overview?project=[*PROJECT_NUMBER*] then retry.
If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.
Filtre esta mensagem usando a seguinte consulta:
resource.type="istio_control_plane"
resource.labels.project_id=[*PROJECT_ID*]
resource.labels.location=[*REGION*]
severity=ERROR
jsonPayload.message=~"Connect Gateway API has not been used in project"
Enquanto isso, a injeção do arquivo secundário e a implantação de recursos personalizados do Kubernetes relacionados ao Cloud Service Mesh também vão falhar e O Cloud Logging vai exibir a seguinte mensagem de aviso:
Error creating: Internal error occurred: failed calling webhook
"rev.namespace.sidecar-injector.istio.io": failed to call webhook: an error on
the server ("unknown") has prevented the request from succeeding.
Filtre esta mensagem usando a seguinte consulta:
resource.type="k8s_cluster"
resource.labels.project_id=[*PROJECT_ID*]
resource.labels.location=[*REGION*]
resource.labels.cluster_name=[*CLUSTER_NAME*]
severity=WARNING
jsonPayload.message=~"Internal error occurred: failed calling webhook"
Para resolver o problema:
Ative a API
connectgateway
necessária.gcloud services enable connectgateway.googleapis.com --project=[*PROJECT_ID*]
Execute uma reinicialização gradual nas cargas de trabalho.
As APIs do Google Cloud não estão ativadas
Se a frota gerenciada do Cloud Service Mesh usar a TRAFFIC_DIRECTOR
implementação do plano de controle,
algumas APIs precisarão ser ativadas.
Ative todas as APIs necessárias, incluindo aquelas listadas como "Pode ser desativada" quando não estiver usando a rede gerenciada do Cloud Service.
gcloud services enable --project=[*PROJECT_ID*] \ trafficdirector.googleapis.com \ networkservices.googleapis.com \ networksecurity.googleapis.com
Verifique se você não tem ferramentas automatizadas para reverter esse problema mudar. Se o erro persistir, atualize as configurações relevantes ou listas de permissão.
A federação de identidade da carga de trabalho do NodePool para o GKE está desativada
O comando a seguir exibe o estado do Cloud Service Mesh gerenciado:
gcloud container fleet mesh describe
O código do erro NODEPOOL_WORKLOAD_IDENTITY_FEDERATION_REQUIRED
no campo Conditions
da sua assinatura:
membershipStates:
projects/test-project/locations/us-central1/memberships/my-membership:
servicemesh:
conditions:
- code: NODEPOOL_WORKLOAD_IDENTITY_FEDERATION_REQUIRED
details: One or more node pools have workload identity federation disabled.
documentationLink: https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity
severity: ERROR
controlPlaneManagement:
details:
- code: REVISION_FAILED_PRECONDITION
details: Required in-cluster components are not ready. This will be retried
within 15 minutes.
implementation: TRAFFIC_DIRECTOR
state: FAILED_PRECONDITION
Esse erro aparece se o cluster do GKE não tiver a federação de identidade da carga de trabalho ativada em todos os pools de nós desse cluster, já que esse é um pré-requisito para a instalação do Cloud Service Mesh.
Para resolver essa mensagem de erro, siga as instruções para Ativar a federação de identidade da carga de trabalho em todos os pools de nós. A ativação pode variar de acordo com seu de cluster.
Após a ativação, a mensagem de erro será removida automaticamente, e o cluster
voltará ao estado ACTIVE
. Se o problema persistir e você precisar
receber mais ajuda, consulte Como receber suporte.