Programar VMs que usam o ambiente de execução da VM no GDC

Este documento é destinado a proprietários de aplicativos e administradores de plataforma que executam o GKE em Bare Metal. Neste documento, mostramos como usar configurações de programação, como afinidade e antiafinidade, para VMs que usam o ambiente de execução da VM na GDC.

Antes de começar

Para concluir este documento, você precisa de acesso aos seguintes recursos:

Acesso ao GKE em um cluster Bare Metal versão 1.12.0 (anthosBareMetalVersion: 1.12.0) ou superior. Use qualquer tipo de cluster capaz de executar cargas de trabalho. Se necessário, teste o GKE em Bare Metal no Compute Engine ou consulte a visão geral da criação de clusters.
A ferramenta do cliente virtctl instalada como um plug-in para o kubectl. Se necessário, instale a ferramenta de cliente virtctl.

Visão geral das configurações de programação

As configurações de programação são valores opcionais no ambiente de execução da VM no GDC. Se nenhuma configuração de programação for especificada, a VM usará como padrão o comportamento de programação padrão do Kubernetes.

Com o comportamento de programação padrão, as VMs são distribuídas pelo cluster. O programador verifica a disponibilidade atual dos recursos dos nós, como CPU e memória, e programa as VMs nos nós para distribuir as demandas de computação. Se você não tiver requisitos específicos, não precisará definir nenhuma configuração de programação.

Os três campos a seguir estão disponíveis para programar VMs:

nodeSelector: especifica os rótulos de nós que o nó host de uma VM precisa ter. O ambiente de execução de VMs no GDC programa a VM apenas nos nós que têm um rótulo especificado.
Afinidade: especifica as regras de afinidade da VM. Isso inclui afinidade de nós e afinidade ou antiafinidade entre VMs. Você define um requisito flexível ou difícil para o programador:
- preferredDuringSchedulingIgnoredDuringExecution: é uma exigência flexível. O programador tenta atender à sua solicitação. Se o programador não conseguir atender à solicitação, a VM poderá ser programada em um nó não preferido.
- requiredDuringSchedulingIgnoredDuringExecution: é um requisito difícil. O programador tenta atender à sua solicitação. Se não houver nós disponíveis que atendam ao seu requisito, a VM não será programada.
Tolerations: permite que a VM seja programada em nós com taints correspondentes.

É possível definir qualquer uma dessas configurações de programação para oferecer suporte às cargas de trabalho de computação e às necessidades de programação. Além de programar as configurações, a programação de VMs depende dos recursos disponíveis.

O ambiente de execução de VMs no GDC usa a mesma lógica de programação de VM e estrutura de manifesto que o Kubernetes para atribuir pods a nós. Para mais informações sobre essas configurações de programação, consulte os seguintes links:

Colocar VMs em um nó específico

Se você tiver nós com configurações de hardware específicas, será possível programar as VMs para serem executadas apenas nesses nós. Por exemplo, sua VM pode querer um determinado chip de CPU ou precisar de suporte a GPUs. É possível usar um nodeSelector básico ou regras de afinidade mais flexíveis para programar VMs que serão executadas nesses nós.

nodeSelector

O manifesto VirtualMachine a seguir usa um nodeSelector para um requisito de programação. Se nenhum nó estiver disponível que atenda à configuração de programação, a VM não poderá ser programada.

Crie um manifesto VirtualMachine, como my-scheduled-vm.yaml,, no editor de sua escolha.
```
nano my-scheduled-vm.yaml
```

Copie e cole o seguinte manifesto YAML:

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: VM_NAME
spec:
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: VM_NAME-boot-dv
      boot: true
  scheduling:
    nodeSelector:
      kubernetes.io/hostname: NODE_NAME

Substitua os seguintes valores:

VM_NAME: o nome da VM.
NODE_NAME: os nós em que você quer programar sua VM.

O disco de inicialização chamado VM_NAME-boot-dv já precisa existir. Para mais informações, consulte Criar um disco de inicialização de VM.

Salve e feche o manifesto da VM no editor.
Crie a VM e programe a configuração usando kubectl:
```
kubectl apply -f my-scheduled-vm.yaml
```

Afinidade

O manifesto VirtualMachine a seguir usa afinidade para um requisito de programação flexível. O programador tenta atender à sua solicitação. Se o programador não puder atender à solicitação, a VM será programada em um nó não preferido.

Crie um manifesto VirtualMachine, como my-scheduled-vm.yaml,, no editor de sua escolha.
```
nano my-scheduled-vm.yaml
```

Copie e cole o seguinte manifesto YAML:

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: VM_NAME
spec:
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: VM_NAME-boot-dv
      boot: true
  scheduling:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            preference:
              matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                - NODE_NAME

Substitua os seguintes valores:

VM_NAME: o nome da VM.
NODE_NAME: os nós em que você quer programar sua VM.

O disco de inicialização chamado VM_NAME-boot-dv já precisa existir. Para mais informações, consulte Criar um disco de inicialização de VM.

Salve e feche o manifesto da VM no editor.
Crie a VM e programe a configuração usando kubectl:
```
kubectl apply -f my-scheduled-vm.yaml
```

Não colocar VMs em um nó específico

Algumas VMs podem ter cargas de trabalho que não são executadas em um nó específico. É possível usar regras antiafinidade para evitar a programação de VMs nesses nós.

