Perguntas frequentes sobre o AKS

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

Suporte

A AKS oferece um acordo de nível de serviço?

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

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

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

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

O AKS atualiza automaticamente meus clusters não suportados?

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 última versão secundária do AKS suportada que está geralmente disponível) 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.

Posso executar contêineres do Windows Server no AKS?

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

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

Os nós do agente AKS são cobrados como máquinas virtuais (VMs) 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.

Operações

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

Não. No momento, não há suporte para mover seu cluster AKS entre locatários.

Posso mover ou migrar meu cluster entre assinaturas?

Não. No momento, não há suporte para mover seu cluster AKS entre assinaturas.

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

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

Posso restaurar meu cluster depois de excluí-lo?

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 está hospedando seus recursos de cluster usando o bloqueio do grupo de recursos do Nó.

Posso dimensionar meu cluster AKS para zero?

Você pode parar completamente um cluster AKS em execução ou User de nós 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áquina virtual para dimensionar manualmente?

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

Posso usar conjuntos de dimensionamento de máquina virtual para dimensionar manualmente para zero nós?

Não. Não há suporte para operações de dimensionamento que usam 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 são do sistema para zero ou parar o cluster .

Posso parar ou desalocar todas as minhas VMs?

Não. Esta configuração não é suportada. Em vez disso, pare o cluster .

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

O AKS baseia-se em muitos recursos de infraestrutura do Azure, incluindo conjuntos de dimensionamento de máquinas virtuais, 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, 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 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. Use esse grupo de recursos somente para recursos que compartilham o ciclo de vida do cluster.

Nota

Modificar qualquer recurso sob o grupo de recursos do nó no cluster 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 AKS.

Posso fornecer o meu próprio nome para o grupo de recursos do nó 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 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 az aks create comando, 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 nodeResourceGroup propriedade.

• 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ó, você não pode:

• 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ó depois de criar o 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ó.

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

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

Nota

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

Por que vejo versões de Helm prefixadas gerenciadas pelo aks no meu cluster e por que a contagem de revisões continua aumentando?

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

Cotas, limites e disponibilidade da região

Quais regiões do Azure fornecem atualmente o AKS?

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

Posso espalhar um cluster AKS entre regiões?

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

Posso espalhar um cluster AKS pelas zonas de disponibilidade?

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

Posso ter diferentes tamanhos de VM em um único cluster?

Sim, você pode usar diferentes tamanhos de VM em seu cluster 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 do contêiner. Mas 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 (TB), 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. Você deve executar uma atualização no cluster e nos pools de nós do Windows Server no cluster AKS. Siga um cronograma regular com base no ciclo de lançamento do Windows Update e no 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, 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 AKS são necessárias para serem executadas como root?

As imagens a seguir têm requisitos funcionais para serem executadas como root, 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

Segurança, acesso e identidade

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

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

• Use intervalos de IP autorizados pelo 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 somente de dentro de sua rede virtual.

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

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 esta tarefa:

• Manualmente, através do portal do Azure ou da CLI do Azure.
• Atualizando seu cluster AKS. O cluster atualiza o cordão e drena os nós automaticamente. Em seguida, ele traz um novo nó on-line com a imagem mais recente do Ubuntu e uma nova versão de patch ou uma versão menor do Kubernetes. Para obter mais informações, veja Atualizar um cluster do AKS.
• Usando uma atualização de imagem de nó.

Existem ameaças à segurança que visam o AKS das quais eu deva estar ciente?

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. Para obter informações sobre uma ameaça à segurança relacionada ao AKS e ao Kubernetes, consulte Novos alvos de campanha em grande escala Kubeflow (8 de junho de 2021).

O AKS armazena dados de clientes 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 propriedade de permissão quando o volume tem vários arquivos?

Tradicionalmente, se o seu pod estiver sendo executado como um usuário não-root (o que deveria), você deve especificar um fsGroup parâmetro 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, consulte 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 chown() comandos e chmod() recursivamente para todos os arquivos e diretórios dentro do volume (com algumas exceções). Esse cenário acontece mesmo se a propriedade do grupo do volume já corresponder ao parâmetro solicitado fsGroup . Essa configuração pode ser cara para volumes maiores com muitos arquivos pequenos, o que pode fazer com que a inicialização do pod demore muito tempo. Este cenário era um problema conhecido antes da v1.20. A solução alternativa é definir o pod para ser executado 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.

