Este método é útil em cenários com hardware de destino que permite o gerenciamento fora da banda e quando se deseja um fluxo de gerenciamento de infraestrutura automatizado.

O cluster de gerenciamento é configurado para oferecer APIs declarativas que permitem o gerenciamento de inventário e de estado dos servidores bare metal do cluster downstream, incluindo inspeção automatizada, limpeza e provisionamento/desprovisionamento.

Há algumas restrições específicas relacionadas ao hardware e à rede de servidor do cluster downstream:

Algumas ferramentas são necessárias e podem ser instaladas no cluster de gerenciamento ou em um host que possa acessá-lo.

Faça download do arquivo de imagem de sistema operacional SL-Micro.x86_64-6.1-Base-GM.raw pelo SUSE Customer Center ou pela página de download da SUSE.

1.3.1 Configurar o cluster de gerenciamento #

 

As etapas básicas de instalação de um cluster de gerenciamento e uso do Metal³ são:

1. Instalar um cluster de gerenciamento RKE2

2. Instalar o Rancher

3. Instalar um provedor de armazenamento (opcional)

4. Instalar as dependências do Metal³

5. Instalar as dependências da CAPI pelo Rancher Turtles

6. Criar uma imagem do sistema operacional SLEMicro para hosts do cluster downstream

7. Registrar CRs de BareMetalHost para definir o inventário de bare metal

8. Criar um cluster downstream definindo recursos da CAPI

Este guia considera que já existe um cluster RKE2 e que o Rancher (incluindo o cert-manager) foi instalado, por exemplo, usando o Edge Image Builder (Capítulo 11, Edge Image Builder).

Dica

Estas etapas também podem ser totalmente automatizadas conforme descrito na documentação do cluster de gerenciamento (Capítulo 40, Configurando o cluster de gerenciamento).

1.3.2 Instalando as dependências do Metal³ #

 

O cert-manager deve ser instalado e executado caso não tenha sido junto com a instalação do Rancher.

É necessário instalar um provedor de armazenamento persistente. O SUSE Storage é recomendado, mas também é possível usar o local-path-provisioner em ambientes de desenvolvimento/PoC. A instrução abaixo considera que StorageClass foi marcada como padrão; do contrário, será necessária uma configuração adicional para o gráfico do Metal³.

Um IP adicional é necessário, que pode ser gerenciado por MetalLB para fornecer um endpoint consistente aos serviços de gerenciamento do Metal³. Esse IP deve fazer parte da sub-rede do plano de controle e ser reservado para configuração estática (e não fazer parte de um pool DHCP).

Dica

Se o cluster de gerenciamento é um nó único, é possível evitar o requisito de IP flutuante adicional gerenciado por MetalLB. Consulte a Seção 1.6.1, “Configuração de nó único”.

1. Vamos instalar primeiro o MetalLB:

   helm install \
     metallb oci://registry.suse.com/edge/charts/metallb \
     --namespace metallb-system \
     --create-namespace

2. Na sequência, definimos um IPAddressPool e L2Advertisement usando o IP reservado, especificado abaixo como STATIC_IRONIC_IP:

   export STATIC_IRONIC_IP=<STATIC_IRONIC_IP>
   
   cat <<-EOF | kubectl apply -f -
   apiVersion: metallb.io/v1beta1
   kind: IPAddressPool
   metadata:
     name: ironic-ip-pool
     namespace: metallb-system
   spec:
     addresses:
     - ${STATIC_IRONIC_IP}/32
     serviceAllocation:
       priority: 100
       serviceSelectors:
       - matchExpressions:
         - {key: app.kubernetes.io/name, operator: In, values: [metal3-ironic]}
   EOF

   cat <<-EOF | kubectl apply -f -
   apiVersion: metallb.io/v1beta1
   kind: L2Advertisement
   metadata:
     name: ironic-ip-pool-l2-adv
     namespace: metallb-system
   spec:
     ipAddressPools:
     - ironic-ip-pool
   EOF

3. Agora é possível instalar o Metal³:

   helm install \
     metal3 oci://registry.suse.com/edge/charts/metal3 \
     --namespace metal3-system \
     --create-namespace \
     --set global.ironicIP="$STATIC_IRONIC_IP"

4. A execução do contêiner init pode levar cerca de dois minutos nesta implantação, portanto, garanta que todos os pods estejam em execução antes de continuar:

   kubectl get pods -n metal3-system
   NAME                                                    READY   STATUS    RESTARTS   AGE
   baremetal-operator-controller-manager-85756794b-fz98d   2/2     Running   0          15m
   metal3-metal3-ironic-677bc5c8cc-55shd                   4/4     Running   0          15m
   metal3-metal3-mariadb-7c7d6fdbd8-64c7l                  1/1     Running   0          15m

Atenção

Não avance para as etapas seguintes até que todos os pods no namespace metal3-system estejam em execução.

cat > values.yaml <<EOF
rancherTurtles:
  features:
    embedded-capi:
      disabled: true
    rancher-webhook:
      cleanup: true
EOF

helm install \
  rancher-turtles oci://registry.suse.com/edge/charts/rancher-turtles \
  --namespace rancher-turtles-system \
  --create-namespace \
  -f values.yaml

1.3.4 Preparar a imagem do cluster downstream #

 

O Kiwi (Capítulo 28, Criando imagens atualizadas do SUSE Linux Micro com o Kiwi) e o Edge Image Builder (Capítulo 11, Edge Image Builder) são usados para preparar a imagem base do SLEMicro modificado que foi provisionado nos hosts do cluster downstream.

Neste guia, abordamos a configuração mínima necessária para implantar o cluster downstream.

1.3.4.1 Configuração da imagem #

 

Nota

Primeiro siga o Capítulo 28, Criando imagens atualizadas do SUSE Linux Micro com o Kiwi para gerar uma imagem nova como a primeira etapa necessária para criar clusters.

Ao executar o Edge Image Builder, um diretório é montado com base no host, portanto, é necessário criar uma estrutura de diretórios para armazenar os arquivos de configuração usados para definir a imagem de destino.

• downstream-cluster-config.yaml é o arquivo de definição da imagem. Consulte o Capítulo 3, Clusters independentes com o Edge Image Builder para obter mais detalhes.

• Quando o download da imagem base é feito, ela é compactada com xz, que deve ser descompactada com unxz e copiada/movida para a pasta base-images.

• A pasta network é opcional. Consulte a Seção 1.3.5.1.1, “Script adicional para configuração de rede estática” para obter mais detalhes.

• O diretório custom/scripts contém scripts que são executados na primeira inicialização. Atualmente, um script 01-fix-growfs.sh é necessário para redimensionar a partição raiz do sistema operacional na implantação.

├── downstream-cluster-config.yaml
├── base-images/
│   └ SL-Micro.x86_64-6.1-Base-GM.raw
├── network/
|   └ configure-network.sh
└── custom/
    └ scripts/
        └ 01-fix-growfs.sh

1.3.4.1.1 Arquivo de definição da imagem do cluster downstream #

 

O downstream-cluster-config.yaml é o arquivo de configuração principal para a imagem do cluster downstream. Veja a seguir um exemplo mínimo de implantação por meio do Metal³:

apiVersion: 1.2
image:
  imageType: raw
  arch: x86_64
  baseImage: SL-Micro.x86_64-6.1-Base-GM.raw
  outputImageName: SLE-Micro-eib-output.raw
operatingSystem:
  time:
    timezone: Europe/London
    ntp:
      forceWait: true
      pools:
        - 2.suse.pool.ntp.org
      servers:
        - 10.0.0.1
        - 10.0.0.2
  kernelArgs:
    - ignition.platform.id=openstack
    - net.ifnames=1
  systemd:
    disable:
      - rebootmgr
      - transactional-update.timer
      - transactional-update-cleanup.timer
  users:
    - username: root
      encryptedPassword: $ROOT_PASSWORD
      sshKeys:
      - $USERKEY1
  packages:
    packageList:
      - jq
  sccRegistrationCode: $SCC_REGISTRATION_CODE

Em que $SCC_REGISTRATION_CODE é o código de registro copiado do SUSE Customer Center, e a lista de pacotes contém o jq, que é obrigatório.

$ROOT_PASSWORD é a senha criptografada do usuário root, que pode ser útil para teste/depuração. É possível gerá-la com o comando openssl passwd -6 PASSWORD.

Para os ambientes de produção, a recomendação é usar as chaves SSH que podem ser adicionadas ao bloco de usuários substituindo a $USERKEY1 pelas chaves SSH reais.

Nota

O net.ifnames=1 habilita a Nomenclatura de interface de rede previsível.

Isso corresponde à configuração padrão do gráfico do Metal³, mas a configuração deve corresponder ao valor predictableNicNames do gráfico.

Veja também que o ignition.platform.id=openstack é obrigatório. Sem esse argumento, a configuração do SUSE Linux Micro pelo ignition vai falhar no fluxo automatizado do Metal³.

A seção time é opcional, mas sua configuração é altamente recomendada para evitar possíveis problemas com certificados e divergência de relógio. O valor usado neste exemplo é somente para fins ilustrativos. Ajuste-o de acordo com seus requisitos específicos.

1.3.4.1.2 Script growfs #

 

Atualmente, é necessário um script personalizado (custom/scripts/01-fix-growfs.sh) para expandir o sistema de arquivos de acordo com o tamanho do disco na primeira inicialização após o provisionamento. O script 01-fix-growfs.sh contém as seguintes informações:

#!/bin/bash
growfs() {
  mnt="$1"
  dev="$(findmnt --fstab --target ${mnt} --evaluate --real --output SOURCE --noheadings)"
  # /dev/sda3 -> /dev/sda, /dev/nvme0n1p3 -> /dev/nvme0n1
  parent_dev="/dev/$(lsblk --nodeps -rno PKNAME "${dev}")"
  # Last number in the device name: /dev/nvme0n1p42 -> 42
  partnum="$(echo "${dev}" | sed 's/^.*[^0-9]\([0-9]\+\)$/\1/')"
  ret=0
  growpart "$parent_dev" "$partnum" || ret=$?
  [ $ret -eq 0 ] || [ $ret -eq 1 ] || exit 1
  /usr/lib/systemd/systemd-growfs "$mnt"
}
growfs /

Nota

Adicione seus próprios scripts personalizados para execução durante o processo de provisionamento usando a mesma abordagem. Para obter mais informações, consulte o Capítulo 3, Clusters independentes com o Edge Image Builder.

1.3.4.2 Criação de imagem #

 

Depois que a estrutura de diretórios for preparada de acordo com as seções anteriores, execute o seguinte comando para criar a imagem:

podman run --rm --privileged -it -v $PWD:/eib \
 registry.suse.com/edge/3.3/edge-image-builder:1.2.1 \
 build --definition-file downstream-cluster-config.yaml

Ele cria o arquivo de imagem de saída chamado SLE-Micro-eib-output.raw, com base na definição descrita acima.

Depois disso, a imagem de saída deverá estar disponível em um servidor web, ou o contêiner de servidor de mídia habilitado pelo gráfico do Metal3 (Nota) ou um outro servidor acessível localmente. Nos exemplos a seguir, chamamos esse servidor de imagecache.local:8080.

Nota

Na implantação de imagens EIB em clusters downstream, é necessário também incluir a soma sha256 da imagem no objeto Metal3MachineTemplate. É possível gerá-la com este comando:

sha256sum <image_file> > <image_file>.sha256
# On this example:
sha256sum SLE-Micro-eib-output.raw > SLE-Micro-eib-output.raw.sha256

1.3.5 Adicionando o inventário de BareMetalHost #

 

Para registrar servidores bare metal para implantação automatizada, é necessário criar dois recursos: um segredo com as credenciais de acesso ao BMC e um recurso BareMetalHost do Metal³ com a definição da conexão com o BMC e outros detalhes:

apiVersion: v1
kind: Secret
metadata:
  name: controlplane-0-credentials
type: Opaque
data:
  username: YWRtaW4=
  password: cGFzc3dvcmQ=
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: controlplane-0
  labels:
    cluster-role: control-plane
spec:
  online: true
  bootMACAddress: "00:f3:65:8a:a3:b0"
  bmc:
    address: redfish-virtualmedia://192.168.125.1:8000/redfish/v1/Systems/68bd0fb6-d124-4d17-a904-cdf33efe83ab
    disableCertificateVerification: true
    credentialsName: controlplane-0-credentials

Observe o seguinte:

• O nome de usuário/senha do segredo deve ser codificado com base64. Observe que ele não deve incluir novas linhas à direita (por exemplo, usar echo -n, não apenas echo!)

• É possível definir o rótulo cluster-role agora ou mais tarde, durante a criação do cluster. No exemplo abaixo, esperamos control-plane ou worker

• bootMACAddress deve ser um MAC válido correspondente à NIC de plano de controle do host

• O endereço bmc é a conexão com a API de gerenciamento de BMC. As seguintes opções são suportadas:

  • redfish-virtualmedia://<ENDEREÇO IP>/redfish/v1/Systems/<ID DO SISTEMA>: mídia virtual Redfish, por exemplo, SuperMicro

  • idrac-virtualmedia://<ENDEREÇO IP>/redfish/v1/Systems/System.Embedded.1: iDRAC da Dell

• Consulte os documentos da API upstream para obter mais detalhes sobre a API BareMetalHost

1.3.5.1 Configurando IPs estáticos #

 

O exemplo do BareMetalHost acima considera que o DHCP configura a rede do plano de controle, mas nos cenários em que a configuração manual é necessária, como no caso dos IPs estáticos, é possível definir uma configuração adicional, conforme descrito abaixo.

1.3.5.1.1 Script adicional para configuração de rede estática #

 

Ao criar a imagem base com o Edge Image Builder, na pasta network, crie o arquivo configure-network.sh a seguir.

Esse procedimento consome os dados da unidade de configuração na primeira inicialização e configura a rede do host usando a ferramenta NM Configurator.

#!/bin/bash

set -eux

# Attempt to statically configure a NIC in the case where we find a network_data.json
# In a configuration drive

CONFIG_DRIVE=$(blkid --label config-2 || true)
if [ -z "${CONFIG_DRIVE}" ]; then
  echo "No config-2 device found, skipping network configuration"
  exit 0
fi

mount -o ro $CONFIG_DRIVE /mnt

NETWORK_DATA_FILE="/mnt/openstack/latest/network_data.json"

if [ ! -f "${NETWORK_DATA_FILE}" ]; then
  umount /mnt
  echo "No network_data.json found, skipping network configuration"
  exit 0
fi

DESIRED_HOSTNAME=$(cat /mnt/openstack/latest/meta_data.json | tr ',{}' '\n' | grep '\"metal3-name\"' | sed 's/.*\"metal3-name\": \"\(.*\)\"/\1/')
echo "${DESIRED_HOSTNAME}" > /etc/hostname

mkdir -p /tmp/nmc/{desired,generated}
cp ${NETWORK_DATA_FILE} /tmp/nmc/desired/_all.yaml
umount /mnt

./nmc generate --config-dir /tmp/nmc/desired --output-dir /tmp/nmc/generated
./nmc apply --config-dir /tmp/nmc/generated

1.3.5.1.2 Segredo adicional com a configuração de rede do host #

 

É possível definir um segredo adicional com os dados no formato nmstate suportado pela ferramenta NM Configurator (Capítulo 12, Rede de borda) para cada host.

Depois disso, o segredo será referenciado no recurso BareMetalHost pelo campo de especificação preprovisioningNetworkDataName.

apiVersion: v1
kind: Secret
metadata:
  name: controlplane-0-networkdata
type: Opaque
stringData:
  networkData: |
    interfaces:
    - name: enp1s0
      type: ethernet
      state: up
      mac-address: "00:f3:65:8a:a3:b0"
      ipv4:
        address:
        - ip:  192.168.125.200
          prefix-length: 24
        enabled: true
        dhcp: false
    dns-resolver:
      config:
        server:
        - 192.168.125.1
    routes:
      config:
      - destination: 0.0.0.0/0
        next-hop-address: 192.168.125.1
        next-hop-interface: enp1s0
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: controlplane-0
  labels:
    cluster-role: control-plane
spec:
  preprovisioningNetworkDataName: controlplane-0-networkdata
# Remaining content as in previous example

Nota

Em algumas situações, é possível omitir o endereço MAC. Consulte a Seção 12.5.8, “Configurações unificadas de nós” para obter mais detalhes.

1.3.5.2 Preparação do BareMetalHost #

 

Depois de criar o recurso BareMetalHost e os segredos associados conforme descrito acima, será acionado um fluxo de trabalho de preparação do host:

• Uma imagem de disco RAM será iniciada depois de conectar a mídia virtual ao BMC do host de destino

• O disco RAM inspeciona os detalhes do hardware e prepara o host para provisionamento (por exemplo, limpando os discos de dados anteriores)

• Ao término desse processo, os detalhes do hardware no campo status.hardware do BareMetalHost serão atualizados e poderão ser verificados

Esse processo pode levar bastante tempo, mas quando for concluído, você verá que o estado do BareMetalHost deve mudar para available:

% kubectl get baremetalhost
NAME             STATE       CONSUMER   ONLINE   ERROR   AGE
controlplane-0   available              true             9m44s
worker-0         available              true             9m44s

1.3.7 Implantação do plano de controle #

 

Para implantar o plano de controle, definimos um manifesto YAML semelhante ao mostrado abaixo, que contém os seguintes recursos:

• O recurso Cluster define o nome do cluster, as redes e o tipo de provedor de plano de controle/infraestrutura (neste caso, RKE2/Metal3)

• Metal3Cluster define o endpoint do plano de controle (IP do host para nó único, endpoint LoadBalancer para vários nós; neste exemplo, foi considerado o nó único)

• RKE2ControlPlane define a versão RKE2 e a configuração adicional necessária durante a inicialização do cluster

• Metal3MachineTemplate define a imagem do sistema operacional que será aplicada aos recursos do BareMetalHost, e hostSelector define quais BareMetalHosts serão consumidos

• Metal3DataTemplate define o metaData adicional que será passado para o BareMetalHost (veja que o networkData não é suportado na solução Edge)

Nota

Para simplificar, este exemplo considera um plano de controle de nó único em que o BareMetalHost está configurado com o IP 192.168.125.200. Para ver exemplos mais avançados de vários nós, consulte o Capítulo 42, Provisionamento de rede direcionado totalmente automatizado.

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: sample-cluster
  namespace: default
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
        - 192.168.0.0/18
    services:
      cidrBlocks:
        - 10.96.0.0/12
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    kind: RKE2ControlPlane
    name: sample-cluster
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3Cluster
    name: sample-cluster
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3Cluster
metadata:
  name: sample-cluster
  namespace: default
spec:
  controlPlaneEndpoint:
    host: 192.168.125.200
    port: 6443
  noCloudProvider: true
---
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: RKE2ControlPlane
metadata:
  name: sample-cluster
  namespace: default
spec:
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3MachineTemplate
    name: sample-cluster-controlplane
  replicas: 1
  version: v1.32.4+rke2r1
  rolloutStrategy:
    type: "RollingUpdate"
    rollingUpdate:
      maxSurge: 0
  agentConfig:
    format: ignition
    kubelet:
      extraArgs:
        - provider-id=metal3://BAREMETALHOST_UUID
    additionalUserData:
      config: |
        variant: fcos
        version: 1.4.0
        systemd:
          units:
            - name: rke2-preinstall.service
              enabled: true
              contents: |
                [Unit]
                Description=rke2-preinstall
                Wants=network-online.target
                Before=rke2-install.service
                ConditionPathExists=!/run/cluster-api/bootstrap-success.complete
                [Service]
                Type=oneshot
                User=root
                ExecStartPre=/bin/sh -c "mount -L config-2 /mnt"
                ExecStart=/bin/sh -c "sed -i \"s/BAREMETALHOST_UUID/$(jq -r .uuid /mnt/openstack/latest/meta_data.json)/\" /etc/rancher/rke2/config.yaml"
                ExecStart=/bin/sh -c "echo \"node-name: $(jq -r .name /mnt/openstack/latest/meta_data.json)\" >> /etc/rancher/rke2/config.yaml"
                ExecStartPost=/bin/sh -c "umount /mnt"
                [Install]
                WantedBy=multi-user.target
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3MachineTemplate
metadata:
  name: sample-cluster-controlplane
  namespace: default
