Perguntas mais frequentes acerca do Azure Kubernetes Service (AKS)

Artigo
11/08/2023

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

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.º Os clusters AKS são recursos regionais e não podem abranger regiões. Consulte as práticas recomendadas para continuidade de negócios e recuperação de desastres para obter orientação sobre como criar uma arquitetura que inclua várias regiões.

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 limitar quem tem acesso ao servidor da API do Kubernetes?

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

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

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

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

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 que ela possa ser corrigida. As imagens AKS são atualizadas automaticamente dentro de 30 dias. Recomendamos que você aplique uma imagem de nó atualizada em uma cadência regular para garantir que as imagens corrigidas mais recentes e os patches do sistema operacional sejam todos aplicados e atuais. Você pode fazer isso usando um dos seguintes métodos:

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

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

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

Nós do Windows Server

Para nós do Windows Server, o Windows Update não executa e aplica automaticamente as atualizações mais recentes. Em um cronograma regular em torno do ciclo de lançamento do Windows Update e seu próprio processo de validação, você deve executar uma atualização no cluster e no(s) pool(s) do Windows Server no cluster AKS. Esse processo de atualização cria nós que executam a imagem e os patches mais recentes do Windows Server e, em seguida, remove os nós mais antigos. Para obter mais informações sobre esse processo, consulte Atualizar um pool de nós no AKS.

Existem ameaças de segurança direcionadas ao 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. A seguinte ameaça à segurança está relacionada ao AKS e ao Kubernetes que você deve estar ciente:

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

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 o servidor api e os kubelets de nó individuais se comuniquem mesmo em redes virtuais separadas. O túnel é protegido através de criptografia mTLS. O túnel principal atual que é usado pelo AKS é o Konnectivity, anteriormente conhecido como apiserver-network-proxy. Verifique se todas as regras de rede seguem as regras de rede e os FQDNs necessários do Azure.

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

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 Escala de Máquina Virtual, redes virtuais e discos gerenciados. Essas integrações permitem que você aplique muitos dos principais recursos da plataforma Azure no ambiente Kubernetes gerenciado fornecido pelo AKS. Por exemplo, a maioria dos tipos de máquina virtual do Azure pode ser usada diretamente com o AKS e as Reservas do Azure podem ser usadas para receber descontos nesses recursos automaticamente.

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

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

Posso fornecer o meu próprio nome para o grupo de recursos do nó AKS?

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

Para especificar seu próprio nome de grupo de recursos, instale a extensão aks-preview Azure CLI versão 0.3.2 ou posterior. Ao criar um cluster AKS usando o comando, use o parâmetro e especifique um nome para o az aks create--node-resource-group grupo de recursos. Se você usar um modelo do Azure Resource Manager para implantar um cluster AKS, poderá definir o nome do grupo de recursos usando a propriedade nodeResourceGroup.

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

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

Especifique um grupo de recursos existente para o grupo de recursos do nó.
Especifique uma assinatura diferente para o grupo de recursos do nó.
Altere o nome do grupo de recursos do nó após a criação do cluster.
Especifique nomes para os recursos gerenciados dentro do grupo de recursos do nó.
Modifique ou exclua marcas criadas pelo Azure de recursos gerenciados dentro do grupo de recursos do nó. Consulte as informações adicionais na próxima secção.

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 é criar Políticas do Azure com um escopo no grupo de recursos gerenciados.

As tags criadas pelo Azure são criadas para seus respetivos Serviços do Azure e sempre devem ser permitidas. Para o AKS, existem as aks-managed tags e k8s-azure . Modificar quaisquer marcas criadas pelo Azure em recursos sob o grupo de recursos de nó no cluster AKS é uma ação sem suporte, que quebra o SLO (objetivo de nível de serviço). Para obter mais informações, consulte O AKS oferece um contrato de nível de serviço?

Nota

No passado, o nome da tag "Proprietário" 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 usam o prefixo aks-managed . Para recursos herdados, não use políticas do Azure para aplicar o nome da marca "Proprietário". Caso contrário, todos os recursos em suas operações de implantação e atualização de cluster AKS serão interrompidos. Isso não se aplica aos recursos recém-criados.

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

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

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

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 kube-system, o namespace AKS tem um Admissions Enforcer, que exclui automaticamente os namespaces internos kube-system e AKS. Este serviço garante que os controladores de admissão personalizados não afetem os serviços em execução no kube-system.

