Perguntas frequentes sobre o AKS

Este artigo fornece respostas a algumas das perguntas mais comuns sobre o Serviço de Kubernetes do Azure (AKS).

Suporte

O AKS oferece um SLA?

O AKS fornece garantias de SLA (contrato de nível de serviço) no tipo de preço Standard com o recurso SLA de tempo de atividade.

O que é suporte à plataforma e o que ele inclui?

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

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

O AKS atualiza automaticamente meus clusters sem suporte?

Sim, o AKS inicia atualizações automáticas para clusters sem suporte. Quando um cluster em uma versão n-3 (onde n é a versão secundária do AKS com suporte mais recente que está em disponibilidade geral) está prestes a cair para n-4, o AKS atualizará 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.

Posso executar contêineres do Windows Server no AKS?

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.

Posso aplicar descontos de reserva do Azure aos meus nós de agente do AKS?

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

Operações

Posso mover ou migrar meu cluster entre locatários do Azure?

Não. No momento, não há suporte para a movimentação do cluster AKS entre locatários.

Posso mover ou migrar meu cluster entre assinaturas?

Não. No momento, não há suporte para a migração do cluster do AKS entre assinaturas.

Posso mover meu cluster do AKS ou recursos de infraestrutura do AKS para outros grupos de recursos ou renomeá-los?

Não. Não há suporte para movimentar ou renomear o cluster do AKS e seus recursos associados.

Posso restaurar meu cluster depois de excluí-lo?

Não. Você não pode restaurar o cluster depois de 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 um dos seus recursos, mova-os para outro grupo de recursos antes de excluir seu cluster. Se você quiser se proteger contra exclusões acidentais, poderá bloquear o grupo de recursos gerenciados do AKS que está hospedando seus recursos de cluster usando o bloqueio do grupo de recursos do nó.

Posso dimensionar meu cluster do AKS para zero?

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.

Posso usar as APIs do conjunto de dimensionamento de máquinas virtuais para executar uma operação de escala manual?

Não. Não há suporte para as operações de dimensionamento que usam as APIs do conjunto de dimensionamento de máquinas virtuais. Você pode usar as APIs do AKS (az aks scale).

Posso usar conjuntos de dimensionamento de máquinas virtuais para executar uma operação de escala manual para 0 nó?

Não. Não há suporte para as operações de dimensionamento que usam as APIs do conjunto de dimensionamento de máquinas virtuais. Você pode usar a API do AKS para dimensionar pools de nós que não sejam do sistema para zero ou parar o cluster.

Posso parar ou desalocar todas as minhas VMs?

Não. Esta configuração não tem suporte. Em vez disso, pare o cluster.

Por que são criados dois grupos de recursos com o AKS?

O AKS baseia-se em muitos recursos da infraestrutura do Azure, incluindo 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, você pode usar a maioria dos tipos de VM do Azure diretamente com o AKS e pode usar as Reservas do Azure 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. Use esse grupo de recursos apenas para os recursos que compartilham o ciclo de vida do cluster.

Observação

Modificar qualquer recurso no grupo de recursos do nó no cluster do AKS é uma ação sem suporte e causará falhas na operação do cluster. Você pode impedir que alterações sejam feitas no grupo de recursos do nó. Impedir que os usuários modifiquem os recursos gerenciados pelo cluster do AKS.

Posso fornecer um nome personalizado para o grupo de recursos do nó no AKS?

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. Ao criar um cluster do AKS por meio do comando 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, 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 ao criar o cluster.

Ao trabalhar com o grupo de recursos do nó, 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 de criar o cluster.
• 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ó.

Posso modificar marcas e outras propriedades dos recursos do AKS no 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 que você crie e modifique 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 é aplicar políticas e modificar marcas por meio do próprio recurso do AKS — especificamente por meio dos pools de clusters e nós.

As marcas criadas pelo Azure são criadas para seus respectivos serviços do Azure e você sempre deve permiti-las. 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).

Observação

No passado, o nome Owner da marca era reservado para o AKS gerenciar o IP público atribuído ao IP de front-end do balanceador de carga. Agora, os serviços usam o prefixo aks-managed. Para os recursos herdados, não use as políticas do Azure para aplicar o nome da marca Owner. Caso contrário, todos os recursos em suas operações de implantação e atualização de cluster do AKS serão interrompidos. Essa restrição não se aplica aos recursos recém-criados.

