Perguntas frequentes sobre o Serviço de Kubernetes do Azure (AKS)

Este artigo aborda as perguntas frequentes sobre o AKS (Serviço de Kubernetes do Azure).

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

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 dão suporte a elas.

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

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

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

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

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

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

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

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

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. No entanto, é importante entender que quanto maior a imagem, maior a demanda de memória. Potencialmente, um tamanho maior poderia exceder os limites de recursos ou a memória geral disponível dos nós de trabalho. Por padrão, a memória para o tamanho da VM Standard_DS2_v2 para um cluster do AKS é definida como 7 GiB.

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

Nós do Windows Server

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

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

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

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

Como o Plano de Controle gerenciado se comunica com meus nós?

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

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. Isso é útil nos casos em que a saída do cluster é feita por meio de um firewall de camada 7, como ao usar Firewall do Azure com regras de aplicativo.

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

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

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

1. Você cria o primeiro grupo de recursos. Esse grupo contém apenas o recurso do Serviço de Kubernetes. O provedor de recursos do AKS cria automaticamente o segundo grupo de recursos durante a implantação. Um exemplo do segundo grupo de recursos é MC_myResourceGroup_myAKSCluster_eastus. Para obter informações sobre como especificar o nome desse segundo grupo de recursos, confira a próxima seção.

2. O segundo grupo de recursos, conhecido como o grupo de recursos do nó, contém todos os recursos de infraestrutura associados ao cluster. Esses recursos incluem as máquinas virtuais do nó do Kubernetes, rede virtual e armazenamento. Por padrão, o grupo de recursos do nó tem um nome como MC_myResourceGroup_myAKSCluster_eastus. O AKS exclui automaticamente o grupo de recursos do nó sempre que você exclui o cluster. Você só deve usar esse cluster para 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ó impedindo 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?

Sim. Por padrão, o AKS nomeia o grupo de recursos do nó MC_resourcegroupname_clustername_location, mas você também poderá usar um nome personalizado.

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 usando o 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, defina o nome do grupo de recursos usando a propriedade nodeResourceGroup.

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

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

• Especificar um grupo de recursos existente para o grupo de recursos do nó.
• Especificar uma assinatura diferente para o grupo de recursos do nó.
• Alterar o nome do grupo de recursos do nó depois que o cluster for criado.
• Especificar nomes para os recursos gerenciados dentro do grupo de recursos do nó.
• Modificar ou excluir marcas criadas pelo Azure de recursos gerenciados dentro do grupo de recursos do nó. Confira as informações adicionais na próxima seção.

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 criar e modificar marcas personalizadas criadas por usuários finais, e você pode adicionar essas marcas ao criar um pool de nós. O ideal é criar ou modificar marcas personalizadas, por exemplo, para atribuir uma unidade de negócios ou um centro de custo. Outra opção é criar políticas do Azure com um escopo no grupo de recursos gerenciados.

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

Observação

No passado, o nome de marca "Owner" era reservado para o AKS gerenciar o IP público atribuído no IP front-end do balanceador de carga. Agora, os serviços seguem o uso do prefixo aks-managed. Para recursos herdados, não use políticas do Azure para aplicar o nome de 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. Isso não se aplica a recursos recém-criados.

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 excluir os namespaces internos do AKS que estão marcados com o rótulo do painel de controle. Por exemplo:

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

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

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

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

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

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

O Azure Key Vault é integrado com o AKS?

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

Posso executar contêineres do Windows Server no AKS?

Sim, os contêineres do Windows Server estão disponíveis no AKS. Para executar os contêineres do Windows Server no AKS, crie um pool de nós que executa o Windows Server como o SO convidado. Os contêineres do Windows Server podem usar apenas o Windows Server 2019. Para começar a usá-lo, confira Criar um cluster do AKS com um pool de nós do Windows Server.

O suporte do Windows Server para pools de nós inclui algumas limitações que fazem parte do Windows Server upstream no projeto do Kubernetes. Para obter mais informações sobre essas limitações, confira Limitações de contêineres do Windows Server no AKS.

O AKS oferece um SLA?

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

O tipo de preço Gratuito não tem um Contrato de nível de serviço associado, mas tem um Objetivo de nível de serviço de 99,5%. Problemas transitórios de conectividade são observados se houver uma atualização, nós subjacentes não íntegros, manutenção da plataforma, um aplicativo sobrecarregar o Servidor de API com solicitações etc. Para cargas de trabalho críticas e de produção, ou se sua carga de trabalho não tolera reinicializações do Servidor de API, recomendamos usar a camada Standard, que inclui SLA do Tempo de Atividade.

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

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

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

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

