Melhores práticas de implementação e confiabilidade do cluster para o Azure Kubernetes Service (AKS)

Este artigo apresenta as melhores práticas para a fiabilidade dos clusters implementadas tanto a nível de implantação como de cluster para as suas cargas de trabalho no Azure Kubernetes Service (AKS). O artigo é destinado a operadores de clusters e desenvolvedores responsáveis pela implementação e gestão de aplicações no AKS.

As melhores práticas neste artigo estão organizadas nas seguintes categorias:

Melhores práticas ao nível da implementação

As melhores práticas ao nível de implementação ajudam a garantir alta disponibilidade e fiabilidade para as suas cargas de trabalho AKS. Estas melhores práticas são configurações locais que pode implementar nos ficheiros YAML para os seus pods e implementações.

Limites de CPU e memória do Pod

Best practice guidance

Defina limites para CPU e memória dos pods em todos os pods para garantir que os pods não consumam todos os recursos de um nó e para fornecer proteção durante ameaças de serviço, como ataques DDoS.

Os limites de CPU e memória do pod definem a quantidade máxima de CPU e memória que um pod pode usar. Quando um pod ultrapassa os seus limites definidos, é marcado para remoção. Para mais informações, consulte CPU resource units in Kubernetes e Memory resource units in Kubernetes.

Definir limites para CPU e memória ajuda a manter a saúde do nó e minimiza o impacto em outros pods no nó. Evite definir um limite de pod superior ao que os seus nós podem suportar. Cada nó do AKS reserva uma quantidade definida de CPU e memória para os componentes principais do Kubernetes. Se definir um limite de pods superior ao que o nó pode suportar, a sua aplicação pode tentar consumir muitos recursos e impactar negativamente outros pods no nó. Os administradores do cluster precisam definir quotas de recursos para um namespace que requer a definição de solicitações e limites de recursos. Para mais informações, veja Impor cotas de recursos no AKS.

No ficheiro de definição do pod do exemplo seguinte, a secção resources define os limites de CPU e memória para o pod:

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 250m
        memory: 256Mi

kubectl describe node <node-name>

# Example output
Capacity:
 cpu:                8
 ephemeral-storage:  129886128Ki
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             32863116Ki
 pods:               110
Allocatable:
 cpu:                7820m
 ephemeral-storage:  119703055367
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             28362636Ki
 pods:               110

Para mais informações, consulte Atribuir Recursos de CPU a Contentores e Pods e Atribuir Recursos de Memória a Contentores e Pods.

Autoscaler de pod vertical (VPA)

Best practice guidance

Use o Vertical Pod Autoscaler (VPA) para ajustar automaticamente as solicitações de CPU e memória para seus pods com base em seu uso real.

Embora não seja implementado diretamente através do pod YAML, o Vertical Pod Autoscaler (VPA) ajuda a otimizar a alocação de recursos ajustando automaticamente as solicitações de CPU e memória para seus pods. Isso garante que seus aplicativos tenham os recursos de que precisam para serem executados de forma eficiente sem provisionamento excessivo ou insuficiente.

O VPA opera em três modalidades:

• Desativado: fornece apenas recomendações sem aplicar alterações.
• Automático: atualiza automaticamente as solicitações de recursos dos pods durante as reinicializações.
• Inicial: define solicitações de recursos somente durante a criação do pod.

O exemplo a seguir mostra como configurar um recurso VPA no Kubernetes:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: my-deployment
  updatePolicy:
    updateMode: "Auto" # Options: Off, Auto, Initial

Para obter mais informações, consulte a documentação do Vertical Pod Autoscaler.

Orçamentos de Disrupção de Pod (PDBs)

Best practice guidance

Use Orçamentos de Disrupção de Pod (PDBs) para garantir que um número mínimo de pods permaneça disponível durante disrupções voluntárias, como operações de atualização ou exclusões acidentais de pods.

