Resolver problemas de escalonamento automático de clusters que não estão reduzindo a escala vertical

Nesta página, mostramos como diagnosticar e resolver problemas que impedem o escalonador automático de clusters de reduzir verticalmente os nós do Google Kubernetes Engine (GKE).

Esta página é destinada a desenvolvedores de aplicativos que querem resolver uma situação inesperada ou negativa com o app ou serviço e administradores e operadores de plataforma que querem evitar interrupções na entrega de produtos e serviços.

Entender quando o escalonador automático de clusters reduz a escala vertical dos nós

Antes de seguir para as etapas de solução de problemas, é importante entender quando o escalonador automático de clusters tentaria reduzir a escala vertical dos nós. Talvez o escalonador automático de clusters não tenha reduzido porque não era necessário.

O escalonador automático de clusters determina se um nó está subutilizado e qualificado para redução de escala vertical calculando um fator de utilização. O fator de utilização é calculado dividindo a vCPU e a memória solicitada pelos pods no nó pela vCPU e memória alocáveis no nó.

A cada 10 segundos, o escalonador automático de clusters verifica o fator de utilização dos nós para saber se eles estão abaixo do limite necessário. Se você estiver usando um perfil de escalonamento automático balanced, o limite do fator de utilização será 0,5. Se estiver usando o perfil optimize-utilization, o fator de utilização vai variar. Quando o fator de utilização for menor que o limite necessário para vCPU e memória, o escalonador automático de clusters vai considerar o nó subutilizado.

Quando um nó é subutilizado, o escalonador automático de clusters marca o nó para remoção e o monitora nos próximos 10 minutos para garantir que o fator de utilização continue abaixo do limite necessário. Se o nó ainda estiver pouco utilizado após 10 minutos, ele será removido pelo escalonador automático de clusters.

Exemplo: cálculo do fator de utilização

Você tem um cluster com o escalonador automático ativado e está usando o perfil de escalonamento automático balanced. Um nó do cluster é provisionado com o tipo de máquina e2-standard-4, que oferece 4 vCPUs e 16 GB de memória. Um pod nesse nó solicita 0,5 vCPU e 10 GB de memória, então o escalonador automático de clusters calcula os seguintes fatores de utilização:

  • Fator de utilização da vCPU: 0,5 vCPU / 4 vCPUs = 0,125
  • Fator de utilização da memória: 10 GB / 16 GB = 0,625

Nesse cenário, o escalonador automático de clusters não considera esse nó subutilizado porque o fator de utilização de memória (0,625) excede o limite de 0,5. Mesmo que a utilização da vCPU seja baixa, o uso maior de memória impede a redução da escala vertical para garantir que haja recursos suficientes disponíveis para a carga de trabalho do pod.

Verificar se o problema é causado por uma limitação

Se você observar um cluster com baixa utilização por mais de 10 minutos e ele não estiver sendo reduzido, verifique se a causa não é uma das limitações do escalonador automático de clusters.

Ver erros

Se o problema não for causado por uma limitação, confira as mensagens de erro para diagnosticar a causa:

Ver erros nas notificações

Se o problema observado ocorreu há menos de 72 horas, confira as notificações sobre erros no console do Google Cloud. Essas notificações fornecem insights valiosos sobre por que o escalonador automático de clusters não reduziu a escala vertical e oferecem conselhos sobre como resolver o erro e conferir os registros relevantes para realizar uma investigação mais detalhada.

Para conferir as notificações no console do Google Cloud, siga estas etapas:

  1. No Console do Google Cloud, acesse a página de clusters do Kubernetes.

    Acessar clusters do Kubernetes

  2. Confira a coluna Notificações. As notificações a seguir estão associadas a problemas de redução de escala vertical:

    • Can't scale down nodes
    • Scale down blocked by pod

  3. Clique na notificação relevante para abrir um painel com detalhes sobre o que causou o problema e as ações recomendadas para resolvê-lo.

  4. Opcional: para conferir os registros desse evento, clique em Registros. Essa ação leva você à Análise de registros com uma consulta pré-preenchida para ajudar a investigar melhor o evento de escalonamento. Para saber como os eventos de redução de escala funcionam, consulte Conferir eventos do escalonador automático de clusters.