Por que vejo as versões do Helm prefixadas gerenciadas pelo AKS no meu cluster e por que a contagem de revisão deles continua aumentando?

O AKS usa o Helm para entregar componentes ao seu cluster. Você pode ignorar com segurança aks-managed versões prefixadas do Helm. Revisões cada vez maiores nessas versões do Helm são esperadas e são seguras.

Cotas, limites e disponibilidade de região

Quais regiões do Azure atualmente fornecem o AKS?

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

Posso distribuir um cluster do AKS entre regiões?

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

Posso distribuir um cluster do AKS entre zonas de disponibilidade?

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

Posso ter diferentes tamanhos de VM em um só cluster?

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

Qual é o limite de tamanho em uma imagem de contêiner no AKS?

O AKS não define um limite para o tamanho da imagem de contêiner. Mas 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 é excessivamente grande, como no intervalo de terabyte (TB), o kubelet pode não conseguir baixá-la do seu 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. Você deve executar uma atualização no cluster e nos pools de nós do Windows Server no seu cluster do AKS. Siga um agendamento regular com base no ciclo de lançamento do Windows Update e em seu próprio processo de validação. Esse processo de atualização cria nós que executam a imagem e os patches mais recentes do Windows Server e 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 do AKS devem ser executadas como raiz?

As imagens a seguir têm requisitos funcionais para serem executadas como raiz e as exceções devem ser arquivadas para as 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

Segurança, acesso e identidade

Posso limitar quem tem acesso ao servidor de API do Kubernetes?

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

• Use intervalos de IP autorizados do servidor de API se você 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 somente de dentro de sua rede virtual.

As atualizações de segurança são aplicadas aos nós do agente do AKS?

O AKS corrige CVEs que têm uma correção de fornecedor toda semana. Os CVEs sem correção aguardam uma correção do fornecedor antes que possam ser corrigidos. As imagens do 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 executar essa tarefa:

• Manualmente, por meio do portal do Azure ou da CLI do Azure.
• Atualizando o cluster AKS. O cluster atualiza os nós de isolamento e dreno automaticamente. Em seguida, ele traz 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, confira Atualizar um cluster do AKS.
• Usando uma atualização de imagem de nó.

Existem ameaças de segurança direcionadas ao AKS que eu devo saber?

A Microsoft fornece diretrizes para outras ações que você pode executar para proteger suas cargas de trabalho por meio de serviços como o Microsoft Defender para contêineres. Para obter informações sobre uma ameaça de segurança relacionada ao AKS e ao Kubernetes, veja Nova campanha em larga escala tem como alvo o Kubeflow (8 de junho de 2021).

O AKS armazena dados do cliente fora da região do cluster?

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

Como posso evitar problemas de lentidão na configuração de propriedades de permissão quando o volume tem inúmeros arquivos?

Tradicionalmente, se o pod estiver em execução como um usuário não raiz (como deveria), é preciso especificar um parâmetro fsGroup dentro do contexto de segurança do pod para que o volume seja legível e gravável pelo pod. Para obter mais informações sobre esse requisito, veja Configurar um contexto de segurança para um pod ou contêiner.

Um efeito colateral da configuração fsGroup é que cada vez que um volume é montado, o Kubernetes deve usar os comandos chown() e chmod() recursivamente para todos os arquivos e diretórios dentro do volume (com algumas exceções). Este cenário ocorre mesmo se a propriedade do grupo do volume já corresponder ao parâmetro fsGroup solicitado. Esta configuração pode ser cara para volumes maiores com muitos arquivos pequenos, o que pode fazer com que a inicialização do pod leve muito tempo. Este cenário era um problema conhecido antes da v1.20. A solução alternativa é definir o pod para ser executado 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, veja Kubernetes 1.20: Controle granular de alterações de permissão de volume.

Rede

Como o painel de controle gerenciado se comunica com meus nós?

O AKS usa uma comunicação de túnel seguro para permitir que o api-server e os kubelets de nó individuais se comuniquem, mesmo em redes virtuais separadas. O túnel é protegido por meio da criptografia TLS mútua. O túnel principal atual usado pelo AKS é o Konnectivity, anteriormente conhecido como apiserver-network-proxy. Verifique se todas as regras de rede seguem as regras de rede obrigatórias para o Azure e os FQDNs (nomes de domínio totalmente qualificados).