spec:
  template:
    spec:
      dataTemplate:
        name: sample-cluster-controlplane-template
      hostSelector:
        matchLabels:
          cluster-role: control-plane
      image:
        checksum: http://imagecache.local:8080/SLE-Micro-eib-output.raw.sha256
        checksumType: sha256
        format: raw
        url: http://imagecache.local:8080/SLE-Micro-eib-output.raw
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3DataTemplate
metadata:
  name: sample-cluster-controlplane-template
  namespace: default
spec:
  clusterName: sample-cluster
  metaData:
    objectNames:
      - key: name
        object: machine
      - key: local-hostname
        object: machine
      - key: local_hostname
        object: machine

Depois de adaptado ao seu ambiente, aplique o exemplo usando o kubectl e monitore o status do cluster por meio do clusterctl.

% kubectl apply -f rke2-control-plane.yaml

# Wait for the cluster to be provisioned
% clusterctl describe cluster sample-cluster
NAME                                                    READY  SEVERITY  REASON  SINCE  MESSAGE
Cluster/sample-cluster                                  True                     22m
├─ClusterInfrastructure - Metal3Cluster/sample-cluster  True                     27m
├─ControlPlane - RKE2ControlPlane/sample-cluster        True                     22m
│ └─Machine/sample-cluster-chflc                        True                     23m

apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  labels:
    cluster.x-k8s.io/cluster-name: sample-cluster
  name: sample-cluster
  namespace: default
spec:
  clusterName: sample-cluster
  replicas: 1
  selector:
    matchLabels:
      cluster.x-k8s.io/cluster-name: sample-cluster
  template:
    metadata:
      labels:
        cluster.x-k8s.io/cluster-name: sample-cluster
    spec:
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1alpha1
          kind: RKE2ConfigTemplate
          name: sample-cluster-workers
      clusterName: sample-cluster
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: Metal3MachineTemplate
        name: sample-cluster-workers
      nodeDrainTimeout: 0s
      version: v1.32.4+rke2r1
---
apiVersion: bootstrap.cluster.x-k8s.io/v1alpha1
kind: RKE2ConfigTemplate
metadata:
  name: sample-cluster-workers
  namespace: default
spec:
  template:
    spec:
      agentConfig:
        format: ignition
        version: v1.32.4+rke2r1
        kubelet:
          extraArgs:
            - provider-id=metal3://BAREMETALHOST_UUID
        additionalUserData:
          config: |
            variant: fcos
            version: 1.4.0
            systemd:
              units:
                - name: rke2-preinstall.service
                  enabled: true
                  contents: |
                    [Unit]
                    Description=rke2-preinstall
                    Wants=network-online.target
                    Before=rke2-install.service
                    ConditionPathExists=!/run/cluster-api/bootstrap-success.complete
                    [Service]
                    Type=oneshot
                    User=root
                    ExecStartPre=/bin/sh -c "mount -L config-2 /mnt"
                    ExecStart=/bin/sh -c "sed -i \"s/BAREMETALHOST_UUID/$(jq -r .uuid /mnt/openstack/latest/meta_data.json)/\" /etc/rancher/rke2/config.yaml"
                    ExecStart=/bin/sh -c "echo \"node-name: $(jq -r .name /mnt/openstack/latest/meta_data.json)\" >> /etc/rancher/rke2/config.yaml"
                    ExecStartPost=/bin/sh -c "umount /mnt"
                    [Install]
                    WantedBy=multi-user.target
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3MachineTemplate
metadata:
  name: sample-cluster-workers
  namespace: default
spec:
  template:
    spec:
      dataTemplate:
        name: sample-cluster-workers-template
      hostSelector:
        matchLabels:
          cluster-role: worker
      image:
        checksum: http://imagecache.local:8080/SLE-Micro-eib-output.raw.sha256
        checksumType: sha256
        format: raw
        url: http://imagecache.local:8080/SLE-Micro-eib-output.raw
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3DataTemplate
metadata:
  name: sample-cluster-workers-template
  namespace: default
spec:
  clusterName: sample-cluster
  metaData:
    objectNames:
      - key: name
        object: machine
      - key: local-hostname
        object: machine
      - key: local_hostname
        object: machine

% kubectl apply -f rke2-agent.yaml

# Wait for the worker nodes to be provisioned
% clusterctl describe cluster sample-cluster
NAME                                                    READY  SEVERITY  REASON  SINCE  MESSAGE
Cluster/sample-cluster                                  True                     25m
├─ClusterInfrastructure - Metal3Cluster/sample-cluster  True                     30m
├─ControlPlane - RKE2ControlPlane/sample-cluster        True                     25m
│ └─Machine/sample-cluster-chflc                        True                     27m
└─Workers
  └─MachineDeployment/sample-cluster                    True                     22m
    └─Machine/sample-cluster-56df5b4499-zfljj           True                     23m

% kubectl delete -f rke2-agent.yaml
% kubectl delete -f rke2-control-plane.yaml

% kubectl get bmh
NAME             STATE            CONSUMER                            ONLINE   ERROR   AGE
controlplane-0   deprovisioning   sample-cluster-controlplane-vlrt6   false            10m
worker-0         deprovisioning   sample-cluster-workers-785x5        false            10m

...

% kubectl get bmh
NAME             STATE       CONSUMER   ONLINE   ERROR   AGE
controlplane-0   available              false            15m
worker-0         available              false            15m

A documentação do SUSE Edge for Telco (Capítulo 37, SUSE Edge for Telco) tem exemplos de uso mais avançado do Metal³ para casos de uso de telecomunicações.

global:
  ironicIP: <MANAGEMENT_CLUSTER_IP>
metal3-ironic:
  service:
    type: NodePort

global:
  enable_vmedia_tls: false

kubectl get secret -n metal3-system ironic-vmedia-cert -o yaml

metal3-ironic:
  persistence:
    ironic:
      size: "5Gi"

Veja a seguir uma descrição dos requisitos mínimos de sistema e de ambiente para execução por meio desta inicilização rápida:

Nota

Os dados existentes nas máquinas de destino serão substituídos como parte do processo. Faça um backup dos dados em dispositivos de armazenamento USB e discos conectados aos nós de implantação de destino.

Este guia foi criado com um droplet da DigitalOcean para hospedar o cluster upstream e com um Intel NUC como dispositivo downstream. Para montar a mídia de instalação, o SUSE Linux Enterprise Server foi usado.

Para começar, crie um cluster capaz de hospedar o Rancher e o Elemental. Esse cluster precisa ser roteável na rede à qual os nós downstream estão conectados.

2.3.2 Configurar o DNS #

 

Antes de continuar, você precisa configurar o acesso ao cluster. Assim como na configuração do próprio cluster, a configuração do DNS será diferente dependendo do local onde ele está hospedado.

Dica

Se você não deseja configurar registros DNS (por exemplo, quando se trata apenas de um servidor de teste efêmero), uma alternativa é usar um serviço como o sslip.io. Com ele, você resolve qualquer endereço IP com <endereço>.sslip.io.

Para instalar o Rancher, você precisa acessar a API Kubernetes do cluster que acabou de criar. Esse procedimento muda dependendo da distribuição Kubernetes que é usada.

Para o RKE2, o arquivo kubeconfig será gravado em /etc/rancher/rke2/rke2.yaml. Salve-o como ~/.kube/config no sistema local. Talvez você tenha que editar o arquivo para incluir o endereço IP ou o nome de host roteável externamente correto.

Instale o Rancher facilmente com os comandos apresentados na documentação do Rancher:

Instale o cert-manager:

helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager \
 --namespace cert-manager \
 --create-namespace \
 --set crds.enabled=true

Em seguida, instale o próprio Rancher:

helm repo add rancher-prime https://charts.rancher.com/server-charts/prime
helm repo update
helm install rancher rancher-prime/rancher \
  --namespace cattle-system \
  --create-namespace \
  --set hostname=<DNS or sslip from above> \
  --set replicas=1 \
  --set bootstrapPassword=<PASSWORD_FOR_RANCHER_ADMIN> \
  --version 2.11.2

Nota

Se a finalidade do sistema é de produção, use o cert-manager para configurar um certificado real (como aquele da Let’s Encrypt).

Procure o nome de host que você configurou e faça login no Rancher com a bootstrapPassword usada. Você será guiado por um curto processo de configuração.

Com o Rancher instalado, agora você pode instalar o operador Elemental e as CRDs necessárias. O gráfico Helm do Elemental foi publicado como um artefato OCI, portanto, a instalação é um pouco mais simples do que a dos outros gráficos. É possível instalá-lo do mesmo shell usado para instalar o Rancher ou no navegador dentro do shell do Rancher.

helm install --create-namespace -n cattle-elemental-system \
 elemental-operator-crds \
 oci://registry.suse.com/rancher/elemental-operator-crds-chart \
 --version 1.6.8

helm install -n cattle-elemental-system \
 elemental-operator \
 oci://registry.suse.com/rancher/elemental-operator-chart \
 --version 1.6.8

Para simplificar, recomendamos definir a variável $ELEM como o caminho completo do local desejado para o diretório de configuração:

export ELEM=$HOME/elemental
mkdir -p $ELEM

Para que as máquinas sejam registradas no Elemental, precisamos criar um objeto MachineRegistration no namespace fleet-default.

Vamos criar uma versão básica desse objeto:

cat << EOF > $ELEM/registration.yaml
apiVersion: elemental.cattle.io/v1beta1
kind: MachineRegistration
metadata:
  name: ele-quickstart-nodes
  namespace: fleet-default
spec:
  machineName: "\${System Information/Manufacturer}-\${System Information/UUID}"
  machineInventoryLabels:
    manufacturer: "\${System Information/Manufacturer}"
    productName: "\${System Information/Product Name}"
EOF

kubectl apply -f $ELEM/registration.yaml

Nota

O comando cat insere um caractere de escape de barra (\) para cada $ para que o Bash não os utilize como gabarito. Remova as barras se estiver copiando manualmente.

Depois que o objeto é criado, encontre e observe o endpoint que foi atribuído:

REGISURL=$(kubectl get machineregistration ele-quickstart-nodes -n fleet-default -o jsonpath='{.status.registrationURL}')

Você também pode fazer isso pela IU.

A versão atual do Elemental conta com um método para criar a própria mídia de instalação. No SUSE Edge 3.3.1, fazemos isso com o Kiwi e o Edge Image Builder, portanto, o sistema resultante é desenvolvido com o SUSE Linux Micro como o sistema operacional de base.

Dica

Para saber mais detalhes sobre o Kiwi, siga o processo do construtor de imagens do Kiwi (Capítulo 28, Criando imagens atualizadas do SUSE Linux Micro com o Kiwi) para primeiro criar novas imagens e, para o Edge Image Builder, consulte o Guia de Introdução do Edge Image Builder (Capítulo 3, Clusters independentes com o Edge Image Builder) e também a documentação do componente (Capítulo 11, Edge Image Builder).

Em um sistema Linux com o Podman instalado, crie os diretórios e insira a imagem base criada pelo Kiwi:

mkdir -p $ELEM/eib_quickstart/base-images
cp /path/to/{micro-base-image-iso} $ELEM/eib_quickstart/base-images/
mkdir -p $ELEM/eib_quickstart/elemental

curl $REGISURL -o $ELEM/eib_quickstart/elemental/elemental_config.yaml

cat << EOF > $ELEM/eib_quickstart/eib-config.yaml
apiVersion: 1.2
image:
    imageType: iso
    arch: x86_64
    baseImage: SL-Micro.x86_64-6.1-Base-SelfInstall-GM.install.iso
    outputImageName: elemental-image.iso
operatingSystem:
  time:
    timezone: Europe/London
    ntp:
      forceWait: true
      pools:
        - 2.suse.pool.ntp.org
      servers:
        - 10.0.0.1
        - 10.0.0.2
  isoConfiguration:
    installDevice: /dev/vda
  users:
    - username: root
      encryptedPassword: \$6\$jHugJNNd3HElGsUZ\$eodjVe4te5ps44SVcWshdfWizrP.xAyd71CVEXazBJ/.v799/WRCBXxfYmunlBO2yp1hm/zb4r8EmnrrNCF.P/
  packages:
    sccRegistrationCode: XXX
EOF

Nota

• A seção time é opcional, mas sua configuração é altamente recomendada para evitar possíveis problemas com certificados e divergência de relógio. O valor usado neste exemplo é somente para fins ilustrativos. Ajuste-o de acordo com seus requisitos específicos.

• A senha não codificada é eib.

• O sccRegistrationCode é necessário para fazer download e instalar os RPMs exigidos das fontes oficiais (se preferir, faça sideload manual dos RPMs elemental-register e o elemental-system-agent ).

• O comando cat insere um caractere de escape de barra (\) para cada $ para que o Bash não os utilize como gabarito. Remova as barras se estiver copiando manualmente.

• O dispositivo de instalação será apagado durante a instalação.

podman run --privileged --rm -it -v $ELEM/eib_quickstart/:/eib \
 registry.suse.com/edge/3.3/edge-image-builder:1.2.1 \
 build --definition-file eib-config.yaml

Se você está inicializando um dispositivo físico, precisa gravar a imagem em uma unidade flash USB, o que pode ser feito com o comando:

sudo dd if=/eib_quickstart/elemental-image.iso of=/dev/<PATH_TO_DISK_DEVICE> status=progress

Agora que já criamos a mídia de instalação, podemos inicializar os nós downstream com ela.

Para cada um dos sistemas que você quer controlar usando o Elemental, adicione a mídia de instalação e inicialize o dispositivo. Após a instalação, ele será reinicializado e se registrará.

Se você usa a extensão de IU, deve ver o nó listado em "Inventory of Machines" (Inventário de máquinas).

Nota

Não remova o meio de instalação antes de ver o prompt de login. Durante a primeira inicialização, os arquivos ainda são acessados no dispositivo USB.

Precisamos criar dois objetos ao provisionar um novo cluster usando o Elemental.

Após a criação dos objetos, você deverá ver um novo cluster Kubernetes dar arranque (partida) usando o nó com o qual você acabou de instalar.

O SUSE Rancher Elemental permite executar uma "redefinição de nó", que pode ser acionada quando um cluster inteiro é excluído do Rancher, um único nó é excluído do cluster ou um nó é excluído manualmente do inventário de máquinas. Esse recurso é útil para redefinir e limpar recursos órfãos e recuperar automaticamente o nó limpo no inventário de máquinas para que possa ser reutilizado. Isso não está habilitado por padrão e, portanto, um sistema que foi removido não será limpo (ou seja, os dados não serão removidos, e os recursos do cluster Kubernetes continuarão operando nos clusters downstream), será necessária uma intervenção manual para limpar os dados e registrar a máquina novamente no Rancher pelo Elemental.

Para habilitar essa funcionalidade por padrão, você precisa garantir que o MachineRegistration a habilite explicitamente adicionando config.elemental.reset.enabled: true, por exemplo:

config:
  elemental:
    registration:
      auth: tpm
    reset:
      enabled: true

Na sequência, todos os sistemas registrados com esse MachineRegistration receberão automaticamente a anotação elemental.cattle.io/resettable: 'true' na respectiva configuração. Para fazer isso manualmente em nós individuais, por exemplo, porque obteve um MachineInventory existente que não tem essa anotação ou já implantou os nós, você pode modificar o MachineInventory e adicionar a configuração resettable, por exemplo:

apiVersion: elemental.cattle.io/v1beta1
kind: MachineInventory
metadata:
  annotations:
    elemental.cattle.io/os.unmanaged: 'true'
    elemental.cattle.io/resettable: 'true'

No SUSE Edge 3.1, o operador Elemental insere um marcador no sistema operacional que aciona o processo de limpeza automaticamente; ele interrompe todos os serviços do Kubernetes, remove todos os dados persistentes, desinstala todos os serviços do Kubernetes, limpa os diretórios restantes do Kubernetes/Rancher e força o novo registro no Rancher por meio da configuração original MachineRegistration do Elemental. Isso é feito automaticamente, não há necessidade de intervenção manual. O script chamado está disponível em /opt/edge/elemental_node_cleanup.sh e é acionado pelo systemd.path depois de inserir o marcador, portanto, sua execução é imediata.

Atenção

Com o uso do resettable, a funcionalidade assume que o comportamento desejado ao remover um nó/cluster do Rancher é limpar os dados e forçar um novo registro. A perda de dados é certa nessa situação, portanto, use essa funcionalidade apenas se tiver certeza de que deseja executar a redefinição automática.

Veja alguns recursos recomendados para pesquisa depois de usar este guia:

Como o EIB é executado dentro de um contêiner, precisamos montar um diretório de configuração do host, o que permite especificar a configuração desejada e, durante o processo de criação, o EIB tem o acesso aos arquivos de entrada necessários e artefatos auxiliares. Esse diretório deve seguir uma estrutura específica. Vamos criá-lo imaginando que ele existe em seu diretório pessoal com o nome "eib":

export CONFIG_DIR=$HOME/eib
mkdir -p $CONFIG_DIR/base-images

Na etapa anterior, criamos um diretório "base-images" que hospedará a imagem de entrada do SUSE Linux Micro 6.1. Vamos garantir que a imagem seja copiada para o diretório de configuração:

cp /path/to/SL-Micro.x86_64-6.1-Base-SelfInstall-GM.install.iso $CONFIG_DIR/base-images/slemicro.iso

Nota

Durante a execução do EIB, a imagem base original não é modificada. Uma versão nova e personalizada é criada com a configuração desejada na raiz do diretório de configuração do EIB.

Neste momento, o diretório de configuração deve ter a seguinte aparência:

└── base-images/
    └── slemicro.iso

O arquivo de definição descreve grande parte das opções configuráveis disponíveis no Edge Image Builder. Um exemplo completo das opções é apresentado aqui, e recomendamos que você leia o guia de imagens de criação upstream para ver exemplos mais detalhados do que vamos executar a seguir. Vamos começar com um arquivo de definição bem básico para a nossa imagem de sistema operacional:

cat << EOF > $CONFIG_DIR/iso-definition.yaml
apiVersion: 1.2
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
EOF

Essa definição especifica que estamos gerando uma imagem de saída para um sistema baseado em AMD64/Intel 64. A imagem que será usada como base para modificação posterior é uma imagem iso chamada slemicro.iso, que esperamos que esteja no local $CONFIG_DIR/base-images/slemicro.iso. Ela também descreve que, depois que o EIB terminar de modificar a imagem, a imagem de saída se chamará eib-image.iso e, por padrão, residirá em $CONFIG_DIR.

Agora a estrutura do nosso diretório deve ter esta aparência:

├── iso-definition.yaml
└── base-images/
    └── slemicro.iso

Nas seções a seguir, vamos analisar alguns exemplos de operações comuns:

3.3.1 Configurando usuários do sistema operacional #

 

O EIB permite pré-configurar usuários com informações de login, como senhas ou chaves SSH, incluindo a definição de uma senha de root fixa. Como parte deste exemplo, vamos corrigir a senha de root, e o primeiro passo é usar o OpenSSL para criar uma senha criptografada unidirecional:

openssl passwd -6 SecurePassword

A saída será semelhante a esta:

$6$G392FCbxVgnLaFw1$Ujt00mdpJ3tDHxEg1snBU3GjujQf6f8kvopu7jiCBIhRbRvMmKUqwcmXAKggaSSKeUUOEtCP3ZUoZQY7zTXnC1

Em seguida, podemos adicionar uma seção chamada operatingSystem ao arquivo de definição com uma matriz users dentro dela. O arquivo resultante terá esta aparência:

apiVersion: 1.2
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$G392FCbxVgnLaFw1$Ujt00mdpJ3tDHxEg1snBU3GjujQf6f8kvopu7jiCBIhRbRvMmKUqwcmXAKggaSSKeUUOEtCP3ZUoZQY7zTXnC1

Nota

É possível também adicionar outros usuários, criar diretórios pessoais, definir IDs de usuário, adicionar autenticação por chave SSH e modificar informações de grupo. Consulte o guia de criação de imagens upstream para ver mais exemplos.

3.3.2 Configurando o horário do sistema operacional #

 

A seção time é opcional, mas sua configuração é altamente recomendada para evitar possíveis problemas com certificados e divergência do relógio. O EIB configura o chronyd e o /etc/localtime dependendo desses parâmetros.

