Perguntas frequentes sobre o AKS

O AKS fornece garantias de SLA no Tipo de preço Standard com o recurso de SLA de tempo de atividade.

O suporte à plataforma é um plano de suporte reduzido para clusters de versão “N-3” sem suporte. O suporte à plataforma inclui apenas suporte à infraestrutura do Azure.

Para mais informações, consulte a política de suporte à plataforma.

Sim, o AKS inicia atualizações automáticas para clusters sem suporte. Quando um cluster em uma versão n-3 (em que n é a versão secundária mais recente do AKS em GA com suporte) está prestes a cair para n-4, o AKS atualiza automaticamente o cluster para n-2 para permanecer em uma política de suporte do AKS.

Para mais informações, confira Versões do Kubernetes com suporte, Janelas de manutenção planejada e Atualizações automáticas.

Sim, o AKS dá suporte a contêineres do Windows Server. Para obter mais informações, consulte as Perguntas frequentes sobre o AKS do Windows Server.

Os nós do agente do AKS são cobrados como máquinas virtuais padrão do Azure. Se você comprou reservas do Azure para o tamanho da VM que está usando no AKS, esses descontos são aplicados automaticamente.

Não, mover seu cluster do AKS entre locatários atualmente não tem suporte.

Não, atualmente não há suporte para a movimentação do cluster do AKS entre assinaturas.

Não, não há suporte para mover ou renomear seu cluster do AKS e seus recursos associados.

Não, você não pode restaurar seu cluster após excluí-lo. Quando você exclui o cluster, o grupo de recursos do nó e todos os recursos contidos nele também são excluídos.

Se você quiser manter recursos, mova-os para outro grupo de recursos antes de excluir o cluster. Caso deseje fornecer proteção contra exclusões acidentais, bloqueie o grupo de recursos gerenciado do AKS que hospeda seus recursos de cluster usando a opção Bloqueio do grupo de recursos do nó.

Você pode parar completamente um cluster do AKS em execução ou escalar ou ajustar automaticamente todos ou pools de nós User específicos para zero.

Não é possível dimensionar diretamente os pools de nós do sistema para zero.

Não, operações de dimensionamento usando as APIs do Conjunto de Dimensionamento de Máquinas Virtuais não têm suporte. Você pode usar as APIs do AKS (az aks scale).

Não, operações de dimensionamento usando as APIs do Conjunto de Dimensionamento de Máquinas Virtuais não têm suporte. Em vez disso, você pode usar a API AKS para dimensionar pools de nós que não sejam do sistema para zero ou parar o cluster.

Não, esta não é uma configuração com suporte. Em vez disso, pare o cluster.

O AKS baseia-se em muitos recursos da infraestrutura do Azure, incluindo os Conjuntos de Dimensionamento de Máquinas Virtuais, redes virtuais e discos gerenciados. Essas integrações permitem que você aplique muitas das funcionalidades básicas da plataforma Azure no ambiente do Kubernetes gerenciado fornecido pelo AKS. Por exemplo, a maioria dos tipos de máquinas virtuais do Azure pode ser usada diretamente com o AKS e as Reservas do Azure podem ser usadas para receber descontos nesses recursos automaticamente.

Para habilitar essa arquitetura, cada implantação do AKS abrange dois grupos de recursos:

1. Você cria o primeiro grupo de recursos. Esse grupo contém apenas o recurso do Serviço de Kubernetes. O provedor de recursos do AKS cria automaticamente o segundo grupo de recursos durante a implantação. Um exemplo do segundo grupo de recursos é MC_myResourceGroup_myAKSCluster_eastus. Para obter informações sobre como especificar o nome desse segundo grupo de recursos, confira a próxima seção.
2. O segundo grupo de recursos, conhecido como o grupo de recursos do nó, contém todos os recursos de infraestrutura associados ao cluster. Esses recursos incluem as máquinas virtuais do nó do Kubernetes, rede virtual e armazenamento. Por padrão, o grupo de recursos do nó tem um nome como MC_myResourceGroup_myAKSCluster_eastus. O AKS exclui automaticamente o grupo de recursos do nó sempre que você exclui o cluster. Você só deve usar esse grupo de recursos para recursos que compartilham o ciclo de vida do cluster.

Por padrão, o AKS nomeia o grupo de recursos do nó MC_resourcegroupname_clustername_location, mas você pode fornecer seu próprio nome.

