Perguntas mais frequentes acerca do Azure Kubernetes Service (AKS)

Este artigo aborda questões frequentes sobre Azure Kubernetes Service (AKS).

Quais as regiões de Azure que atualmente fornecem AKS?

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

Posso espalhar um aglomerado AKS por regiões?

N.º Os aglomerados AKS são recursos regionais e não podem abranger regiões. Consulte as melhores práticas para a continuidade do negócio e recuperação de desastres para obter orientações sobre como criar uma arquitetura que inclua várias regiões.

Posso espalhar um cluster AKS através de zonas de disponibilidade?

Sim. Você pode implementar um cluster AKS em uma ou mais zonas de disponibilidade em regiões que as suportam.

Posso limitar quem tem acesso ao servidor API da Kubernetes?

Sim. Existem duas opções para limitar o acesso ao servidor API:

  • Utilize gamas IP autorizadas do servidor API se pretender manter um ponto final público para o servidor API, mas restringir o acesso a um conjunto de gamas IP fidedignas.
  • Utilize um cluster privado se pretender limitar o servidor API para estar apenas acessível a partir da sua rede virtual.

Posso ter diferentes tamanhos de VM num único aglomerado?

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

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

AKS patches CVE's que têm uma "correção de fornecedor" todas as semanas. Os CVE's sem uma correção estão à espera de uma "correção do fornecedor" antes de poder ser remediada. As imagens AKS serão automaticamente atualizadas dentro de 30 dias e recomendou que o cliente aplicasse uma Imagem de Nó atualizada numa cadência regular para garantir que as imagens remendadas e patches de OS mais recentes sejam todas aplicadas e atuais:

Qual é o limite de tamanho numa imagem de contentor em AKS?

AKS não estabelece um limite para o tamanho da imagem do recipiente. No entanto, é importante entender que quanto maior a imagem, maior a procura de memória. Isto poderia potencialmente exceder os limites de recursos ou a memória geral disponível dos nós dos trabalhadores. Por predefinição, a memória para o tamanho VM Standard_DS2_v2 para um cluster AKS é definida para 7 GiB.

Quando uma imagem de recipiente é excessivamente grande, como na gama Terabyte (TBs), o kubelet pode não conseguir retirá-la do registo do seu contentor para um nó devido à falta de espaço no disco.

Os acenos do Servidor do Windows

Para os nós do Windows Server, Windows Update não executam automaticamente e aplicam as atualizações mais recentes. Numa programação regular em torno do ciclo de lançamento Windows Update e do seu próprio processo de validação, deverá realizar uma atualização no cluster e no conjunto de nós do Windows Server no seu cluster AKS. Este processo de atualização cria nós que executam a mais recente imagem e patches do Windows Server e, em seguida, remove os nós mais antigos. Para obter mais informações sobre este processo, consulte a atualização de um conjunto de nós em AKS.

Existem ameaças de segurança que visam a AKS que os clientes devem ter conhecimento?

Microsoft fornece orientações para outras ações que pode tomar para garantir as suas cargas de trabalho através de serviços como Microsoft Defender para contentores. A seguinte ameaça de segurança está relacionada com AKS e Kubernetes que os clientes devem estar cientes:

Como é que o avião de controlo gerido comunica com os meus nós?

A AKS utiliza uma comunicação de túnel segura para permitir que o servidor api e os kubelets individuais do nó se comuniquem mesmo em redes virtuais separadas. O túnel está protegido através da encriptação TLS. O atual túnel principal que é usado pela AKS é a Konnectivity, anteriormente conhecida como apiserver-network-proxy. Verifique todas as regras de rede que seguem as regras de rede exigidas pelo Azure e as FQDNs.

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

A AKS baseia-se em muitos recursos de infraestrutura Azure, incluindo conjuntos de escala de máquinas virtuais, redes virtuais e discos geridos. Isto permite-lhe aplicar muitas das capacidades centrais da plataforma Azure dentro do ambiente gerido de Kubernetes fornecido pela AKS. Por exemplo, a maioria dos tipos de máquinas virtuais Azure podem ser usados diretamente com reservas AKS e Azure podem ser usados para receber descontos nesses recursos automaticamente.