operatingSystem:
  time:
    timezone: Europe/London
    ntp:
      forceWait: true
      pools:
        - 2.suse.pool.ntp.org
      servers:
        - 10.0.0.1
        - 10.0.0.2

• O timezone especifica o fuso horário no formato "região/localidade" (por exemplo, "Europa/Londres"). É possível ver a lista completa executando o comando timedatectl list-timezones no sistema Linux.

• ntp: define atributos relacionados à configuração do NTP (usando o chronyd).

• forceWait: solicita que o chronyd tente sincronizar as fontes de horário antes de iniciar outros serviços, com um tempo limite de 180 segundos.

• pools: especifica uma lista de pools que o chronyd usará como fontes de dados (usando o iburst para melhorar o tempo gasto na sincronização inicial).

• servers: especifica uma lista de servidores que o chronyd usará como fontes de dados (usando o iburst para melhorar o tempo gasto na sincronização inicial).

Nota

Os valores apresentados neste exemplo são apenas para fins ilustrativos. Ajuste-os de acordo com seus requisitos específicos.

.
├── definition.yaml
└── certificates
    ├── my-ca.pem
    └── my-ca.crt

3.3.4 Configurando pacotes RPM #

 

Um dos principais recursos do EIB é o mecanismo para adicionar outros pacotes de software à imagem, dessa forma, o sistema pode aproveitar os pacotes instalados assim que a instalação é concluída. O EIB permite que os usuários especifiquem o seguinte:

• Pacotes por nome em uma lista na definição da imagem

• Repositórios de rede nos quais pesquisar os pacotes

• Credenciais do SUSE Customer Center (SCC) para pesquisar os pacotes listados em repositórios oficiais da SUSE

• Por um diretório $CONFIG_DIR/rpms, fazer sideload dos RPMs personalizados que não existem nos repositórios de rede

• Pelo mesmo diretório ($CONFIG_DIR/rpms/gpg-keys), chaves GPG para habilitar a validação de pacotes de terceiros

Em seguida, o EIB é executado por um processo de resolução de pacote no momento da criação da imagem, usando a imagem base como entrada, e tenta obter e instalar todos os pacotes fornecidos, especificados pela lista ou fornecidos localmente. O EIB faz download de todos os pacotes, incluindo as dependências, em um repositório existente na imagem de saída, e instrui o sistema a instalá-los durante o processo da primeira inicialização. A execução desse processo durante a criação da imagem garante que os pacotes sejam devidamente instalados na plataforma desejada, por exemplo, o nó de borda, durante a primeira inicialização. Isso também é vantajoso em ambientes nos quais você deseja fazer bake dos pacotes adicionais na imagem, em vez de extraí-los pela rede durante a operação, por exemplo, em ambientes air-gapped ou de rede restrita.

Como um exemplo simples para demonstrar esse procedimento, vamos instalar o pacote RPM nvidia-container-toolkit encontrado no repositório NVIDIA mantido por fornecedor terceirizado:

  packages:
    packageList:
      - nvidia-container-toolkit
    additionalRepos:
      - url: https://nvidia.github.io/libnvidia-container/stable/rpm/x86_64

O arquivo de definição resultante terá esta aparência:

apiVersion: 1.2
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$G392FCbxVgnLaFw1$Ujt00mdpJ3tDHxEg1snBU3GjujQf6f8kvopu7jiCBIhRbRvMmKUqwcmXAKggaSSKeUUOEtCP3ZUoZQY7zTXnC1
  packages:
    packageList:
      - nvidia-container-toolkit
    additionalRepos:
      - url: https://nvidia.github.io/libnvidia-container/stable/rpm/x86_64

O exemplo acima é simples, mas para uma totalidade, faça download da chave de assinatura do pacote NVIDIA antes de gerar a imagem:

$ mkdir -p $CONFIG_DIR/rpms/gpg-keys
$ curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey > $CONFIG_DIR/rpms/gpg-keys/nvidia.gpg

Atenção

A adição de outros RPMs por esse método tem como objetivo incluir componentes de terceiros compatíveis ou pacotes fornecidos (e mantidos) pelo usuário. Esse mecanismo não deve ser usado para adicionar pacotes que não costumam ser suportados no SUSE Linux Micro. Se ele for usado para adicionar componentes de repositórios openSUSE (que não são suportados), inclusive de versões ou pacotes de serviço mais recentes, você poderá acabar com um configuração sem suporte, principalmente quando a resolução de dependência resulta na substituição de partes importantes do sistema operacional, mesmo que o sistema resultante pareça funcionar conforme o esperado. Se você tiver qualquer dúvida, entre em contato com seu representante SUSE para obter ajuda para determinar se a configuração desejada é suportada.

Nota

Um guia mais completo com exemplos adicionais está disponível no guia de instalação de pacotes upstream.

3.3.5 Configurando o cluster Kubernetes e as cargas de trabalho dos usuários #

 

Outro recurso do EIB é a capacidade de usá-lo para automatizar a implantação de clusters Kubernetes altamente disponíveis, tanto de nó único quanto de vários nós, que são "inicializados no local" (ou seja, não exigem a coordenação de nenhuma forma de infraestrutura de gerenciamento centralizado). O principal motivador dessa abordagem são as implantações air-gapped, ou ambientes de rede restrita, mas ela também é útil para inicializar rapidamente clusters independentes, mesmo com acesso à rede total e irrestrito disponível.

Com esse método, é possível implantar o sistema operacional personalizado e especificar a configuração do Kubernetes, componentes adicionais em camadas por gráficos Helm e cargas de trabalho de usuários por manifestos fornecidos pelo Kubernetes. No entanto, o princípio do projeto por trás do uso desse método é que já consideramos que o usuário deseja se desconectar e, portanto, os itens especificados na definição da imagem serão inseridos na imagem, o que inclui as cargas de trabalho fornecidas pelo usuário. O EIB garantirá que todas as imagens descobertas necessárias, conforme as definições especificadas, sejam copiadas localmente e enviadas pelo registro de imagens incorporado ao sistema implantado resultante.

Neste exemplo, vamos usar nossa definição de imagem existente e especificar uma configuração do Kubernetes (não há uma lista dos sistemas e suas funções, portanto, vamos considerar um nó único), que vai instruir o EIB a provisionar um cluster Kubernetes RKE2 de nó único. Para mostrar a automação da implantação das cargas de trabalho fornecidas pelo usuário (por manifesto) e dos componentes em camadas (por Helm), vamos instalar o KubeVirt por meio do gráfico Helm do SUSE Edge e o NGINX por meio de um manifesto do Kubernetes. A configuração adicional que precisamos para anexar a definição da imagem existente é:

kubernetes:
  version: v1.32.4+rke2r1
  manifests:
    urls:
      - https://k8s.io/examples/application/nginx-app.yaml
  helm:
    charts:
      - name: kubevirt
        version: 303.0.0+up0.5.0
        repositoryName: suse-edge
    repositories:
      - name: suse-edge
        url: oci://registry.suse.com/edge/charts

O arquivo de definição completo resultante agora tem esta aparência:

apiVersion: 1.2
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$G392FCbxVgnLaFw1$Ujt00mdpJ3tDHxEg1snBU3GjujQf6f8kvopu7jiCBIhRbRvMmKUqwcmXAKggaSSKeUUOEtCP3ZUoZQY7zTXnC1
  packages:
    packageList:
      - nvidia-container-toolkit
    additionalRepos:
      - url: https://nvidia.github.io/libnvidia-container/stable/rpm/x86_64
kubernetes:
  version: v1.32.4+k3s1
  manifests:
    urls:
      - https://k8s.io/examples/application/nginx-app.yaml
  helm:
    charts:
      - name: kubevirt
        version: 303.0.0+up0.5.0
        repositoryName: suse-edge
    repositories:
      - name: suse-edge
        url: oci://registry.suse.com/edge/charts

Nota

Há outros exemplos de opções, como implantações de vários nós, rede personalizada e opções/valores do gráfico Helm, disponíveis na documentação upstream.

3.3.6 Configurando a rede #

 

No último exemplo deste início rápido, vamos configurar a rede que será criada quando um sistema for provisionado com a imagem gerada pelo EIB. É importante entender que, exceto se uma configuração de rede for especificada, o DHCP usará o modelo padrão em todas as interfaces descobertas no momento da inicialização. No entanto, ela nem sempre é a configuração desejada, principalmente se o DHCP não estiver disponível e você precisar fazer configurações estáticas, configurar estruturas de rede mais complexas, como vínculos, LACP e VLANs, ou substituir determinados parâmetros, por exemplo, nomes de host, servidores DNS e rotas.

O EIB permite fazer configurações por nó (em que o sistema em questão é identificado exclusivamente por seu endereço MAC) ou uma substituição para especificar uma configuração idêntica para cada máquina, o que é mais útil quando não se sabe os endereços MAC do sistema. O EIB usa uma ferramenta adicional chamada Network Manager Configurator, ou nmc na forma abreviada, que foi desenvolvida pela equipe do SUSE Edge para que a configuração de rede personalizada seja aplicada com base no esquema de rede declarativo nmstate.io e, no momento da inicialização, identificará o nó em que está sendo inicializado e aplicará a configuração de rede desejada antes da ativação de quaisquer serviços.

Agora vamos aplicar uma configuração de rede estática a um sistema com uma interface única descrevendo o estado desejado da rede em um arquivo específico do nó (com base no nome de host desejado) no diretório network exigido:

mkdir $CONFIG_DIR/network

cat << EOF > $CONFIG_DIR/network/host1.local.yaml
routes:
  config:
  - destination: 0.0.0.0/0
    metric: 100
    next-hop-address: 192.168.122.1
    next-hop-interface: eth0
    table-id: 254
  - destination: 192.168.122.0/24
    metric: 100
    next-hop-address:
    next-hop-interface: eth0
    table-id: 254
dns-resolver:
  config:
    server:
    - 192.168.122.1
    - 8.8.8.8
interfaces:
- name: eth0
  type: ethernet
  state: up
  mac-address: 34:8A:B1:4B:16:E7
  ipv4:
    address:
    - ip: 192.168.122.50
      prefix-length: 24
    dhcp: false
    enabled: true
  ipv6:
    enabled: false
EOF

Atenção

O exemplo acima foi configurado para a sub-rede padrão 192.168.122.0/24 considerando que o teste é executado em uma máquina virtual. Adapte-o de acordo com o seu ambiente, lembrando do endereço MAC. Como é possível usar a mesma imagem para provisionar vários nós, a rede configurada pelo EIB (via nmc) depende da capacidade de identificar exclusivamente o nó por seu endereço MAC. Como resultado, durante a inicialização, o nmc aplicará a configuração de rede correta a cada máquina. Isso significa que você precisa saber os endereços MAC dos sistemas nos quais deseja instalar. Como alternativa, o comportamento padrão é confiar no DHCP, mas você pode usar o gancho configure-network.sh para aplicar uma configuração comum a todos os nós. Consulte o guia de rede (Capítulo 12, Rede de borda) para obter mais detalhes.

A estrutura do arquivo resultante deverá ter esta aparência:

├── iso-definition.yaml
├── base-images/
│   └── slemicro.iso
└── network/
    └── host1.local.yaml

A configuração de rede que acabamos de criar será analisada, e os arquivos de conexão necessários do NetworkManager serão automaticamente gerados e inseridos na nova imagem de instalação que o EIB criará. Esses arquivos serão aplicados durante o provisionamento do host, resultando na configuração de rede completa.

Nota

Consulte o componente de rede de borda (Capítulo 12, Rede de borda) para ver uma explicação mais abrangente da configuração acima e exemplos desse recurso.

Agora que temos uma imagem base e uma definição da imagem para o EIB usar, vamos criar a imagem. Para isso, simplesmente usaremos o podman para chamar o contêiner do EIB com o comando "build", especificando o arquivo de definição:

podman run --rm -it --privileged -v $CONFIG_DIR:/eib \
registry.suse.com/edge/3.3/edge-image-builder:1.2.1 \
build --definition-file iso-definition.yaml

A saída do comando deve ter esta aparência:

Setting up Podman API listener...
Downloading file: dl-manifest-1.yaml 100% (498/498 B, 9.5 MB/s)
Pulling selected Helm charts... 100% (1/1, 43 it/min)
Generating image customization components...
Identifier ................... [SUCCESS]
Custom Files ................. [SKIPPED]
Time ......................... [SKIPPED]
Network ...................... [SUCCESS]
Groups ....................... [SKIPPED]
Users ........................ [SUCCESS]
Proxy ........................ [SKIPPED]
Resolving package dependencies...
Rpm .......................... [SUCCESS]
Os Files ..................... [SKIPPED]
Systemd ...................... [SKIPPED]
Fips ......................... [SKIPPED]
Elemental .................... [SKIPPED]
Suma ......................... [SKIPPED]
Populating Embedded Artifact Registry... 100% (3/3, 10 it/min)
Embedded Artifact Registry ... [SUCCESS]
Keymap ....................... [SUCCESS]
Configuring Kubernetes component...
The Kubernetes CNI is not explicitly set, defaulting to 'cilium'.
Downloading file: rke2_installer.sh
Downloading file: rke2-images-core.linux-amd64.tar.zst 100% (657/657 MB, 48 MB/s)
Downloading file: rke2-images-cilium.linux-amd64.tar.zst 100% (368/368 MB, 48 MB/s)
Downloading file: rke2.linux-amd64.tar.gz 100% (35/35 MB, 50 MB/s)
Downloading file: sha256sum-amd64.txt 100% (4.3/4.3 kB, 6.2 MB/s)
Kubernetes ................... [SUCCESS]
Certificates ................. [SKIPPED]
Cleanup ...................... [SKIPPED]
Building ISO image...
Kernel Params ................ [SKIPPED]
Build complete, the image can be found at: eib-image.iso

A imagem ISO criada é armazenada em $CONFIG_DIR/eib-image.iso:

├── iso-definition.yaml
├── eib-image.iso
├── _build
│   └── cache/
│       └── ...
│   └── build-<timestamp>/
│       └── ...
├── base-images/
│   └── slemicro.iso
└── network/
    └── host1.local.yaml

Cada build cria uma pasta com marcação de data e hora em $CONFIG_DIR/_build/, que inclui os registros do build, os artefatos usados durante o build e os diretórios combustion e artefacts com todos os scripts e artefatos adicionados à imagem CRB.

O conteúdo do diretório deve ter esta aparência:

├── build-<timestamp>/
│   │── combustion/
│   │   ├── 05-configure-network.sh
│   │   ├── 10-rpm-install.sh
│   │   ├── 12-keymap-setup.sh
│   │   ├── 13b-add-users.sh
│   │   ├── 20-k8s-install.sh
│   │   ├── 26-embedded-registry.sh
│   │   ├── 48-message.sh
│   │   ├── network/
│   │   │   ├── host1.local/
│   │   │   │   └── eth0.nmconnection
│   │   │   └── host_config.yaml
│   │   ├── nmc
│   │   └── script
│   │── artefacts/
│   │   │── registry/
│   │   │   ├── hauler
│   │   │   ├── nginx:<version>-registry.tar.zst
│   │   │   ├── rancher_kubectl:<version>-registry.tar.zst
│   │   │   └── registry.suse.com_suse_sles_15.6_virt-operator:<version>-registry.tar.zst
│   │   │── rpms/
│   │   │   └── rpm-repo
│   │   │       ├── addrepo0
│   │   │       │   ├── nvidia-container-toolkit-<version>.rpm
│   │   │       │   ├── nvidia-container-toolkit-base-<version>.rpm
│   │   │       │   ├── libnvidia-container1-<version>.rpm
│   │   │       │   └── libnvidia-container-tools-<version>.rpm
│   │   │       ├── repodata
│   │   │       │   ├── ...
│   │   │       └── zypper-success
│   │   └── kubernetes/
│   │       ├── rke2_installer.sh
│   │       ├── registries.yaml
│   │       ├── server.yaml
│   │       ├── images/
│   │       │   ├── rke2-images-cilium.linux-amd64.tar.zst
│   │       │   └── rke2-images-core.linux-amd64.tar.zst
│   │       ├── install/
│   │       │   ├── rke2.linux-amd64.tar.gz
│   │       │   └── sha256sum-amd64.txt
│   │       └── manifests/
│   │           ├── dl-manifest-1.yaml
│   │           └── kubevirt.yaml
│   ├── createrepo.log
│   ├── eib-build.log
│   ├── embedded-registry.log
│   ├── helm
│   │   └── kubevirt
│   │       └── kubevirt-0.4.0.tgz
│   ├── helm-pull.log
│   ├── helm-template.log
│   ├── iso-build.log
│   ├── iso-build.sh
│   ├── iso-extract
│   │   └── ...
│   ├── iso-extract.log
│   ├── iso-extract.sh
│   ├── modify-raw-image.sh
│   ├── network-config.log
│   ├── podman-image-build.log
│   ├── podman-system-service.log
│   ├── prepare-resolver-base-tarball-image.log
│   ├── prepare-resolver-base-tarball-image.sh
│   ├── raw-build.log
│   ├── raw-extract
│   │   └── ...
│   └── resolver-image-build
│       └──...
└── cache
    └── ...

Se houver falha no build, eib-build.log será o primeiro registro com as informações. A partir disso, ele vai direcionar você para o componente com falha para depuração.

Neste ponto, você deve ter uma imagem pronta para uso que:

Se o processo de criação da imagem falhar, consulte o guia de depuração upstream.

Para obter instruções de como testar a imagem CRB recém-criada, consulte o guia de teste de imagem upstream.

Se você já tem uma instância da versão mais recente do SUSE Multi-Linux Manager 5.0 em execução, pode ignorar esta etapa.

Você pode executar o SUSE Multi-Linux Manager Server em um servidor físico dedicado, como uma máquina virtual em seu próprio hardware, ou na nuvem. São fornecidas imagens pré-configuradas da máquina virtual para o SUSE Multi-Linux Server para nuvens públicas suportadas.

Neste início rápido, usamos a imagem "qcow2" SUSE-Manager-Server.x86_64-5.0.2-Qcow-2024.12.qcow2 para AMD64/Intel 64, que você encontra em https://www.suse.com/download/suse-manager/ ou no SUSE Customer Center. Essa imagem funciona como uma máquina virtual em hipervisores do tipo KVM. Verifique e use sempre a versão mais recente da imagem para novas instalações.

Você também pode instalar o SUSE Multi-Linux Manager Server em qualquer outra arquitetura de hardware compatível. Nesse caso, escolha a imagem correspondente à arquitetura.

Depois de fazer download da imagem, crie uma máquina virtual que atenda pelo menos às seguintes especificações mínimas de hardware:

Com a imagem qcow2, não há necessidade de instalar o sistema operacional. É possível anexar a imagem diretamente como a partição raiz.

Configure a rede para que os nós de borda possam acessar o SUSE Multi-Linux Manager Server posteriormente com um nome de host que inclua o nome de domínio completo e qualificado ("FQDN", Fully Qualified Domain Name)!

Quando você inicializa o SUSE Multi-Linux Manager pela primeira vez, precisa fazer algumas configurações iniciais:

As etapas seguintes precisam ser realizas como usuário "root":

Para a etapa seguinte, são necessários dois códigos de registro, que você encontra no SUSE Customer Center:

Registre o SUSE Linux Micro:

transactional-update register -r <REGCODE> -e <your_email>

Registre o SUSE Multi-Linux Manager:

transactional-update register -p SUSE-Manager-Server/5.0/x86_64 -r <REGCODE>

A string do produto depende da arquitetura de hardware. Por exemplo, se você usa o SUSE Multi-Linux Manager em um sistema Arm de 64 bits, a string é "SUSE-Manager-Server/5.0/aarch64".

Reinicializar

Atualize o sistema:

transactional-update

Reinicialize para aplicar as atualizações (se houver).

O SUSE Multi-Linux Manager é oferecido por um contêiner gerenciado pelo Podman. O comando mgradm cuida da instalação e da configuração para você.

Atenção

É muito importante configurar o nome de host no SUSE Multi-Linux Manager Server com um nome de domínio completo e qualificado ("FQDN", Fully Qualified Domain Name) que os nós de borda que você deseja gerenciar possam resolver apropriadamente na rede!