Meus pods podem usar o FQDN do servidor de API em vez do IP do cluster?

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. Essa modificação é útil nos casos em que a saída do cluster é feita por meio de um firewall de camada 7. Um exemplo é quando você usa o Firewall do Azure com as regras do aplicativo.

Posso configurar NSGs com o AKS?

O AKS não aplica NSGs (grupos de segurança de rede) à sua sub-rede e não modifica nenhum dos NSGs associados a essa sub-rede. O AKS modifica apenas as configurações de NSG do adaptador de rede. Se você estiver usando a CNI (Interface de Rede de Contêiner), também deverá garantir que as regras de segurança nos NSGs permitam o tráfego entre os intervalos de CIDR (Roteamento entre Domínios sem Classificação) do nó e do pod. Se você estiver usando o kubenet, também deverá garantir que as regras de segurança nos NSGs permitam o tráfego entre o CIDR do nó e do pod. Para saber mais, confira Grupos de segurança de rede.

Como funciona a sincronização de horário no AKS?

Os nós do AKS executam o serviço cronony, que obtém a hora a partir do host local. Os contêineres executados em pods que obtém a hora a partir dos nós do AKS. Os aplicativos abertos dentro de um contêiner usam a hora do contêiner do pod.

Complementos, extensões e integrações

Posso usar extensões de VM personalizadas?

Não. O AKS é um serviço gerenciado. Não há suporte para a manipulação dos recursos de IaaS (infraestrutura como serviço). Para instalar componentes personalizados, use as APIs e os mecanismos do Kubernetes. Por exemplo, use DaemonSets para instalar todos os componentes obrigatórios.

Quais os controles de admissão de Kubernetes que o AKS suporta? Controladores de admissão podem ser adicionados ou removidos?

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.

Posso usar webhooks do controlador de admissão no AKS?

Sim, você pode usar webhooks do controlador de admissão no AKS. Recomendamos que você exclua namespaces internos do AKS, que são marcados com o rótulo control-plane. Por exemplo:

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

O AKS bloqueia o tráfego de saída do servidor da API, de modo que seus webhooks do controlador de admissão precisem ser acessíveis de dentro do cluster.

Os webhooks do controlador de admissão podem afetar o sistema kube e os namespaces internos do AKS?

Para proteger a estabilidade do sistema e impedir que os controladores de admissão personalizados afetem os serviços internos no namespace kube-system, o AKS tem um executor de admissões, que exclui automaticamente kube-system e namespaces internos do AKS. Esse serviço garante que os controladores de admissão personalizados não afetem os serviços executados em kube-system.

Se você tiver um caso de uso crítico para implantar algo no kube-system (não recomendado) para dar suporte ao webhook de admissão personalizado, você poderá adicionar o seguinte rótulo ou anotação para que o executor de admissões o ignore:

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

O Azure Key Vault é integrado com o AKS?

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

Posso usar bibliotecas criptográficas FIPS com implantações no AKS?

Os nós que estão habilitados com padrões FIPS agora têm suporte em pools de nós baseados em Linux. Para obter mais informações, consulte Adicionar um pool de nós habilitados para FIPS.

Como os complementos do AKS são atualizados?

Qualquer patch, incluindo um patch de segurança, é aplicado automaticamente ao cluster do AKS. O que for maior que um patch, como alterações de versão principal ou secundária (que podem ter alterações interruptivas em seus objetos implantados), será atualizado quando você atualizar seu cluster se uma nova versão estiver disponível. Para obter informações sobre quando uma nova versão está disponível, veja as notas de versão do AKS.

Qual é a finalidade da extensão do AKS Linux que vejo instalada em minhas instâncias de conjuntos de dimensionamento de máquinas virtuais do Linux?

A extensão do 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 novos e existentes do Linux. Configura as seguintes ferramentas de monitoramento:

• Exportador de nó: coleta a telemetria de hardware da VM e a disponibiliza usando um ponto de extremidade de métricas. Em seguida, uma ferramenta de monitoramento, como o Prometheus, pode coletar 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 Events e NodeConditions.
• ig: é uma estrutura de código aberto alimentada por eBPF para depuração e observação de sistemas Linux e Kubernetes. Ele fornece um conjunto de ferramentas (ou gadgets) que coletam informações relevantes que os usuários podem usar para identificar 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 inoperante
• Problemas de hardware: CPU, memória ou disco inválido
• Problemas de kernel: Deadlock do kernel, sistema de arquivos corrompido
• Problemas de runtime do contêiner: Daemon de runtime sem resposta

