Todos os produtos
Search

Este produto

    Container Service for Kubernetes:Cluster management FAQ

    Central de documentação

    Container Service for Kubernetes:Cluster management FAQ

    Última atualização: Jun 27, 2026

    Este tópico descreve problemas comuns e soluções relacionados à criação, ao uso e ao gerenciamento de clusters.

    Como migro um cluster Kubernetes autogerenciado para o ACK?

    O Container Service for Kubernetes (ACK) da Alibaba Cloud fornece uma solução contínua para migrar clusters Kubernetes autogerenciados para clusters ACK. Essa solução garante que seus negócios não sejam afetados durante a migração. Para obter mais informações, consulte Visão geral da solução de migração do Kubernetes.

    Clusters com o sistema operacional Alibaba Cloud Linux são compatíveis com imagens de contêiner CentOS?

    Sim, são compatíveis. Clusters que executam Alibaba Cloud Linux são compatíveis com imagens de contêiner baseadas em CentOS. Para obter mais informações, consulte Alibaba Cloud Linux 3.

    Se eu escolher o runtime de contêiner containerd ao criar um cluster, poderei alterá-lo para Docker posteriormente?

    Não, não é possível. Após a criação de um cluster, você não pode alterar seu runtime de contêiner. No entanto, é possível criar pools de nós que usam runtimes de contêiner diferentes dentro do mesmo cluster. Para obter mais informações, consulte Criar e gerenciar pools de nós.

    Para migrar o runtime de contêiner de um nó de Docker para containerd, consulte Migrar o runtime de contêiner de um nó de Docker para containerd.

    Nota

    O Docker não é suportado como runtime de contêiner integrado para clusters que executam Kubernetes 1,24 ou posterior. Você deve usar o containerd como runtime do pool de nós para esses clusters.

    Quais são as diferenças entre os runtimes de contêiner containerd, Docker e sandboxed?

    Container Service for Kubernetes suporta três runtimes: containerd, Docker e Sandboxed-Container. Recomendamos o uso do containerd como runtime de contêiner. Você pode usar o Docker como runtime de contêiner em clusters que executam Kubernetes 1,22 e anteriores. O Sandboxed-Container pode ser usado como runtime de contêiner em clusters que executam Kubernetes 1,24 e anteriores. Para comparar esses runtimes, consulte Comparação dos runtimes containerd, Sandboxed-Container e Docker. Se o seu cluster usa Docker como runtime de contêiner, você deve migrar o runtime para containerd antes de atualizar a versão do Kubernetes do cluster para 1,24 ou posterior. Para obter mais informações, consulte Migrar o runtime de contêiner do nó de Docker para containerd.

    O Container Service for Kubernetes (ACK) possui certificação MLPS 2.0 Nível 3?

    Sim, possui. Você pode ativar a proteção classificada para seu cluster e configurar políticas de verificação de linha de base. Com base no Alibaba Cloud Linux, é possível implementar o MLPS 2.0 Nível 3 e configurar verificações de linha de base de conformidade de proteção classificada para atender aos seguintes requisitos:

    • Autenticação de identidade

    • Controle de acesso

    • Auditoria de segurança

    • Prevenção de intrusão

    • Prevenção de código malicioso

    Para obter mais informações, consulte Instruções de endurecimento MLPS do ACK.

    Um cluster ACK suporta Istio?

    Sim, suporta. Você pode usar o Service Mesh da Alibaba Cloud (ASM). O ASM é um produto de service mesh totalmente compatível com o Istio da comunidade. Ele fornece um plano de controle totalmente gerenciado que permite focar no desenvolvimento e na implantação de seus aplicativos de negócios. O ASM suporta vários sistemas operacionais para nós ACK e diversos plug-ins de rede implantados no cluster. Adicione um cluster ACK existente a uma instância ASM para usar recursos como gerenciamento de tráfego, tratamento de falhas, monitoramento unificado e gerenciamento de logs. Para obter mais informações, consulte Adicionar um cluster a uma instância ASM. Para obter informações sobre o faturamento do ASM, consulte Faturamento do ASM.

    Como coleto informações de diagnóstico para um cluster Kubernetes?

    Se um cluster Kubernetes apresentar problemas ou um nó estiver anormal, use o recurso de diagnóstico fornecido pelo ACK para ajudar a localizar problemas no cluster. Para obter mais informações, consulte Usar diagnósticos de cluster.

    Caso o recurso de diagnóstico do cluster não atenda às suas necessidades, colete informações de diagnóstico dos nós mestres e dos nós trabalhadores anormais. Siga as etapas abaixo para coletar informações de nós Linux ou Windows.

    Coletar informações de diagnóstico de um nó Linux

    Nós trabalhadores podem executar Linux ou Windows, mas nós mestres só podem executar Linux. O método a seguir aplica-se tanto a nós mestres quanto a nós trabalhadores que executam Linux. Este exemplo usa um nó mestre.

    1. Faça login em um nó mestre do cluster Kubernetes e execute o comando a seguir para baixar o script de diagnóstico.

      curl -o /usr/local/bin/diagnose_k8s.sh http://aliacs-k8s-cn-hangzhou.oss-cn-hangzhou.aliyuncs.com/public/diagnose/diagnose_k8s.sh
      Nota

      O script de diagnóstico para nós Linux só pode ser baixado da região China (Hangzhou).

    2. Execute o comando a seguir para conceder permissões de execução ao script de diagnóstico.

      chmod u+x /usr/local/bin/diagnose_k8s.sh

    3. Execute o comando a seguir para mudar para o diretório especificado.

      cd /usr/local/bin

    4. Execute o comando a seguir para executar o script de diagnóstico.

      diagnose_k8s.sh

      A saída a seguir é retornada. O nome do arquivo de log gerado pelo script de diagnóstico varia. Neste exemplo, o arquivo é chamado diagnose_1514939155.tar.gz.

      ......
