Documentação do SUSE Edge|Dicas e truques|Metal3

32 Metal3

 

32.1 Seleção do BareMetalHost e associação do cluster

 

Após a criação de um objeto de cluster Metalˆ3ˆ e dos objetos associados correspondentes, será realizado um processo para escolher o BareMetalHost que fará parte do cluster. Esse processo conecta um BareMetalHost a um Metal3MachineTemplate específico usando rótulos do Kubernetes e seletores padrão.

Como exemplo, cada BareMetalHost recebe um rótulo para identificar as respectivas propriedades e o cluster pretendido (por exemplo, função do cluster, nome do cluster, local etc.):

apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: mynode1
  labels:
    cluster-role: control-plane
    cluster: foobar
    location: madrid
    datacenter: xyz
<snip>
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: mynode2
  labels:
    cluster-role: worker
    cluster: foobar
    location: madrid
    datacenter: xyz
<snip>
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: mynode3
  labels:
    cluster-role: worker
    cluster: foobar2
    location: madrid
    datacenter: xyz
<snip>
...

Em seguida, o objeto Metal3MachineTemplate usa o campo spec.hostSelector para corresponder o BareMetalHost desejado.

É possível usar tanto matchLabels (para correspondência exata de chave-valor) quanto matchExpressions (para regras mais complexas):

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3MachineTemplate
metadata:
  name: foobar-cluster-controlplane
  namespace: mynamespace
spec:
  template:
    spec:
      hostSelector:
        matchLabels:
          cluster-role: control-plane
          cluster: foobar
<snip>
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3MachineTemplate
metadata:
  name: foobar-cluster-worker
  namespace: mynamespace
spec:
  template:
    spec:
      hostSelector:
        matchExpressions:
          - { key: cluster-role, operator: In, values: [worker] }
          - { key: cluster, operator: In, values: [foobar] }
<snip>
Nota
Nota

É possível também usar namespaces do kubernetes para organizar melhor os diversos objetos.

32.2 Limpar entradas de boot EFI antigas

 

Às vezes, o gerenciador de boot UEFI contém várias entradas de sistemas operacionais mais antigos que, provavelmente, não são mais necessárias (em especial, de hosts provisionados várias vezes). É possível limpar essas entradas antigas seguindo qualquer um destes procedimentos:

  • Exclua as entradas diretamente pela interface de configuração do BIOS/EFI (o procedimento exato depende do hardware).

  • Execute o shell UEFI bcfg como:

    # List the entries
bcfg boot dump -b
# Delete entry number X
bcfg boot rm X
# X is the number associated the entry to remove. For example, if the entry is "Boot0002 foobar", then X is 2.

  • Use efibootmgr em um sistema Linux como:

    # List the entries
efibootmgr -v
# Delete entry number X
efibootmgr -b X -B

O processo pode deixar arquivos órfãos na partição de sistema EFI (ESP), que costumam ficar em subdiretórios nomeados pelo fornecedor (por exemplo, EFI/opensuse ou EFI/Microsoft). Em geral, esses arquivos não são prejudiciais, mas poderão ser excluídos se consumirem um espaço excessivo, já que isso pode impedir a instalação de um novo SO ou a atualização de um gerenciador de boot. A remoção pode exigir a montagem explícita da ESP, normalmente montada como /boot/efi/EFI nos sistemas Linux.