As Orçamentações de Interrupção de Pods (PDBs) permitem definir como as implementações ou conjuntos de réplicas respondem durante interrupções voluntárias, como operações de atualização ou eliminações acidentais de pods. Usando PDBs, pode definir um número mínimo ou máximo de recursos indisponíveis. Os PDBs afetam apenas a Eviction API para interrupções voluntárias.

Por exemplo, digamos que você precisa realizar uma atualização do cluster e já tem um PDB definido. Antes de executar a atualização do cluster, o escalonador do Kubernetes assegura que o número mínimo de pods definidos no PDB esteja disponível. Se a atualização fizer com que o número de pods disponíveis caia abaixo do mínimo definido nos PDBs, o agendador programa pods extras em outros nós antes de permitir que a atualização prossiga. Se não definir um PDB, o agendador não tem restrições sobre o número de pods que podem ficar indisponíveis durante a atualização, o que pode levar a uma falta de recursos e possíveis interrupções no cluster.

No seguinte exemplo de ficheiro de definição PDB, o campo minAvailable define o número mínimo de pods que devem permanecer disponíveis durante interrupções voluntárias. O valor pode ser um número absoluto (por exemplo, 3) ou uma percentagem do número desejado de pods (por exemplo, 10%).

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
   name: mypdb
spec:
   minAvailable: 3 # Minimum number of pods that must remain available during voluntary disruptions
   selector:
    matchLabels:
      app: myapp

Para mais informações, consulte Plano para disponibilidade usando PDBs e Especificando um Orçamento de Disrupção para a sua Aplicação.

Rescisão graciosa para pods

Best practice guidance

Utilizar hooks PreStop e configurar um valor apropriado terminationGracePeriodSeconds para garantir que os pods sejam encerrados normalmente.

A rescisão ordenada garante que os pods tenham tempo adequado para limpar recursos, finalizar tarefas em andamento ou notificar serviços dependentes antes de serem encerrados. Isso é particularmente importante para aplicativos ou serviços com estado que exigem procedimentos de desligamento adequados.

Usando PreStop ganchos

Um PreStop hook é chamado imediatamente antes de um contêiner ser encerrado devido a um pedido de API ou evento de gestão, como preempção, contenção de recursos ou uma falha em uma sonda de aliveness ou de inicialização. O PreStop gancho permite definir comandos ou scripts personalizados para executar antes que o contêiner seja interrompido. Por exemplo, você pode usá-lo para liberar logs, fechar conexões de banco de dados ou notificar outros serviços sobre o desligamento.

O seguinte exemplo de ficheiro de definição de pod mostra como usar um gancho PreStop para garantir a terminação graciosa de um contêiner:

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "nginx -s quit; while killall -0 nginx; do sleep 1; done"]

Configuração terminationGracePeriodSeconds

O terminationGracePeriodSeconds campo especifica a quantidade de tempo que o Kubernetes aguarda antes de encerrar um pod à força. Este período inclui o tempo necessário para executar o PreStop gancho. Se o PreStop hook não se completar dentro do período de carência, o pod será encerrado forçadamente.

Por exemplo, a seguinte definição de pod define um período de carência de rescisão de 30 segundos:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  terminationGracePeriodSeconds: 30
  containers:
  - name: example-container
    image: nginx

Para mais informações, veja Ganchos do ciclo de vida do container e Terminação de Pods.

Alta disponibilidade durante upgrades

Utilização maxSurge para atualizações mais rápidas

Best practice guidance

Configure o maxSurge campo para permitir que pods adicionais sejam criados durante atualizações contínuas, permitindo atualizações mais rápidas com o mínimo de tempo de inatividade.

O maxSurge campo especifica o número máximo de pods adicionais que podem ser criados além do número desejado de pods durante uma atualização contínua. Isso permite que novos pods sejam criados e fiquem prontos antes que os pods antigos sejam encerrados, garantindo atualizações mais rápidas e reduzindo o risco de tempo de inatividade.

O exemplo de manifesto de implantação a seguir demonstra como configurar maxSurge:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 33% # Maximum number of additional pods created during the update