O manifesto VirtualMachine a seguir usa afinidade para um requisito de programação flexível. O programador tenta atender à sua solicitação. Se o programador não conseguir atender à solicitação, a VM poderá ser programada em um nó inapropriado.

Crie um manifesto VirtualMachine, como my-scheduled-vm.yaml,, no editor de sua escolha.
```
nano my-scheduled-vm.yaml
```

Copie e cole o seguinte manifesto YAML:

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: VVM_NAME
spec:
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: VM_NAME-boot-dv
      boot: true
  scheduling:
    affinity:
      nodeAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          preference:
            matchExpressions:
            - key: kubernetes.io/hostname
              operator: NotIn
              values:
              - NODE_NAME

Substitua os seguintes valores:

VM_NAME: o nome da VM.
NODE_NAME: o nó em que você quer programar a VM.

O disco de inicialização chamado VM_NAME-boot-dv já precisa existir. Para mais informações, consulte Criar um disco de inicialização de VM.

Salve e feche o manifesto da VM no editor.
Crie a VM e programe a configuração usando kubectl:
```
kubectl apply -f my-scheduled-vm.yaml
```

Mantenha as VMs separadas

Suas cargas de trabalho de computação podem ter VMs que precisam ser distribuídas entre os nós para alta disponibilidade, como um pool de VMs de front-end. É possível usar regras de antiafinidade entre VMs para evitar a programação de VMs em nós.

Crie um manifesto VirtualMachine, como my-scheduled-vm.yaml,, no editor de sua escolha.
```
nano my-scheduled-vm.yaml
```

Copie e cole o seguinte manifesto YAML:

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: VM_NAME
  labels:
    KEY:VALUE
spec:
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: VM_NAME-boot-dv
      boot: true
  scheduling:
    affinity:
      podAntiAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            topologyKey: kubernetes.io/hostname
            labelSelector:
              matchLabels:
                KEY:VALUE

Substitua os seguintes valores:

VM_NAME: o nome da VM.
KEY:VALUE: o rótulo key:value a ser aplicado às VMs que você quer programar em diferentes nós. Para mais informações, consulte rótulos e anotações.

O disco de inicialização chamado VM_NAME-boot-dv já precisa existir. Para mais informações, consulte Criar um disco de inicialização de VM.

Salve e feche o manifesto da VM no editor.
Crie a VM e programe a configuração usando kubectl:
```
kubectl apply -f my-scheduled-vm.yaml
```

Manter as VMs juntas

Suas cargas de trabalho de computação podem ter VMs que precisam ser mantidas juntas em nós para reduzir a latência, como um middleware e um nível de banco de dados. É possível usar regras de afinidade entre VMs para programar VMs em nós.

Crie um manifesto VirtualMachine, como my-scheduled-vm.yaml,, no editor de sua escolha.
```
nano my-scheduled-vm.yaml
```

Copie e cole o seguinte manifesto YAML:

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: VM_NAME
  labels:
    KEY:VALUE
spec:
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: VM_NAME-boot-dv
      boot: true
  scheduling:
    affinity:
      podAffinity:
        preferredDuringSchedulingIgnoredDuringExecution
        - podAffinityTerm:
            topologyKey: kubernetes.io/hostname
            labelSelector:
              matchLabels:
                KEY:VALUE
          weight: 100

Substitua os seguintes valores:

VM_NAME: o nome da VM.
KEY:VALUE: o par de rótulos key:value a ser aplicado às VMs que você quer programar em diferentes nós. Para mais informações, consulte rótulos e seletores.

O disco de inicialização chamado VM_NAME-boot-dv já precisa existir. Para mais informações, consulte Criar um disco de inicialização de VM.

Salve e feche o manifesto da VM no editor.
Crie a VM e programe a configuração usando kubectl:
```
kubectl apply -f my-scheduled-vm.yaml
```

Programar VMs em nós com taints

Taints são uma propriedade de programação que permite que os nós permitam que apenas VMs com tolerâncias especificadas sejam programadas para serem executadas nelas. Aplique um taint a um nó. Em seguida, no manifesto VirtualMachine, defina uma tolerância para permitir que a VM seja executada no nó. Para mais informações, consulte Taints e tolerâncias.

Crie um manifesto VirtualMachine, como my-scheduled-vm.yaml,, no editor de sua escolha.
```
nano my-scheduled-vm.yaml
```

Copie e cole o seguinte manifesto YAML:

apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  name: VM_NAME
spec:
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: VM_NAME-boot-dv
      boot: true
  scheduling:
    tolerations:
    - key: KEY_NAME
      operator: "Equal"
      value: KEY_VALUE
      effect: "NoSchedule"

Substitua os seguintes valores:

VM_NAME: o nome da VM.
KEY_NAME: o nome da chave da tolerância que corresponde ao taint no nó.
KEY_VALUE: o valor da chave da tolerância que corresponde ao taint no nó.

O disco de inicialização chamado VM_NAME-boot-dv já precisa existir. Para mais informações, consulte Criar um disco de inicialização de VM.

Salve e feche o manifesto da VM no editor.
Crie a VM e programe a configuração usando kubectl:
```
kubectl apply -f my-scheduled-vm.yaml
```

A seguir

Editar uma VM no GKE em Bare Metal