A extensão não requer acesso extra de saída a URLs, endereços IP ou portas além dos requisitos de saída do AKS documentados. 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.

Solucionar problemas de cluster

Por que está demorando tanto para excluir meu cluster?

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 grupos de recursos, a exclusão pode levar mais tempo ou até mesmo falhar. Se você tiver um problema com exclusões, verifique se não tem bloqueios no grupo de recursos. Verifique também se todos os recursos fora do grupo de recursos estão desassociados do grupo de recursos.

Por que está demorando tanto para criar ou atualizar meu cluster?

Se você tiver problemas com a criação e atualização de clusters, verifique se você não tem nenhuma política ou restrições de serviço atribuídas que possam impedir o cluster do AKS de gerenciar recursos como VMs, balanceadores de carga ou marcas.

Se eu tiver pods ou implantações nos estados NodeLost ou Desconhecidos, ainda posso atualizar meu cluster?

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

Se eu tiver um cluster com um ou mais nós em um estado Não íntegro ou se ele estiver desligado, posso executar uma atualização?

Não. Exclua ou remova todos os nós que estão em um estado com falha ou diferente do cluster antes de atualizar.

Tentei excluir meu cluster, mas vejo o erro "[Errno 11001] getaddrinfo falhou."

Mais comumente, esse erro surgirá se você tiver um ou mais NSGs em uso que ainda estejam associados ao cluster. Remova-os e tente excluir o cluster novamente.

Executei uma atualização, mas agora meus pods estão em loops de falha e as investigações de preparação estão falhando.

Confirme se a sua entidade de serviço não expirou. Para obter mais informações, veja a entidade de serviço do AKS e as credenciais de atualização do AKS.

Meu cluster estava funcionando, mas de repente não consigo provisionar balanceadores de carga ou montar declarações de volume persistentes.

Confirme se a sua entidade de serviço não expirou. Para obter mais informações, veja a entidade de serviço do AKS e as credenciais de atualização do AKS.

Este artigo fornece respostas a algumas das perguntas mais comuns sobre o Serviço de Kubernetes do Azure (AKS).

O AKS fornece garantias de SLA (contrato de nível de serviço) no tipo de preço Standard com o recurso 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 o 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 (onde n é a versão secundária do AKS com suporte mais recente que está em disponibilidade geral) está prestes a cair para n-4, o AKS atualizará 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 de agente do AKS são cobrados como VMs (máquinas virtuais) do Azure padrão. Se você comprou reservas do Azure para o tamanho da VM que está usando no AKS, esses descontos são aplicados automaticamente.

Não. No momento, não há suporte para a movimentação do cluster AKS entre locatários.

Não. No momento, não há suporte para a migração do cluster do AKS entre assinaturas.

Não. Não há suporte para movimentar ou renomear o cluster do AKS e seus recursos associados.

Não. Você não pode restaurar o cluster depois de 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 um dos seus recursos, mova-os para outro grupo de recursos antes de excluir seu cluster. Se você quiser se proteger contra exclusões acidentais, poderá bloquear o grupo de recursos gerenciados do AKS que está hospedando seus recursos de cluster usando 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. Não há suporte para as operações de dimensionamento que usam as APIs do conjunto de dimensionamento de máquinas virtuais. Você pode usar as APIs do AKS (az aks scale).

Não. Não há suporte para as operações de dimensionamento que usam as APIs do conjunto de dimensionamento de máquinas virtuais. Você pode usar a API do AKS para dimensionar pools de nós que não sejam do sistema para zero ou parar o cluster.

Não. Esta configuração não tem suporte. Em vez disso, pare o cluster.

O AKS baseia-se em muitos recursos da infraestrutura do Azure, incluindo 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, você pode usar a maioria dos tipos de VM do Azure diretamente com o AKS e pode usar as Reservas do Azure 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. Use esse grupo de recursos apenas para os recursos que compartilham o ciclo de vida do cluster.

Observação

Modificar qualquer recurso no grupo de recursos do nó no cluster do AKS é uma ação sem suporte e causará falhas na operação do cluster. Você pode impedir que alterações sejam feitas no grupo de recursos do nó. Impedir que os usuários modifiquem os recursos gerenciados pelo cluster do AKS.

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. Ao criar um cluster do AKS por meio do comando 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, 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 ao criar o cluster.