+ echo 'please get diagnose_1514939155.tar.gz for diagnostics'
please get diagnose_1514939155.tar.gz for diagnostics
+ echo 'Please upload diagnose_1514939155.tar.gz'
Please upload diagnose_1514939155.tar.gz

    5. Execute o comando a seguir para visualizar o arquivo que armazena as informações de diagnóstico do cluster.

      ls -ltr | grep diagnose_1514939155.tar.gz
      Nota

      Substitua diagnose_1514939155.tar.gz pelo nome real do arquivo de log.

    Coletar informações de diagnóstico de um nó Windows

    Para coletar informações de diagnóstico de um nó trabalhador que executa Windows, baixe e execute o script de diagnóstico.

    Nota

    O Windows só pode ser usado para nós trabalhadores.

    1. Faça login no nó trabalhador anormal e abra a interface de linha de comando.

    2. Execute o comando a seguir para entrar no modo PowerShell.

      powershell

    3. Execute o comando a seguir para baixar e executar o script de diagnóstico.

      O script de diagnóstico para nós Windows pode ser baixado da região onde o cluster reside. Substitua [$Region_ID] no comando pelo ID real da região.

      Invoke-WebRequest -UseBasicParsing -Uri http://aliacs-k8s-[$Region_ID].oss-[$Region_ID].aliyuncs.com/public/pkg/windows/diagnose/diagnose.ps1 | Invoke-Expression

      A saída a seguir indica que as informações de diagnóstico foram coletadas.

      INFO: Compressing diagnosis clues ...