Para especificar um nome do grupo de recursos, instale a extensão da CLI do Azure aks-preview versão 0.3.2 ou posterior. Quando você cria um cluster do AKS usando o comando [az aks create][az-aks-create], use o parâmetro --node-resource-group e especifique um nome para o grupo de recursos. Se você usar um modelo do Azure Resource Manager para implantar um cluster do AKS, defina o nome do grupo de recursos usando a propriedade nodeResourceGroup.

• O provedor de recursos do Azure cria automaticamente o grupo de recursos secundário.
• Você poderá especificar um nome de grupo de recursos personalizado somente quando estiver criando o cluster.

Ao trabalhar com o grupo de recursos do nó, tenha em mente que não é possível:

• Especificar um grupo de recursos existente para o grupo de recursos do nó.
• Especificar uma assinatura diferente para o grupo de recursos do nó.
• Alterar o nome do grupo de recursos do nó depois que o cluster for criado.
• Especificar nomes para os recursos gerenciados dentro do grupo de recursos do nó.
• Modificar ou excluir marcas criadas pelo Azure de recursos gerenciados dentro do grupo de recursos do nó.

Você pode se deparar com erros inesperados de escala e atualização se modificar ou excluir marcas criadas pelo Azure e outras propriedades de recursos no grupo de recursos do nó. O AKS permite criar e modificar marcas personalizadas criadas por usuários finais, e você pode adicionar essas marcas ao criar um pool de nós. O ideal é criar ou modificar marcas personalizadas, por exemplo, para atribuir uma unidade de negócios ou um centro de custo. Outra opção é criar políticas do Azure com um escopo no grupo de recursos gerenciados.

As marcas criadas pelo Azure são criadas para os respectivos Serviços do Azure e sempre devem ser permitidas. Para o AKS, existem as marcas aks-managed e k8s-azure. A modificação quaisquer Marcas criadas pelo Azure nos recursos do grupo de recursos do nó no cluster do AKS é uma ação não suportada, que quebra o objetivo do nível de serviço (SLO).

Para obter uma lista completa das regiões disponíveis, confira Regiões e disponibilidade do AKS.

Não, os clusters do AKS são recursos regionais e não podem abranger várias regiões. Confira Melhores práticas de continuidade dos negócios e recuperação de desastres para obter diretrizes sobre como criar uma arquitetura que inclui várias regiões.

Sim, você pode implantar um cluster do AKS em uma ou mais zonas de disponibilidade nas regiões que lhes dão suporte.

Sim, você pode usar diferentes tamanhos de máquina virtual no seu cluster do AKS criando vários pools de nós.

O AKS não define um limite para o tamanho da imagem de contêiner. No entanto, é importante entender que quanto maior a imagem, maior a demanda de memória. Potencialmente, um tamanho maior poderia exceder os limites de recursos ou a memória geral disponível dos nós de trabalho. Por padrão, a memória para o tamanho da VM Standard_DS2_v2 para um cluster do AKS é definida como 7 GiB.

Quando uma imagem de contêiner é grande demais, como no intervalo de Terabyte (TBs), o kubelet pode não ser capaz de efetuar pull dela do registro de contêiner para um nó devido à falta de espaço em disco.

Para os nós do Windows Server, o Windows Update não executa e aplica automaticamente as atualizações mais recentes. Regularmente, de acordo com o ciclo de lançamento do Windows Update e o próprio processo de validação, você deverá executar uma atualização no cluster e nos pools de nó do Windows Server no cluster do AKS. Esse processo de atualização cria nós que executam a imagem e os patches mais recentes do Windows Server e, em seguida, remove os nós mais antigos. Para obter mais informações sobre esse processo, confira Atualizar um pool de nós no AKS.

As imagens a seguir têm requisitos funcionais para "Executar como Raiz" e as exceções devem ser arquivadas para qualquer política:

• mcr.microsoft.com/oss/kubernetes/coredns
• mcr.microsoft.com/azuremonitor/containerinsights/ciprod
• mcr.microsoft.com/oss/calico/node
• mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

Sim, há duas opções para limitar o acesso ao servidor da API:

• Usar intervalos de IP autorizados do servidor de API se você quiser manter um ponto de extremidade público para o servidor de API, mas quiser restringir o acesso a um conjunto de intervalos de IP confiáveis.
• Use um cluster privado se desejar limitar o servidor de API para ser acessível apenas de dentro de sua rede virtual.

