O melhor dos dois mundos: workloads Autopilot no GKE Standard

Veja alguns dos problemas que as organizações encontram ao optar por clusters puramente Standard ou puramente Autopilot, e por que nenhum dos modos sozinho dá conta do recado em todos os casos.

• Overhead operacional nos clusters Standard: você tem controle total, mas também assume a responsabilidade por escalonamento, manutenção e segurança, o que pode pesar bastante para times menores.
• Perda de flexibilidade nos clusters Autopilot: embora o Autopilot entregue mais operações gerenciadas, ele também impõe restrições: requisições mínimas de recursos, imagens de SO específicas, menos controle sobre a configuração dos nodes etc.
• Custos e cobrança: em um cluster Standard, você paga pelas máquinas virtuais (VMs) que formam seus node pools, independentemente de os workloads estarem usando todos os recursos disponíveis. Sem uma gestão atenta, isso pode levar a superprovisionamento e desperdício de dinheiro.

Por causa disso, muitas organizações ficavam presas na escolha entre o modo Standard completo (flexível, mas com mais manutenção) e o modo Autopilot completo (menos manutenção, porém menos controle e mais restrições). Nenhuma das opções é ideal em cenários com workloads mistos.

O mecanismo "Autopilot ComputeClasses em clusters Standard" do GKE usa as ComputeClasses (um recurso customizado do Kubernetes que define uma lista de configurações de node, como tipos de máquina ou ajustes de recursos) para viabilizar esse modelo híbrido, oferecendo um novo patamar de flexibilidade e diversos benefícios.

O modo Autopilot dentro do Standard roda em uma nova base de plataforma de computação otimizada para containers, projetada para latência mínima e máximo desempenho. Essa nova plataforma entrega tempos de agendamento de pods até 7x mais rápidos, melhorando de forma expressiva o tempo de resposta das aplicações cujos workloads usam as Autopilot ComputeClasses.

Outros benefícios em destaque:

• Rodar workloads específicos em modo Autopilot, totalmente gerenciados pelo Google.
• Manter o controle manual sobre workloads e infraestrutura que não usam o modo Autopilot, como node pools criados manualmente.
• Definir uma Autopilot ComputeClass como padrão para o cluster ou para o namespace, garantindo que os workloads herdem os benefícios do Autopilot, salvo se especificado de outra forma.

Requisitos e limitações

Curtiu a ideia? Então confira os requisitos e limitações antes de habilitar workloads Autopilot dentro de um cluster Standard.

• Os nodes Autopilot têm regras rígidas de recursos e segurança. Workloads Standard podem ser rejeitados se não atenderem a esses requisitos, então revise as configurações dos nodes para garantir compatibilidade.
• O cluster precisa estar inscrito no canal de release Rapid e rodar a versão 1.33.1-gke.1107000 ou posterior.
• O canal Rapid lança recursos e novas versões do Kubernetes mais rápido, mas também pode trazer mudanças incompatíveis. Revise e ajuste qualquer alteração de API ou outras antes de fazer o upgrade do cluster.
• Pelo menos um node pool do cluster precisa estar sem node taints para rodar os pods de sistema padrão.
• O cluster precisa ser VPC-native, com Shielded GKE Nodes habilitados por padrão.

Autopilot ComputeClasses nativas

O GKE configura automaticamente os recursos customizados ComputeClasses autopilot e autopilot-spot assim que o cluster é atualizado para uma versão compatível.

Exemplo de Autopilot computeclasses

Para selecionar uma Autopilot ComputeClass em um workload, use um node selector com o label cloud.google.com/compute-class.

#Sample workload that uses built-in autopilot 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 COMPUTE_CLASS with the name of the compute class to use.
        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"

Os recursos do container são ajustados automaticamente para atender aos requisitos do Autopilot e agendados em nodes da plataforma de computação otimizada para containers.

ComputeClasses customizadas

Se as ComputeClasses nativas não atenderem aos seus requisitos, você pode criar Autopilot ComputeClasses customizadas, sob medida para workloads específicos. Isso é especialmente útil para workloads que precisam de GPUs ou de determinadas famílias de máquinas.

Se você já usa uma Custom ComputeClass e quer atualizar os recursos ComputeClass existentes no cluster para o modo Autopilot, é preciso recriar essa ComputeClass com uma especificação atualizada. Para mais informações, veja Habilitar o Autopilot em uma ComputeClass customizada existente.

#sample custom ComputeClass with autopilot mode enabled
---
apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: autopilot-n2-class
spec:
  autopilot:
    enabled: true
  priorities:
  - machineFamily: n2
    spot: true
    minCores: 64
  - machineFamily: n2
    spot: true
  - machineFamily: n2
    spot: false
  activeMigration:
    optimizeRulePriority: true
  whenUnsatisfiable: DoNotScaleUp

Você não pode usar a regra de prioridade podFamily nas suas próprias ComputeClasses. Essa regra está disponível apenas nas Autopilot ComputeClasses nativas.

Você pode usar as ComputeClasses customizadas com modo Autopilot habilitado para definir uma compute class padrão no nível do cluster GKE ou do namespace. A classe padrão configurada vale para qualquer Pod no cluster ou namespace que não especifique outra compute class. Quando você implanta um Pod sem especificar uma compute class, o GKE aplica as compute classes padrão nesta ordem:

1. Se o namespace tiver uma compute class padrão, o GKE modifica a especificação do Pod para selecionar essa compute class.
2. Caso contrário, a configuração padrão do cluster é aplicada, se houver, e o GKE não altera o Pod.

Para mais detalhes, consulte o link.