Acerca das ComputeClasses equilibradas e de expansão horizontal em clusters do Autopilot

Pode usar as Balanced e Scale-Out ComputeClasses nos clusters do Google Kubernetes Engine (GKE) Autopilot para executar cargas de trabalho que requerem capacidade de computação adicional ou configurações de CPU especializadas. Esta página destina-se a administradores de clusters que querem opções de computação mais flexíveis do que as que a configuração predefinida do cluster do Autopilot oferece.

Vista geral das ComputeClasses equilibradas e de expansão

Por predefinição, os agrupamentos nos clusters do GKE Autopilot são executados numa plataforma de computação otimizada para contentores. Esta plataforma é ideal para cargas de trabalho de uso geral, como servidores Web e tarefas de lotes de intensidade média. A plataforma de computação otimizada para contentores oferece uma configuração de hardware fiável, escalável e otimizada em termos de custos que pode processar os requisitos da maioria das cargas de trabalho.

Se tiver cargas de trabalho com requisitos de hardware exclusivos (como realizar tarefas de aprendizagem automática ou IA, executar bases de dados de tráfego elevado em tempo real ou precisar de plataformas e arquitetura de CPU específicas), pode usar ComputeClasses para aprovisionar esse hardware.

Apenas em clusters do Autopilot, o GKE fornece as seguintes ComputeClasses preparadas que lhe permitem executar pods que precisam de mais flexibilidade do que a plataforma de computação otimizada para contentores predefinida:

  • Balanced: oferece uma capacidade máxima de CPU e memória superior à da plataforma de computação otimizada para contentores.
  • Scale-Out: desativa o processamento multitarefas simultâneo (SMT) e está otimizado para aumentar a escala.

Estas ComputeClasses só estão disponíveis em clusters do Autopilot. Semelhante à plataforma de computação otimizada para contentores predefinida, o Autopilot gere o dimensionamento dos nós e a atribuição de recursos com base nos seus pods em execução.

ComputeClasses personalizadas para maior flexibilidade

Se as ComputeClasses equilibradas ou de expansão horizontal nos clusters do Autopilot não cumprirem os requisitos da sua carga de trabalho, pode configurar as suas próprias ComputeClasses. Implementa recursos personalizados do Kubernetes ComputeClass nos seus clusters com conjuntos de atributos de nós que o GKE usa para configurar novos nós no cluster. Estas ComputeClasses personalizadas podem, por exemplo, permitir-lhe implementar cargas de trabalho no mesmo hardware que as ComputeClasses Balanced ou Scale-Out em qualquer cluster do GKE Autopilot ou Standard. Para mais informações, consulte o artigo Acerca das cargas de trabalho do modo Autopilot no GKE Standard.

Preços

Os pods que usam as ComputeClasses Balanced ou Scale-Out são faturados com base nos seguintes SKUs:

Para mais informações, consulte os preços do GKE.

Detalhes técnicos equilibrados e de expansão

Esta secção descreve os tipos de máquinas e os exemplos de utilização das classes Balanced e Scale-Out. Se não pedir uma ComputeClass nos seus pods, o Autopilot coloca os pods na plataforma de computação otimizada para contentores por predefinição. Por vezes, pode ver ek como a série de máquinas de nós nos nós do Autopilot que usam a plataforma de computação otimizada para contentores. As máquinas EK são tipos de máquinas E2 exclusivos do Autopilot.

A tabela seguinte fornece uma vista geral técnica das Balanced e das Scale-Out ComputeClasses.

Balanced e Scale-Out ComputeClasses
Balanced

Oferece mais capacidade de CPU e capacidade de memória do que os máximos da plataforma de computação otimizada para contentores. Oferece plataformas de CPU adicionais e a capacidade de definir plataformas de CPU mínimas para Pods, como Intel Ice Lake ou posterior.

  • CPUs disponíveis: AMD EPYC Rome, AMD EPYC Milan, Intel Ice Lake, Intel Cascade Lake
  • Arquitetura disponível: amd64
  • Série de máquinas: N2 (CPUs Intel) ou Série de máquinas N2D (CPUs AMD).

Use a classe Balanced para aplicações como as seguintes:

  • Servidores Web
  • Bases de dados médias a grandes
  • A colocar em cache
  • Streaming e publicação de conteúdo multimédia
  • Débito do Hyperdisk e armazenamento extremo
Scale-Out

Oferece computação de thread único por núcleo e escalabilidade horizontal.

  • CPUs disponíveis: Ampere Altra Arm ou AMD EPYC Milan
  • Arquitetura disponível: arm64 ou amd64
  • Série de máquinas: T2A (Arm) ou T2D (x86).
  • Funcionalidades adicionais:
    • O SMT está desativado, pelo que uma vCPU é igual a um núcleo físico.
    • Velocidade máxima de relógio de 3,5 GHz.

