Perguntas frequentes sobre o AKS

O AKS fornece garantias de SLA no nível de preço padrão 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 da plataforma inclui apenas o suporte à infraestrutura do Azure.

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

Sim, o AKS inicia atualizações automáticas para clusters não suportados. Quando um cluster em uma versão n-3 (onde n é a versão secundária mais recente suportada do AKS GA) 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 obter mais informações, consulte Versões do Kubernetes suportadas, Janelas de manutenção planejada e Atualizações automáticas.

Sim, o AKS suporta contêineres do Windows Server. Para obter mais informações, consulte as Perguntas frequentes sobre o Windows Server no AKS.

Os nós do agente 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 serão aplicados automaticamente.

Não, mover seu cluster AKS entre locatários não é suportado no momento.

Não, mover seu cluster AKS entre assinaturas não é suportado no momento.

Não, mover ou renomear seu cluster AKS e seus recursos associados não é suportado.

Não, não é possível restaurar o cluster depois de excluí-lo. Quando você exclui o cluster, o grupo de recursos do nó e todos os seus recursos também são excluídos.

Se quiser manter qualquer um dos seus recursos, mova-os para outro grupo de recursos antes de excluir o cluster. Se quiser se proteger contra exclusões acidentais, você pode bloquear o grupo de recursos gerenciados pelo AKS que hospeda seus recursos de cluster usando o bloqueio do grupo de recursos Node.

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

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

Não, não há suporte para operações de dimensionamento usando as APIs do Conjunto de Dimensionamento de Máquina Virtual. Você pode usar as APIs do AKS (az aks scale).

Não, não há suporte para operações de dimensionamento usando as APIs do Conjunto de Dimensionamento de Máquina Virtual. 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 suportada. Em vez disso, pare o cluster .

O AKS baseia-se em muitos recursos de infraestrutura do Azure, incluindo Conjuntos de Escala de Máquina Virtual, redes virtuais e discos gerenciados. Essas integrações permitem que você aplique muitos dos principais recursos da plataforma Azure no ambiente Kubernetes gerenciado fornecido pelo AKS. Por exemplo, a maioria dos tipos de máquina virtual 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 de serviço do Kubernetes. O provedor de recursos 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, consulte a próxima seção.
2. O segundo grupo de recursos, conhecido como grupo de recursos de nó, contém todos os recursos de infraestrutura associados ao cluster. Esses recursos incluem as VMs do nó 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 seu próprio nome de grupo de recursos, instale a extensão aks-preview Azure CLI versão 0.3.2 ou posterior. Ao criar um cluster AKS usando o comando [az aks create][az-aks-create], use o --node-resource-group parâmetro e especifique um nome para o grupo de recursos. Se você usar um modelo do Azure Resource Manager para implantar um cluster AKS, poderá definir 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ê pode especificar um nome de grupo de recursos personalizado somente quando estiver criando o cluster.

Ao trabalhar com o grupo de recursos do nó, lembre-se de que não é possível:

• Especifique um grupo de recursos existente para o grupo de recursos do nó.
• Especifique uma assinatura diferente para o grupo de recursos do nó.
• Altere o nome do grupo de recursos do nó após a criação do cluster.
• Especifique nomes para os recursos gerenciados dentro do grupo de recursos do nó.
• Modifique ou exclua marcas criadas pelo Azure de recursos gerenciados dentro do grupo de recursos do nó.

Você pode obter erros inesperados de dimensionamento 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 que você crie e modifique tags personalizadas criadas por usuários finais, e você pode adicionar essas tags ao criar um pool de nós. Talvez você queira criar ou modificar tags 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 tags criadas pelo Azure são criadas para seus respetivos Serviços do Azure e sempre devem ser permitidas. Para o AKS, existem as aks-managed tags e k8s-azure . Modificar quaisquer marcas criadas pelo Azure em recursos sob o grupo de recursos de nó no cluster AKS é uma ação sem suporte, que quebra o SLO (objetivo de nível de serviço).

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

Não, os clusters AKS são recursos regionais e não podem abranger regiões. Consulte as práticas recomendadas para continuidade de negócios e recuperação de desastres para obter orientação sobre como criar uma arquitetura que inclua várias regiões.

Sim, você pode implantar um cluster AKS em uma ou mais zonas de disponibilidade em regiões que oferecem suporte a elas.

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

O AKS não define um limite para o tamanho da imagem do contêiner. No entanto, é importante entender que quanto maior a imagem, maior a demanda de memória. Um tamanho maior pode potencialmente 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 AKS é definida como 7 GiB.

Quando uma imagem de contêiner é excessivamente grande, como no intervalo de Terabytes (TBs), o kubelet pode não ser capaz de puxá-la do seu registro de contêiner para um nó devido à falta de espaço em disco.

Para nós do Windows Server, o Windows Update não executa e aplica automaticamente as atualizações mais recentes. Em um cronograma regular em torno do ciclo de lançamento do Windows Update e seu próprio processo de validação, você deve executar uma atualização no cluster e no(s) pool(s) do Windows Server no cluster 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, consulte Atualizar um pool de nós no AKS.

As imagens a seguir têm requisitos funcionais para "Executar como raiz" e exceções devem ser arquivadas para quaisquer políticas:

• 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 de API:

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