Se você ainda tiver problemas depois de analisar as orientações na notificação, consulte as tabelas de mensagens de erro para receber mais ajuda.

Ver erros em eventos

Se o problema observado ocorreu há mais de 72 horas, confira os eventos no Cloud Logging. Quando ocorre um erro, ele geralmente é registrado em um evento.

Para conferir os registros do escalonador automático de clusters no console do Google Cloud, siga estas etapas:

  1. No Console do Google Cloud, acesse a página de clusters do Kubernetes.

    Acessar clusters do Kubernetes

  2. Selecione o nome do cluster que você quer investigar para acessar a página Detalhes do cluster.

  3. Na página Detalhes do cluster, clique na guia Registros.

  4. Na guia Registros, clique em Registros do escalonador automático para ver os registros.

  5. Opcional: para aplicar filtros mais avançados para restringir os resultados, clique no botão com a seta no lado direito da página para visualizar os registros na Análise de registros.

Para saber como os eventos de redução de escala funcionam, consulte Conferir eventos do escalonador automático de clusters. Para um exemplo de como usar o Cloud Logging, consulte o exemplo de solução de problemas a seguir.

Exemplo: resolver um problema com mais de 72 horas

O exemplo a seguir mostra como investigar e resolver um problema com um cluster que não está reduzindo a escala vertical.

Cenário:

Há uma semana, você estava analisando o painel do GKE Enterprise e notou que seu cluster utilizou apenas 10% da CPU e da memória. Apesar da baixa utilização, o escalonador automático de clusters não excluiu o nó conforme esperado. Quando você olha o painel agora, o problema parece ter sido resolvido, mas você decide descobrir o que aconteceu para evitar que ele ocorra de novo.

Investigação:

  1. Como o problema ocorreu há mais de 72 horas, você investiga o problema usando o Cloud Logging em vez de analisar as mensagens de notificação.
  2. No Cloud Logging, você encontra os detalhes de registro dos eventos do escalonador automático de clusters, conforme descrito em Ver erros em eventos.
  3. Você pesquisa eventos scaleDown com os nós pertencentes ao cluster que você está investigando no campo nodesToBeRemoved. É possível filtrar as entradas de registro, incluindo a filtragem por um valor de campo JSON específico. Saiba mais em Consultas de registros avançados.
  4. Você não encontra nenhum evento scaleDown. No entanto, se você encontrar um evento scaleDown, poderá pesquisar um evento eventResult com o eventId associado. É possível pesquisar um erro no campo errorMsg.

  5. Você decide continuar a investigação pesquisando eventos noScaleDown com nó que está sendo investigado no campo correspondente.

    Você encontra um evento noScaleDown com um motivo para o nó não ser reduzido verticalmente. O ID da mensagem é "no.scale.down.node.pod.not.backed.by.controller" e há um único parâmetro: "test-single-pod".

Resolução:

Você consulta a tabela de mensagens de erro e descobre que essa mensagem significa que o pod está bloqueando a redução de escala vertical porque não é apoiado por um controlador. Você descobre que uma solução é adicionar uma anotação "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" ao pod. Você investiga test-single-pod e percebe que um colega adicionou a anotação. Depois disso, o escalonador automático de cluster reduziu corretamente. Você decide adicionar a anotação a todos os outros pods em que for seguro fazer isso para evitar que o problema aconteça de novo.

Resolver erros de redução de escala vertical

Depois de identificar o erro, use as tabelas a seguir para entender a causa e a solução.

Erros de ScaleDown

As mensagens de evento de erro para eventos scaleDown estão no evento eventResult correspondente, no campo resultInfo.results[].errorMsg.

Mensagem de evento Detalhes Parâmetro Mitigação
"scale.down.error.failed.to.mark.to.be.deleted" Não foi possível marcar um nó para ser excluído. Nome do nó com falha. Essa mensagem deve ser temporária. Se o problema persistir, entre em contato com o Cloud Customer Care para realizar uma investigação mais detalhada.
"scale.down.error.failed.to.evict.pods" O escalonador automático de clusters não pode ser reduzido verticalmente porque alguns dos pods não podem ser removidos de um nó. Nome do nó com falha. Revise o PodDisruptionBudget do pod e verifique se as regras permitem a remoção de réplicas do aplicativo quando aceitável. Para saber mais, consulte Como especificar um orçamento de interrupção para seu aplicativo na documentação do Kubernetes.
"scale.down.error.failed.to.delete.node.min.size.reached" O escalonador automático de clusters não reduziu verticalmente porque não foi possível excluir um nó. Isso aconteceu porque o cluster já está com o tamanho mínimo. Nome do nó com falha. Revise o valor mínimo definido para o escalonamento automático do pool de nós e ajuste as configurações conforme necessário. Para saber mais, consulte o Erro: os nós no cluster atingiram o tamanho mínimo.