Ao trabalhar com o grupo de recursos do nó, 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 de criar o cluster.
• 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 que você crie e modifique 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 é aplicar políticas e modificar marcas por meio do próprio recurso do AKS — especificamente por meio dos pools de clusters e nós.

As marcas criadas pelo Azure são criadas para seus respectivos serviços do Azure e você sempre deve permiti-las. 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).

Observação

No passado, o nome Owner da marca era reservado para o AKS gerenciar o IP público atribuído ao IP de front-end do balanceador de carga. Agora, os serviços usam o prefixo aks-managed. Para os recursos herdados, não use as políticas do Azure para aplicar o nome da marca Owner. Caso contrário, todos os recursos em suas operações de implantação e atualização de cluster do AKS serão interrompidos. Essa restrição não se aplica aos recursos recém-criados.

O AKS usa o Helm para entregar componentes ao seu cluster. Você pode ignorar com segurança aks-managed versões prefixadas do Helm. Revisões cada vez maiores nessas versões do Helm são esperadas e são seguras.

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 regiões. Para obter diretrizes sobre como criar uma arquitetura que inclua várias regiões, veja as melhores práticas para continuidade dos negócios e recuperação de desastres.

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 tamanhos de VM diferentes no 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. Mas 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 é excessivamente grande, como no intervalo de terabyte (TB), o kubelet pode não conseguir baixá-la do seu 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. Você deve executar uma atualização no cluster e nos pools de nós do Windows Server no seu cluster do AKS. Siga um agendamento regular com base no ciclo de lançamento do Windows Update e em seu próprio processo de validação. Esse processo de atualização cria nós que executam a imagem e os patches mais recentes do Windows Server e 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 serem executadas como raiz e as exceções devem ser arquivadas para as 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 da API:

• Use intervalos de IP autorizados do servidor de API se você 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 somente de dentro de sua rede virtual.

O AKS corrige CVEs que têm uma correção de fornecedor toda semana. Os CVEs sem correção aguardam uma correção do fornecedor antes que possam ser corrigidos. As imagens do 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 executar essa tarefa:

• Manualmente, por meio do portal do Azure ou da CLI do Azure.
• Atualizando o cluster AKS. O cluster atualiza os nós de isolamento e dreno automaticamente. Em seguida, ele traz 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, confira Atualizar um cluster do AKS.
• Usando uma atualização de imagem de nó.

A Microsoft fornece diretrizes para outras ações que você pode executar para proteger suas cargas de trabalho por meio de serviços como o Microsoft Defender para contêineres. Para obter informações sobre uma ameaça de segurança relacionada ao AKS e ao Kubernetes, veja Nova campanha em larga escala tem como alvo o Kubeflow (8 de junho de 2021).

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

Tradicionalmente, se o pod estiver em execução como um usuário não raiz (como deveria), é preciso especificar um parâmetro fsGroup dentro do contexto de segurança do pod para que o volume seja legível e gravável pelo pod. Para obter mais informações sobre esse requisito, veja Configurar um contexto de segurança para um pod ou contêiner.

Um efeito colateral da configuração fsGroup é que cada vez que um volume é montado, o Kubernetes deve usar os comandos chown() e chmod() recursivamente para todos os arquivos e diretórios dentro do volume (com algumas exceções). Este cenário ocorre mesmo se a propriedade do grupo do volume já corresponder ao parâmetro fsGroup solicitado. Esta configuração pode ser cara para volumes maiores com muitos arquivos pequenos, o que pode fazer com que a inicialização do pod leve muito tempo. Este cenário era um problema conhecido antes da v1.20. A solução alternativa é definir o pod para ser executado 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, veja 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 api-server e os kubelets de nó individuais se comuniquem, mesmo em redes virtuais separadas. O túnel é protegido por meio da criptografia TLS mútua. O túnel principal atual usado pelo AKS é o Konnectivity, anteriormente conhecido como apiserver-network-proxy. Verifique se todas as regras de rede seguem as regras de rede obrigatórias para o Azure e os FQDNs (nomes de domínio totalmente qualificados).

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. Essa modificação é útil nos casos em que a saída do cluster é feita por meio de um firewall de camada 7. Um exemplo é quando você usa o Firewall do Azure com as regras do aplicativo.