Use a classe Scale-Out para aplicações como as seguintes:

  • Servidores Web
  • Microsserviços contentorizados
  • Tratamento de registos de dados
  • Apps Java de grande escala
  • Armazenamento de débito do Hyperdisk

Seleção de ComputeClass em cargas de trabalho

Para usar uma ComputeClass para uma carga de trabalho do GKE, selecione a ComputeClass no manifesto da carga de trabalho usando um seletor de nós para a etiqueta cloud.google.com/compute-class.

O manifesto de implementação de exemplo seguinte seleciona uma ComputeClass:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloweb
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      nodeSelector:
        # Replace with the name of a compute class
        cloud.google.com/compute-class: COMPUTE_CLASS 
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "250m"
            memory: "4Gi"

Substitua COMPUTE_CLASS pelo nome de uma ComputeClass, como Balanced ou Scale-Out. Pode selecionar um máximo de uma ComputeClass numa carga de trabalho.

Quando implementa a carga de trabalho, o GKE faz o seguinte:

  • Aprovisiona automaticamente nós suportados pela configuração especificada para executar os seus pods.
  • Adiciona automaticamente etiquetas de nós e manchas aos novos nós para impedir que outros pods sejam agendados nesses nós. As restrições são exclusivas de cada ComputeClass. Se também selecionar uma arquitetura de CPU, o GKE adiciona uma rejeição separada exclusiva dessa arquitetura.
  • Adiciona automaticamente tolerâncias correspondentes às restrições aplicadas aos seus pods implementados, o que permite ao GKE colocar esses pods nos novos nós.

Por exemplo, se pedir a Scale-Out ComputeClass para um pod:

  1. O Autopilot adiciona uma restrição específica para Scale-Out a esses nós.
  2. O Autopilot adiciona uma tolerância para essa mancha aos Scale-Out pods.

Os pods que não pedirem Scale-Out não recebem a tolerância. Como resultado, o GKE não agenda esses pods nos nós Scale-Out.

Se não pedir explicitamente uma ComputeClass na especificação da carga de trabalho, o Autopilot agenda pods em nós que usam a plataforma de computação otimizada para contentores predefinida. A maioria das cargas de trabalho de fins gerais pode ser executada sem problemas nesta plataforma.

Como pedir uma arquitetura de CPU

Em alguns casos, as suas cargas de trabalho podem ser criadas para uma arquitetura específica, como Arm. A ComputeClass de expansão suporta várias arquiteturas de CPU. Pode pedir uma arquitetura específica juntamente com o pedido ComputeClass especificando uma etiqueta no seletor de nós ou na regra de afinidade de nós, como no exemplo seguinte:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-arm
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-arm
  template:
    metadata:
      labels:
        app: nginx-arm
    spec:
      nodeSelector:
        cloud.google.com/compute-class: COMPUTE_CLASS
        kubernetes.io/arch: ARCHITECTURE
      containers:
      - name: nginx-arm
        image: nginx
        resources:
          requests:
            cpu: 2000m
            memory: 2Gi

Substitua ARCHITECTURE pela arquitetura da CPU que quer, como arm64 ou amd64. Pode selecionar, no máximo, uma arquitetura na sua carga de trabalho. A ComputeClass que selecionar tem de suportar a arquitetura especificada.

Se não pedir explicitamente uma arquitetura, o Autopilot usa a arquitetura predefinida da ComputeClass.

Arquitetura ARM no Autopilot

O piloto automático suporta pedidos de nós que usam a arquitetura de CPU Arm. Os nós ARM são mais rentáveis do que os nós x86 semelhantes, ao mesmo tempo que oferecem melhorias no desempenho. Para obter instruções sobre como pedir nós Arm, consulte o artigo Implemente cargas de trabalho do Autopilot na arquitetura Arm.

Certifique-se de que está a usar as imagens corretas nas suas implementações. Se os seus pods usarem imagens Arm e não pedir nós Arm, o Autopilot agenda os pods em nós x86 e os pods falham. Da mesma forma, se usar acidentalmente imagens x86, mas pedir nós Arm para os pods, os pods falham.

Pedidos de recursos predefinidos, mínimos e máximos

Ao escolher uma ComputeClass para as suas cargas de trabalho do Autopilot, certifique-se de que especifica pedidos de recursos que cumprem os pedidos mínimos e máximos dessa ComputeClass. Para obter informações sobre os pedidos predefinidos, bem como os pedidos mínimos e máximos para cada ComputeClass, consulte o artigo Pedidos e limites de recursos no GKE Autopilot.

O que se segue?