O AKS corrige CVEs que têm uma "correção de fornecedor" todas as semanas. CVEs sem uma correção estão aguardando uma "correção do fornecedor" antes de poderem ser corrigidos. As imagens AKS são atualizadas automaticamente dentro de 30 dias. Recomendamos que você aplique uma imagem de nó atualizada em uma cadência regular para garantir que as imagens corrigidas mais recentes e os patches do sistema operacional sejam todos aplicados e atuais. Você pode fazer isso usando um dos seguintes métodos:

• Manualmente, através do portal do Azure ou da CLI do Azure.
• Atualizando seu cluster AKS. O cluster atualiza os nós de cordão e drenagem automaticamente e, em seguida, coloca um novo nó online com a imagem mais recente do Ubuntu e uma nova versão de patch ou uma versão secundária do Kubernetes. Para obter mais informações, veja Atualizar um cluster do AKS.
• Usando a atualização de imagem de nó.

A Microsoft fornece orientação para outras ações que você pode tomar para proteger suas cargas de trabalho por meio de serviços como o Microsoft Defender for Containers. A seguinte ameaça à segurança está relacionada ao AKS e ao Kubernetes que você deve estar ciente:

• Nova campanha em grande escala visa Kubeflow (8 de junho de 2021).

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

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

Um efeito colateral da configuração 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 observadas abaixo). Esse cenário acontece mesmo que a propriedade do grupo do volume já corresponda ao solicitado fsGroup. Pode ser caro para volumes maiores com muitos arquivos pequenos, o que pode fazer com que a inicialização do pod demore muito tempo. Este cenário tem sido um problema conhecido antes da v1.20, e a solução alternativa está definindo a execução do Pod como root:

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 segura para permitir que o servidor api e os kubelets de nó individuais se comuniquem mesmo em redes virtuais separadas. O túnel é protegido através de criptografia mTLS. O túnel principal atual que é usado 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 KUBERNETES_SERVICE_HOST variável 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 o Firewall do Azure com Regras de Aplicativo.

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

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

Não, o AKS é um serviço gerido e a manipulação dos recursos de IaaS não é suportada. Para instalar componentes personalizados, use as APIs e os mecanismos do Kubernetes. Por exemplo, use DaemonSets para instalar os componentes necessários.

O AKS suporta os seguintes controladores de admissão:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidandoAdmissionWebhook
• Cota de Recursos
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

Atualmente, 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. É recomendável excluir namespaces AKS internos, que são marcados com o rótulo do plano de controle. Por exemplo:

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

O AKS protege a saída do servidor de API para que os webhooks do controlador de admissão precisem estar acessíveis de dentro do cluster.

Para proteger a estabilidade do sistema e evitar que os controladores de admissão personalizados afetem os serviços internos no kube-system, o namespace AKS tem um Admissions Enforcer, que exclui automaticamente os namespaces internos kube-system e AKS. Este serviço garante que os controladores de admissão personalizados não afetem 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) em suporte ao seu webhook de admissão personalizado, você pode adicionar o seguinte rótulo ou anotação para que o Admissions Enforcer o ignore.

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

O Azure Key Vault Provider for Secrets Store CSI Driver fornece integração nativa do Azure Key Vault no AKS.

Os nós habilitados para FIPS agora são suportados em pools de nós baseados em Linux. Para obter mais informações, consulte Adicionar um pool de nós habilitado para FIPS.

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

A Extensão AKS Linux é uma extensão de 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 Linux novos e existentes. Ele configura as seguintes ferramentas de monitoramento:

• Exportador de nó: coleta a telemetria de hardware da máquina virtual e a disponibiliza usando um ponto de extremidade de métrica. Então, uma ferramenta de monitoramento, como o Prometheus, é capaz de descartar essas métricas.
• Node-problem-detector: Visa tornar vários problemas de nó visíveis para camadas upstream na pilha de gerenciamento de cluster. É uma unidade systemd que é executada em cada nó, deteta problemas de nó e os relata ao servidor de API do cluster usando Events e NodeConditions.
• ig: Um framework de código aberto alimentado por eBPF para depuração e observação de sistemas Linux e Kubernetes. Ele fornece um conjunto de ferramentas (ou gadgets) projetados para reunir 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 torno de muitos problemas relacionados à integridade do nó, como:

• Problemas de daemon de infraestrutura: serviço NTP inativo
• Problemas de hardware: CPU, memória ou disco defeituosos
• Problemas do kernel: Impasse do kernel, sistema de arquivos corrompido
• Problemas de tempo de execução do contêiner: daemon de tempo de execução sem resposta

A extensão não requer acesso de saída adicional a URLs, endereços IP ou portas além dos requisitos de saída do AKS documentados. Ele não requer nenhuma permissão especial concedida no Azure. Ele usa kubeconfig para se conectar ao servidor de API para 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 RGs, a exclusão pode levar mais tempo ou até mesmo falhar. Se você tiver um problema com exclusões, verifique se você não tem bloqueios no RG, se todos os recursos fora do RG estão desassociados do RG e assim por diante.

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

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

Não, exclua/remova quaisquer nós em um estado com falha ou de outra forma do cluster antes da atualização.

Mais comumente, esse erro surge se você tiver um ou mais NSGs (Network Security Groups) ainda em uso associados ao cluster. Removê-los e tentar excluir novamente.

Confirme se a entidade de serviço não expirou. Consulte a entidade de serviço do AKS e as credenciais de atualização do AKS.

Confirme se a entidade de serviço não expirou. Consulte a entidade de serviço do AKS e as credenciais de atualização do AKS.