Esta página mostra como configurar as implantações do Autopilot do Google Kubernetes Engine (GKE) para solicitar nós baseados na arquitetura do Arm.
Sobre a arquitetura do Arm no Autopilot
Os clusters do Autopilot oferecem
classes de computação
para cargas de trabalho que têm requisitos de hardware específicos. Algumas dessas classes
de computação aceitam várias arquiteturas de CPU, como amd64
e arm64
.
Casos de uso para nós do Arm
Nós com arquitetura do Arm oferecem desempenho mais econômico em comparação a nós x86 semelhantes. Selecione o Arm para as cargas de trabalho do Autopilot em situações como a seguinte:
- Seu ambiente depende da arquitetura do Arm para criação e testes.
- Você está desenvolvendo aplicativos para dispositivos Android que são executados em CPUs Arm.
- Você usa imagens de várias arquiteturas e quer otimizar custos durante a execução das cargas de trabalho.
Como solicitar nós do Arm no Autopilot
Para solicitar nós do Arm para seus pods, é preciso solicitar nós com a arquitetura do Arm e uma classe de computação compatível com os nós do Arm. As seções a seguir mostram como solicitar a classe de computação e a arquitetura do Arm usando um seletor de nós ou uma regra de afinidade de nó na especificação do pod.
Para ver uma lista de classes de computação compatíveis com a arquitetura do Arm, consulte Classes de computação no Autopilot.
Antes de começar
Antes de começar, verifique se você realizou as tarefas a seguir:
- Ativar a API Google Kubernetes Engine. Ativar a API Google Kubernetes Engine
- Se você quiser usar a Google Cloud CLI para essa tarefa,
instale e, em seguida,
inicialize a
CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão
mais recente executando
gcloud components update
.
- Verifique se você tem um cluster do Autopilot do GKE
com a versão 1.24.1-gke.1400 ou posterior do GKE. Para definir a
versão, use a sinalização
--cluster-version
no comando create ou upgrade. - Verifique se você tem cota para o tipo de máquina
T2A
do Compute Engine. - Verifique se você tem um pod com uma imagem de contêiner criada para a arquitetura do Arm.
Solicitar uma classe de computação e uma arquitetura do Arm
Para instruir o Autopilot a colocar os pods em uma classe de computação compatível com a arquitetura do Arm, especifique o seguinte: ambos os seguintes rótulos em u regrama nodeSelector ou de afinidade de nós:
cloud.google.com/compute-class: COMPUTE_CLASS
kubernetes.io/arch: arm64
Substitua COMPUTE_CLASS
pelo nome de uma classe de computação
compatível com a arquitetura do Arm, como Scale-Out
.
Quando você implanta sua carga de trabalho, o Autopilot faz o seguinte:
- Provisiona automaticamente os nós do Arm para executar seus pods.
- Impede automaticamente os novos nós para evitar que pods que não sejam do Arm sejam programados nesses nós.
- Adiciona automaticamente uma tolerância aos pods de grupo para permitir a programação nos novos nós.
Também é possível solicitar a arquitetura do Arm para pods do Spot.
Exemplo de solicitação de arquitetura do Arm
As especificações do exemplo a seguir mostram como usar um seletor de nó ou uma regra de afinidade de nó para solicitar a arquitetura do Arm no Autopilot.
nodeSelector
O exemplo de manifesto a seguir mostra como solicitar nós do Arm em um nodeSelector:
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: Scale-Out
kubernetes.io/arch: arm64
containers:
- name: nginx-arm
image: nginx
resources:
requests:
cpu: 2000m
memory: 2Gi
nodeAffinity
Use a afinidade de nó para solicitar nós do Arm. Também é possível especificar o tipo de afinidade de nó a ser usada:
requiredDuringSchedulingIgnoredDuringExecution
: precisa usar a classe e a arquitetura de computação especificadaspreferredDuringSchedulingIgnoredDuringExecution
: use a classe de computação e a arquitetura especificadas da melhor maneira possível. Por exemplo, se um nó x86 atual for alocável, o GKE colocará seu pod no nó x86 em vez de provisionar um novo nó Arm. O pod falhará a menos que você esteja usando um manifesto de imagem de várias arquiteturas. É altamente recomendável solicitar explicitamente a arquitetura específica que você quer.
O manifesto de exemplo a seguir requer a classe Scale-Out
e os nós do
Arm:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-arm
spec:
replicas: 3
selector:
matchLabels:
app: nginx-arm
template:
metadata:
labels:
app: nginx-arm
spec:
terminationGracePeriodSeconds: 25
containers:
- name: nginx-arm
image: nginx
resources:
requests:
cpu: 2000m
memory: 2Gi
ephemeral-storage: 1Gi
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: cloud.google.com/compute-class
operator: In
values:
- Scale-Out
- key: kubernetes.io/arch
operator: In
values:
- arm64
Recomendações
- Crie e use imagens de multiarquiteturas como parte do pipeline. As imagens de várias arquiteturas garantem que seus pods sejam executados mesmo que sejam colocados em nós x86.
- Solicitar explicitamente a arquitetura e as classes de computação nos manifestos da carga de trabalho Se você não fizer isso, o Autopilot usará a arquitetura padrão da classe de computação selecionada, que pode não ser Arm.
Disponibilidade
É possível implantar cargas de trabalho do Autopilot na arquitetura do Arm nas seguintes regiões do Google Cloud:
- us-central1
- europe-west4
- asia-southeast1
Solução de problemas
Para informações sobre erros comuns e solução de problemas, consulte Como solucionar problemas em cargas de trabalho do Arm.
A seguir
- Saiba mais sobre a arquitetura de cluster do Autopilot.
- Saiba mais sobre o ciclo de vida dos pods.
- Saiba mais sobre as classes de computação do Autopilot disponíveis.
- Leia sobre as solicitações de recursos padrão, mínima e máxima de cada plataforma.