Antes de instalar e configurar o contêiner do SUSE Multi-Linux Manager Server, você precisa preparar o dispositivo de blocos adicional que já incluiu. Para isso, é necessário saber o nome que a máquina virtual atribuiu ao dispositivo. Por exemplo, se o dispositivos de blocos é /dev/vdb, configure-o para uso no SUSE Multi-Linux Manager executando o seguinte comando:

mgr-storage-server /dev/vdb

Implante o SUSE Multi-Linux Manager:

mgradm install podman <FQDN>

Insira a senha para o certificado de CA. Essa senha deve ser diferente das suas senhas de login. Em geral, você não precisa inseri-la posteriormente, mas é bom anotá-la.

Insira a senha do usuário "admin". Esse é o usuário inicial para fazer login no SUSE Multi-Linux Manager. Você pode criar outros usuários com direitos completos ou restritos no futuro.

Após a conclusão da implantação, faça login na IU da web do SUSE Multi-Linux Manager usando o nome de host que você já forneceu. O usuário inicial é "admin". Use a senha informada na etapa anterior.

Para a etapa seguinte, você precisa das credenciais da sua organização, que estão na segunda subguia da guia "Usuários" da organização no SUSE Customer Center. Com essas credenciais, o SUSE Multi-Linux Manager pode sincronizar todos os produtos que você assinou.

Selecione Admin › Assistente de configuração.

Na guia Credenciais da Organização, crie uma nova credencial com seu Nome de usuário e Senha que constam no SUSE Customer Center.

Vá para a guia seguinte Produtos SUSE. Aguarde o término da primeira sincronização de dados com o SUSE Customer Center.

Depois que a lista for preenchida, use o filtro para mostrar apenas "Micro 6". Marque a caixa do SUSE Linux Micro 6.1 relativa à arquitetura de hardware em que seus nós de borda serão executados (x86_64 ou aarch64).

Clique em Adicionar produtos para adicionar o repositório ("canal") de pacotes principal do SUSE Linux Micro e, automaticamente, o canal para as ferramentas do cliente SUSE Manager como um subcanal.

Dependendo da sua conexão com a Internet, a primeira sincronização levará algum tempo. Você já pode iniciar as etapas seguintes:

Em Sistemas > Grupos do Sistema, crie pelo menos um grupo em que seus sistemas ingressarão quando forem integrados. Os grupos são importantes para categorizar os sistemas de modo que você possa aplicar uma configuração ou ações a todo o conjunto de sistemas de uma vez. Por concepção, eles são similares aos rótulos no Kubernetes.

Clique em + Criar Grupo.

Insira um nome abreviado, por exemplo, "Nós de borda", e uma descrição longa.

Em Sistemas > Chaves de ativação, crie pelo menos uma chave de ativação. Pense nas chaves de ativação como perfis de configuração que são automaticamente aplicados aos sistemas depois de integrados ao SUSE Multi-Linux Manager. Para adicionar determinados nós de borda a grupos diferentes ou usar outra configuração, você pode criar chaves de ativação separadas para eles e usá-las no Edge Image Builder para criar uma mídia de instalação personalizada.

Um caso de uso avançado comum das chaves de ativação é para atribuir clusters de teste aos canais de software com as atualizações mais recentes, e os clusters de produção aos canais de software que apenas recebem essas atualizações mais recentes depois que você as testou no cluster de teste.

Clique em + Criar chave.

Escolha uma descrição resumida, por exemplo, "Nós de borda". Insira um nome exclusivo que identifique a chave, por exemplo, "edge-x86_64" para os nós de borda com arquitetura de hardware AMD64/Intel 64. Um prefixo de número é automaticamente adicionado à chave. Para a organização padrão, o número é sempre "1". Se você criar mais organizações no SUSE Multi-Linux Manager e gerar chaves para elas, esse número poderá ser diferente.

Se você não criou canais de software clonados, pode manter a configuração do canal base como "padrão do SUSE Manager". Isso atribui automaticamente o repositório de atualização correto do SUSE aos nós de borda.

Como "canal filho", selecione o controle deslizante para "incluir recomendações" referente à arquitetura de hardware para a qual a chave de ativação é usada. Dessa forma, o "SUSE-Manager-Tools-For-SL-Micro-6.1" será adicionado ao canal.

Na guia "Grupos", adicione o grupo criado. Todos os nós integrados por meio dessa chave de ativação serão automaticamente adicionados a esse grupo.

Para usar o Edge Image Builder, você precisa apenas de um ambiente para iniciar o contêiner baseado em Linux com o Podman.

Na verdade, para configuração mínima de laboratório, podemos usar a mesma máquina virtual na qual o SUSE Multi-Linux Manager Server está em execução. Verifique se você tem espaço em disco suficiente na máquina virtual! Essa configuração não é recomendada para uso em produção. Consulte a Seção 3.1, “Pré-requisitos” para saber quais sistemas operacionais host foram testados com o Edge Image Builder.

Faça login no host do SUSE Multi-Linux Manager Server como root.

Acesse o contêiner do Edge Image Builder:

podman pull registry.suse.com/edge/3.3/edge-image-builder:1.2.1

Crie o diretório /opt/eib e o subdiretório base-images:

mkdir -p /opt/eib/base-images

Neste início rápido, usamos a variante de "autoinstalação" da imagem do SUSE Linux Micro. Posteriormente, essa imagem poderá ser gravada em uma unidade removível USB física que você pode usar para instalação em servidores físicos. Se o servidor tem a opção de anexar remotamente as ISOs de instalação por um BMC (Baseboard Management Controller), você também pode adotar essa abordagem. Por fim, também é possível usar essa imagem com grande parte das ferramentas de virtualização.

Para pré-carregar a imagem diretamente em um nó físico ou iniciá-la de uma VM, você também pode usar a variante de imagem "bruta".

Você encontra essas imagens no SUSE Customer Center ou em https://www.suse.com/download/sle-micro/

Faça download ou copie a imagem SL-Micro.x86_64-6.1-Default-SelfInstall-GM.install.iso no diretório base-images e dê o nome "slemicro.iso" a ela.

A criação de imagens AArch64 em hosts de build baseados no Arm é uma prévia de tecnologia no SUSE Edge 3.3.1. É muito provável que ela funcione, mas ainda não tem suporte. Se você quer tentar, precisa ter o Podman em uma máquina Arm de 64 bits e substituir "x86_64" em todos os exemplos e trechos de código por "aarch64".

Em /opt/eib, crie um arquivo chamado iso-definition.yaml. Essa é a definição do seu build para o Edge Image Builder.

Este é um exemplo simples para instalar o SL Micro 6.1, definir uma senha de root e o mapa do teclado, iniciar a IU gráfica do Cockpit e registrar o nó no SUSE Multi-Linux Manager:

apiVersion: 1.0
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
  - username: root
    createHomeDir: true
    encryptedPassword: $6$aaBTHyqDRUMY1HAp$pmBY7.qLtoVlCGj32XR/Ogei4cngc3f4OX7fwBD/gw7HWyuNBOKYbBWnJ4pvrYwH2WUtJLKMbinVtBhMDHQIY0
  keymap: de
  systemd:
    enable:
      - cockpit.socket
  packages:
    noGPGCheck: true
  suma:
    host: ${fully qualified hostname of your SUSE Multi-Linux Manager Server}
    activationKey: 1-edge-x86_64

O Edge Image Builder também configura a rede, instala automaticamente o Kubernetes no nó e até implanta aplicativos por gráficos Helm. Consulte o Capítulo 3, Clusters independentes com o Edge Image Builder para ver exemplos mais completos.

Para baseImage, especifique o nome real da ISO no diretório base-images que deseja usar.

Neste exemplo, a senha de root é "root". Consulte a Seção 3.3.1, “Configurando usuários do sistema operacional” para criar um hash para a senha segura que deseja usar.

Defina o mapa do teclado com o layout desejado para o sistema após a instalação.

Nota

Usamos a opção noGPGCheck: true porque não vamos fornecer uma chave GPG para verificar pacotes RPM. Um guia completo com uma configuração mais segura recomendada para uso em produção está disponível no guia de instalação de pacotes upstream.

Como já foi mencionado várias vezes, o host do SUSE Multi-Linux Manager exige um nome de host completo e qualificado que possa ser resolvido na rede em que os nós de borda serão inicializados.

O valor de activationKey precisa corresponder à chave que você criou no SUSE Multi-Linux Manager.

Para criar uma imagem de instalação que registre automaticamente os nós de borda no SUSE Multi-Linux Manager após a instalação, você também precisa preparar dois artefatos:

curl -O http://${HOSTNAME_OF_SUSE_MANAGER}/pub/repositories/slmicro/6/1/bootstrap/x86_64/venv-salt-minion-3006.0-3.1.x86_64.rpm

Em /opt/eib, crie o subdiretório certificates.

Faça download do certificado de CA do SUSE Multi-Linux Manager para esse diretório:

curl -O http://${HOSTNAME_OF_SUSE_MANAGER}/pub/RHN-ORG-TRUSTED-SSL-CERT

Atenção

Você deve renomear o certificado para RHN-ORG-TRUSTED-SSL-CERT.crt. Depois disso, o Edge Image Builder garantirá que ele seja instalado e ativado no nó de borda durante a instalação.

Agora execute o Edge Image Builder:

cd /opt/eib
podman run --rm -it --privileged -v /opt/eib:/eib \
registry.suse.com/edge/3.3/edge-image-builder:1.2.1 \
build --definition-file iso-definition.yaml

Se você usou outro nome para o arquivo de definição YAML e quer usar uma versão diferente do Edge Image Builder, precisa adaptar o comando de acordo.

Após o término da criação, a ISO de instalação estará no diretório /opt/eib como eib-image.iso.

O Rancher oferece várias funcionalidades importantes para a pilha do SUSE Edge:

O SUSE Edge usa o Capítulo 11, Edge Image Builder para personalizar as imagens base do sistema operacional SUSE Linux Micro. Leia a Seção 27.6, “Instalação do Rancher” para instalação air-gapped do Rancher em clusters Kubernetes provisionados pelo EIB.

Todos os componentes do SUSE Edge 3.3.1, incluindo as extensões de dashboard, são distribuídos como artefatos OCI. Para instalar as extensões do SUSE Edge, você pode usar a IU do Rancher Dashboard, o Helm ou o Fleet:

6.1.2 Instalando com o Helm #

 

# KubeVirt extension
helm install kubevirt-dashboard-extension oci://registry.suse.com/edge/charts/kubevirt-dashboard-extension --version 303.0.2+up1.3.2 --namespace cattle-ui-plugin-system

# Akri extension
helm install akri-dashboard-extension oci://registry.suse.com/edge/charts/akri-dashboard-extension --version 303.0.2+up1.3.1 --namespace cattle-ui-plugin-system

Nota

É preciso instalar as extensões no namespace cattle-ui-plugin-system.

Nota

Após a instalação de uma extensão, a IU do Rancher Dashboard deverá ser recarregada.

6.1.3 Instalando com o Fleet #

 

A instalação de extensões de dashboard com o Fleet requer a definição de um recurso gitRepo que aponte para um repositório Git com um ou mais arquivos de configuração de bundle fleet.yaml personalizados.

# KubeVirt extension fleet.yaml
defaultNamespace: cattle-ui-plugin-system
helm:
  releaseName: kubevirt-dashboard-extension
  chart: oci://registry.suse.com/edge/charts/kubevirt-dashboard-extension
  version: "303.0.2+up1.3.2"

# Akri extension fleet.yaml
defaultNamespace: cattle-ui-plugin-system
helm:
  releaseName: akri-dashboard-extension
  chart: oci://registry.suse.com/edge/charts/akri-dashboard-extension
  version: "303.0.2+up1.3.1"

Nota

A propriedade releaseName é necessária e precisa corresponder ao nome da extensão para instalá-la corretamente.

cat <<- EOF | kubectl apply -f -
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: edge-dashboard-extensions
  namespace: fleet-local
spec:
  repo: https://github.com/suse-edge/fleet-examples.git
  branch: main
  paths:
  - fleets/kubevirt-dashboard-extension/
  - fleets/akri-dashboard-extension/
EOF

Para obter mais informações, consulte o Capítulo 8, Fleet e o repositório fleet-examples.

Após a instalação das extensões, elas serão listadas na seção Extensions (Extensões) nas guias Installed (Instaladas). Como não são instaladas via Apps/Marketplace, elas são marcadas com o rótulo Third-Party (Terceiros).

A extensão KubeVirt fornece gerenciamento de máquinas virtuais básicas para a IU do Rancher Dashboard. Seus recursos estão descrito na Seção 21.7.2, “Usando a extensão KubeVirt do Rancher Dashboard”.

Akri é uma interface de recursos do Kubernetes que permite expor facilmente dispositivos folha heterogêneos (por exemplo, câmeras IP e dispositivos USB) como recursos em um cluster Kubernetes, além de oferecer suporte à exposição de recursos de hardware incorporados, como GPUs e FPGAs. A Akri detecta continuamente os nós com acesso a esses dispositivos e programa as cargas de trabalho com base neles.

Com a extensão de dashboard Akri, você pode usar a interface de usuário do Rancher Dashboard para gerenciar e monitorar dispositivos folha e executar cargas de trabalho após a descoberta desses dispositivos.

Há uma descrição mais detalhada dos recursos da extensão na Seção 14.5, “Extensão Akri do Rancher Dashboard”.

A pilha do SUSE Edge oferece um gráfico Helm agrupador que instala o Rancher Turtles com uma configuração específica que habilita:

Há suporte apenas para os provedores padrão instalados pelo gráfico agrupador. Os provedores alternativos de plano de controle, inicialização e infraestrutura não são suportados atualmente como parte da pilha do SUSE Edge.

É possível instalar o Rancher Turtles seguindo o Guia de Início Rápido do Metal3 (Capítulo 1, Implantações automatizadas de BMC com Metal³) ou a documentação do cluster de gerenciamento (Capítulo 40, Configurando o cluster de gerenciamento).

O Fleet está incorporado ao Rancher, mas também é possível instalá-lo como aplicativo independente em qualquer cluster Kubernetes que usa o Helm.

O Rancher usa o Fleet para implantar aplicativos em clusters gerenciados. A entrega contínua com o Fleet introduz o GitOps em escala, o que foi projetado para gerenciar aplicativos executados em uma grande quantidade de clusters.

O Fleet se destaca como parte integrante do Rancher. O agente Fleet é automaticamente implantado em clusters gerenciados com o Rancher, como parte do processo de instalação/importação, e o cluster fica imediatamente disponível para gerenciamento pelo Fleet.

O Fleet vem pré-instalado no Rancher e é gerenciado pela opção Continuous Delivery (Entrega contínua) na IU do Rancher.

A seção Continuous Delivery (Entrega contínua) consiste nos seguintes itens:

A seção de navegação "Advanced" (Avançado) apresenta visões gerais dos recursos do Fleet de nível mais baixo. Bundle é um recurso interno usado para orquestração dos recursos do Git. Quando um repositório Git é verificado, ele gera um ou mais bundles.

Para localizar os bundles relevantes a um repositório específico, vá até a página de detalhes do repositório Git e clique na guia Bundles.

Para cada cluster, o bundle é aplicado a um recurso BundleDeployment que foi criado. Para ver os detalhes do BundleDeployment, clique no botão Graph (Gráfico) na parte superior direita da página de detalhes do repositório Git. É carregado um gráfico de Repo > Bundles > BundleDeployments (Repositório > Bundles > BundleDeployments). Clique no BundleDeployment no gráfico para ver seus detalhes e clique no Id para conferir o YAML do BundleDeployment.

Para obter informações adicionais com dicas de solução de problemas no Fleet, acesse aqui.

A equipe do Edge mantém um repositório com exemplos de instalação de projetos do Edge com o Fleet.

O projeto do Fleet inclui o repositório fleet-examples que abrange todos os casos de uso da estrutura de repositório Git.

O SUSE Linux Micro é usado como o sistema operacional de base para a nossa pilha de plataforma. Desse modo, contamos com uma base segura, estável e mínima para criação.

O SUSE Linux Micro é exclusivo na questão do uso de instantâneos do sistema de arquivos (Btrfs) para facilitar as reversões se houver qualquer erro no upgrade. Esse recurso protege os upgrades remotos de toda a plataforma mesmo sem acesso físico em caso de problemas.

Este método é útil em cenários com hardware de destino que permite o gerenciamento fora da banda e quando se deseja um fluxo de gerenciamento de infraestrutura automatizado.

Esse método fornece APIs declarativas que permitem o gerenciamento de inventário e de estado dos servidores bare metal, incluindo inspeção, limpeza e provisionamento/desprovisionamento automatizados.

O SUSE Edge usa o EIB para configuração rápida e simplificada de imagens personalizadas do SUSE Linux Micro para diversos cenários, incluindo inicialização de máquinas virtuais e bare metal com:

A documentação completa sobre uso e teste do Edge Image Builder está disponível aqui.

Consulte também o Capítulo 3, Clusters independentes com o Edge Image Builder que apresenta um cenário de implantação básica.

Depois que você se familiarizar com a ferramenta, encontre mais informações úteis em nossa página de dicas de truques.

O NetworkManager é uma ferramenta que gerencia a conexão de rede principal e outras interfaces de conexão.

O NetworkManager armazena as configurações de rede como arquivos de conexão que contêm o estado desejado. Essas conexões são armazenadas como arquivos no diretório /etc/NetworkManager/system-connections/.

Os detalhes sobre o NetworkManager estão disponíveis na documentação do SUSE Linux Micro.

O nmstate é uma biblioteca muito usada (com uma ferramenta CLI auxiliar) que oferece uma API declarativa para configurações de rede usando um esquema predefinido.

Os detalhes sobre o nmstate estão disponíveis na documentação upstream.

As opções de personalização de rede no SUSE Edge são obtidas por uma ferramenta CLI chamada NetworkManager Configurator, ou nmc na forma abreviada, que aproveita a funcionalidade da biblioteca nmstate e, desse modo, é totalmente capaz de configurar endereços IP estáticos, servidores DNS, VLANs, vínculos, pontes etc. Essa ferramenta permite gerar configurações de rede com base em estados desejados predefinidos e aplicá-las a vários nós de maneira automatizada.

Os detalhes sobre o NetworkManager Configurator (nmc) estão disponíveis no repositório upstream.

O SUSE Edge utiliza o nmc para as personalizações de rede em diversos modelos de provisionamento:

O Edge Image Builder (EIB) é uma ferramenta que permite configurar vários hosts com uma única imagem de sistema operacional. Nesta seção, vamos mostrar como usar uma abordagem declarativa para descrever os estados da rede desejados, como eles são convertidos nas respectivas conexões do NetworkManager e, em seguida, aplicados durante o processo de provisionamento.

podman pull registry.suse.com/edge/3.3/edge-image-builder:1.2.1

export CONFIG_DIR=$HOME/eib
mkdir -p $CONFIG_DIR/base-images

mv /path/to/downloads/SL-Micro.x86_64-6.1-Base-GM.raw $CONFIG_DIR/base-images/

└── base-images/
    └── SL-Micro.x86_64-6.1-Base-GM.raw

cat << EOF > $CONFIG_DIR/definition.yaml
apiVersion: 1.2
image:
  arch: x86_64
  imageType: raw
  baseImage: SL-Micro.x86_64-6.1-Base-GM.raw
  outputImageName: modified-image.raw
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$jHugJNNd3HElGsUZ$eodjVe4te5ps44SVcWshdfWizrP.xAyd71CVEXazBJ/.v799/WRCBXxfYmunlBO2yp1hm/zb4r8EmnrrNCF.P/
EOF

├── definition.yaml
└── base-images/
    └── SL-Micro.x86_64-6.1-Base-GM.raw

12.5.5 Definindo as configurações de rede #

 

As configurações de rede desejadas não fazem parte do arquivo de definição da imagem que acabamos de criar. Vamos agora preenchê-las no diretório especial network/. Para criá-lo:

mkdir -p $CONFIG_DIR/network

Como já foi mencionado, a ferramenta NetworkManager Configurator (nmc) espera uma entrada no formato de esquema predefinido. Você encontra como configurar uma ampla variedade de opções de rede na documentação de exemplos upstream do NMState.

Esse guia explica como configurar a rede em três nós diferentes:

• Um nó que usa duas interfaces Ethernet

• Um nó que usa vínculo de rede

• Um nó que usa ponte de rede

Atenção