Posso mover/migrar meu cluster entre assinaturas?

No momento, não há suporte para a movimentação de clusters entre assinaturas.

Posso mover meus clusters do AKS da assinatura atual do Azure para outra?

Não há suporte para a movimentação do cluster do AKS e dos recursos associados entre assinaturas do Azure.

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

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

Por que a exclusão do meu cluster demora tanto?

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

Por que a criação/atualização do meu cluster demora tanto?

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

Posso restaurar o 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. Um exemplo do segundo grupo de recursos é MC_myResourceGroup_myAKSCluster_eastus.

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

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 suporte à infraestrutura do Azure. O suporte à plataforma não inclui nada relacionado ao seguinte:

• Funcionalidade e componentes do Kubernetes
• Criação do cluster ou pool de nós
• Hotfixes
• Correções de bug
• Patches de segurança
• Componentes desativados

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

O AKS depende dos lançamentos e patches do Kubernetes, que é um projeto de código aberto que dá suporte apenas a uma janela deslizante de três versões secundárias. O AKS só pode garantir suporte total enquanto essas versões estão sendo atendidas em upstream. Como não há mais patches sendo produzidos em upstream, o AKS pode deixar essas versões sem patch ou bifurcá-las. Devido a essa limitação, o suporte à plataforma não dá suporte a nada que dependa do upstream do kubernetes.

O AKS atualiza automaticamente meus clusters sem suporte?

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

Por exemplo, o kubernetes v1.25 atualiza para v1.26 durante o lançamento para GA da v1.29. Para minimizar as interrupções, configure janelas de manutenção. Confira atualização automática para obter detalhes sobre canais de atualização automática.

Se eu tiver um pod/implantações no estado 'NodeLost' ou 'Unknown', ainda poderei atualizar o meu cluster?

Você pode, mas não recomendamos. Você deve executar 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 desligado, poderei executar uma atualização?

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

Executei uma exclusão de cluster, mas o erro [Errno 11001] getaddrinfo failed é exibido

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

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

Confirme se a entidade de serviço não expirou. Consulte: Entidade de serviço do AKS e Credenciais de atualização do AKS.

Meu cluster estava funcionando, mas, de repente, não consegue provisionar LoadBalancers, montar PVCs etc.?

Confirme se a entidade de serviço não expirou. Consulte: Entidade de serviço do AKS e Credenciais de atualização do AKS.

Posso dimensionar meu cluster do AKS para zero?

Você pode interromper completamente um cluster do AKS em execução, economizando nos respectivos custos de computação. Além disso, você também pode optar por dimensionar ou fazer o dimensionamento automático de User todos os pools de nós ou pools de nós específicos para 0, mantendo apenas a configuração de cluster necessária.

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 escalar manualmente?

Não. Não há suporte para operações de escala usando as APIs do conjunto de dimensionamento de máquinas virtuais. Use as APIs do AKS (az aks scale).

Posso usar Conjuntos de Dimensionamento de Máquinas Virtuais para escalar manualmente para 0 nó?

Não. Não há suporte para operações de escala usando as APIs do conjunto de dimensionamento de máquinas virtuais. Use a API do AKS para escalar para zero os pools de nós que não são do sistema ou parar o cluster.

Posso interromper ou desalocar todas as minhas VMs?

Embora o AKS tenha mecanismos de resiliência para tolerar uma configuração como essa e se recuperar dela, não é uma configuração com suporte. Em vez disso, pare o cluster.

Posso usar extensões de VM personalizadas?

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

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

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

As imagens do AKS devem ser executadas como raiz?

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

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

O que é Modo transparente da CNI do Azure x Modo de ponte?

A partir da versão 1.2.0, o Azure CNI define o modo Transparente como padrão para implantações de CNI do Linux de locação única. O modo transparente está substituindo o modo de ponte. Nas seções modo Ponte e modo Transparente a seguir, discutimos mais sobre as diferenças entre ambos os modos e os benefícios e limitações do modo Transparente na CNI do Azure.

Modo de ponte