O AKS aplica patches em CVEs que têm uma "correção de fornecedor" toda semana. As CVEs sem correção estão aguardando uma “correção de fornecedor” antes de serem corrigidas. As imagens do AKS são atualizadas automaticamente dentro de 30 dias. Recomendamos que você aplique uma Imagem de Nó atualizada regularmente para garantir que as imagens com patches aplicados mais recentemente e os patches de SO sejam aplicados e atuais. Você pode fazer isso usando um dos seguintes métodos:

• Manualmente, por meio do portal do Azure ou da CLI do Azure.
• Atualizando o cluster AKS. O cluster atualiza automaticamente nós de cordon e frenagem e coloca um novo nó online com a última imagem do Ubuntu e uma nova versão de patch ou uma versão secundária do Kubernetes. Para obter mais informações, confira Atualizar um cluster do AKS.
• Usando a atualização de imagem de nó.

A Microsoft fornece orientação sobre outras ações que você pode tomar para proteger suas cargas de trabalho através de serviços como o Microsoft Defender para contêineres. A ameaça de segurança a seguir está relacionada ao AKS e ao Kubernetes que você deve conhecer:

• Novos destinos de campanha em grande escala do Kubeflow (8 de junho de 2021).

Não, todos os dados são armazenados na região do cluster.

Tradicionalmente, se seu pod estiver sendo executado como um usuário não root (que é o recomendado), é preciso especificar um fsGroup dentro do contexto de segurança do pod para que o volume possa ser legível e gravável pelo pod. Esse requisito é abordado em mais detalhes aqui.

Um efeito colateral da configuração do fsGroup é que, cada vez que um volume é montado, o Kubernetes deve recursivamente chown() e chmod() todos os arquivos e diretórios dentro do volume (com algumas exceções indicadas abaixo). Esse cenário ocorre mesmo que a propriedade do grupo do volume já corresponda ao fsGroup solicitado. Pode ser caro para volumes maiores com muitos arquivos pequenos, o que pode fazer com que a inicialização do pod demore muito. Esse cenário tem sido um problema conhecido antes da v1.20 e a solução alternativa é definir a execução do Pod como raiz:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

O problema foi resolvido com o Kubernetes versão 1.20. Para obter mais informações, consulte Kubernetes 1.20: Controle granular de alterações de permissão de volume.

O AKS usa uma comunicação de túnel seguro para permitir que o servidor de API e os kubelets de nó individuais se comuniquem mesmo em redes virtuais separadas. O túnel é protegido por meio da criptografia mTLS. O principal túnel usado atualmente pelo AKS é o Konnectivity, anteriormente conhecido como apiserver-network-proxy. Verifique se todas as regras de rede seguem as regras de rede e os FQDNs necessários do Azure.

Sim, você pode adicionar a anotação kubernetes.azure.com/set-kube-service-host-fqdn aos pods para definir a variável KUBERNETES_SERVICE_HOST como o nome de domínio do servidor de API em vez do IP do serviço no cluster. Isso é útil nos casos em que a saída do cluster é feita por meio de um firewall de camada 7, como ao usar Firewall do Azure com regras de aplicativo.

O AKS não aplica NSGs (grupos de segurança de rede) à sua sub-rede e não muda nenhum dos NSGs associados a essa sub-rede. O AKS modifica apenas as configurações de NSGs de interfaces de rede. Se estiver usando CNI, você também precisará garantir que as regras de segurança nos NSGs permitam o tráfego entre os intervalos CIDR de nó e pod. Se estiver usando kubenet, você precisará garantir também que as regras de segurança nos NSGs permitam o tráfego entre o CIDR do nó e pod. Para saber mais, confira Grupos de segurança de rede.

Os nós do AKS executam o serviço "chrony", que extrai a hora do localhost. Os contêineres em execução nos pods obtêm o tempo dos nós do AKS. Os aplicativos iniciados dentro de um contêiner usam o tempo do contêiner do pod.

Não. O AKS é um serviço gerenciado e não há suporte para o processamento dos recursos de IaaS. Para instalar componentes personalizados, use as APIs e os mecanismos do Kubernetes. Por exemplo, aproveite os DaemonSets para instalar os componentes necessários.

O AKS dá suporte aos seguintes controladores de admissão:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

No momento, não é possível modificar a lista de controladores de admissão no AKS.

Sim, você pode usar webhooks do controlador de admissão no AKS. Recomendamos excluir os namespaces internos do AKS que estão marcados com o rótulo do plano de controle. Por exemplo:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

Os firewalls do AKS protegem a saída do servidor de API para que os WebHooks do controlador de admissão precisem ser acessados de dentro do cluster.