Motivos para um evento noScaleDown

Um evento noScaleDown é emitido periodicamente quando há nós impedidos de serem excluídos pelo escalonador automático de clusters. Os eventos noScaleDown são baseados no melhor esforço e não cobrem todos os casos possíveis.

Motivos de nível superior NoScaleDown

Mensagens de motivo de nível superior para eventos noScaleDown aparecem no campo noDecisionStatus.noScaleDown.reason. A mensagem contém um motivo de nível superior que explica por que o escalonador automático de clusters não pode reduzir o cluster.

Mensagem de evento Detalhes Mitigação
"no.scale.down.in.backoff" O escalonador automático de clusters não pode ser reduzido verticalmente porque a redução está em um período de espera (temporariamente bloqueado).

Essa mensagem deve ser temporária e pode ocorrer quando há um evento de escalonamento vertical recente.

Se a mensagem persistir, entre em contato com o Cloud Customer Care para realizar uma investigação mais detalhada.
"no.scale.down.in.progress"

O escalonador automático de clusters não pode ser reduzido verticalmente porque uma redução anterior ainda estava em andamento.

 Essa mensagem deve ser temporária, já que o pod será removido. Se essa mensagem ocorrer com frequência, analise o período de carência do encerramento da redução de escala vertical dos pods que estão bloqueando. Para acelerar a resolução, também é possível excluir o pod se ele não for mais necessário.

Motivos no nível do nó NoScaleDown

Mensagens de motivo no nível do nó para eventos noScaleDown aparecem em noDecisionStatus.noScaleDown.nodes[].reason field. A mensagem contém um motivo pelo qual o escalonador automático de cluster não pode remover um nó específico.

Mensagem de evento Detalhes Parâmetros Mitigação
"no.scale.down.node.scale.down.disabled.annotation" O escalonador automático de cluster não pode remover um nó do pool de nós porque ele tem a anotação cluster-autoscaler.kubernetes.io/scale-down-disabled: true. N/A O escalonador automático de clusters pula nós com essa anotação sem considerar a utilização deles, e essa mensagem é registrada independentemente do fator de utilização do nó. Se você quiser que o escalonador automático de clusters reduza verticalmente esses nós, remova a anotação.
"no.scale.down.node.node.group.min.size.reached"

O escalonador automático do cluster não pode ser reduzido quando o tamanho do grupo de nós excede o limite mínimo.

Isso acontece porque a remoção de nós violaria os limites mínimos de recursos em todo o cluster definidos nas configurações de provisionamento automático de nós.

 N/A Revise o valor mínimo definido para o escalonamento automático do pool de nós. Se você quiser que o escalonador automático do cluster reduza verticalmente esse nó, ajuste o valor mínimo.
"no.scale.down.node.minimal.resource.limits.exceeded"

O escalonador automático de clusters não conseguiu reduzir a escala vertical dos nós porque isso violaria os limites mínimos de recursos em todo o cluster.

Estes são os limites de recursos definidos para o provisionamento automático de nós.

 N/A Revise seus limites de memória e vCPU e, se você quiser que o escalonador automático de clusters reduza verticalmente esse nó, aumente os limites.
"no.scale.down.node.no.place.to.move.pods" O escalonador automático de clusters não pode reduzir a escala vertical porque não há um lugar para mover pods. N/A Se você espera que o pod seja reprogramado, avalie os requisitos de programação dos pods no nó subutilizado para determinar se podem ser movidos para outro nó no cluster. Para saber mais, consulte Erro: não há lugar para mover os pods.
"no.scale.down.node.pod.not.backed.by.controller"