INFO: ...done
INFO: Please get diagnoses_1514939155.zip for diagnostics
      Nota

      O arquivo diagnoses_1514939155.zip é salvo no diretório onde o script é executado.

    Como soluciono problemas em um cluster ACK?

    1. Verificar nós do cluster

    1. Execute o comando a seguir para visualizar o status dos nós no cluster. Confirme se todos os nós existem e estão no estado Ready.

      kubectl get nodes

      A saída esperada é semelhante à seguinte. p

      • Se todos os nós existirem e estiverem no estado Ready, os nós do cluster estão normais.

      • Se um nó estiver anormal, prossiga para a Etapa 2.

    2. Execute o comando a seguir para visualizar informações detalhadas e eventos de um nó.

      Substitua [$NODE_NAME] pelo nome do seu nó.

      kubectl describe node [$NODE_NAME]
      Nota

      Para obter informações sobre a saída do kubectl, consulte Status do nó.

    2. Verificar componentes do cluster

    Se não for possível identificar o problema após verificar os nós do cluster, prossiga para verificar os logs dos componentes no plano de controle.

    1. Execute o comando a seguir para visualizar todos os componentes no namespace kube-system.

      kubectl get pods -n kube-system

      A saída esperada é a seguinte. 1 Pods com nomes que começam com kube- são componentes do sistema do cluster Kubernetes. Pods com nomes que começam com coredns- são plug-ins de DNS. A saída esperada indica que os componentes estão em estado normal. Se um componente estiver em estado anormal, prossiga para a próxima etapa.

    2. Execute o comando a seguir para visualizar os logs do componente anormal e localizar e resolver o problema.

      Substitua [$Component_Name] pelo nome do componente anormal.

      kubectl logs -f [$Component_Name] -n kube-system

    3. Verificar o componente kubelet

    1. Execute o comando a seguir para verificar o status do kubelet.

      systemctl status kubelet

    2. Se o status do kubelet não for active (running), execute o comando a seguir para visualizar os logs do kubelet e localizar e resolver o problema.

      journalctl -u kubelet

    Problemas comuns de cluster

    A tabela a seguir lista algumas causas comuns de falhas em clusters ACK e suas soluções.

    Cenários de solução de problemas

    Solução

    O componente API Server ou um componente mestre para de executar:

    • Não é possível criar, parar ou atualizar recursos, como pods, serviços e deployments.

    • Pods e serviços existentes continuam em execução, a menos que precisem chamar APIs ACK, como o Kubernetes Dashboard.

    Os componentes ACK possuem recursos integrados de alta disponibilidade. Verifique se o próprio componente está anormal. Por exemplo, o API Server de um cluster ACK usa uma instância SLB por padrão. Solucione problemas na instância SLB para determinar a causa do status anormal.

    Dados de backend do API Server são perdidos:

    • O API Server não consegue iniciar.

    • Pods e serviços existentes continuam em execução, a menos que precisem chamar APIs ACK, como o Kubernetes Dashboard.

    • Você deve recuperar ou reconstruir os dados do API Server para iniciar o API Server.

    Se você criou um snapshot, restaure os dados a partir dele para resolver o problema. Caso não tenha criado um snapshot, envie um ticket. Após a resolução do problema, use os métodos a seguir para evitar que ele se repita:

    Um nó individual é desligado e todos os pods nesse nó param de executar.

    Use cargas de trabalho, como deployments, StatefulSets ou DaemonSets, para criar pods em vez de criá-los diretamente. Isso evita que os pods falhem ao serem agendados para outros nós íntegros.

    O componente kubelet falha:

    • Não é possível criar pods no nó com o kubelet anormal.

    • O kubelet pode ter excluído incorretamente alguns pods.

    • O nó é marcado como Unhealthy.

    • Um deployment ou ReplicationController cria novos pods em outros nós.

    • Se você criou um snapshot antes da ocorrência do problema, restaure os dados a partir dele para resolvê-lo. Caso não tenha criado um snapshot, envie um ticket para relatar o problema. Após a resolução, crie snapshots regularmente para os volumes gerenciados pelo kubelet. Para obter mais informações, consulte Criar um snapshot para um único volume de disco.

    • Utilize cargas de trabalho, como deployments, StatefulSets ou DaemonSets, para criar pods em vez de criá-los diretamente. Isso impede que os pods falhem ao serem agendados para outros nós íntegros.

    Configuração incorreta ou outros problemas.

    Se você criou um snapshot antes da ocorrência do problema, restaure os dados a partir dele para resolvê-lo. Caso não tenha criado um snapshot, envie um ticket para relatar o problema. Após a resolução, crie snapshots regularmente para os volumes gerenciados pelo kubelet. Para obter mais informações, consulte Criar um snapshot para um único volume persistente de disco em nuvem.

    Como concedo permissões refinadas quando um usuário RAM opera um cluster ACK?

    1. Por padrão, usuários RAM e funções RAM não têm permissão para usar a OpenAPI dos serviços da Alibaba Cloud. Conceda a eles a permissão de sistema AliyunCSFullAccess para o Container Service ou as permissões personalizadas necessárias para usar e gerenciar clusters ACK. Para obter mais informações, consulte Conceder permissões de acesso a clusters e recursos em nuvem usando RAM.

    2. Com base no mecanismo RBAC do Kubernetes, você deve usar RBAC para conceder permissões a usuários RAM para gerenciar recursos dentro do cluster, como criar deployments e serviços.

      Para cenários que exigem controle refinado sobre permissões de leitura e gravação de recursos, use ClusterRoles e Roles personalizados para configurar permissões RBAC mais granulares. Para obter mais informações, consulte Usar RBAC personalizado para restringir operações em recursos de um cluster.

    3. Quando um usuário RAM acessa o console, conceda também as permissões necessárias para os serviços relevantes da Alibaba Cloud para usar recursos como visualização de atividades de dimensionamento de pool de nós e painéis de cluster. Para obter mais informações, consulte Dependências de permissão do console do Container Service.

    Ao configurar a política de controle de acesso para a instância SLB do API Server de um cluster, quais faixas de endereços IP precisam ser permitidas?

    As regras da lista de controle de acesso (ACL) para a instância SLB do API Server devem permitir as seguintes faixas de endereços IP.

    • O bloco CIDR 100.104.0.0/16, reservado para o plano de controle do Container Service for Kubernetes.

    • Os blocos CIDR primário e adicionais da Virtual Private Cloud (VPC) do cluster, ou os blocos CIDR dos vSwitches onde os nós do cluster residem.

    • Os blocos CIDR de saída dos clientes que precisam acessar o servidor de API.

    • Para clusters ACK Edge, adicione também os blocos CIDR de saída dos nós de borda.

    • Para clusters ACK Lingjun, adicione também os blocos CIDR do Virtual Private Datacenter (VPD) Lingjun.

    Para obter mais informações, consulte Configurar a política de controle de acesso para o API Server.

    Como a alta disponibilidade é garantida para o plano de controle de um cluster gerenciado ACK?

    O plano de controle de um cluster gerenciado ACK é hospedado pela Alibaba Cloud. A Alibaba Cloud fornece configurações recomendadas de alta disponibilidade para dimensões do plano de dados, como nós, pools de nós, cargas de trabalho e Server Load Balancer, para ajudar você a construir arquiteturas de cluster e aplicativos seguras e confiáveis. Para obter mais informações, consulte Configurações recomendadas para arquitetura de alta disponibilidade de cluster.

    O nome de domínio do API Server de um cluster ACK gerenciado pode ser resolvido entre VPCs?

    Não, não pode. Por padrão, o nome de domínio do API Server de um cluster ACK, apiserver.<cluster-id>.<region-id>.cs.aliyuncs.com, é resolvido usando O que é Private DNS?. O registro DNS é válido apenas na VPC onde o cluster está localizado e não pode ser resolvido a partir de outra VPC.

    Para resolver o nome de domínio entre VPCs, siga as instruções em Associar VPCs entre contas para adicionar a conta da Alibaba Cloud. Em seguida, envie um ticket e forneça as informações da VPC para concluir o anexo.

    Por que a resolução do nome de domínio do API Server falha para um cluster gerenciado ACK?

    O ACK registra o nome de domínio do API Server de um cluster gerenciado ACK no O que é Private DNS?. A resolução do nome de domínio do API Server pode falhar se um nó usar um servidor DNS personalizado em vez dos servidores DNS padrão da Alibaba Cloud, 100.100.2.136 e 100.100.2.138.

    Nesse caso, defina os servidores upstream para o nome de domínio do API Server (apiserver.<cluster-id>.<region-id>.cs.aliyuncs.com) como 100.100.2.136 e 100.100.2.138.

    Se o servidor DNS personalizado e o cluster gerenciado ACK estiverem em VPCs diferentes, envie um ticket para configurar a resolução entre VPCs.

    A instância CLB criada automaticamente para um API Server de cluster gerenciado ACK pode ser reutilizada?

    Não. O CLB de rede interna para o API Server atua como o ponto de entrada principal para o plano de controle e é dedicado ao API Server. Reutilizar a instância ou modificar sua configuração, como adicionar listeners ou alterar grupos de servidores backend, pode interromper o acesso ao API Server e comprometer a estabilidade do cluster. Não modifique esta instância CLB.

    Como acesso um nó mestre?

    • ACK dedicated cluster: Para obter mais informações, consulte Conectar-se ao nó mestre de um cluster dedicado ACK usando SSH.

    • ACK managed cluster: Os nós do plano de controle de um ACK managed cluster são totalmente gerenciados. Não é possível fazer login nos terminais dos nós do plano de controle. Para fazer login nos nós do plano de controle, considere usar um ACK dedicated cluster.

    Se eu excluir acidentalmente um nó mestre de um ACK dedicated cluster, ainda poderei atualizar o cluster?

    Não, não poderá. Após excluir um nó mestre de um ACK dedicated cluster, não é possível adicionar nós mestres ou atualizar o cluster. Você pode criar um cluster dedicado ACK (Descontinuado).

    Posso adicionar ou remover nós mestres de um ACK dedicated cluster? Quais são as operações de alto risco?

    Não, não pode. Adicionar ou remover nós mestres de um ACK dedicated cluster pode tornar o cluster inutilizável e irrecuperável.

    Para os nós mestres de um ACK dedicated cluster, operações inadequadas podem causar a indisponibilidade dos nós mestres ou até mesmo de todo o cluster. Operações de alto risco incluem substituir certificados mestre ou etcd, modificar componentes principais, excluir ou formatar dados em diretórios principais como /etc/kubernetes em um nó, ou reinstalar o sistema operacional. Para obter mais informações, consulte Operações de alto risco relacionadas a cluster.

    O que devo fazer se o ACK dedicated cluster API Server retornar o erro "api/v1/namespaces/xxx/resourcequotes": x509: certificate has expired or is not yet valid: current time XXX is after xxx?

    Sintomas

    Ao criar um pod em um ACK dedicated cluster, o API Server retorna um erro de expiração de certificado, ou os logs ou eventos do kube-controller-manager mostram um erro de expiração de certificado. A mensagem de erro é a seguinte.

    "https://localhost:6443/api/v1/namespaces/xxx/resourcequotes": x509: certificate has expired or is not yet valid: current time XXX is after XXX
    "https://[::1]:6443/api/v1/namespaces/xxx/resourcequotes": x509: certificate has expired or is not yet valid: current time XXX is after XXX

    Causa

    No Kubernetes, o API Server possui um certificado integrado para seu servidor interno LoopbackClient. Na versão da comunidade, este certificado tem um período de validade de um ano e não pode ser rotacionado automaticamente. Ele é rotacionado e atualizado automaticamente apenas quando o pod do API Server reinicia. Se a versão do Kubernetes não for atualizada por mais de um ano, o certificado interno expira, o que causa falhas nas solicitações de API. Para obter mais informações, consulte #86552.

    Para reduzir o risco causado pelo curto período de validade dos certificados em clusters ACK que executam Kubernetes 1,24 ou posterior, o período de validade padrão dos certificados integrados foi estendido para 10 anos. Para obter mais informações, consulte Alteração de produto: Alteração no período de validade dos certificados internos do API Server de cluster ACK.

    Solução

    Faça login em um nó mestre e execute o comando a seguir para consultar o horário de expiração do certificado LoopbackClient.

    No comando, XX.XX.XX.XX é o endereço IP local do nó mestre.

    curl --resolve apiserver-loopback-client:6443:XX.XX.XX.XX -k -v https://apiserver-loopback-client:6443/healthz 2>&1 |grep expire

    • Para clusters com certificados de 1 ano que expiraram ou estão prestes a expirar, atualize o cluster para a versão 1,24 ou posterior. Para obter mais informações, consulte Atualizar manualmente um cluster. Recomendamos migrar para uma instância ACK Managed Cluster Pro. Para obter mais informações, consulte Migrar a quente um cluster dedicado ACK para um ACK Managed Cluster Pro.

    • Para clusters dedicados ACK que não podem ser atualizados a curto prazo, faça login em cada nó mestre e reinicie manualmente o API Server para gerar um novo certificado válido.

      • Nó containerd

        crictl pods  |grep kube-apiserver- | awk '{print $1}' | xargs -I '{}' crictl stop {}

      • Nó Docker

        docker ps | grep kube-apiserver- | awk '{print $1}' | xargs -I '{}' docker restart {}