O uso de configurações de rede completamente diferentes não é recomendado em builds de produção, especialmente na configuração de clusters Kubernetes. Em geral, as configurações de rede devem ser homogêneas entre os nós ou, pelo menos, entre as funções em um determinado cluster. Este guia inclui diversas opções apenas para servir como referência de exemplo.

Nota

No exemplo abaixo, foi considerada a rede padrão libvirt com um intervalo de endereços IP 192.168.122.1/24. Ajuste-a de acordo se for diferente em seu ambiente.

Vamos criar os estados desejados para o primeiro nó, que será chamado de node1.suse.com:

cat << EOF > $CONFIG_DIR/network/node1.suse.com.yaml
routes:
  config:
    - destination: 0.0.0.0/0
      metric: 100
      next-hop-address: 192.168.122.1
      next-hop-interface: eth0
      table-id: 254
    - destination: 192.168.122.0/24
      metric: 100
      next-hop-address:
      next-hop-interface: eth0
      table-id: 254
dns-resolver:
  config:
    server:
      - 192.168.122.1
      - 8.8.8.8
interfaces:
  - name: eth0
    type: ethernet
    state: up
    mac-address: 34:8A:B1:4B:16:E1
    ipv4:
      address:
        - ip: 192.168.122.50
          prefix-length: 24
      dhcp: false
      enabled: true
    ipv6:
      enabled: false
  - name: eth3
    type: ethernet
    state: down
    mac-address: 34:8A:B1:4B:16:E2
    ipv4:
      address:
        - ip: 192.168.122.55
          prefix-length: 24
      dhcp: false
      enabled: true
    ipv6:
      enabled: false
EOF

Nesse exemplo, definimos um estado desejado de duas interfaces Ethernet (eth0 e eth3), os endereços IP solicitados, o roteamento e a resolução DNS.

Atenção

Garanta que os endereços MAC de todas as interfaces Ethernet sejam listados. Eles são usados durante o processo de provisionamento como identificadores dos nós e servem para determinar quais configurações devem ser aplicadas. É dessa forma que podemos configurar vários nós usando uma única imagem ISO ou RAW.

O próximo é o segundo nó que será chamado de node2.suse.com e usará vínculo de rede:

cat << EOF > $CONFIG_DIR/network/node2.suse.com.yaml
routes:
  config:
    - destination: 0.0.0.0/0
      metric: 100
      next-hop-address: 192.168.122.1
      next-hop-interface: bond99
      table-id: 254
    - destination: 192.168.122.0/24
      metric: 100
      next-hop-address:
      next-hop-interface: bond99
      table-id: 254
dns-resolver:
  config:
    server:
      - 192.168.122.1
      - 8.8.8.8
interfaces:
  - name: bond99
    type: bond
    state: up
    ipv4:
      address:
        - ip: 192.168.122.60
          prefix-length: 24
      enabled: true
    link-aggregation:
      mode: balance-rr
      options:
        miimon: '140'
      port:
        - eth0
        - eth1
  - name: eth0
    type: ethernet
    state: up
    mac-address: 34:8A:B1:4B:16:E3
    ipv4:
      enabled: false
    ipv6:
      enabled: false
  - name: eth1
    type: ethernet
    state: up
    mac-address: 34:8A:B1:4B:16:E4
    ipv4:
      enabled: false
    ipv6:
      enabled: false
EOF

Nesse exemplo, definimos um estado desejado de duas interfaces Ethernet (eth0 e eth1) que não habilitam endereçamento IP, além de um vínculo com política round robin e o respectivo endereço que será usado para encaminhar o tráfego de rede.

Por fim, vamos criar o terceiro e último arquivo de estado desejado, que usará uma ponte de rede e será chamado de node3.suse.com:

cat << EOF > $CONFIG_DIR/network/node3.suse.com.yaml
routes:
  config:
    - destination: 0.0.0.0/0
      metric: 100
      next-hop-address: 192.168.122.1
      next-hop-interface: linux-br0
      table-id: 254
    - destination: 192.168.122.0/24
      metric: 100
      next-hop-address:
      next-hop-interface: linux-br0
      table-id: 254
dns-resolver:
  config:
    server:
      - 192.168.122.1
      - 8.8.8.8
interfaces:
  - name: eth0
    type: ethernet
    state: up
    mac-address: 34:8A:B1:4B:16:E5
    ipv4:
      enabled: false
    ipv6:
      enabled: false
  - name: linux-br0
    type: linux-bridge
    state: up
    ipv4:
      address:
        - ip: 192.168.122.70
          prefix-length: 24
      dhcp: false
      enabled: true
    bridge:
      options:
        group-forward-mask: 0
        mac-ageing-time: 300
        multicast-snooping: true
        stp:
          enabled: true
          forward-delay: 15
          hello-time: 2
          max-age: 20
          priority: 32768
      port:
        - name: eth0
          stp-hairpin-mode: false
          stp-path-cost: 100
          stp-priority: 32
EOF

Neste momento, o diretório de configuração deve ter a seguinte aparência:

├── definition.yaml
├── network/
│   │── node1.suse.com.yaml
│   │── node2.suse.com.yaml
│   └── node3.suse.com.yaml
└── base-images/
    └── SL-Micro.x86_64-6.1-Base-GM.raw

Nota

Os nomes dos arquivos no diretório network/ são intencionais e correspondem aos nomes de host que serão definidos durante o processo de provisionamento.

podman run --rm -it -v $CONFIG_DIR:/eib registry.suse.com/edge/3.3/edge-image-builder:1.2.1 build --definition-file definition.yaml

Generating image customization components...
Identifier ................... [SUCCESS]
Custom Files ................. [SKIPPED]
Time ......................... [SKIPPED]
Network ...................... [SUCCESS]
Groups ....................... [SKIPPED]
Users ........................ [SUCCESS]
Proxy ........................ [SKIPPED]
Rpm .......................... [SKIPPED]
Systemd ...................... [SKIPPED]
Elemental .................... [SKIPPED]
Suma ......................... [SKIPPED]
Embedded Artifact Registry ... [SKIPPED]
Keymap ....................... [SUCCESS]
Kubernetes ................... [SKIPPED]
Certificates ................. [SKIPPED]
Building RAW image...
Kernel Params ................ [SKIPPED]
Image build complete!

mkdir edge-nodes && cd edge-nodes
for i in {1..4}; do cp $CONFIG_DIR/modified-image.raw node$i.raw; done

virt-install --name node1 --ram 10000 --vcpus 6 --disk path=node1.raw,format=raw --osinfo detect=on,name=sle-unknown --graphics none --console pty,target_type=serial --network default,mac=34:8A:B1:4B:16:E1 --network default,mac=34:8A:B1:4B:16:E2 --virt-type kvm --import

Starting install...
Creating domain...

Running text console command: virsh --connect qemu:///system console node1
Connected to domain 'node1'
Escape character is ^] (Ctrl + ])


Welcome to SUSE Linux Micro 6.0 (x86_64) - Kernel 6.4.0-18-default (tty1).

SSH host key: SHA256:XN/R5Tw43reG+QsOw480LxCnhkc/1uqMdwlI6KUBY70 (RSA)
SSH host key: SHA256:/96yGrPGKlhn04f1rb9cXv/2WJt4TtrIN5yEcN66r3s (DSA)
SSH host key: SHA256:Dy/YjBQ7LwjZGaaVcMhTWZNSOstxXBsPsvgJTJq5t00 (ECDSA)
SSH host key: SHA256:TNGqY1LRddpxD/jn/8dkT/9YmVl9hiwulqmayP+wOWQ (ED25519)
eth0: 192.168.122.50
eth1:


Configured with the Edge Image Builder
Activate the web console with: systemctl enable --now cockpit.socket

node1 login:

node1:~ # hostnamectl
 Static hostname: node1.suse.com
 ...

node1:~ # ip r
default via 192.168.122.1 dev eth0 proto static metric 100
192.168.122.0/24 dev eth0 proto static scope link metric 100
192.168.122.0/24 dev eth0 proto kernel scope link src 192.168.122.50 metric 100

node1:~ # ping google.com
PING google.com (142.250.72.78) 56(84) bytes of data.
64 bytes from den16s09-in-f14.1e100.net (142.250.72.78): icmp_seq=1 ttl=56 time=13.2 ms
64 bytes from den16s09-in-f14.1e100.net (142.250.72.78): icmp_seq=2 ttl=56 time=13.4 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 13.248/13.304/13.361/0.056 ms

node1:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e1 brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    altname ens2
    inet 192.168.122.50/24 brd 192.168.122.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e2 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    altname ens3

node1:~ # nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME con show
NAME  UUID                                  TYPE      DEVICE  FILENAME
eth0  dfd202f5-562f-5f07-8f2a-a7717756fb70  ethernet  eth0    /etc/NetworkManager/system-connections/eth0.nmconnection
eth1  7e211aea-3d14-59cf-a4fa-be91dac5dbba  ethernet  --      /etc/NetworkManager/system-connections/eth1.nmconnection

node1:~ # journalctl -u combustion | grep nmc
Apr 23 09:20:19 localhost.localdomain combustion[1360]: [2024-04-23T09:20:19Z INFO  nmc::apply_conf] Identified host: node1.suse.com
Apr 23 09:20:19 localhost.localdomain combustion[1360]: [2024-04-23T09:20:19Z INFO  nmc::apply_conf] Set hostname: node1.suse.com
Apr 23 09:20:19 localhost.localdomain combustion[1360]: [2024-04-23T09:20:19Z INFO  nmc::apply_conf] Processing interface 'eth0'...
Apr 23 09:20:19 localhost.localdomain combustion[1360]: [2024-04-23T09:20:19Z INFO  nmc::apply_conf] Processing interface 'eth3'...
Apr 23 09:20:19 localhost.localdomain combustion[1360]: [2024-04-23T09:20:19Z INFO  nmc::apply_conf] Using interface name 'eth1' instead of the preconfigured 'eth3'
Apr 23 09:20:19 localhost.localdomain combustion[1360]: [2024-04-23T09:20:19Z INFO  nmc] Successfully applied config

virt-install --name node2 --ram 10000 --vcpus 6 --disk path=node2.raw,format=raw --osinfo detect=on,name=sle-unknown --graphics none --console pty,target_type=serial --network default,mac=34:8A:B1:4B:16:E3 --network default,mac=34:8A:B1:4B:16:E4 --virt-type kvm --import

node2:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond99 state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e3 brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    altname ens2
3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond99 state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e3 brd ff:ff:ff:ff:ff:ff permaddr 34:8a:b1:4b:16:e4
    altname enp0s3
    altname ens3
4: bond99: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.60/24 brd 192.168.122.255 scope global noprefixroute bond99
       valid_lft forever preferred_lft forever

node2:~ # ip r
default via 192.168.122.1 dev bond99 proto static metric 100
192.168.122.0/24 dev bond99 proto static scope link metric 100
192.168.122.0/24 dev bond99 proto kernel scope link src 192.168.122.60 metric 300

node2:~ # nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME con show
NAME    UUID                                  TYPE      DEVICE  FILENAME
bond99  4a920503-4862-5505-80fd-4738d07f44c6  bond      bond99  /etc/NetworkManager/system-connections/bond99.nmconnection
eth0    dfd202f5-562f-5f07-8f2a-a7717756fb70  ethernet  eth0    /etc/NetworkManager/system-connections/eth0.nmconnection
eth1    0523c0a1-5f5e-5603-bcf2-68155d5d322e  ethernet  eth1    /etc/NetworkManager/system-connections/eth1.nmconnection

virt-install --name node3 --ram 10000 --vcpus 6 --disk path=node3.raw,format=raw --osinfo detect=on,name=sle-unknown --graphics none --console pty,target_type=serial --network default,mac=34:8A:B1:4B:16:E5 --virt-type kvm --import

node3:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master linux-br0 state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e5 brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    altname ens2
3: linux-br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 34:8a:b1:4b:16:e5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.70/24 brd 192.168.122.255 scope global noprefixroute linux-br0
       valid_lft forever preferred_lft forever

node3:~ # ip r
default via 192.168.122.1 dev linux-br0 proto static metric 100
192.168.122.0/24 dev linux-br0 proto static scope link metric 100
192.168.122.0/24 dev linux-br0 proto kernel scope link src 192.168.122.70 metric 425

node3:~ # nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME con show
NAME       UUID                                  TYPE      DEVICE     FILENAME
linux-br0  1f8f1469-ed20-5f2c-bacb-a6767bee9bc0  bridge    linux-br0  /etc/NetworkManager/system-connections/linux-br0.nmconnection
eth0       dfd202f5-562f-5f07-8f2a-a7717756fb70  ethernet  eth0       /etc/NetworkManager/system-connections/eth0.nmconnection

virt-install --name node4 --ram 10000 --vcpus 6 --disk path=node4.raw,format=raw --osinfo detect=on,name=sle-unknown --graphics none --console pty,target_type=serial --network default --virt-type kvm --import

localhost:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:56:63:71 brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    altname ens2
    inet 192.168.122.86/24 brd 192.168.122.255 scope global dynamic noprefixroute eth0
       valid_lft 3542sec preferred_lft 3542sec
    inet6 fe80::5054:ff:fe56:6371/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

localhost:~ # journalctl -u combustion | grep nmc
Apr 23 12:15:45 localhost.localdomain combustion[1357]: [2024-04-23T12:15:45Z ERROR nmc] Applying config failed: None of the preconfigured hosts match local NICs