O modo Ponte da CNI do Azure cria uma ponte L2 chamada "azure0" de forma "just-in-time". Todas as interfaces de par veth do pod do lado do host serão conectadas a essa ponte. A comunicação da VM intra pods e o tráfego restante passa por essa ponte. A ponte é um dispositivo virtual de camada 2 que, por sua vez, não pode receber ou transmitir nada, a menos que você associe um ou mais dispositivos reais a ela. Por esse motivo, o eth0 da VM do Linux precisa ser convertido em uma ponte subordinada a "azure0", o que cria uma topologia de rede complexa dentro da VM do Linux. Como sintoma, a CNI precisava lidar com outras funções de rede, como atualizações do servidor DNS.

O exemplo a seguir mostra como é a configuração da rota de IP no modo de Ponte. Independentemente de quantos pods o nó tem, haverá apenas duas rotas. A primeira rota diz que o tráfego (excluindo local no azure0) vai para o gateway padrão da sub-rede por meio da interface com ip "src 10.240.0.4", que é o IP principal do nó. O segundo diz "10.20.x.x" Espaço de pod para kernel para o kernel decidir.

default via 10.240.0.1 dev azure0 proto dhcp src 10.240.0.4 metric 100
10.240.0.0/12 dev azure0 proto kernel scope link src 10.240.0.4
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
root@k8s-agentpool1-20465682-1:/#

Modo transparente

O modo transparente usa uma abordagem direta para configurar a rede do Linux. Nesse modo, a CNI do Azure não alterará nenhuma propriedade da interface eth0 na VM do Linux. Essa abordagem de alteração das propriedades de rede do Linux ajuda a reduzir os problemas de caso complexos que os clusters podem enfrentar com o modo Ponte. No modo Transparente, a CNI do Azure criará e adicionará interfaces de par veth do pod do lado do cliente que serão adicionadas à rede do host. A comunicação entre pods da VM é por meio de rotas ip adicionadas pela CNI. Essencialmente, a comunicação entre pods é sobre as regras de roteamento de camada 3 e L3 rotear o tráfego do pod.

O exemplo a seguir mostra uma configuração de rota IP no modo Transparente. A interface de cada pod terá uma rota estática anexada para que o tráfego com o IP de destino como o Pod seja enviado diretamente para a interface de par veth do lado do host do Pod.

10.240.0.216 dev azv79d05038592 proto static
10.240.0.218 dev azv8184320e2bf proto static
10.240.0.219 dev azvc0339d223b9 proto static
10.240.0.222 dev azv722a6b28449 proto static
10.240.0.223 dev azve7f326f1507 proto static
10.240.0.224 dev azvb3bfccdd75a proto static
168.63.129.16 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
169.254.169.254 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

Benefícios do modo Transparente

• Fornece mitigação para a conntrack condição de corrida paralela do DNS e evitar problemas de latência de DNS de 5 segundos sem a necessidade de configurar o DNS local do nó (você ainda pode usar o DNS local do nó por motivos de desempenho).
• Elimina o modo de ponte da CNI de latência de DNS de 5 segundos inicial que apresenta hoje devido à configuração de ponte "Just-in-time".
• Um dos casos extremos no modo Ponte é que a CNI do Azure não pode continuar atualizando as listas de servidores DNS personalizadas que os usuários adicionam à VNET ou NIC. Esse cenário resulta na CNI selecionando apenas a primeira instância da lista de servidores DNS. Esse problema é resolvido no modo Transparente, pois a CNI não altera nenhuma propriedade eth0. Obtenha mais informações aqui.
• Fornece melhor tratamento do tráfego UDP e mitigação para o storm de inundação UDP quando o ARP atinge o tempo limite. No modo Ponte, quando a ponte não conhece um endereço MAC do pod de destino na comunicação entre pods da VM, por padrão, resulta no storm do pacote para todas as portas. Esse problema é resolvido no modo Transparente, pois não há dispositivos L2 no caminho. Obtenha mais informações aqui.
• O modo Transparente tem melhor desempenho na comunicação entre pods da VM em termos de taxa de transferência e latência quando comparado ao modo Ponte.

Como evitar que a propriedade de permissão defina problemas lentos quando o volume tiver vários arquivos?

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

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

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

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

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

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

Posso configurar NSGs com o AKS?

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

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

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

Como os complementos do AKS são atualizados?

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

Qual é a finalidade da extensão AKS Linux instalada em minhas instâncias de Conjuntos de Dimensionamento de Máquinas Virtuais do Linux?

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

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

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

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

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