O pod está bloqueando a redução de escala vertical porque não é apoiado por um controlador.

Especificamente, o escalonador automático de cluster não consegue reduzir a escala vertical de um nó subutilizado porque um pod não tem um controlador reconhecido. Os controladores permitidos incluem ReplicationController, DaemonSet, Job, StatefulSet ou ReplicaSet.

 Nome do pod que está bloqueando. Defina a anotação "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" para o pod ou defina um controlador aceitável.
"no.scale.down.node.pod.has.local.storage" O pod está bloqueando a redução de escala vertical porque tem armazenamento local. Nome do pod que está bloqueando. Defina uma anotação "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" para o pod se os dados no armazenamento local do pod não forem essenciais. Esse erro só ocorre em clusters que usam uma versão anterior à 1.22.
"no.scale.down.node.pod.not.safe.to.evict.annotation" Um pod no nó tem a anotação safe-to-evict=false. Nome do pod que está bloqueando. Se o pod puder ser removido com segurança, edite o manifesto dele e atualize a anotação para "cluster-autoscaler.kubernetes.io/safe-to-evict": "true".
"no.scale.down.node.pod.kube.system.unmovable" O pod está bloqueando a redução de escala vertical porque não tem DaemonSet, não é espelhado e não tem PodDisruptionBudget no namespace kube-system. Nome do pod que está bloqueando.

Por padrão, os pods no namespace kube-system não são removidos pelo escalonador automático de clusters.

Para resolver esse problema, adicione um PodDisruptionBudget para os pods kube-system ou use uma combinação de taints e tolerâncias de pools de nós para separar os pods kube-system dos pods do aplicativo. Para saber mais, consulte Erro: não é possível remover o pod kube-system.
"no.scale.down.node.pod.not.enough.pdb" O pod está bloqueando a redução de escala vertical porque não tem PodDisruptionBudget suficiente. Nome do pod que está bloqueando. Analise o PodDisruptionBudget do pod e considere torná-lo menos restritivo. Para saber mais, consulte Erro: PodDisruptionBudget insuficiente.
"no.scale.down.node.pod.controller.not.found" O pod está bloqueando a redução de escala vertical porque o controlador (por exemplo, uma implantação ou ReplicaSet) não foi encontrado. N/A Para determinar quais ações foram realizadas e deixaram o pod em execução após a remoção do controlador, analise os registros. Para resolver esse problema, exclua o pod manualmente.
"no.scale.down.node.pod.unexpected.error" O pod está bloqueando a redução de escala vertical devido a um erro inesperado. N/A A causa raiz desse erro é desconhecida. Entre em contato com o Cloud Customer Care para realizar uma investigação mais detalhada.

Realizar uma investigação mais detalhada

Nas seções a seguir, fornecemos orientações sobre como usar a Análise de registros e o gcpdiag para ter mais insights sobre os erros.

Investigar erros na Análise de registros

Se você quiser investigar melhor a mensagem, confira os registros específicos do erro:

  1. No console do Google Cloud, acesse a página da Análise de registros.

    Acessar a ferramenta Análise de registros

  2. No painel de consulta, insira o seguinte:

    resource.type="k8s_cluster"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.resultInfo.results.errorMsg.messageId="ERROR_MESSAGE"

    Substitua ERROR_MESSAGE pela mensagem que você quer investigar. Por exemplo, scale.down.error.failed.to.delete.node.min.size.reached.

  3. Clique em Executar consulta.

Depurar alguns erros com o gcpdiag

O gcpdiag é uma ferramenta de código aberto criada com o suporte de engenheiros técnicos do Google Cloud. Não é um produto do Google Cloud com suporte oficial.

Se você receber uma das seguintes mensagens de erro, use gcpdiag para ajudar a resolver o problema:

  • scale.down.error.failed.to.evict.pods
  • no.scale.down.node.node.group.min.size.reached

Para conferir uma lista e descrição de todas as flags da ferramenta gcpdiag, consulte Instruções de uso do gcpdiag.

Resolver erros complexos de redução de escala vertical

As seções a seguir incluem orientações sobre como resolver erros em que as mitigações envolvem várias etapas e erros sem uma mensagem de evento de escalonador automático de clusters associada.

Erro: os nós no cluster atingiram o tamanho mínimo