Ao definir maxSurge como 3, essa configuração garante que até três pods adicionais possam ser criados durante a atualização contínua, acelerando o processo de implantação e mantendo a disponibilidade do seu aplicativo. Para obter mais informações, consulte Atualizações contínuas no Kubernetes.

Usando maxUnavailable para atualizações controladas

Best practice guidance

Configure o campo maxUnavailable para limitar o número de pods que podem ficar indisponíveis durante as atualizações graduais, garantindo que a sua aplicação permaneça funcional com mínima interrupção.

O maxUnavailable campo é particularmente útil para aplicativos que exigem computação intensiva ou têm necessidades específicas de infraestrutura. Ele especifica o número máximo de pods que podem ficar indisponíveis a qualquer momento durante uma atualização contínua. Isso garante que uma parte do seu aplicativo permaneça funcional enquanto novos pods estão sendo implantados e os antigos são encerrados.

Você pode definir maxUnavailable como um número absoluto (por exemplo, 1) ou uma porcentagem do número desejado de cápsulas (por exemplo, 25%). Por exemplo, se seu aplicativo tiver quatro réplicas e você definir maxUnavailable como 1, o Kubernetes garantirá que pelo menos três pods permaneçam disponíveis durante o processo de atualização.

O exemplo de manifesto de implantação a seguir demonstra como configurar maxUnavailable:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1 # Maximum number of pods that can be unavailable during the update

Neste exemplo, a configuração maxUnavailable para 1 garante que não mais de um pod esteja indisponível a qualquer momento durante a atualização gradual. Essa configuração é ideal para aplicativos que exigem computação especializada, onde manter um nível mínimo de disponibilidade de serviço é fundamental.

Para obter mais informações, consulte Atualizações contínuas no Kubernetes.

Constrangimentos de dispersão da topologia do Pod

Best practice guidance

Utilize as restrições de espalhamento da topologia de pods para garantir que os pods sejam distribuídos por diferentes nós ou zonas, melhorando assim a disponibilidade e fiabilidade.

Pode utilizar restrições de disseminação de topologia de pods para controlar como os pods são distribuídos pelo seu cluster com base na topologia dos nós, espalhando os pods por diferentes nós ou zonas para melhorar a disponibilidade e a fiabilidade.

O seguinte exemplo de ficheiro de definição de pod mostra como utilizar o campo topologySpreadConstraints para distribuir pods por diferentes nós:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  # Configure a topology spread constraint
  topologySpreadConstraints:
    - maxSkew: <integer>
      minDomains: <integer> # optional
      topologyKey: <string>
      whenUnsatisfiable: <string>
      labelSelector: <object>
      matchLabelKeys: <list> # optional
      nodeAffinityPolicy: [Honor|Ignore] # optional
      nodeTaintsPolicy: [Honor|Ignore] # optional

Para mais informações, veja Pod Topology Spread Constraints.

Provas de prontidão, vitalidade e inicialização

Best practice guidance

Configure as sondas de readiness, liveness e startup, quando aplicável, para melhorar a resiliência a cargas elevadas e reduzir os reinícios dos contentores.

Sondas de prontidão

No Kubernetes, o kubelet usa sondagens de prontidão para saber quando um contentor está pronto para começar a aceitar tráfego. Um pod é considerado pronto quando todos os seus contentores estão prontos. Quando um pod não está pronto, ele é removido dos balanceadores de carga de serviço. Para mais informações, consulte Readiness Probes in Kubernetes.

O seguinte exemplo de ficheiro de definição de pod mostra uma configuração de sonda de prontidão:

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

Para mais informações, consulte Configure readiness probes.

Verificações de Vitalidade

No Kubernetes, o kubelet usa sondas de liveness para saber quando reiniciar um contentor. Se um contentor falhar na sua sonda de vivacidade, o contentor é reiniciado. Para mais informações, consulte Liveness Probes in Kubernetes.

O seguinte exemplo de ficheiro de definição de pod mostra uma configuração de verificação de vivacidade:

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy

Outro tipo de sonda de liveness utiliza uma requisição HTTP GET. O seguinte exemplo de ficheiro de definição de pod mostra uma configuração de sonda de liveness de pedido HTTP GET:

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

Para mais informações, consulte Configurar sondas de vivacidade e Definir uma solicitação HTTP de vivacidade.

Verificações de inicialização

No Kubernetes, o kubelet usa sondas de inicialização para saber quando uma aplicação em contentor foi iniciada. Ao configurar uma sonda de inicialização, as sondas de prontidão e vivacidade não começam até que a sonda de inicialização seja bem-sucedida, garantindo que as sondas de prontidão e vivacidade não interfiram na inicialização da aplicação. Para mais informações, consulte Startup Probes in Kubernetes.

O seguinte exemplo de ficheiro de definição de pod mostra uma configuração de sonda de arranque:

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

Aplicações multi-réplicas

Best practice guidance

Implante pelo menos duas réplicas da sua aplicação para garantir alta disponibilidade e resiliência em cenários de falha de nó.

No Kubernetes, pode usar o campo replicas no seu deployment para especificar o número de pods que deseja executar. Executar múltiplas instâncias da sua aplicação ajuda a garantir alta disponibilidade e resiliência em cenários de falha de nó. Se tiver availability zones ativadas, pode usar o campo replicas para especificar o número de pods que deseja executar em várias availability zones.

O ficheiro de definição de pod no exemplo a seguir mostra como usar o campo replicas para especificar o número de pods que deseja executar:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Para mais informações, consulte Visão geral da solução recomendada de alta disponibilidade ativa-ativa para AKS e Réplicas em Especificações de Implementação.

Práticas recomendadas ao nível de agrupamento e conjunto de nós

As melhores práticas ao nível dos clusters e pools de nós ajudam a garantir alta disponibilidade e fiabilidade para os seus clusters AKS. Pode implementar estas práticas recomendadas ao criar ou atualizar os seus clusters AKS.

Zonas de Disponibilidade

Best practice guidance

Utilize múltiplas zonas de disponibilidade ao criar um cluster AKS para garantir alta disponibilidade em cenários de falha de zona. Tenha em mente que não pode alterar a configuração da zona de disponibilidade após a criação do cluster.

Zonas de disponibilidade são grupos separados de datacenters dentro de uma região. Estas zonas estão suficientemente próximas para terem conexões de baixa latência entre si, mas suficientemente afastadas para reduzir a probabilidade de que mais de uma zona seja afetada por falhas locais ou condições meteorológicas. Utilizar zonas de disponibilidade ajuda a manter os seus dados sincronizados e acessíveis em cenários de falha da zona. Para mais informações, consulte Running in multiple zones.

Escalonamento automático de clusters

Best practice guidance

Utilize o dimensionamento automático de clusters para garantir que o seu cluster consiga lidar com cargas aumentadas e para reduzir custos durante períodos de baixa carga.

Para acompanhar as exigências das aplicações no AKS, pode ser necessário ajustar o número de nós que executam as suas cargas de trabalho. O componente de ajuste automático do cluster monitoriza os pods no seu cluster que não podem ser agendados devido a restrições de recursos. Quando o autoscaler de cluster detecta problemas, aumenta o número de nós no grupo de nós para atender à demanda da aplicação. Verifica também regularmente os nós para a falta de pods em execução e reduz o número de nós conforme necessário. Para mais informações, consulte Cluster autoscaling no AKS.

Pode usar o parâmetro --enable-cluster-autoscaler ao criar um cluster AKS para ativar o escalonador automático de clusters, conforme mostrado no exemplo seguinte:

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 2 \
    --vm-set-type VirtualMachineScaleSets \
    --load-balancer-sku standard \
    --enable-cluster-autoscaler  \
    --min-count 1 \
    --max-count 3 \
    --generate-ssh-keys

Também pode ativar o escalador automático de clusters num conjunto de nós existente e configurar detalhes mais granulares do escalador automático alterando os valores padrão no perfil de escalador automático de todo o cluster.

Para mais informações, veja Use the cluster autoscaler in AKS.

