Sobre as ComputeClasses Balanced e Scale-Out em clusters do Autopilot

É possível usar as ComputeClasses Balanced e Scale-Out em clusters do Autopilot do Google Kubernetes Engine (GKE) para executar cargas de trabalho que exigem capacidade de computação extra ou configurações especializadas de CPU. Esta página é destinada a administradores de cluster que querem opções de computação mais flexíveis do que as oferecidas pela configuração padrão do cluster do Autopilot.

Visão geral das classes de computação balanceadas e de escalonamento horizontal

Por padrão, os pods em clusters do GKE Autopilot são executados em uma plataforma de computação otimizada para contêineres. Essa plataforma é ideal para cargas de trabalho de uso geral, como servidores da Web e jobs em lote de intensidade média. A plataforma de computação otimizada para contêineres oferece uma configuração de hardware confiável, escalonável e otimizada para custos que atende aos requisitos da maioria das cargas de trabalho.

Se você tiver cargas de trabalho com requisitos de hardware exclusivos, como a execução de tarefas de machine learning ou IA, a execução de bancos de dados de alto tráfego em tempo real ou a necessidade de plataformas e arquitetura de CPU específicas, use ComputeClasses para provisionar esse hardware.

Somente em clusters do Autopilot, o GKE oferece as seguintes ComputeClasses selecionadas que permitem executar pods que precisam de mais flexibilidade do que a plataforma de computação otimizada para contêineres padrão:

  • Balanced: oferece capacidade máxima de CPU e memória maior do que a plataforma de computação otimizada para contêineres.
  • Scale-Out: desativa a multissegmentação simultânea (SMT) e é otimizada para escalonamento horizontal.

Essas ComputeClasses estão disponíveis apenas em clusters do Autopilot. Semelhante à plataforma de computação otimizada para contêineres padrão, o Autopilot gerencia o dimensionamento de nós e a alocação de recursos com base nos pods em execução.

Classes de computação personalizadas para mais flexibilidade

Se as ComputeClasses balanceadas ou de escalonamento horizontal nos clusters do Autopilot não atenderem aos requisitos da sua carga de trabalho, configure suas próprias ComputeClasses. Você implanta recursos personalizados do Kubernetes ComputeClass nos clusters com conjuntos de atributos de nó que o GKE usa para configurar novos nós no cluster. Essas ComputeClasses personalizadas podem, por exemplo, permitir que você implante 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 Sobre cargas de trabalho do modo Autopilot no GKE Standard.

Preços

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

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

Detalhes técnicos de balanceamento e escalonamento horizontal

Esta seção descreve os tipos de máquinas e casos de uso das classes Balanced e Scale-Out. Se você não solicitar uma ComputeClass nos seus pods, o Autopilot vai colocar os pods na plataforma de computação otimizada para contêineres por padrão. A plataforma de computação otimizada para contêineres usa qualquer uma das séries de máquinas da família de máquinas de uso geral do Compute Engine, com preferência por tipos de máquinas redimensionáveis. Como a série de máquinas subjacente não é fixa, a performance por CPU varia dependendo da série de máquinas em que o GKE programa seu pod.

Além disso, o agendamento de pods com armazenamento permanente anexado depende da compatibilidade do tipo de disco:

  • Persistent Disks legados: os pods com Persistent Disks legados anexados (como pd-standard) são executados apenas em séries de máquinas que os aceitam, como E2.
  • Hyperdisk: os pods com armazenamento de última geração anexado (como hyperdisk-balanced) são executados em séries de máquinas mais recentes, como C3.
  • Estado pendente: se você configurar explicitamente um pod para ser executado em uma série de máquinas mais recente (por exemplo, usando seletores de nós para solicitar nós C3 ou configurando uma ComputeClass personalizada), mas anexar um Persistent Disk legado, o pod vai permanecer no estado Pending indefinidamente. Isso acontece porque o GKE não consegue encontrar um nó que atenda às restrições de tipo de máquina e de compatibilidade de disco. Quando você seleciona explicitamente uma série de máquinas, é responsável por garantir a compatibilidade do PersistentVolume e do disco.

A tabela a seguir fornece uma visão geral técnica das ComputeClasses Balanced e Scale-Out.

ComputeClasses balanceadas e de escalonamento horizontal
Balanced

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

  • CPUs disponíveis: 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 aplicativos como os seguintes:

  • Servidores da Web
  • Bancos de dados médios a grandes
  • Armazenamento em cache
  • Exibição de mídia e streaming
  • Hyperdisk Throughput e armazenamento Extreme
Scale-Out