Para permitir esta arquitetura, cada implantação AKS abrange dois grupos de recursos:

  1. Cria-se o primeiro grupo de recursos. Este grupo contém apenas o recurso de serviço Kubernetes. O fornecedor de recursos AKS cria automaticamente o segundo grupo de recursos durante a implementação. Um exemplo do segundo grupo de recursos é MC_myResourceGroup_myAKSCluster_eastus. Para obter informações sobre como especificar o nome deste segundo grupo de recursos, consulte a secção seguinte.
  2. O segundo grupo de recursos, conhecido como grupo de recursos de nó, contém todos os recursos de infraestrutura associados ao cluster. Estes recursos incluem os VMs de nó de Kubernetes, networking virtual e armazenamento. Por padrão, o grupo de recursos de nó tem um nome como MC_myResourceGroup_myAKSCluster_eastus. A AKS elimina automaticamente o grupo de recursos de nó sempre que o cluster é eliminado, pelo que só deve ser utilizado para recursos que partilhem o ciclo de vida do cluster.

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

Sim. Por padrão, a AKS nomeará o grupo de recursos de nó MC_resourcegroupname_clustername_location, mas também pode fornecer o seu próprio nome.

Para especificar o nome do seu próprio grupo de recursos, instale a versão de extensão Azure CLI de pré-visualização aks-preview0.3.2 ou posterior. Quando criar um cluster AKS utilizando os az aks criar comando, use o --node-resource-group parâmetro e especifique um nome para o grupo de recursos. Se utilizar um modelo Azure Resource Manager para implantar um cluster AKS, pode definir o nome do grupo de recursos utilizando a propriedade nodeResourceGroup.

  • O grupo de recursos secundários é automaticamente criado pelo fornecedor de recursos Azure na sua própria subscrição.
  • Só pode especificar um nome de grupo de recursos personalizados quando estiver a criar o cluster.

Ao trabalhar com o grupo de recursos de nó, lembre-se que não pode:

  • Especifique um grupo de recursos existente para o grupo de recursos de nó.
  • Especifique uma subscrição diferente para o grupo de recursos de nó.
  • Mude o nome do grupo de recursos do nó após a criação do cluster.
  • Especificar os nomes dos recursos geridos dentro do grupo de recursos do nó.
  • Modificar ou eliminar tags criadas pelo Azure de recursos geridos dentro do grupo de recursos do nó. (Ver informações adicionais na secção seguinte.)

Posso modificar etiquetas e outras propriedades dos recursos AKS no grupo de recursos de nó?

Se modificar ou eliminar tags criadas pelo Azure e outras propriedades de recursos no grupo de recursos de nó, poderá obter resultados inesperados, tais como erros de escala e de atualização. A AKS permite-lhe criar e modificar tags personalizadas criadas pelos utilizadores finais, e pode adicionar essas tags ao criar um conjunto de nós. É possível que queira criar ou modificar tags personalizadas, por exemplo, para atribuir uma unidade de negócio ou um centro de custos. Isto também pode ser conseguido através da criação de Políticas Azure com âmbito no grupo de recursos geridos.

No entanto, modificar quaisquer Etiquetas criadas pelo Azure em recursos no âmbito do grupo de recursos de nó no cluster AKS é uma ação não suportada, que interrompe o objetivo de nível de serviço (SLO). Para mais informações, consulte a AKS oferecer um acordo de nível de serviço?

Que controladores de admissão kubernetes suportam AKS? Os controladores de admissão podem ser adicionados ou removidos?

A AKS suporta os seguintes controladores de admissão:

  • Espaço nomeLifecycle
  • LimiteRanger
  • ServiceAccount
  • Classe defaultstorage
  • Padrão DeleraçãoSegundos
  • MutatingAdmissionWebhook
  • Validação DoWebhook deAdmission
  • RecursosQuota
  • PodNodeSelector
  • PodTolerationRestriction
  • Ampliação da Localização

Atualmente, não é possível modificar a lista de controladores de admissão em AKS.

Posso usar webhooks de controlador de admissão na AKS?