Balanceador de Carga Padrão

Best practice guidance

Utilize o Standard Load Balancer para proporcionar maior fiabilidade e recursos, suporte para várias zonas de disponibilidade, sondas HTTP e funcionalidade em vários centros de dados.

No Azure, o SKU Standard Load Balancer foi projetado para ser equipado para balancear o tráfego de camada de rede quando alta performance e baixa latência são necessárias. O Standard Load Balancer encaminha o tráfego dentro e entre regiões e para zonas de disponibilidade para alta resiliência. A SKU Standard é a SKU recomendada e predefinida para usar ao criar um cluster AKS.

O exemplo a seguir mostra um LoadBalancer manifesto de serviço que utiliza o Standard Load Balancer:

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-ipv4 # Service annotation for an IPv4 address
  name: azure-load-balancer
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-load-balancer

Para mais informações, consulte Usar um balanceador de carga padrão no AKS.

Pools de Nós do Sistema

Utilize pools de nós de sistema dedicados

Best practice guidance

Utilize os pools de nós do sistema para garantir que nenhuma outra aplicação de utilizador seja executada nos mesmos nós, o que pode causar escassez de recursos e impactar os pods do sistema.

Use piscinas dedicadas de nós do sistema para garantir que nenhuma outra aplicação de utilizador seja executada nos mesmos nós, o que pode causar escassez de recursos e possíveis falhas no cluster devido a condições de corrida. Para utilizar um grupo de nós do sistema dedicado, pode usar a "tinta" CriticalAddonsOnly no grupo de nós do sistema. Para mais informações, consulte Use system node pools in AKS.

Dimensionamento automático para grupos de nós do sistema

Best practice guidance

Configure o redimensionador automático para pools de nós do sistema para definir limites mínimos e máximos de escala para o pool de nós.

Utilize o dimensionador automático nos grupos de nós para configurar os limites mínimos e máximos de escala para o grupo de nós. O grupo de nós do sistema deve estar sempre apto a escalar para satisfazer as demandas dos pods do sistema. Se o pool de nós do sistema não conseguir escalar, o cluster fica sem recursos para ajudar a gerir a programação, escalonamento e balanceamento de carga, o que pode levar a um cluster sem resposta.

Para mais informações, consulte Use the cluster autoscaler on node pools.

Pelo menos dois nós em cada pool de nós do sistema

Best practice guidance

Certifique-se de que os pools de nós do sistema tenham pelo menos dois nós para garantir a resiliência contra cenários de congelamento/atualização, o que pode levar à reinicialização ou desligamento dos nós.

As pools de nós do sistema são usadas para executar pods do sistema, como o kube-proxy, o coredns e o plugin Azure CNI. Recomendamos que você garanta que os pools de nós do sistema tenham pelo menos dois nós para garantir a resiliência contra cenários de congelamento/atualização, o que pode levar à reinicialização ou desligamento dos nós. Para mais informações, consulte Gerir pools de nós do sistema no AKS.

Configurações de atualização para pools de nós

Usando maxSurge para atualizações do pool de nós

Best practice guidance

Configure a definição do maxSurge para atualizações do pool de nós para melhorar a fiabilidade e minimizar o tempo de inatividade durante as operações de atualização.

A maxSurge configuração especifica o número máximo de nós adicionais que podem ser criados durante uma atualização. Isso garante que os novos nós sejam provisionados e prontos antes que os nós antigos sejam drenados e removidos, reduzindo o risco de tempo de inatividade do aplicativo.

Por exemplo, o seguinte comando da CLI do Azure define maxSurge como 1 para um pool de nós:

az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name myNodePool \
  --max-surge 1

Ao configurar maxSurgeo , você pode garantir que as atualizações sejam executadas mais rapidamente, mantendo a disponibilidade do aplicativo.

Para obter mais informações, consulte Realizar o upgrade de pools de nós no AKS.

Usando maxUnavailable para atualizações do pool de nós

Best practice guidance

Configure a configuração para atualizações do pool de nós para garantir a disponibilidade do aplicativo durante as maxUnavailable operações de atualização.

