5 Clusters autônomos com o Edge Image Builder #

A imagem de contêiner do EIB está disponível publicamente e pode ser baixada do registro SUSE Telco Cloud executando o seguinte comando em seu host de compilação de imagem:

podman pull registry.suse.com/edge/3.6/edge-image-builder:1.3.3.1

A seção operatingSystem do EIB destina-se a configurar onde o sistema operacional será instalado, o tamanho da imagem, etc. É uma seção opcional e não deve ser incluída, a menos que uma ou mais personalizações estejam sendo aplicadas.

apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-Base-RT-SelfInstall.iso
operatingSystem:
  isoConfiguration:
    installDevice: /dev/disk/by-id/ata-QEMU_HARDDISK_111-disk1 # first defined disk

Configuração específica do tipo. Dependendo do tipo de imagem que está sendo personalizada, uma das seguintes seções opcionais pode ser incluída.

O EIB permite que você pré-configure 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 definir a senha de root, e o primeiro passo é usar OpenSSL para criar uma senha criptografada de mão única:

openssl passwd -6 SecurePassword

Isso gerará algo semelhante a:

$6$G392FCbxVgn[...]Y7zTXnC1

Podemos então adicionar uma seção no arquivo de definição chamada operatingSystem com uma matriz users dentro dela. O arquivo resultante deve ter a seguinte aparência:

apiVersion: 1.3
image:
  imageType: iso
  arch: x86_64
  baseImage: slemicro.iso
  outputImageName: eib-image.iso
operatingSystem:
  users:
    - username: root
      encryptedPassword: $6$G392FCbxVgn[...]Y7zTXnC1

Note

Também é possível adicionar usuários adicionais, criar os diretórios home, 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 obter mais exemplos.

A seção time é opcional, mas é altamente recomendável que seja configurada para evitar possíveis problemas com certificados e desvio de relógio. O EIB configurará o chronyd e o /etc/localtime dependendo dos parâmetros aqui.

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

Note

Os valores fornecidos neste exemplo são apenas para fins ilustrativos. Por favor, ajuste-os para atender aos seus requisitos específicos.

Arquivos de certificado com a extensão ".pem" ou ".crt" armazenados no diretório certificates serão instalados no armazenamento de certificados de todo o sistema do nó:

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

Consulte o guia "Securing Communication with TLS Certificate" para obter mais informações.

Os arquivos colocados no diretório os-files no diretório de configuração da imagem são copiados automaticamente para o sistema de arquivos da imagem criada. O diretório exato será mantido quando eles forem copiados. Por exemplo, se um arquivo existe em um subdiretório chamado os-files/etc, ele é colocado no diretório /etc da imagem criada.

Note

Se o diretório os-files existir, ele não pode estar vazio.

.
├── definition.yaml
└── os-files
    └── etc
        └── ssh
            └── sshd_config

Um dos principais recursos do EIB é fornecer um mecanismo para adicionar pacotes de software adicionais à imagem, para que, quando a instalação for concluída, o sistema seja capaz de aproveitar os pacotes instalados imediatamente. O EIB permite que os usuários especifiquem o seguinte:

O EIB então executará um processo de resolução de pacotes no momento da criação da imagem, tomando a imagem base como entrada, e tentará baixar e instalar todos os pacotes fornecidos, seja especificados por meio da lista ou fornecidos localmente. O EIB baixa todos os pacotes, incluindo quaisquer dependências, para um repositório que existe dentro da imagem de saída e instrui o sistema a instalá-los durante o processo de primeira inicialização. Realizar esse processo durante a criação da imagem garante que os pacotes sejam instalados com sucesso durante a primeira inicialização na plataforma desejada, por exemplo, o nó na borda. Isso também é vantajoso em ambientes onde você deseja incluir os pacotes adicionais na imagem em vez de baixá-los pela rede durante a operação, por exemplo, para ambientes air-gapped ou com rede restrita.

Como um exemplo simples para demonstrar isso, vamos instalar o pacote RPM nvidia-container-toolkit encontrado no repositório NVIDIA suportado por terceiros:

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

O arquivo de definição resultante parece com o seguinte:

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

O exemplo acima é simples, mas para fins de completude, baixe a chave de assinatura do pacote NVIDIA antes de executar a geração da imagem:

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

Warning

Adicionar pacotes RPM adicionais por meio deste método destina-se à adição de componentes de terceiros suportados ou pacotes fornecidos (e mantidos) pelo usuário; este mecanismo não deve ser usado para adicionar pacotes que normalmente não seriam suportados no SUSE Linux Micro. Se este mecanismo for usado para adicionar componentes de repositórios openSUSE (que não são suportados), incluindo de versões ou pacotes de serviço mais recentes, você pode acabar com uma configuração não suportada, especialmente quando a resolução de dependências resulta na substituição de partes principais do sistema operacional, mesmo que o sistema resultante possa parecer funcionar conforme o esperado. Se você não tiver certeza, entre em contato com seu representante SUSE para obter assistência na determinação da capacidade de suporte da configuração desejada.