Sim, pode usar webhooks do controlador de admissão na AKS. Recomenda-se que exclua espaços internos de nomes AKS, que são marcados com a etiqueta do plano de controlo. Por exemplo, adicionando o abaixo à configuração webhook:

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

AKS firewalls o servidor API egress para que os seus webhooks do controlador de admissão de admissão devem estar acessíveis a partir do cluster.

Os webhooks do controlador de admissão podem impactar o sistema kube e os espaços internos de nomeS AKS?

Para proteger a estabilidade do sistema e evitar que os controladores de admissão personalizados impactem os serviços internos no sistema kube, o namespace AKS tem um Executor de Admissões, que exclui automaticamente o sistema kube e os espaços de nome internos AKS. Este serviço garante que os controladores de admissão personalizados não afetam os serviços em execução no sistema kube.

Se tiver um caso de uso crítico para implementar algo no sistema kube (não recomendado) em apoio ao seu webhook de admissão personalizado, pode adicionar a etiqueta ou anotação abaixo para que o Executor de Admissões o ignore.

Etiqueta: "admissions.enforcer/disabled": "true" ou Anotação: "admissions.enforcer/disabled": true

O Azure Key Vault integrado com a AKS?

Azure Key Vault Provider for Secrets Store CSI Driver proporciona integração nativa do Azure Key Vault em AKS.

Posso executar os contentores do Windows Server na AKS?

Sim, os contentores do Windows Server estão disponíveis em AKS. Para executar os contentores do Windows Server em AKS, cria uma piscina de nós que executa o Windows Server como o SISTEMA convidado. Os contentores do Windows Server só podem utilizar o Windows Server 2019. Para começar, consulte Criar um cluster AKS com uma piscina de nó de nó do Windows Server.

O suporte do Windows Server para o conjunto de nós inclui algumas limitações que fazem parte do projeto Do Windows Server a montante em Kubernetes. Para obter mais informações sobre estas limitações, consulte os recipientes do Windows Server em limitações AKS.

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

A AKS fornece garantias SLA como uma funcionalidade opcional com Uptime SLA.

O SKU gratuito oferecido por padrão não tem um Acordo de Nível de Serviço associado, mas tem um Objetivo de Nível de Serviço de 99,5%. Os problemas de conectividade transitórios são observados se houver uma atualização, nós de subalques pouco saudáveis, manutenção da plataforma, ou uma aplicação sobrecarrega o Servidor API com pedidos, etc. Se a sua carga de trabalho não tolerar o reinício do Servidor API, então sugerimos a utilização de SLA uptime.

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

Os nós de agente AKS são faturados como máquinas virtuais Azure padrão. Se adquiriu reservas Azure para o tamanho VM que está a usar em AKS, esses descontos são automaticamente aplicados.

Posso mover/migrar o meu aglomerado entre inquilinos do Azure?

Mover o seu cluster AKS entre inquilinos não é atualmente suportado.

Posso mover/migrar o meu cluster entre assinaturas?

Atualmente, a circulação de clusters entre subscrições não é apoiada.

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

A deslocação do seu cluster AKS e os seus recursos associados entre subscrições Azure não são suportados.

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

Mover ou renomear o seu cluster AKS e os seus recursos associados não é suportado.

Porque é que o meu grupo está a demorar tanto tempo?

A maioria dos clusters são eliminados a pedido do utilizador; em alguns casos, especialmente quando os clientes estão a trazer o seu próprio Grupo de Recursos, ou a fazer a eliminação de tarefas cross-RG pode demorar mais tempo ou falhar. Se tiver algum problema com as eliminações, verifique duas vezes se não tem fechaduras no RG, que quaisquer recursos fora do RG são dissociados do RG, e assim por diante.

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

Podes, mas a AKS não recomenda isto. As atualizações devem ser realizadas quando o estado do cluster é conhecido e saudável.

Se eu tiver um aglomerado com um ou mais nós em estado pouco saudável ou desligado, posso fazer uma atualização?

Não, elimine/remova quaisquer nós num estado falhado ou de outra forma removidos do cluster antes da atualização.

Fiz um aglomerado apagar, mas ver o erro [Errno 11001] getaddrinfo failed