Se você encontrar os erros a seguir, o escalonador automático de clusters não conseguiu excluir um nó porque o número de nós no cluster já estava no mínimo:

Notificação

A redução em escala vertical do nó subutilizado foi bloqueada porque foram alcançados os limites mínimos de recursos do escalonador automático de clusters.

Evento

"scale.down.error.failed.to.delete.node.min.size.reached"

Para resolver esse problema, revise e atualize os limites mínimos do escalonamento automático:

  1. No Console do Google Cloud, acesse a página de clusters do Kubernetes:

    Acessar clusters do Kubernetes

  2. Clique no nome do cluster identificado na notificação ou no Cloud Logging.

  3. Na página Detalhes do cluster, acesse a guia Nós.

  4. Confira o valor na coluna Número de nós e compare com o número mínimo de nós listados na coluna Escalonamento automático. Por exemplo, se houver quatro a seis nós listados na coluna Escalonamento automático e o número de nós no pool de nós for quatro, o número de pools de nós já será igual ao mínimo. Portanto, o escalonador automático de clusters não poderá reduzir a escala vertical dos nós.

  5. Se a configuração estiver correta e o valor do número de nós for igual ao mínimo definido para o Escalonamento automático, o escalonador automático de clusters estará funcionando corretamente. Se o número mínimo de nós for muito alto para suas necessidades, reduza o tamanho mínimo para que os nós possam ser reduzidos verticalmente.

Erro: não há lugar para mover os pods

Os erros a seguir ocorrem quando o escalonador automático de clusters tenta reduzir o tamanho de um nó, mas não consegue, porque um pod nesse nó não pode ser movido para outro:

Notificação

A redução em escala do nó subutilizado foi bloqueada porque ele tem um pod que não pode ser movido para outro nó do cluster.

Evento

"no.scale.down.node.no.place.to.move.pods"

Se não quiser que esse pod seja reprogramado, essa mensagem é esperada e você não precisa mudar nada. Se quiser que o pod seja reprogramado, investigue as seguintes definições no pod.spec block no manifesto do pod:

  • NodeAffinity: analise os requisitos de programação dos pods no nó subutilizado. Para revisar esses requisitos, examine o manifesto do pod e procure regras NodeAffinity ou NodeSelector. Se o pod tiver um nodeSelector definido e não houver outros nós (de outros pools de nós) no cluster que correspondam a esse seletor, o escalonador automático de clusters não poderá mover o pod para outro nó, o que impede a remoção de nós subutilizados.
  • maxPodConstraint: se maxPodConstraint estiver configurado para qualquer outro número que não seja o padrão 110, confirme se essa foi uma mudança intencional. Diminuir esse valor aumenta a chance de acontecer problemas. O escalonador automático de clusters não pode reprogramar pods para outros nós caso todos os outros nós no cluster já tenham atingido o valor definido em maxPodConstraint, sem deixar espaço para que novos pods sejam programados. Aumentar o valor de maxPodConstraint permite que mais pods sejam programados em nós e o escalonador automático de clusters tenha espaço para reprogramar pods e reduzir verticalmente os nós subutilizados. Ao definir maxPodConstraint, lembre que há aproximadamente 10 pods do sistema em cada nó.
  • hostPort: especificar hostPort para o pod significa que apenas um pod pode ser executado nesse nó. Isso pode dificultar a redução do número de nós pelo escalonador automático de cluster, porque é possível que o pod não consiga se mover para outro nó se a porta dele já estiver em uso. Esse comportamento é esperado.

Erro: o pod kube-system não pode ser movido

Os seguintes erros ocorrem quando um pod do sistema impede a redução de escala vertical:

Notificação

O pod está bloqueando a redução de escala vertical porque não tem DaemonSet, não é espelhado e não tem PodDisruptionBudget no namespace kube-system.

Evento

"no.scale.down.node.pod.kube.system.unmovable"

Um pod no namespace kube-system é considerado um pod do sistema. Por padrão, o escalonador automático de clusters não remove pods no namespace kube-system.