Note

Um guia mais abrangente com exemplos adicionais pode ser encontrado no guia de instalação de pacotes upstream.

Outro recurso do EIB é sua capacidade de automatizar a implantação de clusters Kubernetes, tanto de nó único quanto de múltiplos nós altamente disponíveis que se inicializam no local (ou seja, não requerem qualquer forma de infraestrutura de gerenciamento centralizada para coordenação). O principal motivador por trás dessa abordagem são as implantações air-gapped ou ambientes com rede restrita, mas também serve como uma maneira de inicializar rapidamente clusters autônomos, mesmo que o acesso total e irrestrito à rede esteja disponível.

Este método permite não apenas a implantação do sistema operacional personalizado, mas também a capacidade de especificar a configuração do Kubernetes, quaisquer componentes em camadas adicionais via gráficos Helm e quaisquer cargas de trabalho do usuário via manifestos do Kubernetes fornecidos. No entanto, o princípio de design por trás deste método é que partimos do pressuposto de que o usuário deseja operar em ambiente air-gapped. Portanto, quaisquer itens especificados na definição da imagem serão incluídos na imagem, o que inclui cargas de trabalho fornecidas pelo usuário. O EIB garante que quaisquer imagens descobertas que sejam exigidas pelas definições sejam copiadas localmente e servidas pelo registro de imagem incorporado no sistema implantado resultante.

Neste próximo exemplo, vamos utilizar nossa definição de imagem existente e especificar uma configuração do Kubernetes (neste exemplo, como ela não lista os sistemas e suas funções, assumimos por padrão que se trata de um nó único), o que instruirá o EIB a provisionar um cluster Kubernetes RKE2 de nó único. Para demonstrar a automação na implantação tanto de cargas de trabalho fornecidas pelo usuário (via manifesto) quanto de componentes em camadas (via Helm), vamos instalar o KubeVirt utilizando o chart Helm SUSE Telco Cloud, assim como o NGINX por meio de um manifesto do Kubernetes. A configuração adicional que precisamos anexar à definição de imagem existente é a seguinte:

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

O arquivo de definição completo resultante deve agora ter a seguinte aparência:

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

Note

Outros exemplos de opções, como implantações de vários nós, rede personalizada e opções/valores de gráfico Helm, podem ser encontrados na documentação upstream.

No último exemplo deste guia de início rápido, vamos configurar a rede que será ativada quando um sistema for provisionado com a imagem gerada pelo EIB. É importante entender que, a menos que uma configuração de rede seja fornecida, o modelo padrão é que o DHCP seja usado em todas as interfaces descobertas no momento da inicialização. No entanto, essa nem sempre é uma configuração desejável, especialmente se o DHCP não estiver disponível e você precisar fornecer configurações estáticas, ou se precisar configurar construções de rede mais complexas, por exemplo, bonds, LACP e VLANs, ou precisar substituir certos parâmetros, por exemplo, nomes de host, servidores DNS e rotas.

O EIB oferece a capacidade de fornecer configurações por nó (onde o sistema em questão é identificado exclusivamente pelo seu endereço MAC), ou uma substituição para fornecer uma configuração idêntica a cada máquina, o que é mais útil quando os endereços MAC do sistema não são conhecidos. Uma ferramenta adicional é usada pelo EIB chamada Network Manager Configurator, ou nmc para abreviar, que é uma ferramenta criada pela equipe SUSE Telco Cloud para permitir que configurações de rede personalizadas sejam aplicadas com base no esquema de rede declarativo nmstate.io e, no momento da inicialização, identificará o nó no qual está inicializando e aplicará a configuração de rede desejada antes que quaisquer serviços sejam iniciados.

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

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: 192.168.122.1
    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

Warning

O exemplo acima está configurado para a sub-rede 192.168.122.0/24 padrão, assumindo que o teste está sendo executado em uma máquina virtual. Por favor, adapte-o para o seu ambiente, não se esquecendo do endereço MAC. Como a mesma imagem pode ser usada para provisionar vários nós, a rede configurada pelo EIB (via nmc) depende de sua capacidade de identificar exclusivamente o nó pelo seu endereço MAC e, portanto, durante a inicialização, o nmc aplicará a configuração de rede correta a cada máquina. Isso significa que você precisará saber os endereços MAC dos sistemas nos quais deseja instalar. Alternativamente, o comportamento padrão é confiar no DHCP, mas você pode utilizar o hook configure-network.sh para aplicar uma configuração comum a todos os nós. Consulte o guia de redes (Chapter 13, Rede de borda) para obter mais detalhes.

A estrutura de arquivos resultante deve ser semelhante a:

├── 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 do NetworkManager necessários serão gerados automaticamente e inseridos na nova imagem de instalação que o EIB criará. Esses arquivos serão aplicados durante o provisionamento do host, resultando em uma configuração de rede completa.

Note

Consulte o componente Edge Networking (Chapter 13, Rede de borda) para obter uma explicação mais abrangente da configuração acima e exemplos desse recurso.