Mais comummente, isto é causado por utilizadores que têm um ou mais Grupos de Segurança de Rede (NSGs) ainda em uso e associados ao cluster. Retire-os e tente apagar novamente.

Fiz um upgrade, mas agora as minhas cápsulas estão em circuitos de colisão, e as sondas de prontidão falham?

Confirme que o seu diretor de serviço não expirou. Ver: Credenciais de atualização de serviço AKS e AKS.

O meu grupo estava a funcionar, mas de repente não consegue abastecer LoadBalancers, montar PVCs, etc.?

Confirme que o seu diretor de serviço não expirou. Ver: Credenciais de atualização de serviço AKS e AKS.

Posso escalar o meu cluster AKS para zero?

Você pode parar completamente um cluster AKS em execução, economizando nos respetivos custos de cálculo. Além disso, também pode optar por escalar ou autoescalar todas as piscinas de nó ou conjuntos de nós específicos User para 0, mantendo apenas a configuração de cluster necessária. Não se pode escalar diretamente as piscinas de nós do sistema a zero.

Posso utilizar as APIs de escala de máquina virtual para escalar manualmente?

Não, as operações de escala utilizando as APIs de escala de máquina virtual não são suportadas. Utilize as APIs AKS (az aks scale).

Posso usar conjuntos de balança de máquinas virtuais para escalar manualmente até zero nós?

Não, as operações de escala utilizando as APIs de escala de máquina virtual não são suportadas. Pode utilizar a API AKS para escalar para zero piscinas de nó não-sistema ou parar o seu cluster .

Posso parar ou desatribuer todos os meus VMs?

Embora a AKS tenha mecanismos de resiliência para resistir a tal config e recuperar dele, esta não é uma configuração suportada. Em vez disso, pare o seu agrupamento.

Posso usar extensões VM personalizadas?

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

A AKS armazena algum dado de cliente 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 funcionar como raiz?

As seguintes imagens têm requisitos funcionais para "Executar como Raiz" e as exceções devem ser apresentadas 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 é Azure CNI Modo Transparente vs. Modo de Ponte?

Começando pela versão 1.2.0, o Azure CNI define o modo Transparente como padrão para as implementações do Linux CNI de arrendamento único. O modo transparente está a substituir o modo de ponte. Nesta secção, discutiremos mais sobre as diferenças em ambos os modos e quais são os benefícios/limitações para a utilização do modo Transparente no Azure CNI.

Modo ponte

Como o nome sugere, o modo ponte Azure CNI, de uma forma "just in time", vai criar uma ponte L2 chamada "azure0". Todas as interfaces de par de pods veth laterais do anfitrião serão ligadas a esta ponte. Assim, Pod-Pod comunicação intra VM e o tráfego restante passa por esta ponte. A ponte em questão é um dispositivo virtual de camada 2 que por si só não pode receber ou transmitir nada a menos que você ligue um ou mais dispositivos reais a ela. Por esta razão, o eth0 do Linux VM tem de ser convertido numa ponte subordinada a "azure0". Isto cria uma topologia complexa da rede dentro do Linux VM e como um sintoma CNI teve que cuidar de outras funções de networking como a atualização do servidor DNS e assim por diante.

Topologia do modo de ponte

Abaixo está um exemplo de como a configuração da rota ip se parece no modo Bridge. Independentemente de quantas cápsulas o nó tem, haverá apenas duas rotas. O primeiro a dizer, todo o tráfego excluindo o local em azure0 irá para o portão padrão da sub-rede através da interface com ip "src 10.240.0.4" (que é o NODE primário IP) e o segundo dizendo "10.20.x" Pod espaço para kernel para 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 tem uma abordagem direta para a criação da rede Linux. Neste modo, o Azure CNI não altera quaisquer propriedades da interface eth0 no Linux VM. Esta abordagem mínima de alteração das 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 criará e adicionará interfaces de par de pods veth do lado do anfitrião que serão adicionadas à rede de anfitriões. A comunicação Intra VM Pod-to-Pod é através de rotas ip que o CNI irá adicionar. Essencialmente, a comunicação Pod-to-Pod é sobre a camada 3 e o tráfego de pod é encaminhado pelas regras de encaminhamento L3.