A maxUnavailable configuração especifica o número máximo de nós que podem estar indisponíveis durante uma atualização. Isso garante que uma parte do pool de nós permaneça operacional enquanto os nós estão sendo atualizados.

Por exemplo, o seguinte comando da CLI do Azure define maxUnavailable como 1 para um pool de nós:

az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name myNodePool \
  --max-unavailable 1

Ao configurar maxUnavailable, pode controlar o impacto das atualizações nas suas cargas de trabalho, garantindo que recursos suficientes permaneçam disponíveis durante o processo.

Para obter mais informações, consulte Atualizar pools de nós no AKS.

Best practice guidance

Utilize a Rede Acelerada para proporcionar menor latência, reduzir variação de atraso e diminuir a utilização da CPU nas suas máquinas virtuais.

A Rede Acelerada permite a virtualização de I/O de raiz única (SR-IOV) nos tipos de máquinas virtuais suportados, melhorando significativamente o desempenho da rede.

O diagrama a seguir ilustra como duas VMs comunicam-se com e sem Rede Acelerada.

Para mais informações, consulte visão geral da Rede Acelerada.

Versões de imagem

Best practice guidance

As imagens não devem usar a etiqueta latest.

Tags de imagem de contêiner

Utilizar a etiqueta latest para imagens de contêiner pode levar a comportamentos imprevisíveis e torna difícil rastrear qual versão da imagem está a ser executada no seu cluster. Pode reduzir esses riscos integrando e executando ferramentas de análise e correção nos seus contêineres durante a construção e o tempo de execução. Para mais informações, consulte Melhores práticas para gestão de imagens de contêiner no AKS.

Atualizações de imagem do nodo

AKS oferece múltiplos canais de atualização automática para atualizações de imagem do sistema operativo dos nós. Pode usar estes canais para controlar o tempo das atualizações. Recomendamos aderir a estes canais de atualização automática para garantir que os seus nós estejam a executar os patches de segurança e atualizações mais recentes. Para mais informações, veja Auto-upgrade node OS images in AKS.

Camada padrão para cargas de trabalho de produção

Best practice guidance

Use o nível Standard para cargas de trabalho de produtos para maior fiabilidade e recursos do cluster, suporte para até 5.000 nós num cluster, e SLA de tempo de atividade ativado por padrão. Se precisar de LTS, considere usar o nível Premium.

O nível Standard do Azure Kubernetes Service (AKS) oferece um acordo de nível de serviço (SLA) com 99,9% de tempo de atividade garantido financeiramente para as suas cargas de trabalho de produção. A camada padrão também oferece maior fiabilidade e recursos do cluster, suporte para até 5.000 nós num cluster, e SLA de Uptime ativado por padrão. Para mais informações, consulte Pricing tiers for AKS cluster management.

Azure CNI para alocação dinâmica de IP

Best practice guidance

Configure o Azure CNI para uma alocação dinâmica de IPs para melhorar a utilização de IPs e prevenir a exaustão de IPs para clusters AKS.

A capacidade de alocação dinâmica de IPs no Azure CNI atribui IPs aos pods a partir de uma sub-rede separada da sub-rede que hospeda o cluster AKS e oferece os seguintes benefícios:

• Melhor utilização de IPs: Os IPs são alocados dinamicamente para os Pods do cluster a partir da sub-rede de Pods. Isto leva a uma melhor utilização de IPs no cluster em comparação com a solução CNI tradicional, que faz alocação estática de IPs para cada nó.
• Escalável e flexível: Sub-redes de nós e pods podem ser dimensionadas de forma independente. Uma única sub-rede de pods pode ser compartilhada entre múltiplos conjuntos de nós de um cluster ou entre vários clusters AKS implantados na mesma VNet. Também pode configurar uma sub-rede de pods separada para um pool de nós.
• Alto desempenho: Como os pods recebem IPs de rede virtual, eles têm conectividade direta com outros pods do cluster e recursos na VNet. A solução suporta clusters muito grandes sem qualquer degradação no desempenho.
• Políticas VNet separadas para pods: Como os pods têm uma sub-rede separada, pode configurar políticas VNet distintas para eles, diferentes das políticas dos nós. Isto permite muitos cenários úteis, como permitir a conectividade à internet apenas para pods e não para nós, fixar o IP de origem para pods numa pool de nós usando um Gateway NAT do Azure, e usar NSGs para filtrar o tráfego entre pools de nós.
• Políticas de rede do Kubernetes: Tanto as Políticas de Rede do Azure como o Calico funcionam com esta solução.