Rede

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

O AKS usa uma comunicação de túnel segura para permitir que os api-server kubelets do nó individual se comuniquem, mesmo em redes virtuais separadas. O túnel é protegido através de criptografia mútua Transport Layer Security. O túnel principal atual que o AKS usa é o Konnectivity, anteriormente conhecido como apiserver-network-proxy. Verifique se todas as regras de rede seguem as regras de rede necessárias do 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 KUBERNETES_SERVICE_HOST variável 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 regras de aplicativo.

Posso configurar NSGs com AKS?

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 modifica apenas as configurações NSG da interface de rede. Se você estiver usando a CNI (Container Network Interface), também deverá garantir que as regras de segurança nos NSGs permitam o tráfego entre os intervalos CIDR (roteamento entre domínios sem classe 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.

Como funciona a sincronização de tempo no AKS?

Os nós AKS executam o serviço crony, que extrai tempo do host local. Os contêineres que são executados em pods obtêm o tempo dos nós AKS. Os aplicativos que se abrem dentro de um contêiner usam o tempo 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 manipulação dos recursos de infraestrutura como serviço (IaaS). Para instalar componentes personalizados, use as APIs e os mecanismos do Kubernetes. Por exemplo, use DaemonSets para instalar quaisquer componentes necessários.

Quais controladores de admissão do Kubernetes o AKS suporta? Os controladores de admissão podem ser adicionados ou removidos?

O AKS suporta os seguintes controladores de admissão:

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

Atualmente, 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 AKS internos, que são marcados com o control-plane rótulo. 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.

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

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

Se você tiver um caso de uso crítico para implantar algo em 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 aplicador de admissões o ignore:

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

O Azure Key Vault está integrado ao AKS?

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

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

Os nós habilitados com FIPS (Federal Information Processing Standards) 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.

Como os complementos do AKS são atualizados?

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), são atualizadas quando você atualiza seu cluster se uma nova versão estiver disponível. Para obter informações sobre quando uma nova versão está disponível, consulte as notas de versão do AKS.

Qual é a finalidade da extensão AKS Linux que vejo instalada nas instâncias dos meus conjuntos de escala de máquinas virtuais Linux?

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 VM e a disponibiliza usando um ponto de extremidade de métrica. Então, uma ferramenta de monitoramento, como o Prometheus, pode 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) que reúnem 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 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 extra 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 que são 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 você não tem bloqueios no grupo de recursos. Certifique-se também de que 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, 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 ou tags.

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

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 de falha ou de outra forma do cluster antes de atualizar.

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

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

Eu executei uma atualização, mas agora meus pods estão em loops de falha e as sondas de prontidão falham.

Confirme se a entidade de serviço não expirou. Para obter mais informações, consulte Entidade de serviço AKS e 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 entidade de serviço não expirou. Para obter mais informações, consulte Entidade de serviço AKS e Credenciais de atualização do AKS.

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

O AKS fornece garantias de contrato de nível de serviço (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 à plataforma inclui apenas suporte de 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 última versão secundária do AKS suportada que está geralmente disponível) 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 (VMs) 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. No momento, não há suporte para mover seu cluster AKS entre locatários.

Não. No momento, não há suporte para mover seu cluster AKS entre assinaturas.

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

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 está hospedando seus recursos de cluster usando o bloqueio do grupo de recursos do Nó.

Você pode parar completamente um cluster AKS em execução ou User de nós 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 operações de dimensionamento que usam 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 que usam 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 são do sistema para zero ou parar o cluster .

Não. Esta configuração não é suportada. Em vez disso, pare o cluster .

O AKS baseia-se em muitos recursos de infraestrutura do Azure, incluindo conjuntos de dimensionamento de máquinas virtuais, 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, 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 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. Use esse grupo de recursos somente para recursos que compartilham o ciclo de vida do cluster.

Nota