Oferece computação por núcleo único e escalonamento 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).
  • Outros recursos:
    • A SMT está desativada, então uma vCPU é igual a um núcleo físico.
    • Velocidade máxima do clock de 3,5 GHz.

Use a classe Scale-Out para aplicativos como os seguintes:

  • Servidores da Web
  • Microsserviços em contêiner
  • Processamento de registros de dados
  • Apps Java em grande escala
  • Armazenamento do Hyperdisk Throughput

Seleção de ComputeClass em cargas de trabalho

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

O exemplo de manifesto de implantação a seguir 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: "1Gi"

Substitua COMPUTE_CLASS pelo nome de uma ComputeClass, como Balanced ou Scale-Out. É possível selecionar no máximo uma ComputeClass em uma carga de trabalho.

Quando você implanta a carga de trabalho, o GKE faz o seguinte:

  • Provisiona automaticamente os nós com a configuração especificada para executar seus pods.
  • Adiciona automaticamente rótulos de nós e taints aos novos nós para evitar que outros pods sejam programados neles. Os taints são exclusivos de cada ComputeClass. Se você também selecionar uma arquitetura de CPU, o GKE adicionará um taint exclusivo a ela.
  • Adiciona automaticamente tolerâncias correspondentes aos taints aplicados aos pods implantados, permitindo que o GKE coloque esses pods nos novos nós.

Por exemplo, se você solicitar a ComputeClass Scale-Out para um pod:

  1. O Autopilot adiciona um taint específico para Scale-Out para esses nós.
  2. O Autopilot adiciona uma tolerância a esse taint aos pods Scale-Out.

Os pods que não solicitarem Scale-Out não receberão a tolerância. Como resultado, o GKE não programará esses pods nos nós Scale-Out.

Se você não solicitar explicitamente uma ComputeClass na especificação da carga de trabalho, o Autopilot vai programar os pods em nós que usam a plataforma de computação otimizada para contêineres padrão. A maioria das cargas de trabalho de uso geral pode ser executada sem problemas nessa plataforma.

Se você usar ComputeClasses ou solicitar séries de máquinas específicas, verifique se as cargas de trabalho não usam armazenamento incompatível. Por exemplo, não use tipos de volume de Persistent Disk anteriores, como Persistent Disk padrão (pd-standard) ou SSD (pd-ssd), em séries de máquinas que não os oferecem. O uso de armazenamento incompatível pode fazer com que os pods permaneçam no estado Pending se o GKE não conseguir encontrar ou provisionar um nó que atenda a todas as restrições. Se um pod for programado, mas o armazenamento não for anexado ou montado, o pod vai permanecer no estado ContainerCreating. Para mais informações sobre como resolver problemas de compatibilidade de armazenamento, consulte Carga de trabalho programada em séries de máquinas mais antigas ou presa no estado Pending devido à incompatibilidade de armazenamento.

Como solicitar uma arquitetura de CPU

Em alguns casos, as cargas de trabalho podem ser criadas para uma arquitetura específica, como Arm. A classe de computação de escalonamento horizontal é compatível com várias arquiteturas de CPU. É possível solicitar uma arquitetura específica junto com a solicitação de ComputeClass especificando um rótulo no seletor de nós ou na regra de afinidade de nó, como no exemplo a seguir:

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 de CPU que você quer, como arm64 ou amd64. É possível selecionar no máximo uma arquitetura na sua carga de trabalho. A ComputeClass selecionada precisa ser compatível com a arquitetura especificada.

Se você não solicitar explicitamente uma arquitetura, o Autopilot usará a arquitetura padrão da ComputeClass.

Arquitetura de braço no Autopilot

O Autopilot é compatível com solicitações de nós que usam a arquitetura de CPU Arm. Os nós de Arm têm melhor custo-benefício do que os nós x86 semelhantes, além de melhorar o desempenho. Para ver instruções sobre como solicitar nós do Arm, consulte Implantar cargas de trabalho do Autopilot na arquitetura do Arm.

Verifique se você está usando as imagens corretas nas implantações. Se os pods usarem imagens do Arm e você não solicitar nós do Arm, o Autopilot programará os pods em nós x86, e eles falharão. Da mesma forma, se você usar imagens x86 acidentalmente, mas solicitar nós do Arm para os pods, os pods falharão.

Solicitações de recursos padrão, mínimas e máximas

Ao escolher uma ComputeClass para suas cargas de trabalho do Autopilot, especifique as solicitações de recursos que atendem às solicitações mínima e máxima para essa ComputeClass. Para informações sobre as solicitações padrão, bem como as solicitações mínima e máxima para cada ComputeClass, consulte Solicitações e limites de recursos no Autopilot do GKE.

A seguir