Para resolver esse erro, escolha uma das seguintes soluções:

  • Adicione um PodDisruptionBudget aos pods kube-system. Para mais informações sobre como adicionar manualmente um PodDisruptionBudget para os pods kube-system, consulte as Perguntas frequentes do escalonador automático de clusters do Kubernetes.

    A criação de um PodDisruptionBudget pode afetar a disponibilidade das cargas de trabalho do sistema, fazendo o cluster ficar inativo. O escalonador automático de clusters reprograma essas cargas de trabalho do sistema em diferentes nós de trabalho durante o processo de redução de escala vertical.

  • Use uma combinação de taints e tolerâncias de pools de nós para separar os pods kube-system dos pods do aplicativo. Para mais informações, consulte Provisionamento automático de nós no GKE.

Verificar se os nós têm pods kube-system

Se você não tiver certeza de que os nós estão executando pods kube-system e quiser verificar, siga estas etapas:

  1. Acesse a página da Análise de registros no console do Google Cloud.

    Acessar a ferramenta Análise de registros

  2. Clique em Criador de consultas.

  3. Use a seguinte consulta para encontrar todos os registros de políticas de rede:

    - resource.labels.location="CLUSTER_LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
logName="projects/PROJECT_ID/logs/container.googleapis.com%2Fcluster-autoscaler-visibility"
jsonPayload.noDecisionStatus.noScaleDown.nodes.node.mig.nodepool="NODE_POOL_NAME"

    Substitua:

    • CLUSTER_LOCATION: a região em que o cluster está.
    • CLUSTER_NAME: o nome do cluster.
    • PROJECT_ID: o ID do projeto ao qual o cluster pertence.
    • NODE_POOL_NAME: o nome do pool de nós.

    Se houver pods kube-system em execução no pool de nós, a saída vai incluir:

    "no.scale.down.node.pod.kube.system.unmovable"

Erro: PodDisruptionBudget insuficiente

Os seguintes erros ocorrem quando o PodDisruptionBudget impede a redução de escala:

Notificação

A redução da escala vertical do nó subutilizado está bloqueada porque há um pod em execução sem orçamento de interrupção de pods suficiente para permitir a remoção do pod.

Evento

NoScaleDownNodePodNotEnoughPdb: "no.scale.down.node.pod.not.enough.pdb"

Para saber se um PodDisruptionBudget é muito restritivo, revise as configurações:

kubectl get pdb --all-namespaces

O resultado será assim:

NAMESPACE        NAME    MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
example-app-one  one_pdb       N/A             1                 1               12d
example-app-two  two_pdb       N/A             0                 0               12d

Neste exemplo, os pods que correspondem ao seletor de rótulo two_pdb não serão expulsos pelo escalonador automático de clusters. A configuração maxUnavailable: 0 no PodDisruptionBudget determina que todas as réplicas precisam permanecer disponíveis o tempo todo. Além disso, disruptionsAllowed: 0 proíbe interrupções nesses pods. Consequentemente, os nós que executam esses pods não podem ser reduzidos verticalmente, porque isso causaria uma interrupção e violaria o PodDisruptionBudget.

Se o PodDisruptionBudget estiver funcionando conforme esperado, nenhuma outra ação será necessária. Se você quiser ajustar o PodDisruptionBudget para que os pods em um nó pouco utilizado possam ser movidos, edite o manifesto do PodDisruptionBudget. Por exemplo, se você definiu maxUnavailable como 0, é possível mudar para 1 de modo que o escalonador automático de clusters possa reduzir a escala vertical.

Problema: o nó permanece no status cordoned e não é removido

Erros semelhantes ao seguinte ocorrem quando o escalonador automático de clusters não consegue reduzir o tamanho do pool de nós porque a conta de serviço do Google não tem o papel de editor:

Required 'compute.instanceGroups.update' permission for 'INSTANCE_GROUP_NAME'.

Um sintoma comum desse problema é quando o escalonador automático de clusters tenta reduzir o tamanho do pool de nós, mas o nó não muda de status.

Para resolver esse problema, verifique se a conta de serviço padrão (PROJECT_NUMBER@cloudservices.gserviceaccount.com) tem o papel de editor (roles/editor) no projeto. Se a conta de serviço não tiver esse papel, adicione-o agora. O GKE usa essa conta de serviço para gerenciar os recursos do seu projeto. Para saber como fazer isso, consulte Conceder ou revogar um único papel na documentação do IAM.

A seguir