Partilhar via

Problemas conhecidos com o motor do AKS no Azure Stack Hub

  • Artigo

Este artigo descreve problemas conhecidos do motor do AKS no Azure Stack Hub.

Segredo expirado do principal de serviço (SPN) faz com que o cluster falhe

  • Aplicável a: este problema aplica-se a todas as versões.

  • Descrição: quando o segredo expirar para o SPN, o cluster falhará. Isto afetará todos os clusters kubernetes que foram implementados com o motor AKS. Quando o segredo expirar, o cluster não estará funcional.

  • Remediação: para mitigar o problema, inicie sessão em cada nó kubernetes para atualizar o ficheiro de configuração /etc/kubernetes/azure.json com um novo ID da Aplicação SPN e um segredo não atualizado. Poderá ter de contactar o operador cloud do Azure Stack Hub para obter um SPN e um segredo atual. Para obter instruções, consulte Utilizar uma identidade de aplicação para aceder aos recursos

    1. Pode utilizar os seguintes comandos nos nós do Linux:

      sudo sed -i s/f072c125-c99c-4781-9e85-246b981cd52b/094b1318-baea-4584-bf9c-4a40501ce21b/1 /etc/kubernetes/azure.json

    2. Reinicie o kubelet serviço com o seguinte comando:

      sudo systemctl reboot node

    Também pode utilizar o SPN e o segredo com o modelo de API e forçar uma atualização. Para obter instruções, veja Forçar uma atualização.

  • Ocorrência: Comum

Certificados expirados para o proxy frontal

  • Aplicável a: este problema aplica-se a todas as versões.
  • Descrição: quando o certificado expirar, kubectl topo servidor de métricas poderá deixar de funcionar.
  • Remediação: terá de renovar o certificado. Pode encontrar os passos em Rodar certificados do Kubernetes no Azure Stack Hub
  • Ocorrência: Comum

Limite de 50 nós por subscrição

  • Aplicável a: Azure Stack Hub, motor AKS (tudo)
  • Descrição: ao criar clusters, tem de garantir que não existem mais de 50 nós do Kubernetes (nós do plano de controlo e do agente) implementados por subscrições. O total de nós do Kubernetes implementados em todos os clusters numa única subscrição não deve exceder os 50 nós.
  • Remediação: utilize menos de 51 nós na sua subscrição.
  • Ocorrência: ao tentar adicionar mais de 50 nós por subscrição.

Não é possível redimensionar VMs de cluster com o serviço de Computação

  • Aplicável a: Azure Stack Hub, motor AKS (tudo)
  • Descrição: o redimensionamento de VMs de cluster através do serviço de Computação não funciona com o motor do AKS. O motor do AKS mantém o estado do cluster no ficheiro JSON do modelo de API. Para garantir que o tamanho pretendido da VM se reflete em qualquer operação de criação, atualização ou dimensionamento efetuada com o motor AKS, atualize o modelo de API antes de executar qualquer uma dessas operações. Por exemplo, se alterar o tamanho de uma VM num cluster já implementado para um tamanho diferente com o serviço de Computação, o estado é perdido quando aks-engine upgrade é executado.
  • Remediação: para que isto funcione, localize o modelo de API para o cluster, altere o tamanho e, em seguida, execute aks-engine upgrade.
  • Ocorrência: ao tentar redimensionar com o serviço de Computação.

A operação de desanexação do disco falha no motor AKS 0.55.0

  • Aplicável a: Azure Stack Hub (atualização 2005), motor AKS 0.55.0
  • Descrição: quando tenta eliminar uma implementação que contém volumes persistentes, a operação de eliminação aciona uma série de erros de anexação/desanexação. Este problema deve-se a um erro no fornecedor de cloud do motor AKS v0.55.0. O fornecedor de cloud chama o Azure Resource Manager através de uma versão da API mais recente do que a versão Azure Resource Manager no Azure Stack Hub (atualização 2005) suporta atualmente.
  • Remediação: para obter detalhes e passos de mitigação, veja o repositório do GitHub do motor AKS (problema 3817). Atualize assim que estiver disponível uma nova compilação do motor do AKS e da imagem correspondente.
  • Ocorrência: ao eliminar uma implementação que contém volumes persistentes.

Problemas de atualização no motor AKS 0.51.0

  • Durante a atualização do motor AKS de um cluster do Kubernetes da versão 1.15.x para 1.16.x, atualizar os seguintes componentes do Kubernetes requer passos manuais adicionais: kube-proxy, azure-cni-networkmonitor, csi-secrets-store, kubernetes-dashboard. As seguintes informações descrevem o que poderá ver e como contornar os problemas.

    • Em ambientes ligados, este problema não é óbvio, uma vez que não existem sinais no cluster de que os componentes afetados não foram atualizados. Tudo parece funcionar conforme esperado.

      kubectl get pods -n kube-system

    • Como solução para resolver este problema para cada um destes componentes, execute o comando na coluna Solução na tabela seguinte.

      Nome do Componente Solução Cenários Afetados
      kube-proxy kubectl delete ds kube-proxy -n kube-system Ligado, Desligado
      azure-cni-networkmonitor kubectl delete ds azure-cni-networkmonitor -n kube-system Ligado, Desligado
      csi-secrets-store sudo sed -i s/Always/IfNotPresent/g /etc/kubernetes/addons/secrets-store-csi-driver.yaml
      kubectl delete ds csi-secrets-store -n kube-system      		 Desligado
      kubernetes-dashboard Execute o seguinte comando em cada nó do plano de controlo:
      sudo sed -i s/Always/IfNotPresent/g /etc/kubernetes/addons/kubernetes-dashboard.yaml      		 Desligado

  • O Kubernetes 1.17 não é suportado nesta versão. Embora existam pedidos Pull (PR) do GitHub que referenciam a versão 1.17, não é suportado.

O nó de cluster muda para o estado "Não Pronto" e k8s-kern.log contém a mensagem "Grupo de memória sem memória"

  • Aplicável a: Azure Stack Hub, motor AKS (tudo)

  • Descrição: um nó de cluster move-se para o estado "Não Pronto" e o ficheiro k8s-kern.log contém a mensagem Memory cgroup out of memory. Este problema aplica-se a todas as versões do motor AKS. Para verificar se este problema está a ocorrer no seu sistema, pesquise no ficheiro k8s-kern.log a cadeia "Grupo de memória sem memória".

    Pode encontrar o ficheiro k8s-kern.log ao:

    • Executar aks-engine get-logs e navegar para ${NODE_NAME}/var/log/k8s-kern.log, OR
    • Navegar para /var/log/kern.log no sistema de ficheiros de nó.

  • Remediação: para nós do plano de controlo, aumente o tamanho da VM do perfil principal. Para nós de agente, aumente o tamanho da VM do conjunto de nós ou aumente verticalmente o conjunto de nós. Para aumentar verticalmente o conjunto de nós, execute o comando documentado scale e siga as instruções.

    Para aumentar o tamanho de uma VM do conjunto, atualize o modelo de API e execute aks-engine upgrade. Todas as VMs são eliminadas e recriadas com o novo tamanho da VM.

  • Ocorrência: quando a memória necessária/consumida pelo nó de cluster excede a memória disponível.

Passos seguintes

Descrição geral do motor AKS no Azure Stack Hub