É possível definir conjuntos de atributos de nós e configurações de escalonamento automático que o Google Kubernetes Engine (GKE) usa para criar nós para executar pods usando ComputeClasses. Nesta página, descrevemos como as ComputeClasses funcionam, os casos de uso e benefícios e os tipos disponíveis de ComputeClasses.
Essas informações são destinadas às seguintes pessoas:
- Arquitetos de nuvem e engenheiros de plataforma que querem reduzir a sobrecarga associada ao gerenciamento da infraestrutura de clusters.
- Operadores de apps e SRE que querem se concentrar na operação de cargas de trabalho sem pensar na infraestrutura.
Sobre as ComputeClasses e o escalonamento automático de clusters
Uma ComputeClass é um conjunto de atributos de nós e configurações de escalonamento automático que existe como um objeto da API Kubernetes em um cluster do GKE. É possível selecionar uma ComputeClass em qualquer carga de trabalho do Kubernetes que você implanta. O escalonamento automático de cluster do GKE usa os atributos em uma ComputeClass para criar nós para cargas de trabalho.
Os engenheiros de plataforma podem usar as ComputeClasses para configurar a infraestrutura de vários tipos de cargas de trabalho, de modo que cada novo nó seja otimizado para os requisitos específicos dos aplicativos. As ComputeClasses melhoram a velocidade e a flexibilidade do escalonamento automático do GKE e oferecem um método declarativo de configuração de opções de infraestrutura em clusters. Para mais informações, consulte a seção Benefícios do uso de ComputeClasses.
Recursos específicos do GKE estão disponíveis apenas com as ComputeClasses, como os seguintes:
- Prioridades de computação de fallback: defina vários conjuntos de configurações de infraestrutura em uma ComputeClass, priorizadas com base nas suas preferências. Durante o escalonamento, se a configuração preferida não estiver disponível, o GKE vai usar a próxima configuração.
- Migração ativa para nós de maior prioridade: quando configurado, o GKE substitui automaticamente os nós que estão mais abaixo na lista de prioridades de fallback por nós que estão mais acima nessa lista ao longo do tempo. Como resultado, os pods são executados nos nós preferidos em uma ComputeClass, mesmo que esse hardware não esteja disponível quando você criou a carga de trabalho.
- Autopilot no GKE Standard: execute cargas de trabalho no modo Autopilot do GKE para usar recursos do Autopilot, como a plataforma de computação otimizada para contêineres e o faturamento baseado em pods, mesmo em clusters Standard. O GKE gerencia esses nós e cargas de trabalho, oferecendo os benefícios do modo Autopilot em qualquer cluster.
Benefícios das ComputeClasses
As ComputeClasses oferecem aos administradores e operadores de plataforma benefícios como os seguintes:
- Melhoria da capacidade de obtenção de recursos: as ComputeClasses expandem os recursos do escalonamento automático de cluster do GKE. Os recursos da ComputeClass, como prioridades de fallback e parâmetros de consolidação de nós podem reduzir o risco de pods presos em um status pendente e aumentar o intervalo de opções que podem ser usadas para escalonar os nós.
- Configuração declarativa no nível da plataforma: as ComputeClasses permitem que os engenheiros de plataforma descrevam declarativamente as configurações de nós para vários tipos de carga de trabalho. O escalonamento automático do GKE gerencia a criação e a configuração de nós e pools de nós. É possível integrar as ComputeClasses aos pipelines de CI/CD para ter consistência na infraestrutura provisionada em toda a plataforma.
- Redução da sobrecarga de gerenciamento: as ComputeClasses reduzem a complexidade do gerenciamento de infraestrutura e cargas de trabalho em escala. Os engenheiros de plataforma declaram classes de infraestrutura, e os operadores de apps selecionam uma classe relevante em uma carga de trabalho. O GKE gerencia o escalonamento, a configuração de hardware de nós e aplica taints, tolerâncias e rótulos.
Sobre o recurso personalizado ComputeClass
As ComputeClasses são recursos personalizados do Kubernetes. É possível definir a especificação de uma ComputeClass em um arquivo de manifesto e criá-la nos clusters, da mesma forma que você define e cria os recursos de carga de trabalho do Kubernetes, como implantações e serviços.
O exemplo de manifesto a seguir define uma ComputeClass chamada n4:
apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
name: n4
spec:
nodePoolAutoCreation:
enabled: true
priorities:
- machineFamily: n4
- machineFamily: n2
whenUnsatisfiable: DoNotScaleUp
Quando um pod seleciona essa ComputeClass, o GKE faz o seguinte ao criar novos nós:
- O GKE cria nós que usam a série de máquinas N4.
- Se a série de máquinas N4 não estiver disponível, o GKE vai criar nós que usam a série de máquinas N2.
- Se a série de máquinas N2 não estiver disponível, o GKE vai aguardar até que os recursos fiquem disponíveis para programar o pod.
É possível controlar várias configurações dos nós usando as ComputeClasses, incluindo aceleradores, configurações do sistema de nós, locais de nós e o comportamento de fallback do GKE quando os recursos de hardware não estão disponíveis. Para mais informações sobre todas as configurações disponíveis para ComputeClasses, consulte a ComputeClass CustomResourceDefinition.
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 o rótulo cloud.google.com/compute-class.
O exemplo de manifesto de implantação a seguir seleciona uma ComputeClass:
Substitua COMPUTE_CLASS pelo nome de uma ComputeClass que existe no cluster. Por exemplo, é possível especificar a n4
ComputeClass na
seção
Sobre o recurso personalizado ComputeClass ou a autopilot
ComputeClass integrada.
Configuração de nós em especificações de carga de trabalho
Os clusters do Autopilot do GKE e o provisionamento automático de nós no GKE Standard permitem usar seletores de nós nos pods para criar nós com propriedades específicas, como famílias de máquinas, VMs do Spot ou GPUs e TPUs. As ComputeClasses permitem definir esses requisitos de maneira centralizada, em vez de adicionar seletores individuais a cada carga de trabalho.
Sobre a aplicação de ComputeClasses por padrão
É possível configurar o GKE para aplicar uma ComputeClass por padrão aos pods que não selecionam uma ComputeClass específica. É possível definir uma ComputeClass padrão para namespaces específicos ou para um cluster inteiro. Para mais informações sobre como configurar clusters ou namespaces com uma classe padrão, consulte Aplicar ComputeClasses a pods por padrão.
A tabela a seguir descreve os efeitos de definir uma ComputeClass como padrão para um namespace ou para um cluster:
| Efeitos das ComputeClasses padrão | |
|---|---|
| Padrão no nível do namespace |
|
| Padrão no nível do cluster |
|
Se o GKE aplicar uma ComputeClass padrão no nível do namespace a um pod, esse pod não vai ativar a ComputeClass padrão no nível do cluster, porque o GKE adiciona um seletor de nós para a classe padrão no nível do namespace ao pod.
Migração ativa em ComputeClasses padrão
Se a ComputeClass usada como padrão no nível do namespace ou do cluster tiver o campo activeMigration.optimizeRulePriority definido como true, você poderá observar os seguintes efeitos:
- Classe de computação padrão no nível do cluster: a migração ativa poderá ser acionada se houver nós com prioridade mais baixa e o GKE puder criar nós com maior prioridade. Dependendo do número de nós de prioridade mais baixa, a migração poderá aumentar a interrupção da carga de trabalho.
- Classe de computação padrão no nível do namespace: a migração ativa não é acionada porque o GKE injeta o seletor de nós da classe de computação apenas em pods recém-criados. Os pods atuais não são recriados automaticamente com o seletor.
ComputeClasses padrão no nível do cluster
Ao ativar as ComputeClasses padrão no nível do cluster, um objeto ComputeClass chamado default define as regras de escalonamento automático de nós para o cluster. Se o cluster já tiver uma ComputeClass chamada default, o GKE vai usar essa configuração de ComputeClass para o cluster. Se o cluster não tiver uma ComputeClass personalizada chamada default, o GKE vai se comportar como se as seguintes regras ComputeClass fossem aplicadas:
spec:
whenUnsatisfiable: ScaleUpAnyway
nodePoolAutoCreation:
enabled: true
Por padrão, o GKE não aplica nenhum comportamento de fallback e não altera a configuração dos nós com escalonamento automático. Para aplicar propriedades específicas aos nós com escalonamento automático por padrão, é necessário implantar uma ComputeClass personalizada chamada default.
Considere o seguinte ao configurar a classe de computação padrão no nível do cluster:
- Para evitar que os pods fiquem presos em um estado
Pending, defina o campospec.whenUnsatisfiablecomoScaleUpAnyway. Esse valor permite que o GKE crie nós mesmo que os pods solicitem famílias de máquinas do Compute Engine que não estejam nas regras de prioridade da classe padrão no nível do cluster. Se você quiser forçar esses pods a usar as famílias de máquinas que estão na ComputeClass padrão, defina esse campo comoDoNotScaleUp. - Para restringir as alterações na ComputeClass
default, use um ClusterRole do RBAC para restringir as operações update, patch, delete e create no recursoComputeClasschamadodefault. - Para mudar os parâmetros de consolidação de nós padrão do escalonador automático de clusters, use o campo
spec.autoscalingPolicyna especificação da ComputeClass. Os parâmetros especificados para esse campo na ComputeClass padrão no nível do cluster são aplicados a todos os nós do cluster. Para mais informações, consulte Definir parâmetros de escalonamento automático para consolidação de nós.
A seguir
- Saiba mais sobre as ComputeClasses integradas
- Saiba mais sobre as ComputeClasses personalizadas
- Leia a ComputeClass CustomResourceDefinition
- Implante uma ComputeClass e selecione-a em uma carga de trabalho