localhost:~ # journalctl | grep eth0
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7801] manager: (eth0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/2)
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7802] device (eth0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7929] device (eth0): carrier: link connected
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7931] device (eth0): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7944] device (eth0): Activation: starting connection 'Wired Connection' (300ed658-08d4-4281-9f8c-d1b8882d29b9)
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7945] device (eth0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7947] device (eth0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7953] device (eth0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Apr 23 12:15:29 localhost.localdomain NetworkManager[704]: <info>  [1713874529.7964] dhcp4 (eth0): activation: beginning transaction (timeout in 90 seconds)
Apr 23 12:15:33 localhost.localdomain NetworkManager[704]: <info>  [1713874533.1272] dhcp4 (eth0): state changed new lease, address=192.168.122.86

localhost:~ # nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME con show
NAME              UUID                                  TYPE      DEVICE  FILENAME
Wired Connection  300ed658-08d4-4281-9f8c-d1b8882d29b9  ethernet  eth0    /var/run/NetworkManager/system-connections/default_connection.nmconnection

mkdir -p $CONFIG_DIR/network

cat <<- EOF > $CONFIG_DIR/network/_all.yaml
interfaces:
- name: eth0
  type: ethernet
  state: up
  ipv4:
    dhcp: true
    enabled: true
  ipv6:
    enabled: false
- name: eth1
  type: ethernet
  state: up
  ipv4:
    address:
    - ip: 10.0.0.1
      prefix-length: 24
    enabled: true
    dhcp: false
  ipv6:
    enabled: false
EOF

podman run --rm -it -v $CONFIG_DIR:/eib registry.suse.com/edge/3.3/edge-image-builder:1.2.1 build --definition-file definition.yaml

virt-install --name node1 --ram 10000 --vcpus 6 --disk path=$CONFIG_DIR/modified-image.raw,format=raw --osinfo detect=on,name=sle-unknown --graphics none --console pty,target_type=serial --network default --network default --virt-type kvm --import

localhost:~ # ip r
default via 192.168.122.1 dev eth0 proto dhcp src 192.168.122.100 metric 100
10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.1 metric 101
192.168.122.0/24 dev eth0 proto kernel scope link src 192.168.122.100 metric 100

localhost:~ # ping google.com
PING google.com (142.250.72.46) 56(84) bytes of data.
64 bytes from den16s08-in-f14.1e100.net (142.250.72.46): icmp_seq=1 ttl=56 time=14.3 ms
64 bytes from den16s08-in-f14.1e100.net (142.250.72.46): icmp_seq=2 ttl=56 time=14.2 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 14.196/14.260/14.324/0.064 ms

localhost:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:26:44:7a brd ff:ff:ff:ff:ff:ff
    altname enp1s0
    inet 192.168.122.100/24 brd 192.168.122.255 scope global dynamic noprefixroute eth0
       valid_lft 3505sec preferred_lft 3505sec
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:ec:57:9e brd ff:ff:ff:ff:ff:ff
    altname enp7s0
    inet 10.0.0.1/24 brd 10.0.0.255 scope global noprefixroute eth1
       valid_lft forever preferred_lft forever

localhost:~ # nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME con show
NAME  UUID                                  TYPE      DEVICE  FILENAME
eth0  dfd202f5-562f-5f07-8f2a-a7717756fb70  ethernet  eth0    /etc/NetworkManager/system-connections/eth0.nmconnection
eth1  0523c0a1-5f5e-5603-bcf2-68155d5d322e  ethernet  eth1    /etc/NetworkManager/system-connections/eth1.nmconnection

localhost:~ # cat /etc/NetworkManager/system-connections/eth0.nmconnection
[connection]
autoconnect=true
autoconnect-slaves=-1
id=eth0
interface-name=eth0
type=802-3-ethernet
uuid=dfd202f5-562f-5f07-8f2a-a7717756fb70

[ipv4]
dhcp-client-id=mac
dhcp-send-hostname=true
dhcp-timeout=2147483647
ignore-auto-dns=false
ignore-auto-routes=false
method=auto
never-default=false

[ipv6]
addr-gen-mode=0
dhcp-timeout=2147483647
method=disabled

localhost:~ # cat /etc/NetworkManager/system-connections/eth1.nmconnection
[connection]
autoconnect=true
autoconnect-slaves=-1
id=eth1
interface-name=eth1
type=802-3-ethernet
uuid=0523c0a1-5f5e-5603-bcf2-68155d5d322e

[ipv4]
address0=10.0.0.1/24
dhcp-timeout=2147483647
method=manual

[ipv6]
addr-gen-mode=0
dhcp-timeout=2147483647
method=disabled

12.5.9 Configurações de rede personalizadas #

 

Já abordamos a configuração de rede padrão do Edge Image Builder que usa o NetworkManager Configurator. No entanto, há também a opção de modificá-la por meio de um script personalizado. Essa opção é muito flexível e independente de endereço MAC, mas tem a limitação de que seu uso não é tão prático para inicializar vários nós com uma única imagem.

Nota

A recomendação é usar a configuração de rede padrão por meio dos arquivos que descrevem o estado da rede desejado no diretório /network. Crie scripts personalizados apenas quando esse comportamento não é cabível no seu caso de uso.

Vamos criar e provisionar um nó de borda usando uma estrutura de configuração diferente. Siga todas as etapas, desde a Seção 12.5.3, “Criando o diretório de configuração de imagem” até a Seção 12.5.5, “Definindo as configurações de rede”.

Neste exemplo, vamos criar um script personalizado que aplica a configuração estática da interface eth0 a todos os nós provisionados, além de remover e desabilitar as conexões com fio criadas automaticamente pelo NetworkManager. Isso é vantajoso nos casos em que você quer garantir que cada nó no cluster tenha uma configuração de rede idêntica e, sendo assim, você não precisa se preocupar com o endereço MAC de cada nó antes da criação da imagem.

Para começar, vamos armazenar o arquivo de conexão no diretório /custom/files:

mkdir -p $CONFIG_DIR/custom/files

cat << EOF > $CONFIG_DIR/custom/files/eth0.nmconnection
[connection]
autoconnect=true
autoconnect-slaves=-1
autoconnect-retries=1
id=eth0
interface-name=eth0
type=802-3-ethernet
uuid=dfd202f5-562f-5f07-8f2a-a7717756fb70
wait-device-timeout=60000

[ipv4]
dhcp-timeout=2147483647
method=auto

[ipv6]
addr-gen-mode=eui64
dhcp-timeout=2147483647
method=disabled
EOF

Com a configuração estática criada, vamos também criar nosso script de rede personalizado:

mkdir -p $CONFIG_DIR/network

cat << EOF > $CONFIG_DIR/network/configure-network.sh
#!/bin/bash
set -eux

# Remove and disable wired connections
mkdir -p /etc/NetworkManager/conf.d/
printf "[main]\nno-auto-default=*\n" > /etc/NetworkManager/conf.d/no-auto-default.conf
rm -f /var/run/NetworkManager/system-connections/* || true

# Copy pre-configured network configuration files into NetworkManager
mkdir -p /etc/NetworkManager/system-connections/
cp eth0.nmconnection /etc/NetworkManager/system-connections/
chmod 600 /etc/NetworkManager/system-connections/*.nmconnection
EOF

chmod a+x $CONFIG_DIR/network/configure-network.sh

Nota

Por padrão, o binário nmc ainda será incluído, para ser usado no script configure-network.sh se necessário.

Atenção

O script personalizado deve sempre ser inserido em /network/configure-network.sh no diretório de configuração. Se estiver presente, todos os outros arquivos serão ignorados. NÃO é possível configurar uma rede trabalhando com as configurações estáticas no formato YAML e um script personalizado ao mesmo tempo.

Neste momento, o diretório de configuração deve ter a seguinte aparência:

├── definition.yaml
├── custom/
│   └── files/
│       └── eth0.nmconnection
├── network/
│   └── configure-network.sh
└── base-images/
    └── SL-Micro.x86_64-6.1-Base-GM.raw

Vamos criar a imagem:

podman run --rm -it -v $CONFIG_DIR:/eib registry.suse.com/edge/3.3/edge-image-builder:1.2.1 build --definition-file definition.yaml

Depois que a imagem for criada com sucesso, vamos criar uma máquina virtual com base nela:

virt-install --name node1 --ram 10000 --vcpus 6 --disk path=$CONFIG_DIR/modified-image.raw,format=raw --osinfo detect=on,name=sle-unknown --graphics none --console pty,target_type=serial --network default --virt-type kvm --import

O processo de provisionamento pode levar alguns minutos. Depois que ele for concluído, faça login no sistema com as credenciais fornecidas.

Verifique se o roteamento foi devidamente configurado:

localhost:~ # ip r
default via 192.168.122.1 dev eth0 proto dhcp src 192.168.122.185 metric 100
192.168.122.0/24 dev eth0 proto kernel scope link src 192.168.122.185 metric 100

Verifique se a conexão com a Internet está disponível:

localhost:~ # ping google.com
PING google.com (142.250.72.78) 56(84) bytes of data.
64 bytes from den16s09-in-f14.1e100.net (142.250.72.78): icmp_seq=1 ttl=56 time=13.6 ms
64 bytes from den16s09-in-f14.1e100.net (142.250.72.78): icmp_seq=2 ttl=56 time=13.6 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 13.592/13.599/13.606/0.007 ms

Verifique se uma interface Ethernet foi configurada estaticamente usando nosso arquivo de conexão e se ela está ativa:

localhost:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:31:d0:1b brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    altname ens2
    inet 192.168.122.185/24 brd 192.168.122.255 scope global dynamic noprefixroute eth0

localhost:~ # nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME con show
NAME  UUID                                  TYPE      DEVICE  FILENAME
eth0  dfd202f5-562f-5f07-8f2a-a7717756fb70  ethernet  eth0    /etc/NetworkManager/system-connections/eth0.nmconnection

localhost:~ # cat  /etc/NetworkManager/system-connections/eth0.nmconnection
[connection]
autoconnect=true
autoconnect-slaves=-1
autoconnect-retries=1
id=eth0
interface-name=eth0
type=802-3-ethernet
uuid=dfd202f5-562f-5f07-8f2a-a7717756fb70
wait-device-timeout=60000

[ipv4]
dhcp-timeout=2147483647
method=auto

[ipv6]
addr-gen-mode=eui64
dhcp-timeout=2147483647
method=disabled

Usamos partes do Elemental para gerenciar dispositivos remotos quando o Metal³ não é viável (por exemplo, não existe BMC ou o dispositivo está protegido por um gateway NAT). Essa ferramenta permite que o operador inicialize os dispositivos em laboratório antes de saber quando ou para onde serão enviados. Especificamente, usamos os componentes elemental-register e elemental-system-agent para permitir a integração de hosts do SUSE Linux Micro no Rancher para casos de uso de provisionamento de rede "phone home". Quando o Edge Image Builder (EIB) é usado para criar imagens de implantação, o registro automático pelo Rancher via Elemental pode ser feito especificando a configuração de registro no diretório de configuração do EIB.

Nota

No SUSE Edge 3.3.1, não aproveitamos os aspectos de gerenciamento de sistema operacional do Elemental e, portanto, não é possível gerenciar a aplicação de patches de seu sistema operacional usando o Rancher. Em vez de usar as ferramentas do Elemental para criar imagens de implantação, o SUSE Edge usa as ferramentas do Edge Image Builder, que consome a configuração de registro.

Atenção

Atualmente, o Akri está em prévia de tecnologia na pilha do SUSE Edge.

O Akri está disponível como parte da pilha do Edge sempre que é preciso descobrir e programar uma carga de trabalho com base nos dispositivos folha.

O Akri está disponível como gráfico Helm no repositório Helm do Edge. A maneira recomendada de configurar o Akri é usar o gráfico Helm especificado para implantar os diversos componentes (agente, controlador, manipuladores de descoberta) e usar o mecanismo de implantação de sua preferência para implantar as CRDs de configuração do Akri.

O Akri é configurado usando um objeto akri.sh/Configuration, que obtém todas as informações de como descobrir os dispositivos e do que fazer quando um correspondente é descoberto.

Veja abaixo um exemplo de configuração decomposto com a explicação de todos os campos:

apiVersion: akri.sh/v0
kind: Configuration
metadata:
  name: sample-configuration
spec:

Esta parte descreve a configuração do manipulador de descoberta. Você deve especificar o nome dele (os manipuladores disponíveis como parte do gráfico do Akri são udev, opcua e onvif). O discoveryDetails é específico do manipulador. Consulte a documentação do manipulador para saber como configurá-lo.

  discoveryHandler:
    name: debugEcho
    discoveryDetails: |+
      descriptions:
        - "foo"
        - "bar"

Esta seção define a carga de trabalho que será implantada para cada dispositivo descoberto. O exemplo mostra uma versão mínima da configuração do Pod em brokerPodSpec, todos os campos comuns da especificação de um pod podem ser usados aqui. Ele também mostra a sintaxe específica do Akri para solicitar o dispositivo na seção resources.

Se preferir, use um job no lugar do pod, com a chave brokerJobSpec, e insira a parte da especificação de um job para ele.

  brokerSpec:
    brokerPodSpec:
      containers:
      - name: broker-container
        image: rancher/hello-world
        resources:
          requests:
            "{{PLACEHOLDER}}" : "1"
          limits:
            "{{PLACEHOLDER}}" : "1"

Estas duas seções mostram como configurar o Akri para implantar um serviço por agente (instanceService) ou apontar para todos os agentes (configurationService). Eles contêm todos os elementos que pertencem a um serviço comum.

  instanceServiceSpec:
    type: ClusterIp
    ports:
    - name: http
      port: 80
      protocol: tcp
      targetPort: 80
  configurationServiceSpec:
    type: ClusterIp
    ports:
    - name: https
      port: 443
      protocol: tcp
      targetPort: 443

O campo brokerProperties é um armazenamento de chave/valor que será exposto como variáveis de ambiente adicionais para um pod que solicita um dispositivo descoberto.

A capacidade é o número permitido de usuários simultâneos de um dispositivo descoberto.

  brokerProperties:
    key: value
  capacity: 1

Se o protocolo usado por seu dispositivo não for coberto por um manipulador de descoberta existente, você pode escrever um próprio seguindo o guia de desenvolvimento de manipulador.

Com a extensão de dashboard Akri, você pode usar a interface de usuário do Rancher Dashboard para gerenciar e monitorar dispositivos folha e executar cargas de trabalho após a descoberta desses dispositivos.

Consulte o Capítulo 6, Extensões do Rancher Dashboard para ver a orientação de instalação.

Depois que a extensão for instalada, navegue até um cluster habilitado pelo Akri usando o explorador de clusters. No grupo de navegação Akri, você verá as seções Configurations (Configurações) e Instances (Instâncias).

A lista de configurações apresenta informações sobre o manipulador de descoberta de configuração e o número de instâncias. Clique no nome para abrir a página de detalhes da configuração.

Você também pode editar ou criar uma nova configuração. A extensão permite selecionar o manipulador de descoberta, configurar o pod ou job do agente, personalizar configurações e serviços de instâncias e definir a capacidade da configuração.

Os dispositivos descobertos são relacionados na lista Instances (Instâncias).

Clique no nome da instância para abrir uma página de detalhes com as cargas de trabalho e o serviço da instância.

É possível usar o K3s como distribuição Kubernetes de base para a pilha do SUSE Edge. Ele foi projetado para ser instalado em um sistema operacional SUSE Linux Micro.

O uso do K3s como distribuição Kubernetes da pilha do SUSE Edge é recomendado apenas quando o etcd como back end não atende a suas restrições. Se o etcd como back end for possível, será melhor usar o RKE2 (Capítulo 16, RKE2).

O K3s é uma distribuição Kubernetes leve e totalmente compatível, com foco em borda, IoT e ARM, otimizado para facilidade de uso e ambientes com restrição de recursos.

O RKE2 combina o melhor dos dois mundos: a versão 1.x do RKE (daqui em diante chamada de RKE1) e o K3s.

Do K3s, ele herda a usabilidade, a facilidade de operação e o modelo de implantação.

Do RKE1, ele herda o alinhamento próximo com o Kubernetes upstream. Em alguns locais, o K3s diverge do Kubernetes upstream para otimizar as implantações de borda, mas o RKE1 e o RKE2 mantêm um estreito alinhamento com o upstream.

O RKE2 é um componente fundamental da pilha do SUSE Edge. Ele coexiste com o SUSE Linux Micro (Capítulo 9, SUSE Linux Micro), oferecendo a interface padrão do Kubernetes necessária para implantar cargas de trabalho do Edge.

Se você está seguindo este guia, já deve ter os seguintes itens disponíveis:

O SUSE Storage usa os recursos do Kubernetes chamados StorageClass para provisionar automaticamente os objetos PersistentVolume aos pods. Pense no StorageClass como um método para os administradores descreverem classes ou perfis do armazenamento que eles oferecem.

Vamos criar um StorageClass com algumas opções padrão:

kubectl apply -f - <<EOF
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: longhorn-example
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880" # 48 hours in minutes
  fromBackup: ""
  fsType: "ext4"
EOF

Agora que temos um StorageClass, precisamos que um PersistentVolumeClaim faça referência a ele. Um PersistentVolumeClaim (PVC) é uma solicitação de armazenamento feita pelo usuário. Os PVCs consomem os recursos PersistentVolume. As declarações podem solicitar tamanhos e modos de acesso específicos (por exemplo, é possível montá-las como leitura/gravação uma vez ou como somente leitura várias vezes).

Vamos criar um PersistentVolumeClaim:

kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: longhorn-volv-pvc
  namespace: longhorn-system
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn-example
  resources:
    requests:
      storage: 2Gi
EOF

Pronto! Com a criação do PersistentVolumeClaim, podemos prosseguir e anexá-lo a um Pod. Quando o Pod é implantado, o Kubernetes cria o volume do Longhorn e o vincula ao Pod quando há armazenamento disponível.

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: volume-test
  namespace: longhorn-system
spec:
  containers:
  - name: volume-test
    image: nginx:stable-alpine
    imagePullPolicy: IfNotPresent
    volumeMounts:
    - name: volv
      mountPath: /data
    ports:
    - containerPort: 80
  volumes:
  - name: volv
    persistentVolumeClaim:
      claimName: longhorn-volv-pvc
EOF

Dica

O conceito de armazenamento no Kubernetes é um tópico complexo, porém importante. Mencionamos rapidamente alguns do recursos mais comuns do Kubernetes, mas sugerimos que você se familiarize com a documentação de terminologia que o Longhorn oferece.

Neste exemplo, o resultado deve ter esta aparência:

localhost:~ # kubectl get storageclass
NAME                 PROVISIONER          RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
longhorn (default)   driver.longhorn.io   Delete          Immediate           true                   12m
longhorn-example     driver.longhorn.io   Delete          Immediate           true                   24s

localhost:~ # kubectl get pvc -n longhorn-system
NAME                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
longhorn-volv-pvc   Bound    pvc-f663a92e-ac32-49ae-b8e5-8a6cc29a7d1e   2Gi        RWO            longhorn-example   54s

localhost:~ # kubectl get pods -n longhorn-system
NAME                                                READY   STATUS    RESTARTS      AGE
csi-attacher-5c4bfdcf59-qmjtz                       1/1     Running   0             14m
csi-attacher-5c4bfdcf59-s7n65                       1/1     Running   0             14m
csi-attacher-5c4bfdcf59-w9xgs                       1/1     Running   0             14m
csi-provisioner-667796df57-fmz2d                    1/1     Running   0             14m
csi-provisioner-667796df57-p7rjr                    1/1     Running   0             14m
csi-provisioner-667796df57-w9fdq                    1/1     Running   0             14m
csi-resizer-694f8f5f64-2rb8v                        1/1     Running   0             14m
csi-resizer-694f8f5f64-z9v9x                        1/1     Running   0             14m
csi-resizer-694f8f5f64-zlncz                        1/1     Running   0             14m
csi-snapshotter-959b69d4b-5dpvj                     1/1     Running   0             14m
csi-snapshotter-959b69d4b-lwwkv                     1/1     Running   0             14m
csi-snapshotter-959b69d4b-tzhwc                     1/1     Running   0             14m
engine-image-ei-5cefaf2b-hvdv5                      1/1     Running   0             14m
instance-manager-0ee452a2e9583753e35ad00602250c5b   1/1     Running   0             14m
longhorn-csi-plugin-gd2jx                           3/3     Running   0             14m
longhorn-driver-deployer-9f4fc86-j6h2b              1/1     Running   0             15m
longhorn-manager-z4lnl                              1/1     Running   0             15m
longhorn-ui-5f4b7bbf69-bln7h                        1/1     Running   3 (14m ago)   15m
longhorn-ui-5f4b7bbf69-lh97n                        1/1     Running   3 (14m ago)   15m
volume-test                                         1/1     Running   0             26s

Se você instalou o Longhorn com o kubectl ou o Helm, precisa configurar um controle de entrada para permitir o tráfego externo no cluster. A autenticação não está habilitada por padrão. Se o app de catálogo do Rancher foi usado, o Rancher criou automaticamente um controlador de entrada com controle de acesso (rancher-proxy).

O SUSE Edge usa o Capítulo 11, Edge Image Builder para personalizar as imagens base do sistema operacional SUSE Linux Micro. Vamos demonstrar como fazer isso para provisionar um cluster RKE2 junto com o Longhorn.

Vamos criar o arquivo de definição:

export CONFIG_DIR=$HOME/eib
mkdir -p $CONFIG_DIR

cat << EOF > $CONFIG_DIR/iso-definition.yaml
apiVersion: 1.2
image:
  imageType: iso
  baseImage: SL-Micro.x86_64-6.1-Base-SelfInstall-GM.install.iso
  arch: x86_64
  outputImageName: eib-image.iso
kubernetes:
  version: v1.32.4+rke2r1
  helm:
    charts:
      - name: longhorn
        version: 106.2.0+up1.8.1
        repositoryName: longhorn
        targetNamespace: longhorn-system
        createNamespace: true
        installationNamespace: kube-system
      - name: longhorn-crd
        version: 106.2.0+up1.8.1
        repositoryName: longhorn
        targetNamespace: longhorn-system
        createNamespace: true
        installationNamespace: kube-system
    repositories:
      - name: longhorn
        url: https://charts.rancher.io
operatingSystem:
  packages:
    sccRegistrationCode: <reg-code>
    packageList:
      - open-iscsi
  users:
  - username: root
    encryptedPassword: \$6\$jHugJNNd3HElGsUZ\$eodjVe4te5ps44SVcWshdfWizrP.xAyd71CVEXazBJ/.v799/WRCBXxfYmunlBO2yp1hm/zb4r8EmnrrNCF.P/
EOF

Nota

A personalização de qualquer um dos valores do gráfico Helm é possível com um arquivo separado fornecido em helm.charts[].valuesFile. Consulte a documentação upstream para obter detalhes.

Vamos criar a imagem:

podman run --rm --privileged -it -v $CONFIG_DIR:/eib registry.suse.com/edge/3.3/edge-image-builder:1.2.1 build --definition-file $CONFIG_DIR/iso-definition.yaml

Após a criação da imagem, você poderá usá-la para instalar o sistema operacional em um host físico ou virtual. Depois que o provisionamento é concluído, é possível fazer login no sistema usando o par de credenciais root:eib.

Verifique se o Longhorn foi implantado com sucesso:

localhost:~ # /var/lib/rancher/rke2/bin/kubectl --kubeconfig /etc/rancher/rke2/rke2.yaml -n longhorn-system get pods
NAME                                                READY   STATUS    RESTARTS        AGE
csi-attacher-5c4bfdcf59-qmjtz                       1/1     Running   0               103s
csi-attacher-5c4bfdcf59-s7n65                       1/1     Running   0               103s
csi-attacher-5c4bfdcf59-w9xgs                       1/1     Running   0               103s
csi-provisioner-667796df57-fmz2d                    1/1     Running   0               103s
csi-provisioner-667796df57-p7rjr                    1/1     Running   0               103s
csi-provisioner-667796df57-w9fdq                    1/1     Running   0               103s
csi-resizer-694f8f5f64-2rb8v                        1/1     Running   0               103s
csi-resizer-694f8f5f64-z9v9x                        1/1     Running   0               103s
csi-resizer-694f8f5f64-zlncz                        1/1     Running   0               103s
csi-snapshotter-959b69d4b-5dpvj                     1/1     Running   0               103s
csi-snapshotter-959b69d4b-lwwkv                     1/1     Running   0               103s
csi-snapshotter-959b69d4b-tzhwc                     1/1     Running   0               103s
engine-image-ei-5cefaf2b-hvdv5                      1/1     Running   0               109s
instance-manager-0ee452a2e9583753e35ad00602250c5b   1/1     Running   0               109s
longhorn-csi-plugin-gd2jx                           3/3     Running   0               103s
longhorn-driver-deployer-9f4fc86-j6h2b              1/1     Running   0               2m28s
longhorn-manager-z4lnl                              1/1     Running   0               2m28s
longhorn-ui-5f4b7bbf69-bln7h                        1/1     Running   3 (2m7s ago)    2m28s
longhorn-ui-5f4b7bbf69-lh97n                        1/1     Running   3 (2m10s ago)   2m28s

Nota

Essa instalação não funciona em ambientes totalmente air-gapped. Para esses casos, consulte a Seção 27.8, “Instalação do SUSE Storage”.

O SUSE Edge oferece uma configuração mais simples do SUSE Security como ponto de partida para implantações de borda.

O SUSE Edge usa o Capítulo 11, Edge Image Builder para personalizar as imagens base do sistema operacional SUSE Linux Micro. Siga a Seção 27.7, “Instalação do SUSE Security” para uma instalação air-gapped do SUSE Security em clusters Kubernetes provisionados pelo EIB.

O SUSE Edge usa o MetalLB de duas maneiras principais:

Nota

Para expor a API, o Endpoint Copier Operator (Capítulo 20, Endpoint Copier Operator) é usado para sincronização dos endpoints da API K8s do serviço kubernetes com um serviço LoadBalancer kubernetes-vip.

A instalação do MetalLB no modo L2 está descrita no Capítulo 25, MetalLB no K3s (usando o modo de camada 2).

Um guia para instalação do MetalLB na frente do kube-api-server para obter uma topologia de alta disponibilidade está disponível no Capítulo 26, MetalLB na frente do servidor da API Kubernetes.

No SUSE Edge, o Endpoint Copier Operator desempenha um papel crucial na configuração de alta disponibilidade (HA, High Availability) para clusters K3s/RKE2. Para que isso seja possível, crie um serviço kubernetes-vip do tipo LoadBalancer, garantindo que seu endpoint esteja sempre sincronizado com o endpoint do kubernetes. O MetalLB (Capítulo 19, MetalLB) é usado para gerenciar o serviço kubernetes-vip, já que o endereço IP exposto é usado em outros nós para ingressar no cluster.

Você encontra a documentação completa sobre como usar o Endpoint Copier Operator aqui.

Consulte também nosso guia (Capítulo 25, MetalLB no K3s (usando o modo de camada 2)) para obter uma configuração de alta disponibilidade do K3s/RKE2 por meio do Endpoint Copier Operator e do MetalLB.

No momento, o funcionamento do Endpoint Copier Operator está limitado apenas a um serviço/endpoint. Há planos para estender o suporte a vários serviços/endpoints no futuro.

O KubeVirt permite o gerenciamento de máquinas virtuais com o Kubernetes junto ao restante de suas cargas de trabalho conteinerizadas. Para fazer isso, ele executa a parte referente ao espaço do usuário da pilha de virtualização do Linux em um contêiner. Isso minimiza os requisitos no sistema host, o que facilita a configuração e o gerenciamento.

Se você está seguindo este guia, já deve ter os seguintes itens disponíveis:

Este guia não orientará na implantação do Kubernetes, mas ele considera que você já instalou a versão apropriada ao SUSE Edge do K3s ou do RKE2 e configurou o kubeconfig de acordo para que os comandos kubectl padrão sejam executados como superusuário. Pressupomos que seu nó constitua um cluster de nó único, apesar de não haver diferenças significativas esperadas nas implantações de vários nós.

O SUSE Edge Virtualization é implantado por meio de três gráficos Helm separados, especificamente:

Cada um desses gráficos Helm é versionado de acordo com a versão do SUSE Edge que você usa. Para uso em produção/com suporte, aplique os artefatos disponíveis no SUSE Registry.

Primeiro, garanta que o acesso ao kubectl esteja funcionando:

$ kubectl get nodes

Esse comando deve retornar algo semelhante ao seguinte:

NAME                   STATUS   ROLES                       AGE     VERSION
node1.edge.rdo.wales   Ready    control-plane,etcd,master   4h20m   v1.30.5+rke2r1
node2.edge.rdo.wales   Ready    control-plane,etcd,master   4h15m   v1.30.5+rke2r1
node3.edge.rdo.wales   Ready    control-plane,etcd,master   4h15m   v1.30.5+rke2r1

Agora você pode instalar os gráficos Helm KubeVirt e Containerized Data Importer (CDI):

$ helm install kubevirt oci://registry.suse.com/edge/charts/kubevirt --namespace kubevirt-system --create-namespace
$ helm install cdi oci://registry.suse.com/edge/charts/cdi --namespace cdi-system --create-namespace

Em alguns minutos, os componentes KubeVirt e CDI estarão implantados. Para validar isso, verifique todos os recursos implantados no namespace kubevirt-system e cdi-system.

Verifique os recursos do KubeVirt:

$ kubectl get all -n kubevirt-system

Esse comando deve retornar algo semelhante ao seguinte:

NAME                                   READY   STATUS    RESTARTS      AGE
pod/virt-operator-5fbcf48d58-p7xpm     1/1     Running   0             2m24s
pod/virt-operator-5fbcf48d58-wnf6s     1/1     Running   0             2m24s
pod/virt-handler-t594x                 1/1     Running   0             93s
pod/virt-controller-5f84c69884-cwjvd   1/1     Running   1 (64s ago)   93s
pod/virt-controller-5f84c69884-xxw6q   1/1     Running   1 (64s ago)   93s
pod/virt-api-7dfc54cf95-v8kcl          1/1     Running   1 (59s ago)   118s

NAME                                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/kubevirt-prometheus-metrics   ClusterIP   None            <none>        443/TCP   2m1s
service/virt-api                      ClusterIP   10.43.56.140    <none>        443/TCP   2m1s
service/kubevirt-operator-webhook     ClusterIP   10.43.201.121   <none>        443/TCP   2m1s
service/virt-exportproxy              ClusterIP   10.43.83.23     <none>        443/TCP   2m1s

NAME                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
daemonset.apps/virt-handler   1         1         1       1            1           kubernetes.io/os=linux   93s

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/virt-operator     2/2     2            2           2m24s
deployment.apps/virt-controller   2/2     2            2           93s
deployment.apps/virt-api          1/1     1            1           118s

NAME                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/virt-operator-5fbcf48d58     2         2         2       2m24s
replicaset.apps/virt-controller-5f84c69884   2         2         2       93s
replicaset.apps/virt-api-7dfc54cf95          1         1         1       118s

NAME                            AGE     PHASE
kubevirt.kubevirt.io/kubevirt   2m24s   Deployed

Verifique os recursos do CDI:

$ kubectl get all -n cdi-system

Esse comando deve retornar algo semelhante ao seguinte:

NAME                                   READY   STATUS    RESTARTS   AGE
pod/cdi-operator-55c74f4b86-692xb      1/1     Running   0          2m24s
pod/cdi-apiserver-db465b888-62lvr      1/1     Running   0          2m21s
pod/cdi-deployment-56c7d74995-mgkfn    1/1     Running   0          2m21s
pod/cdi-uploadproxy-7d7b94b968-6kxc2   1/1     Running   0          2m22s

NAME                             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/cdi-uploadproxy          ClusterIP   10.43.117.7    <none>        443/TCP    2m22s
service/cdi-api                  ClusterIP   10.43.20.101   <none>        443/TCP    2m22s
service/cdi-prometheus-metrics   ClusterIP   10.43.39.153   <none>        8080/TCP   2m21s

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/cdi-operator      1/1     1            1           2m24s
deployment.apps/cdi-apiserver     1/1     1            1           2m22s
deployment.apps/cdi-deployment    1/1     1            1           2m21s
deployment.apps/cdi-uploadproxy   1/1     1            1           2m22s

NAME                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/cdi-operator-55c74f4b86      1         1         1       2m24s
replicaset.apps/cdi-apiserver-db465b888      1         1         1       2m21s
replicaset.apps/cdi-deployment-56c7d74995    1         1         1       2m21s
replicaset.apps/cdi-uploadproxy-7d7b94b968   1         1         1       2m22s

Para verificar se as definições de recursos personalizados (CRDs, Custom Resource Definitions) VirtualMachine foram implantadas, faça a validação com:

$ kubectl explain virtualmachine

Esse comando deve retornar a definição do objeto VirtualMachine, com o seguinte conteúdo:

GROUP:      kubevirt.io
KIND:       VirtualMachine
VERSION:    v1

DESCRIPTION:
    VirtualMachine handles the VirtualMachines that are not running or are in a
    stopped state The VirtualMachine contains the template to create the
    VirtualMachineInstance. It also mirrors the running state of the created
    VirtualMachineInstance in its status.
(snip)

Agora que KubeVirt e CDI estão implantados, vamos definir uma máquina virtual simples com base no openSUSE Tumbleweed. Essa máquina virtual tem as configurações mais simples, usando a configuração de "rede de pod" padrão idêntica a qualquer outro pod. Ela também utiliza um armazenamento não persistente, o que garante que seja efêmero como em qualquer contêiner que não tenha um PVC.

$ kubectl apply -f - <<EOF
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: tumbleweed
  namespace: default
spec:
  runStrategy: Always
  template:
    spec:
      domain:
        devices: {}
        machine:
          type: q35
        memory:
          guest: 2Gi
        resources: {}
      volumes:
      - containerDisk:
          image: registry.opensuse.org/home/roxenham/tumbleweed-container-disk/containerfile/cloud-image:latest
        name: tumbleweed-containerdisk-0
      - cloudInitNoCloud:
          userDataBase64: I2Nsb3VkLWNvbmZpZwpkaXNhYmxlX3Jvb3Q6IGZhbHNlCnNzaF9wd2F1dGg6IFRydWUKdXNlcnM6CiAgLSBkZWZhdWx0CiAgLSBuYW1lOiBzdXNlCiAgICBncm91cHM6IHN1ZG8KICAgIHNoZWxsOiAvYmluL2Jhc2gKICAgIHN1ZG86ICBBTEw9KEFMTCkgTk9QQVNTV0Q6QUxMCiAgICBsb2NrX3Bhc3N3ZDogRmFsc2UKICAgIHBsYWluX3RleHRfcGFzc3dkOiAnc3VzZScK
        name: cloudinitdisk
EOF

A saída deve mostrar que uma VirtualMachine foi criada:

virtualmachine.kubevirt.io/tumbleweed created

Essa definição da VirtualMachine é mínima e especifica pouco da configuração. Ela simplesmente descreve que se trata de uma máquina do tipo "q35" com 2 GB de memória, que usa uma imagem de disco baseada em um containerDisk efêmero (ou seja, uma imagem de disco armazenada na imagem de contêiner de um repositório de imagens remoto), e especifica um disco cloudInit codificado com base64, que usamos apenas para criação de usuários e imposição de senha no momento da inicialização (usamos base64 -d para decodificá-lo).

A inicialização da máquina leva alguns minutos porque ela precisa fazer download da imagem de disco do openSUSE Tumbleweed. Depois disso, você poderá consultar as informações para ver mais detalhes sobre a máquina virtual:

$ kubectl get vmi

Esse comando deve mostrar o nó em que a máquina virtual foi iniciada e o endereço IP dela. Como ela usa a rede de pod, lembre-se de que o endereço IP relatado será exatamente igual ao de qualquer outro pod e, dessa forma, roteável:

NAME         AGE     PHASE     IP           NODENAME               READY
tumbleweed   4m24s   Running   10.42.2.98   node3.edge.rdo.wales   True

Ao executar esses comandos nos próprios nós do cluster Kubernetes, com uma CNI para rotear o tráfego diretamente aos pods (por exemplo, Cilium), você pode executar ssh diretamente na máquina. Substitua o seguinte endereço IP pelo que foi atribuído à sua máquina virtual:

$ ssh suse@10.42.2.98
(password is "suse")

Depois que você estiver nessa máquina virtual, poderá explorá-la, mas lembre-se de que ela tem recursos limitados e apenas 1 GB de espaço em disco. Quando concluir, use Ctrl-D ou exit para se desconectar da sessão SSH.

O processo da máquina virtual ainda é agrupado em um pod padrão do Kubernetes. A CRD VirtualMachine é uma representação da máquina virtual desejada, mas o processo em que a máquina virtual foi realmente iniciada é realizado pelo pod virt-launcher, um pod padrão do Kubernetes, assim como com qualquer outro aplicativo. Para cada máquina virtual iniciada, você vê que existe um pod virt-launcher:

$ kubectl get pods

Em seguida, o pod virt-launcher deve aparecer para a máquina Tumbleweed que definimos:

NAME                             READY   STATUS    RESTARTS   AGE
virt-launcher-tumbleweed-8gcn4   3/3     Running   0          10m

Se você observar o pod virt-launcher, verá que ele está executando os processos libvirt e qemu-kvm. É possível entrar e analisar o conteúdo do pod, levando em conta que você precisa adaptar o seguinte comando com o nome do seu pod:

$ kubectl exec -it virt-launcher-tumbleweed-8gcn4 -- bash

Depois que você estiver no pod, execute os comandos virsh enquanto observa os processos. Você verá o binário qemu-system-x86_64 em execução, junto com alguns processos para monitorar a máquina virtual, e também o local da imagem de disco e como a rede está conectada (como um dispositivo TAP):

qemu@tumbleweed:/> ps ax
  PID TTY      STAT   TIME COMMAND
    1 ?        Ssl    0:00 /usr/bin/virt-launcher-monitor --qemu-timeout 269s --name tumbleweed --uid b9655c11-38f7-4fa8-8f5d-bfe987dab42c --namespace default --kubevirt-share-dir /var/run/kubevirt --ephemeral-disk-dir /var/run/kubevirt-ephemeral-disks --container-disk-dir /var/run/kube
   12 ?        Sl     0:01 /usr/bin/virt-launcher --qemu-timeout 269s --name tumbleweed --uid b9655c11-38f7-4fa8-8f5d-bfe987dab42c --namespace default --kubevirt-share-dir /var/run/kubevirt --ephemeral-disk-dir /var/run/kubevirt-ephemeral-disks --container-disk-dir /var/run/kubevirt/con
   24 ?        Sl     0:00 /usr/sbin/virtlogd -f /etc/libvirt/virtlogd.conf
   25 ?        Sl     0:01 /usr/sbin/virtqemud -f /var/run/libvirt/virtqemud.conf
   83 ?        Sl     0:31 /usr/bin/qemu-system-x86_64 -name guest=default_tumbleweed,debug-threads=on -S -object {"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/run/kubevirt-private/libvirt/qemu/lib/domain-1-default_tumbleweed/master-key.aes"} -machine pc-q35-7.1,usb
  286 pts/0    Ss     0:00 bash
  320 pts/0    R+     0:00 ps ax

qemu@tumbleweed:/> virsh list --all
 Id   Name                 State
------------------------------------
 1    default_tumbleweed   running

qemu@tumbleweed:/> virsh domblklist 1
 Target   Source
---------------------------------------------------------------------------------------------
 sda      /var/run/kubevirt-ephemeral-disks/disk-data/tumbleweed-containerdisk-0/disk.qcow2
 sdb      /var/run/kubevirt-ephemeral-disks/cloud-init-data/default/tumbleweed/noCloud.iso

qemu@tumbleweed:/> virsh domiflist 1
 Interface   Type       Source   Model                     MAC
------------------------------------------------------------------------------
 tap0        ethernet   -        virtio-non-transitional   e6:e9:1a:05:c0:92

qemu@tumbleweed:/> exit
exit

Por fim, vamos excluir a máquina virtual para limpeza:

$ kubectl delete vm/tumbleweed
virtualmachine.kubevirt.io "tumbleweed" deleted

Junto com a ferramenta CLI padrão do Kubernetes, ou seja, kubectl, o KubeVirt integra um utilitário CLI complementar que permite estabelecer interface com seu cluster para suprir algumas lacunas entre o cenário da virtualização e o cenário para o qual o Kubernetes foi projetado. Por exemplo, a ferramenta virtctl permite gerenciar o ciclo de vida das máquinas virtuais (início, parada, reinicialização etc.), concedendo acesso aos consoles virtuais, fazendo upload das imagens de máquina virtual e estabelecendo interface com as estruturas do Kubernetes, como serviços, sem usar diretamente a API ou as CRDs.

Vamos fazer download da versão estável mais recente da ferramenta virtctl:

$ export VERSION=v1.4.0
$ wget https://github.com/kubevirt/kubevirt/releases/download/$VERSION/virtctl-$VERSION-linux-amd64

Se você usa uma arquitetura diferente ou uma máquina não Linux, pode encontrar outras versões aqui. Antes de continuar, você precisa torná-la executável, o que pode ser útil para movê-la até um local em seu $PATH:

$ mv virtctl-$VERSION-linux-amd64 /usr/local/bin/virtctl
$ chmod a+x /usr/local/bin/virtctl

Na sequência, use a ferramenta de linha de comando virtctl para criar máquinas virtuais. Vamos replicar nossa máquina virtual anterior, observando que estamos fazendo pipe da saída diretamente em kubectl apply:

$ virtctl create vm --name virtctl-example --memory=1Gi \
    --volume-containerdisk=src:registry.opensuse.org/home/roxenham/tumbleweed-container-disk/containerfile/cloud-image:latest \
    --cloud-init-user-data "I2Nsb3VkLWNvbmZpZwpkaXNhYmxlX3Jvb3Q6IGZhbHNlCnNzaF9wd2F1dGg6IFRydWUKdXNlcnM6CiAgLSBkZWZhdWx0CiAgLSBuYW1lOiBzdXNlCiAgICBncm91cHM6IHN1ZG8KICAgIHNoZWxsOiAvYmluL2Jhc2gKICAgIHN1ZG86ICBBTEw9KEFMTCkgTk9QQVNTV0Q6QUxMCiAgICBsb2NrX3Bhc3N3ZDogRmFsc2UKICAgIHBsYWluX3RleHRfcGFzc3dkOiAnc3VzZScK" | kubectl apply -f -

Isso deve mostrar a máquina virtual em execução (desta vez, ela deve ser iniciada de forma bem mais rápida, já que a imagem de contêiner estará armazenada em cache):

$ kubectl get vmi
NAME              AGE   PHASE     IP           NODENAME               READY
virtctl-example   52s   Running   10.42.2.29   node3.edge.rdo.wales   True

Vamos usar virtctl para conexão direta com a máquina virtual:

$ virtctl ssh suse@virtctl-example
(password is "suse" - Ctrl-D to exit)

Há vários outros comandos que o virtctl pode usar. Por exemplo, o virtctl console concede a você acesso ao console serial quando a rede não está funcionando, e você pode usar o virtctl guestosinfo para obter as informações completas do sistema operacional, desde que o convidado tenha o qemu-guest-agent instalado e em execução.

Por fim, vamos pausar e retomar a máquina virtual:

$ virtctl pause vm virtctl-example
VMI virtctl-example was scheduled to pause

Observe que o objeto VirtualMachine aparece como Paused (Pausado), e o objeto VirtualMachineInstance como Running (Em execução), mas READY=False (PRONTO=Falso):

$ kubectl get vm
NAME              AGE     STATUS   READY
virtctl-example   8m14s   Paused   False

$ kubectl get vmi
NAME              AGE     PHASE     IP           NODENAME               READY
virtctl-example   8m15s   Running   10.42.2.29   node3.edge.rdo.wales   False

Veja também que não é mais possível se conectar à máquina virtual:

$ virtctl ssh suse@virtctl-example
can't access VMI virtctl-example: Operation cannot be fulfilled on virtualmachineinstance.kubevirt.io "virtctl-example": VMI is paused

Vamos retomar a máquina virtual e tentar novamente:

$ virtctl unpause vm virtctl-example
VMI virtctl-example was scheduled to unpause

Agora devemos conseguir reestabelecer a conexão:

$ virtctl ssh suse@virtctl-example
suse@vmi/virtctl-example.default's password:
suse@virtctl-example:~> exit
logout

Por fim, vamos remover a máquina virtual:

$ kubectl delete vm/virtctl-example
virtualmachine.kubevirt.io "virtctl-example" deleted

Nesta seção, mostramos como é possível expor máquinas virtuais como serviços padrão do Kubernetes e disponibilizá-los pelo serviço de entrada do Kubernetes, por exemplo, NGINX com RKE2 ou Traefik com K3s. Este documento pressupõe que esses componentes já foram devidamente configurados e que você tem o ponteiro de DNS, por exemplo, usando um curinga, para apontar para os nós do servidor Kubernetes ou IP virtual de entrada para uma resolução de entrada correta.

No ambiente de exemplo, outra máquina virtual openSUSE Tumbleweed foi implantada, o cloud-init foi usado para instalar o NGINX como servidor web simples no momento da inicialização e uma mensagem simples foi configurada para ser exibida para verificar se ela funciona conforme o esperado quando uma chamada é feita. Para ver como isso é feito, basta executar base64 -d na seção cloud-init na saída a seguir.

Agora vamos criar a máquina virtual:

$ kubectl apply -f - <<EOF
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: ingress-example
  namespace: default
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        app: nginx
    spec:
      domain:
        devices: {}
        machine:
          type: q35
        memory:
          guest: 2Gi
        resources: {}
      volumes:
      - containerDisk:
          image: registry.opensuse.org/home/roxenham/tumbleweed-container-disk/containerfile/cloud-image:latest
        name: tumbleweed-containerdisk-0
      - cloudInitNoCloud:
          userDataBase64: I2Nsb3VkLWNvbmZpZwpkaXNhYmxlX3Jvb3Q6IGZhbHNlCnNzaF9wd2F1dGg6IFRydWUKdXNlcnM6CiAgLSBkZWZhdWx0CiAgLSBuYW1lOiBzdXNlCiAgICBncm91cHM6IHN1ZG8KICAgIHNoZWxsOiAvYmluL2Jhc2gKICAgIHN1ZG86ICBBTEw9KEFMTCkgTk9QQVNTV0Q6QUxMCiAgICBsb2NrX3Bhc3N3ZDogRmFsc2UKICAgIHBsYWluX3RleHRfcGFzc3dkOiAnc3VzZScKcnVuY21kOgogIC0genlwcGVyIGluIC15IG5naW54CiAgLSBzeXN0ZW1jdGwgZW5hYmxlIC0tbm93IG5naW54CiAgLSBlY2hvICJJdCB3b3JrcyEiID4gL3Nydi93d3cvaHRkb2NzL2luZGV4Lmh0bQo=
        name: cloudinitdisk
EOF

Quando a máquina virtual é iniciada com sucesso, podemos usar o comando virtctl para expor VirtualMachineInstance com a porta externa 8080 e a porta de destino 80 (na qual o NGINX escuta por padrão). Usamos o comando virtctl aqui porque ele reconhece o mapeamento entre o objeto e o pod da máquina virtual. Isso cria um novo serviço:

$ virtctl expose vmi ingress-example --port=8080 --target-port=80 --name=ingress-example
Service ingress-example successfully exposed for vmi ingress-example

Desse modo, o serviço apropriado será criado automaticamente:

$ kubectl get svc/ingress-example
NAME              TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)                         AGE
ingress-example   ClusterIP      10.43.217.19    <none>            8080/TCP                        9s

Se depois você usar kubectl create ingress, poderemos criar a seguir um objeto de entrada que aponte para esse serviço. Adapte o URL aqui (conhecido como "host" no objeto ingress) de acordo com sua configuração do DNS e garanta que ele aponte para a porta 8080:

$ kubectl create ingress ingress-example --rule=ingress-example.suse.local/=ingress-example:8080

Com a configuração correta do DNS, você pode executar curl no URL imediatamente:

$ curl ingress-example.suse.local
It works!

Vamos fazer a limpeza removendo a máquina virtual e os respectivos recursos de entrada e serviço:

$ kubectl delete vm/ingress-example svc/ingress-example ingress/ingress-example
virtualmachine.kubevirt.io "ingress-example" deleted
service "ingress-example" deleted
ingress.networking.k8s.io "ingress-example" deleted

O SUSE Edge Virtualization oferece uma extensão de IU para o Rancher Manager, que permite o gerenciamento básico de máquinas virtuais usando a interface de usuário do Rancher Dashboard.

21.7.2 Usando a extensão KubeVirt do Rancher Dashboard #

 

A extensão introduz uma nova seção KubeVirt no explorador de clusters, que é adicionada a qualquer cluster gerenciado que tenha o KubeVirt instalado.

A extensão permite interagir diretamente com os recursos de máquina virtual do KubeVirt para gerenciar o ciclo de vida das máquinas virtuais.

21.7.2.1 Criando uma máquina virtual #

 

1. Navegue até o explorador de clustersr clicando no cluster gerenciado habilitado para KubeVirt na navegação esquerda.

2. Navegue até a página KubeVirt > Virtual Machines (Máquinas virtuais) e clique em Create from YAML (Criar do YAML) na parte superior direita da tela.

3. Preencha ou cole uma definição da máquina virtual e clique em Create (Criar). Use a definição da máquina virtual da seção Implantando máquinas virtuais como modelo.

21.7.2.2 Ações da máquina virtual #

 

É possível usar o menu de ações acessado pela lista suspensa ⋮ à direita de cada máquina virtual para executar as ações iniciar, parar, pausar ou fazer reboot suave. Se preferir, use as ações em grupo na parte superior da lista selecionando as máquinas virtuais nas quais executar a ação.

A execução das ações pode afetar a estratégia de execução da máquina virtual. Consulte a tabela na documentação do KubeVirt para obter mais detalhes.

21.7.2.3 Acessando o console da máquina virtual #

 

A lista de "máquinas virtuais" oferece a lista suspensa Console, que permite conectar-se à máquina usando VNC ou console serial. Essa ação está disponível apenas em máquinas que estão em execução.

Em alguns casos, leva um curto tempo para que o console fique disponível em uma máquina virtual que acabou de ser iniciada.

O SUSE Edge usa o Capítulo 11, Edge Image Builder para personalizar as imagens base do sistema operacional SUSE Linux Micro. Siga a Seção 27.9, “Instalação do KubeVirt e CDI” para saber sobre a instalação air-gapped tanto do KubeVirt quanto da CDI em clusters Kubernetes provisionados pelo EIB.

O SUSE Edge usa o SUC para facilitar diversas operações de "dia 2" relacionadas a upgrades de versão de sistema operacional e Kubernetes em clusters de gerenciamento e downstream.

As operações de "dia 2" são definidas em planos do SUC. Com base nesses planos, o SUC implanta as cargas de trabalho em cada nó para executar a respectiva operação de "dia 2".

O SUC também é usado no Capítulo 23, Controller de upgrade. Para saber mais sobre as principais diferenças entre o SUC e o Controller de upgrade, consulte a Seção 23.2, “Comparação entre Controller de upgrade e System Upgrade Controller”.

Importante

A partir do Rancher v2.10.0, o System Upgrade Controller é instalado automaticamente.

Siga as etapas abaixo apenas se o seu ambiente não é gerenciado pelo Rancher, ou se a versão do Rancher é inferior a v2.10.0.

Recomendamos a instalação do SUC pelo Fleet (Capítulo 8, Fleet), localizado no repositório suse-edge/fleet-examples.

Nota

Os recursos disponíveis no repositório suse-edge/fleet-examples sempre devem ser usados de uma versão válida de fleet-examples. Para determinar a versão que você precisa usar, consulte as Notas de lançamento (Seção 52.1, “Resumo”).

Se não for possível usar o Fleet para instalação do SUC, instale-o por meio do repositório de gráficos Helm do Rancher ou incorpore o gráfico Helm do Rancher ao seu próprio fluxo de trabalho do GitOps de terceiros.

Esta seção aborda o seguinte:

22.2.1 Instalação do System Upgrade Controller pelo Fleet #

 

Com o Fleet, há dois recursos possíveis para serem usados na implantação do SUC:

• GitRepo: para casos de uso em que um servidor Git externo/local está disponível. Para obter instruções de instalação, consulte Instalação do System Upgrade Controller – GitRepo (Seção 22.2.1.1, “Instalação do System Upgrade Controller – GitRepo”).

• Bundle: para casos de uso air-gapped que não oferecem suporte à opção de servidor Git local. Para obter instruções de instalação, consulte Instalação do System Upgrade Controller – Bundle (Seção 22.2.1.2, “Instalação do System Upgrade Controller – Bundle”).

22.2.1.1 Instalação do System Upgrade Controller – GitRepo #

 

Nota

Também é possível realizar esse processo pela IU do Rancher, se disponível. Para obter mais informações, consulte Accessing Fleet in the Rancher UI (Acessando o Fleet na IU do Rancher).

Em seu cluster de gerenciamento:

1. Determine os clusters em que deseja implantar o SUC. Para fazer isso, implante um recurso GitRepo do SUC no espaço de trabalho correto do Fleet em seu cluster de gerenciamento. Por padrão, o Fleet tem dois espaços de trabalho:

   • fleet-local: para recursos que precisam ser implantados no cluster de gerenciamento.

   • fleet-default: para recursos que precisam ser implantados em clusters downstream.

     Para obter mais informações sobre espaços de trabalho do Fleet, consulte a documentação upstream.

2. Implante o recurso GitRepo :

   • Para implantar o SUC no cluster de gerenciamento:

     kubectl apply -n fleet-local -f - <<EOF
     apiVersion: fleet.cattle.io/v1alpha1
     kind: GitRepo
     metadata:
       name: system-upgrade-controller
     spec:
       revision: release-3.3.0
       paths:
       - fleets/day2/system-upgrade-controller
       repo: https://github.com/suse-edge/fleet-examples.git
     EOF

   • Para implantar o SUC em clusters downstream:

     

     Nota

     Antes de implantar o recurso a seguir, você deve especificar uma configuração válida de targets, para que o Fleet saiba em quais clusters downstream implantar seu recurso. Para obter informações de como mapear para clusters downstream, consulte Mapping to Downstream Clusters (Mapeando para clusters downstream).

     kubectl apply -n fleet-default -f - <<EOF
     apiVersion: fleet.cattle.io/v1alpha1
     kind: GitRepo
     metadata:
       name: system-upgrade-controller
     spec:
       revision: release-3.3.0
       paths:
       - fleets/day2/system-upgrade-controller
       repo: https://github.com/suse-edge/fleet-examples.git
       targets:
       - clusterSelector: CHANGEME
       # Example matching all clusters:
       # targets:
       # - clusterSelector: {}
     EOF

3. Valide que o recurso GitRepo foi implantado:

   # Namespace will vary based on where you want to deploy SUC
   kubectl get gitrepo system-upgrade-controller -n <fleet-local/fleet-default>
   
   NAME                        REPO                                              COMMIT          BUNDLEDEPLOYMENTS-READY   STATUS
   system-upgrade-controller   https://github.com/suse-edge/fleet-examples.git   release-3.3.0   1/1

4. Valide a implantação do System Upgrade Controller:

   kubectl get deployment system-upgrade-controller -n cattle-system
   NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
   system-upgrade-controller   1/1     1            1           2m20s

22.2.1.2 Instalação do System Upgrade Controller – Bundle #

 

Esta seção ilustra como criar e implantar um recurso Bundle de uma configuração padrão do Fleet usando fleet-cli.

1. Em uma máquina com acesso à rede, faça download de fleet-cli:

   

   Nota

   Garanta que a versão do fleet-cli do download seja a mesma do Fleet que foi implantado em seu cluster.

   • Para usuários do Mac, existe um Homebrew Formulae fleet-cli.

   • Para usuários do Linux e Windows, os binários estão presentes como ativos para cada versão do Fleet.

     • Linux AMD:

       curl -L -o fleet-cli https://github.com/rancher/fleet/releases/download/v0.12.2/fleet-linux-amd64

     • Linux ARM:

       curl -L -o fleet-cli https://github.com/rancher/fleet/releases/download/v0.12.2/fleet-linux-arm64

2. Torne o fleet-cli executável:

   chmod +x fleet-cli

3. Clone a versão do suse-edge/fleet-examples que deseja usar:

   git clone -b release-3.3.0 https://github.com/suse-edge/fleet-examples.git

4. Navegue até a instância do Fleet do SUC, localizada no repositório fleet-examples:

   cd fleet-examples/fleets/day2/system-upgrade-controller

5. Determine os clusters em que deseja implantar o SUC. Para fazer isso, implante o bundle do SUC no espaço de trabalho correto do Fleet em seu cluster de gerenciamento. Por padrão, o Fleet tem dois espaços de trabalho:

   • fleet-local: para recursos que precisam ser implantados no cluster de gerenciamento.

   • fleet-default: para recursos que precisam ser implantados em clusters downstream.

     Para obter mais informações sobre espaços de trabalho do Fleet, consulte a documentação upstream.

6. Se você pretende implantar o SUC apenas em clusters downstream, crie um arquivo targets.yaml correspondente aos clusters específicos:

   cat > targets.yaml <<EOF
   targets:
   - clusterSelector: CHANGEME
   EOF

   Para obter informações sobre como mapear para clusters downstream, consulte Mapping to Downstream Clusters (Mapeando para clusters downstream).

7. Avance para a criação do bundle :

   

   Nota

   Certifique-se de que você não fez download de fleet-cli no diretório fleet-examples/fleets/day2/system-upgrade-controller; do contrário, ele será empacotado com o bundle, o que não é aconselhável.

   • Para implantar o SUC no cluster de gerenciamento, execute:

     fleet-cli apply --compress -n fleet-local -o - system-upgrade-controller . > system-upgrade-controller-bundle.yaml

   • Para implantar o SUC em clusters downstream, execute:

     fleet-cli apply --compress --targets-file=targets.yaml -n fleet-default -o - system-upgrade-controller . > system-upgrade-controller-bundle.yaml

     Para obter mais informações sobre esse processo, consulte Convert a Helm Chart into a Bundle (Converter um gráfico Helm em bundle).

     Para obter mais informações sobre o comando fleet-cli apply, consulte fleet apply.

8. Transfira o bundle system-upgrade-controller-bundle.yaml para sua máquina do cluster de gerenciamento:

   scp system-upgrade-controller-bundle.yaml <machine-address>:<filesystem-path>

9. No cluster de gerenciamento, implante o bundle system-upgrade-controller-bundle.yaml:

   kubectl apply -f system-upgrade-controller-bundle.yaml

10. No cluster de gerenciamento, valide se o bundle foi implantado:

    # Namespace will vary based on where you want to deploy SUC
    kubectl get bundle system-upgrade-controller -n <fleet-local/fleet-default>
    
    NAME                        BUNDLEDEPLOYMENTS-READY   STATUS
    system-upgrade-controller   1/1

11. De acordo com o espaço de trabalho do Fleet em que você implantou o bundle, navegue até o cluster e valide a implantação do SUC:

    

    Nota

    O SUC é sempre implantado no namespace cattle-system.

    kubectl get deployment system-upgrade-controller -n cattle-system
    NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
    system-upgrade-controller   1/1     1            1           111s

É possível ver os planos do SUC destas maneiras:

Importante

Os pods implantados para os planos do SUC se mantêm ativos por 15 minutos após a execução bem-sucedida e, depois disso, são removidos pelo job correspondente que os criou. Para ter acesso aos registros do pod após esse período, habilite o registro em seu cluster. Para obter informações sobre como fazer isso no Rancher, consulte Rancher Integration with Logging Services (Integração do Rancher a serviços de registro).

22.3.2 Monitorando os planos do System Upgrade Controller – Manual #

 

Nota

As etapas abaixo pressupõem que o kubectl foi configurado para conectar-se ao cluster em que os planos do SUC foram implantados.

1. Liste os planos do SUC implantados:

   kubectl get plans -n cattle-system

2. Obtenha o pod para o plano do SUC:

   kubectl get pods -l upgrade.cattle.io/plan=<plan_name> -n cattle-system

   

   Nota

   Pode haver pods tanto Completed (Concluídos) quanto Unknown (Desconhecidos) para um plano do SUC específico. Isso é esperado e acontece por causa da natureza de alguns upgrades.

3. Obtenha os registros do pod:

   kubectl logs <pod_name> -n cattle-system

O Controller de upgrade é essencial para automação das operações de "dia 2" (que antes eram manuais) necessárias para fazer upgrade dos clusters de gerenciamento de uma versão de lançamento do SUSE Edge para a seguinte.

Para atingir essa automação, o Controller de upgrade usa ferramentas como o System Upgrade Controller (Capítulo 22, System Upgrade Controller) e o Helm Controller.

Para obter mais detalhes de como o Controller de upgrade funciona, consulte a Seção 23.4, “Como funciona o Controller de upgrade?”.

Para saber as limitações conhecidas do Controller de upgrade, consulte a Seção 23.7, “Limitações conhecidas”.

Para obter informações sobre a diferença entre o Controller de upgrade e o System Upgrade Controller, consulte a Seção 23.2, “Comparação entre Controller de upgrade e System Upgrade Controller”.

O System Upgrade Controller (SUC) (Capítulo 22, System Upgrade Controller) é uma ferramenta de uso geral que propaga as instruções de upgrade para os nós específicos do Kubernetes.

Apesar de oferecer suporte a algumas operações de "dia 2" para a plataforma SUSE Edge, ele não abrange todas elas. Mesmo para as operações com suporte, os usuários ainda precisam configurar, manter e implantar manualmente vários planos do SUC, um processo propenso a erros que pode provocar problemas inesperados.

Isso levou à necessidade de uma ferramenta para automatizar e abstrair a complexidade de gerenciar várias operações de "dia 2" na plataforma SUSE Edge. E, assim, o Controller de upgrade foi desenvolvido. Ele simplifica o processo de upgrade com a introdução de um único recurso voltado para o usuário que conduz o upgrade. Os usuários precisam gerenciar apenas esse recurso, e o Controller de upgrade cuida do restante.

Para fazer upgrade de uma versão do Edge, o Controller de upgrade lança dois novos recursos personalizados do Kubernetes:

O Controller de upgrade cria um recurso ReleaseManifest que armazena os dados do componente referentes à versão de lançamento do Edge especificada pelo usuário na propriedade releaseVersion do recurso UpgradePlan.

Usando os dados do componente do ReleaseManifest, o Controller de upgrade faz upgrade do componente da versão do Edge na seguinte ordem:

Nota

Durante o processo de upgrade, o Controller de upgrade envia continuamente as informações de upgrade para o UpgradePlan criado. Para obter mais informações sobre como acompanhar o processo de upgrade, consulte Acompanhando o processo de upgrade (Seção 23.6, “Acompanhando o processo de upgrade”).

23.4.1 Upgrade do sistema operacional #

 

Para fazer upgrade do sistema operacional, o Controller de upgrade cria planos do SUC (Capítulo 22, System Upgrade Controller) com o seguinte gabarito de nomenclatura:

• Para planos do SUC relacionados a upgrades de sistema operacional de nó do plano de controle: control-plane-<nome-do-so>-<versão-do-so>-<sufixo>.

• Para planos do SUC relacionados a upgrades de sistema operacional de nó do worker: workers-<nome-do-so>-<versão-do-so>-<sufixo>.

Com base nesses planos, o SUC cria as cargas de trabalho em cada nó do cluster que faz o upgrade real do sistema operacional.

Dependendo do ReleaseManifest, o upgrade de sistema operacional pode incluir:

• Atualizações somente de pacotes: para casos de uso em que a versão do sistema operacional não é alterada entre os lançamentos do Edge.

• Migração completa do sistema operacional: para casos de uso em que a versão do sistema operacional é alterada entre os lançamentos do Edge.

O upgrade é feito um nó de cada vez, começando primeiro pelos nós do plano de controle. Apenas quando o upgrade do nó do plano de controle é concluído que o upgrade dos nós do worker é iniciado.

Nota

O Controller de upgrade configura os planos do SUC de sistema operacional para fazer uma drenagem dos nós do cluster, se o cluster tiver mais de um um nó do tipo especificado.

Para os clusters em que os nós do plano de controle são mais de um, e existe apenas um nó do worker, a drenagem será realizada somente para os nós do plano de controle e vice-versa.

Para obter informações sobre como desabilitar completamente as drenagens de nós, consulte a seção UpgradePlan (Seção 23.5.1, “UpgradePlan”).

23.4.2 Upgrade do Kubernetes #

 

Para fazer upgrade da distribuição Kubernetes de um cluster, o Controller de upgrade cria planos do SUC (Capítulo 22, System Upgrade Controller) com o seguinte gabarito de nomenclatura:

• Para os planos do SUC relacionados a ugrades do Kubernetes em nós do plano de controle: control-plane-<versão-do-k8s>-<sufixo>.

• Para os planos do SUC relacionados a upgrades do Kubernetes em nós do worker: workers-<versão-do-k8s>-<sufixo>.

Com base nesses planos, o SUC cria as cargas de trabalho em cada nó do cluster que faz o upgrade real do Kubernetes.

O upgrade do Kubernetes é feito um nó de cada vez, começando primeiro pelos nós do plano de controle. Apenas quando o upgrade do nó do plano de controle é concluído que o upgrade dos nós do worker é iniciado.

Nota

O Controller de upgrade configura os planos do SUC do Kubernetes para fazer uma drenagem dos nós do cluster, se o cluster tiver mais de um um nó do tipo especificado.

Para os clusters em que os nós do plano de controle são mais de um, e existe apenas um nó do worker, a drenagem será realizada somente para os nós do plano de controle e vice-versa.

Para obter informações sobre como desabilitar completamente as drenagens de nós, consulte a Seção 23.5.1, “UpgradePlan”.

Extensões para a API Kubernetes lançadas pelo Controller de upgrade.

23.5.2 ReleaseManifest #

 

O Controller de upgrade lança um novo recurso personalizado do Kubernetes chamado ReleaseManifest.

O recurso ReleaseManifest é criado pelo Controller de upgrade e armazena os dados de componente referentes a uma versão de lançamento específica do Edge. Isso significa que o upgrade de cada versão de lançamento do Edge será representado por um recurso ReleaseManifest diferente.

Atenção

O Controller de upgrade sempre deve criar o ReleaseManifest.

Não é aconselhável criar manualmente ou editar os recursos ReleaseManifest . O usuários que decidirem por esse método devem fazê-lo por sua conta e risco.

O ReleaseManifest inclui os seguintes dados de componente, mas sem limitação:

• Dados de sistema operacional: versão, arquiteturas suportadas, dados adicionais de upgrade etc.

• Dados de distribuição Kubernetes: versões suportadas do RKE2/K3s

• Dados de componentes adicionais: dados de gráficos Helm do SUSE (local, versão, nome etc.)

Para ver um exemplo da aparência de um ReleaseManifest, consulte a documentação upstream. Tenha em mente que se trata apenas de um exemplo, sem a intenção de criar um recurso ReleaseManifest válido.

Esta seção apresenta como acompanhar e depurar o processo de upgrade que o Controller de upgrade inicia após a criação do recurso UpgradePlan.