Para mais informações, consulte Configurar o rede CNI do Azure para alocação dinâmica de IPs e suporte aprimorado a sub-redes.

Máquinas Virtuais SKU v5

Best practice guidance

Utilize as configurações SKU de VM v5 para um desempenho melhor durante e após as atualizações, menor impacto geral e uma conexão mais confiável para as suas aplicações.

Para os grupos de nós no AKS, utilize VMs do SKU v5 com discos de SO efêmeros para fornecer recursos computacionais suficientes para os pods do sistema kube. Para mais informações, consulte Práticas recomendadas para desempenho e dimensionamento de grandes cargas de trabalho no AKS.

Não utilize VMs da série B

Best practice guidance

Não utilize VMs da série B para clusters AKS porque têm baixo desempenho e não funcionam bem com o AKS.

Máquinas Virtuais da série B têm baixo desempenho e não funcionam bem com AKS. Em vez disso, recomendamos o uso de v5 SKU VMs.

Premium Disks

Best practice guidance

Utilize Discos Premium para alcançar 99,9% de disponibilidade em uma máquina virtual (VM).

Azure Premium Disks oferecem uma latência de disco submilissegundo consistente e alta IOPS e largura de banda elevada. Discos Premium são projetados para fornecer baixa latência, alto desempenho e desempenho consistente de disco para máquinas virtuais.

O seguinte exemplo de manifesto YAML mostra uma definição de classe de armazenamento para um disco premium:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: premium2-disk-sc
parameters:
   cachingMode: None
   skuName: PremiumV2_LRS
   DiskIOPSReadWrite: "4000"
   DiskMBpsReadWrite: "1000"
provisioner: disk.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true

Para mais informações, consulte Utilizar discos Azure Premium SSD v2 no AKS.

Container Insights

Best practice guidance

Ative o Container Insights para monitorizar e diagnosticar o desempenho das suas aplicações em contentores.

Container Insights é uma funcionalidade do Azure Monitor que recolhe e analisa logs de contentores do AKS. Pode analisar os dados recolhidos com uma coleção de visualizações e livros de trabalho predefinidos.

Pode ativar a monitorização do Container Insights no seu cluster AKS usando vários métodos. O exemplo seguinte mostra como ativar a monitorização de Container Insights num cluster existente usando o CLI do Azure:

az aks enable-addons -a monitoring --name myAKSCluster --resource-group myResourceGroup

Para mais informações, consulte Ativar monitorização para clusters Kubernetes.

Azure Policy

Best practice guidance

Aplique e faça cumprir os requisitos de segurança e conformidade para os seus clusters AKS usando o Azure Policy.

Pode aplicar e impor políticas de segurança integradas nos seus clusters AKS utilizando a Azure Policy. O Azure Policy ajuda a impor padrões organizacionais e a avaliar a conformidade em grande escala. Após instalar o Azure Policy add-on para AKS, pode aplicar definições de políticas individuais ou grupos de definições de políticas chamadas iniciativas aos seus clusters.

Para mais informações, consulte Secure your AKS clusters with Azure Policy.

Próximos passos

Este artigo concentra-se nas melhores práticas para a implementação e fiabilidade dos clusters do Azure Kubernetes Service (AKS). Para mais práticas recomendadas, veja os seguintes artigos:

• Visão geral de alta disponibilidade e recuperação de desastres para AKS
• Executar clusters AKS em grande escala
• Arquitetura de referência para um cluster AKS