Se você tiver um caso de uso crítico para implantar algo no kube-system (não recomendado) em suporte ao seu webhook de admissão personalizado, você pode adicionar o seguinte rótulo ou anotação para que o Admissions Enforcer o ignore.

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

O Azure Key Vault está integrado ao AKS?

O Azure Key Vault Provider for Secrets Store CSI Driver fornece integração nativa do Azure Key Vault no 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 contêineres do Windows Server no AKS, crie um pool de nós que execute o Windows Server como o sistema operacional convidado. Os contêineres do Windows Server podem usar apenas o Windows Server 2019. Para começar, consulte Criar um cluster AKS com um pool de nós do Windows Server.

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

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

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

O nível 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 de subposição não íntegros, manutenção da plataforma, um aplicativo sobrecarrega o Servidor de API com solicitações, etc. Para cargas de trabalho de missão crítica e de produção, ou se sua carga de trabalho não tolerar reinicializações do Servidor de API, recomendamos o uso da camada Padrão, que inclui o SLA de tempo de atividade.

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 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.

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

No momento, não há suporte para mover seu 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 AKS da assinatura atual do Azure para outra?

Não há suporte para mover seu cluster AKS e seus recursos associados entre assinaturas do Azure.

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

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

Por que minha exclusão de cluster está demorando 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 RGs, a exclusão pode levar mais tempo ou até mesmo falhar. Se você tiver um problema com exclusões, verifique se você não tem bloqueios no RG, se todos os recursos fora do RG estão desassociados do RG e assim por diante.

Por que minha criação/atualização de cluster está demorando tanto?

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

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

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

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

Funcionalidade e componentes do Kubernetes
Criação de cluster ou pool de nós
Correções
Correções de erros
Patches de segurança
Componentes retirados

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

O AKS conta com os lançamentos e patches do Kubernetes, que é um projeto Open Source que suporta apenas 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 a montante. Como não há mais patches sendo produzidos a montante, o AKS pode deixar essas versões sem patches ou bifurcação. Devido a essa limitação, o suporte à plataforma não suporta nada de depender do kubernetes upstream.

O AKS atualiza automaticamente meus clusters não suportados?

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

Por exemplo, o kubernetes v1.25 atualiza para v1.26 durante a versão v1.29 GA. Para minimizar interrupções, configure janelas de manutenção. Consulte Atualização automática para obter detalhes sobre os canais de atualização automática.

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

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, posso executar uma atualização?

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

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

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

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. Consulte: Entidade de serviço AKS e credenciais de atualização AKS.

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

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

Posso dimensionar meu cluster AKS para zero?

Você pode parar completamente um cluster AKS em execução, economizando nos respetivos custos de computação. Além disso, você também pode optar por dimensionar ou dimensionar automaticamente todos ou pools de nós específicos User 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áquina Virtual para dimensionar manualmente?

Não, não há suporte para operações de dimensionamento usando as APIs do Conjunto de Dimensionamento de Máquina Virtual. Use 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 usando as APIs do Conjunto de Dimensionamento de Máquina Virtual. Você pode usar a API AKS para dimensionar para zero pools de nós que não sejam do sistema ou parar o cluster .

Posso parar ou desalocar todas as minhas VMs?

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

Posso usar extensões de VM personalizadas?

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

O AKS 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 AKS são necessárias para serem executadas como root?

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

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

O que é o Modo Transparente CNI do Azure vs. Modo Bridge?

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

Modo Bridge

O modo Azure CNI Bridge cria uma ponte L2 chamada "azure0" de forma "just in time". Todas as interfaces de par de pods veth do lado do host estão conectadas a esta ponte. A comunicação intra VM do Pod-Pod e o tráfego restante passam por esta ponte. A ponte é um dispositivo virtual de camada 2 que, por si só, não pode receber ou transmitir nada, a menos que você vincule um ou mais dispositivos reais a ele. Por esse motivo, eth0 da VM Linux tem que ser convertido em um subordinado à ponte "azure0", que cria uma topologia de rede complexa dentro da VM Linux. Como sintoma, a CNI teve que lidar com outras funções de rede, como atualizações do servidor DNS.