O AKS não aplica NSGs (grupos de segurança de rede) à sua sub-rede e não modifica nenhum dos NSGs associados a essa sub-rede. O AKS modifica apenas as configurações de NSG do adaptador de rede. Se você estiver usando a CNI (Interface de Rede de Contêiner), também deverá garantir que as regras de segurança nos NSGs permitam o tráfego entre os intervalos de CIDR (Roteamento entre Domínios sem Classificação) do nó e do pod. Se você estiver usando o kubenet, também deverá garantir que as regras de segurança nos NSGs permitam o tráfego entre o CIDR do nó e do pod. Para saber mais, confira Grupos de segurança de rede.

Os nós do AKS executam o serviço cronony, que obtém a hora a partir do host local. Os contêineres executados em pods que obtém a hora a partir dos nós do AKS. Os aplicativos abertos dentro de um contêiner usam a hora do contêiner do pod.

Não. O AKS é um serviço gerenciado. Não há suporte para a manipulação dos recursos de IaaS (infraestrutura como serviço). Para instalar componentes personalizados, use as APIs e os mecanismos do Kubernetes. Por exemplo, use DaemonSets para instalar todos os componentes obrigató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 que você exclua namespaces internos do AKS, que são marcados com o rótulo control-plane. Por exemplo:

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

O AKS bloqueia o tráfego de saída do servidor da API, de modo que seus webhooks do controlador de admissão precisem ser acessíveis 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 kube-system, o AKS tem um executor de admissões, que exclui automaticamente kube-system e namespaces internos do AKS. Esse serviço garante que os controladores de admissão personalizados não afetem os serviços executados em kube-system.

Se você tiver um caso de uso crítico para implantar algo no kube-system (não recomendado) para dar suporte ao webhook de admissão personalizado, você poderá adicionar o seguinte rótulo ou anotação para que o executor de admissões o ignore:

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

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

Os nós que estão habilitados com padrões FIPS agora têm suporte 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. O que for maior que um patch, como alterações de versão principal ou secundária (que podem ter alterações interruptivas em seus objetos implantados), será atualizado quando você atualizar seu cluster se uma nova versão estiver disponível. Para obter informações sobre quando uma nova versão está disponível, veja as notas de versão do AKS.

A extensão do 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 novos e existentes do Linux. Configura as seguintes ferramentas de monitoramento:

• Exportador de nó: coleta a telemetria de hardware da VM e a disponibiliza usando um ponto de extremidade de métricas. Em seguida, uma ferramenta de monitoramento, como o Prometheus, pode coletar 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 Events e NodeConditions.
• ig: é uma estrutura de código aberto alimentada por eBPF para depuração e observação de sistemas Linux e Kubernetes. Ele fornece um conjunto de ferramentas (ou gadgets) que coletam informações relevantes que os usuários podem usar para identificar 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 inoperante
• Problemas de hardware: CPU, memória ou disco inválido
• Problemas de kernel: Deadlock do kernel, sistema de arquivos corrompido
• Problemas de runtime do contêiner: Daemon de runtime sem resposta

A extensão não requer acesso extra de saída a URLs, endereços IP ou portas além dos requisitos de saída do AKS documentados. 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 grupos de recursos, a exclusão pode levar mais tempo ou até mesmo falhar. Se você tiver um problema com exclusões, verifique se não tem bloqueios no grupo de recursos. Verifique também se todos os recursos fora do grupo de recursos estão desassociados do grupo de recursos.

Se você tiver problemas com a criação e atualização de clusters, verifique se você não tem nenhuma política ou restrições de serviço atribuídas que possam impedir o cluster do AKS de gerenciar recursos como VMs, balanceadores de carga ou marcas.

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

Não. Exclua ou remova todos os nós que estão em um estado com falha ou diferente do cluster antes de atualizar.

Mais comumente, esse erro surgirá se você tiver um ou mais NSGs em uso que ainda estejam associados ao cluster. Remova-os e tente excluir o cluster novamente.

Confirme se a sua entidade de serviço não expirou. Para obter mais informações, veja a entidade de serviço do AKS e as credenciais de atualização do AKS.

Confirme se a sua entidade de serviço não expirou. Para obter mais informações, veja a entidade de serviço do AKS e as credenciais de atualização do AKS.