Modificar qualquer recurso sob o grupo de recursos do nó no cluster 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 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 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 az aks create comando, 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 nodeResourceGroup propriedade.

• 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ó, você não pode:

• 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ó depois de criar o 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 é aplicar políticas e modificar tags por meio do próprio recurso AKS, especificamente por meio dos pools de clusters e nós.

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

Nota

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

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

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. Para obter orientação sobre como criar uma arquitetura que inclua várias regiões, consulte Práticas recomendadas para continuidade de negócios e recuperação de desastres.

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 VM 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. Mas 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 (TB), 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. Você deve executar uma atualização no cluster e nos pools de nós do Windows Server no cluster AKS. Siga um cronograma regular com base no ciclo de lançamento do Windows Update e no 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, 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 serem executadas como root, 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 intervalos de IP autorizados pelo 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 somente 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 esta tarefa:

• Manualmente, através do portal do Azure ou da CLI do Azure.
• Atualizando seu cluster AKS. O cluster atualiza o cordão e drena os nós automaticamente. Em seguida, ele traz um novo nó on-line com a imagem mais recente do Ubuntu e uma nova versão de patch ou uma versão menor do Kubernetes. Para obter mais informações, veja Atualizar um cluster do AKS.
• Usando uma 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. Para obter informações sobre uma ameaça à segurança relacionada ao AKS e ao Kubernetes, consulte Novos alvos de campanha em grande escala 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 deveria), você deve especificar um fsGroup parâmetro 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, consulte 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 chown() comandos e chmod() recursivamente para todos os arquivos e diretórios dentro do volume (com algumas exceções). Esse cenário acontece mesmo se a propriedade do grupo do volume já corresponder ao parâmetro solicitado fsGroup . Essa configuração pode ser cara para volumes maiores com muitos arquivos pequenos, o que pode fazer com que a inicialização do pod demore muito tempo. Este cenário era um problema conhecido antes da v1.20. A solução alternativa é definir o pod para ser executado 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 os api-server kubelets do nó individual se comuniquem, mesmo em redes virtuais separadas. O túnel é protegido através de criptografia mútua Transport Layer Security. O túnel principal atual que o AKS usa é o Konnectivity, anteriormente conhecido como apiserver-network-proxy. Verifique se todas as regras de rede seguem as regras de rede necessárias do 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 KUBERNETES_SERVICE_HOST variável 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 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 modifica apenas as configurações NSG da interface de rede. Se você estiver usando a CNI (Container Network Interface), também deverá garantir que as regras de segurança nos NSGs permitam o tráfego entre os intervalos CIDR (roteamento entre domínios sem classe 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 crony, que extrai tempo do host local. Os contêineres que são executados em pods obtêm o tempo dos nós AKS. Os aplicativos que se abrem dentro de um contêiner usam o tempo do contêiner do pod.

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

O AKS suporta os seguintes controladores de admissão:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• 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. Recomendamos que você exclua namespaces AKS internos, que são marcados com o control-plane rótulo. 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 namespace, o kube-system AKS tem um aplicador de admissões, que exclui kube-system automaticamente os namespaces internos do AKS. Esse serviço garante que os controladores de admissão personalizados não afetem os serviços executados no kube-system.

Se você tiver um caso de uso crítico para implantar algo em 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 aplicador de admissões o ignore:

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

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

Os nós habilitados com FIPS (Federal Information Processing Standards) 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), são atualizadas quando você atualiza seu cluster se uma nova versão estiver disponível. Para obter informações sobre quando uma nova versão está disponível, consulte 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 VM e a disponibiliza usando um ponto de extremidade de métrica. Então, uma ferramenta de monitoramento, como o Prometheus, pode 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) que reúnem 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 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 extra 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 que são 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 você não tem bloqueios no grupo de recursos. Certifique-se também de que 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, 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 ou tags.

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 de falha ou de outra forma do cluster antes de atualizar.

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

Confirme se a entidade de serviço não expirou. Para obter mais informações, consulte Entidade de serviço AKS e Credenciais de atualização do AKS.

Confirme se a entidade de serviço não expirou. Para obter mais informações, consulte Entidade de serviço AKS e Credenciais de atualização do AKS.