Para proteger a estabilidade do sistema e impedir que os controladores de admissão personalizados afetem os serviços internos no namespace do kube-system, o AKS tem uma Imposição de Admissões, que exclui automaticamente os namespaces internos do kube-system e do AKS. Esse serviço verifica se os controladores de admissão personalizados não afetam os serviços em execução no kube-system.

Se você tiver um caso de uso crítico para implantar algo no kube-system (não recomendado), dando suporte ao webhook de admissão personalizado, adicione o rótulo ou a anotação a seguir para que a Imposição de Admissões o ignore.

Rótulo: "admissions.enforcer/disabled": "true" ou Anotação: "admissions.enforcer/disabled": true

O Provedor Azure Key Vault para o Driver CSI do Repositório de Segredos fornece integração nativa do Azure Key Vault ao AKS.

Agora, há suporte para nós habilitados para FIPS em pools de nós baseados em Linux. Para obter mais informações, consulte Adicionar um pool de nós habilitados para FIPS.

Qualquer patch, incluindo um patch de segurança, é aplicado automaticamente ao cluster do AKS. Qualquer coisa maior que um patch, como alterações de versão principal ou secundária (que podem ter alterações interruptivas em seus objetos implantados), é atualizada quando você atualiza o cluster se uma nova versão estiver disponível. Você pode encontrar quando uma nova versão está disponível visitando as notas de versão do AKS.

A extensão AKS Linux é uma extensão da VM do Azure que instala e configura ferramentas de monitoramento em nós de trabalho do Kubernetes. A extensão é instalada em todos os nós novos e existentes do Linux. Configura as seguintes ferramentas de monitoramento:

• Node-exporter: coleta a telemetria de hardware da máquina virtual e a disponibiliza usando um ponto de extremidade de métricas. Em seguida, uma ferramenta de monitoramento, como o Prometheus, é capaz de extrair essas métricas.
• Node-problem-detector: tem como objetivo tornar vários problemas de nós visíveis para as camadas upstream na pilha de gerenciamento do cluster. É uma unidade systemd que é executada em cada nó, detecta problemas de nó e os relata ao servidor da API do cluster usando Eventos e NodeConditions.
• ig: uma estrutura de código aberto alimentada por eBPF para depuração e observação de sistemas Linux e Kubernetes. Fornece um conjunto de ferramentas (ou gadgets) projetadas para coletar informações relevantes, permitindo que os usuários identifiquem a causa de problemas de desempenho, falhas ou outras anomalias. Notavelmente, sua independência do Kubernetes permite que os usuários o empreguem também para depurar problemas do plano de controle.

Essas ferramentas ajudam a fornecer observabilidade em muitos problemas relacionados à integridade do nó, como:

• Problemas de daemon de infraestrutura: serviço de NTP inativo
• Problemas de hardware: CPU, memória ou disco defeituosos
• Problemas de kernel: deadlock do kernel, sistema de arquivos corrompido
• Problemas de runtime de contêiner: daemon de runtime não responsivo

A extensão não requer acesso de saída adicional a nenhum URL, endereço IP ou porta além dos requisitos de saída do AKS documentados. Não requer nenhuma permissão especial concedida no Azure. Usa o kubeconfig para se conectar ao servidor de API e enviar os dados de monitoramento coletados.

A maioria dos clusters é excluída mediante solicitação do usuário. Em alguns casos, especialmente nos casos em que você traz seu próprio Grupo de Recursos ou executa tarefas entre GR, a exclusão pode levar mais tempo ou até mesmo falhar. Se você tiver problemas com exclusões, verifique se não tem bloqueios no grupo de recursos, se todos os recursos fora do grupo de recursos estão desassociados dele, etc.

Se você tiver problemas com as operações de criação e atualização do cluster, verifique se não há políticas ou restrições de serviço atribuídas que possam impedir que o cluster do AKS de gerenciar recursos como VMs, balanceadores de carga, tags etc.

Você pode, mas não recomendamos. Você deve executar atualizações quando o estado do cluster for conhecido e íntegro.

Não exclua/remova todos os nós em estado de falha ou de outra forma do cluster antes de atualizar.

Mais comumente, esse erro surgirá se você tiver um ou mais Grupos de Segurança de Rede (NSGs) ainda em uso associados ao cluster. Remova-os e tente excluir o cluster novamente.

Confirme se a entidade de serviço não expirou. Veja Entidade de serviço do AKS e atualizar credenciais do AKS.

Confirme se a entidade de serviço não expirou. Veja Entidade de serviço do AKS e atualizar credenciais do AKS.