Topologia de modo transparente

Abaixo está um exemplo de configuração da rota ip de modo transparente, cada interface do Pod receberá uma rota estática anexada para que o tráfego com dest IP como o Pod será enviado diretamente para a interface de par lateral veth 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 o estado de corrida paralela DNS e evita problemas de latência DNS de 5 segundos sem a necessidade de configurar DNS locais (você ainda pode usar DNS local de nó por razões de desempenho).
  • Elimina o modo inicial de ponte CNI de latência de 5 seg de latência, introduz hoje devido à configuração da ponte "just in time".
  • Um dos casos de canto no modo ponte é que o Azure CNI não pode continuar a atualizar as listas personalizadas de servidores DNS que os utilizadores adicionam ao VNET ou NIC. Isto resulta na recolha de CNI apenas a primeira instância da lista de servidores DNS. Resolvido em modo Transparente como CNI não altera nenhuma propriedade eth0. Veja mais aqui.
  • Proporciona uma melhor manipulação do tráfego da UDP e mitigação para a tempestade de inundação da UDP quando o ARP se esgotar. No modo ponte, quando a ponte não conhece um endereço MAC do casulo de destino na comunicação intra-VM Pod-to-Pod, por design, isto resulta em tempestade do pacote para todas as portas. Resolvido em modo Transparente, uma vez que não existem dispositivos L2 no caminho. Veja mais aqui.
  • O modo transparente funciona melhor na comunicação Intra VM Pod-to-Pod em termos de produção e latência em comparação com o modo de ponte.

Como evitar a propriedade de permissão definindo problemas lentos quando o volume tem um monte de ficheiros?

Tradicionalmente, se o seu pod estiver a funcionar como um utilizador sem raízes (o que deve fazer), tem de especificar um fsGroup contexto de segurança dentro da cápsula para que o volume possa ser legível e legível pelo Pod. Este requisito está coberto em mais pormenores aqui.

Mas um efeito colateral da definição fsGroup é que, cada vez que um volume é montado, Kubernetes deve recursivamente chown() e chmod() todos os ficheiros e diretórios dentro do volume - com algumas exceções notadas abaixo. Isto acontece mesmo que a propriedade em grupo do volume já corresponda fsGroupao pedido – e pode ser caro para volumes maiores com muitos ficheiros pequenos, o que faz com que o pod startup desemoque muito tempo. Este cenário tem sido um problema conhecido antes do v1.20, e a solução está a definir a corrida do Pod como raiz:

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

O problema foi resolvido com a versão 1.20 da Kubernetes. Para mais informações, consulte Kubernetes 1.20: Controlo Granular de Alterações de Permissão de Volume.

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

Os nós ativados pelo FIPS são atualmente suportados em piscinas de nó baseados em Linux. Para obter mais informações, consulte adicionar um conjunto de nós com o fips.

Posso configurar NSGs com AKS?

AKS não aplica Grupos de Segurança de Rede (NSGs) na sua sub-rede e não modifica nenhum dos NSGs associados a essa sub-rede. AKS apenas modifica as definições de NSGs interfaces de rede. Se estiver a utilizar o CNI, também deve garantir que as regras de segurança nos NSGs permitem o tráfego entre as gamas CIDR do nó e do casulo. Se estiver a utilizar kubenet, também deve garantir que as regras de segurança nos NSGs permitem o tráfego entre o nó e o CIDR do casulo. Para mais informações, consulte os grupos de segurança da Rede.

Como funciona a sincronização do tempo na AKS?

Os nós AKS executam o serviço "crony" que retira tempo do local. Os contentores que correm em vagões obtêm o tempo dos nós AKS. Aplicações lançadas dentro de um contentor tempo de utilização a partir do recipiente da vagem.

Como são atualizados os addons AKS?

Qualquer patch, incluindo patches de segurança, é automaticamente aplicado no cluster AKS. Qualquer coisa maior do que um patch, como alterações de versão maiores ou menores (que podem ter alterações de rutura nos seus objetos implantados), é atualizado quando atualiza o seu cluster se houver uma nova versão disponível. Pode encontrar quando um novo lançamento estiver disponível visitando as notas de lançamento da AKS.