Bridge mode topology

O exemplo a seguir mostra a aparência da configuração da rota ip no modo Bridge. Independentemente de quantos pods o nó tenha, existem apenas duas rotas. A primeira rota diz que o tráfego (excluindo local no azure0) vai para o gateway padrão da sub-rede através da interface com ip "src 10.240.0.4", que é o IP primário do Node. O segundo diz "10.20.x.x" Pod space to kernel for kernel to kernel to mind.

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 adota uma abordagem direta para configurar a rede Linux. Neste modo, o Azure CNI não altera nenhuma propriedade da interface eth0 na VM Linux. Essa abordagem de alterar as propriedades de rede Linux ajuda a reduzir problemas complexos de casos de canto que os clusters podem enfrentar com o modo Bridge. No modo Transparente, o Azure CNI cria e adiciona interfaces de par de pods veth do lado do host que são adicionadas à rede do host. A comunicação Intra VM Pod-to-Pod é através de rotas ip adicionadas pela CNI. Essencialmente, a comunicação Pod-to-Pod é sobre a camada 3 e as regras de roteamento L3 roteiam o tráfego do pod.

Transparent mode topology

O exemplo a seguir mostra uma configuração de rota ip do modo Transparente. A interface de cada Pod recebe uma rota estática anexada para que o tráfego com dest IP como o Pod seja enviado diretamente para a interface de par do lado veth 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 conntrack a condição de corrida paralela de DNS e evita 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 CNI de latência DNS inicial de 5 segundos introduzido hoje devido à configuração de ponte "just in time".
Um dos casos de canto no modo Bridge é 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 faz com que a CNI pegue 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. Veja mais aqui.
Fornece melhor manuseio do tráfego UDP e mitigação para tempestades de inundação UDP quando o ARP expira. No modo Bridge, quando o bridge não sabe um endereço MAC do pod de destino na comunicação intra-VM Pod-to-Pod, por design, isso resulta em tempestade do pacote para todas as portas. Esse problema é resolvido no modo transparente, pois não há dispositivos L2 no caminho. Veja mais aqui.
O modo transparente tem melhor desempenho na comunicação Intra VM Pod-to-Pod em termos de taxa de transferência e latência quando comparado ao modo Bridge.

Como evitar problemas lentos de 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 você deve), você deve especificar um fsGroup dentro do contexto de segurança do pod para que o volume possa ser legível e gravável pelo Pod. Este requisito é abordado em mais pormenor aqui.

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

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

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

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

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

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 apenas modifica as configurações NSGs das interfaces de rede. Se você estiver usando CNI, também deve garantir que as regras de segurança nos NSGs permitam o tráfego entre os intervalos CIDR do nó e do pod. Se você estiver usando kubenet, também deve garantir que as regras de segurança nos NSGs permitam o tráfego entre o nó e o pod CIDR. Para obter mais informações, consulte Grupos de segurança de rede.

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

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

Como os addons 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), é atualizada quando você atualiza seu cluster se uma nova versão estiver disponível. Você pode descobrir quando uma nova versão está disponível visitando as notas de versão do AKS.

Qual é a finalidade da extensão AKS Linux que vejo instalada nas minhas instâncias do Linux Virtual Machine Scale Sets?

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

Exportador de nó: coleta a telemetria de hardware da máquina virtual e a disponibiliza usando um ponto de extremidade de métrica. Então, uma ferramenta de monitoramento, como o Prometheus, é capaz de descartar essas métricas.
Node-problem-detector: Visa tornar vários problemas de nó visíveis para camadas upstream na pilha de gerenciamento de cluster. É uma unidade systemd que é executada em cada nó, deteta problemas de nó e os relata ao servidor de API do cluster usando Events e NodeConditions.
ig: Um framework de código aberto alimentado por eBPF para depuração e observação de sistemas Linux e Kubernetes. Ele fornece um conjunto de ferramentas (ou gadgets) projetados para reunir informações relevantes, permitindo que os usuários identifiquem a causa de problemas de desempenho, falhas ou outras anomalias. Notavelmente, sua independência do Kubernetes permite que os usuários o empreguem também para depurar problemas do plano de controle.

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

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

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