O cluster de gerenciamento é uma implantação única, de local único. O Provisionamento baseado em imagem agrupa todos os componentes em uma única imagem inicializável. Dessa forma, o cluster de gerenciamento inicializará a si mesmo, exigindo complexidade operacional mínima. É a maneira mais simples e direta de colocá-lo em funcionamento.

Clusters downstream, no entanto, são uma história diferente. Em ambientes de telecomunicações, eles são implantados em escala em muitos data centers e locais de borda, muitas vezes sem experiência técnica local disponível. O Provisionamento de Rede Direcionado foi projetado para isso: ele exige que os servidores de destino suportem uma interface de gerenciamento fora de banda, como o Redfish, através da qual o cluster de gerenciamento liga, inspeciona e provisiona remotamente nós bare metal sem qualquer intervenção no local.

Incorporar toda a configuração específica do cluster em uma imagem de inicialização, como o Provisionamento baseado em imagem exigiria, significa que cada variação de local exige uma imagem diferente, e qualquer alteração de configuração requer a reconstrução e redistribuição de imagens em todos os locais. O Provisionamento de Rede Direcionado resolve isso mantendo a imagem do SO genérica e conduzindo toda a configuração específica do cluster, incluindo rede, Kubernetes e perfis de Telecomunicações, a partir do cluster de gerenciamento no momento do provisionamento. Os operadores simplesmente instalam em rack, ligam e conectam o hardware, e o cluster de gerenciamento cuida do resto.

Essa separação também desbloqueia a integração total com GitOps. Como toda a definição do cluster downstream é expressa como manifestos da API de Cluster, ela pode ser armazenada no Git e reconciliada pelo Fleet em todos os locais, tornando as operações de provisionamento, configuração e ciclo de vida totalmente auditáveis e repetíveis sem intervenção manual.

Usando o Edge Image Builder (Capítulo 12, Edge Image Builder) para criar uma nova imagem ISO com a pilha de gerenciamento incluída. Você pode então usar esta imagem ISO para instalar um novo cluster de gerenciamento em VMs ou bare-metal.

Nota

Para obter mais informações sobre como implantar um novo cluster de gerenciamento, consulte o guia do SUSE Telco Cloud Management Cluster (Parte V, “Configurando o cluster de gerenciamento”).

Nota

Para obter mais informações sobre como usar o Edge Image Builder, consulte o guia do Edge Image Builder (Capítulo 5, Clusters autônomos com o Edge Image Builder).

Assim que tivermos o cluster de gerenciamento em funcionamento, podemos usá-lo para implantar um cluster downstream de nó único com todos os recursos de Telco habilitados e configurados usando o fluxo de trabalho de provisionamento de rede direcionado.

O diagrama a seguir mostra o fluxo de trabalho de alto nível para implantá-lo:

Nota

Para obter mais informações sobre como implantar um cluster downstream, consulte o guia de provisionamento automatizado do SUSE Telco Cloud. (Parte VII, “Provisionamento de rede direcionado totalmente automatizado”)

Nota

Para obter mais informações sobre os recursos do Telco, consulte o guia de recursos do Telco do SUSE Telco Cloud. (Parte VI, “Configuração de recursos de Telco”)

Assim que tivermos o cluster de gerenciamento em funcionamento, podemos usá-lo para implantar um cluster downstream de alta disponibilidade com o MetalLB como balanceador de carga usando o fluxo de trabalho de provisionamento de rede direcionado.

O diagrama a seguir mostra o fluxo de trabalho de alto nível para implantá-lo:

Nota

Para obter mais informações sobre como implantar um cluster downstream, consulte o guia de provisionamento automatizado do SUSE Telco Cloud (Parte VII, “Provisionamento de rede direcionado totalmente automatizado”)

Nota

Para obter mais informações sobre o MetalLB, consulte aqui: (Capítulo 17, MetalLB)

Este método é útil para cenários em que o hardware de destino suporta gerenciamento fora de banda e deseja-se um fluxo de gerenciamento de infraestrutura totalmente automatizado.

Um cluster de gerenciamento é configurado para fornecer APIs declarativas que permitem o gerenciamento de inventário e estado de servidores bare-metal de clusters downstream, incluindo inspeção, limpeza e provisionamento/desprovisionamento automatizados.

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

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

A SUSE Telco Cloud Management Cluster Documentation (Parte V, “Configurando o cluster de gerenciamento”) contém exemplos de uso mais avançado do Metal³ para casos de uso em 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"

Como o EIB é executado dentro de um contêiner, precisamos montar um diretório de configuração a partir do host, permitindo que você especifique a configuração desejada e, durante o processo de compilação, o EIB tenha acesso a quaisquer arquivos de entrada e artefatos de suporte necessários. Este diretório deve seguir uma estrutura específica. Vamos criá-lo, assumindo que este diretório existirá em seu diretório home e será chamado de "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.2, vamos garantir que a imagem seja copiada para o diretório de configuração:

cp /path/to/SL-Micro.x86_64-6.2-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.

O diretório de configuração neste ponto deve estar assim:

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

O arquivo de definição descreve a maioria das opções configuráveis que o Edge Image Builder suporta; um exemplo completo de opções pode ser encontrado aqui, e recomendamos que você dê uma olhada no guia de construção de imagens upstream para exemplos mais abrangentes do que o que vamos analisar abaixo. Vamos começar com um arquivo de definição muito básico para nossa imagem de SO:

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

Esta 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ções posteriores é uma imagem iso chamada slemicro.iso, esperada para estar localizada em $CONFIG_DIR/base-images/slemicro.iso. Ela também descreve que, após o EIB terminar de modificar a imagem, a imagem de saída será nomeada eib-image.iso e, por padrão, residirá em $CONFIG_DIR.

Agora, nossa estrutura de diretórios deve estar assim:

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

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

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

5.3.2 Configurando usuários do SO #

 

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

Nota

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.

5.3.3 Configurando o horário do SO #

 

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

• O timezone especifica o fuso horário no formato "Região/Localidade" (por exemplo, "Europe/London"). A lista completa pode ser encontrada executando timedatectl list-timezones em um sistema Linux.

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

• forceWait - Solicita que o chronyd tente sincronizar as fontes de tempo antes de iniciar outros serviços, com um tempo limite de 180s.

• pools - Especifica uma lista de pools que o chronyd usará como fontes de dados (usando iburst para melhorar o tempo necessário para a sincronização inicial).

• servers - Especifica uma lista de servidores que o chronyd usará como fontes de dados (usando iburst para melhorar o tempo necessário para a sincronização inicial).

Nota

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

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

5.3.5 Adicionando Arquivos de sistema operacional #

 

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.

Nota

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

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

5.3.6 Configurando pacotes RPM #

 

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:

• Pacotes por seus nomes dentro de uma lista na definição da imagem

• Repositórios de rede para pesquisar esses pacotes

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

• Por meio de um diretório $CONFIG_DIR/rpms, carregue pacotes RPM personalizados que não existem em repositórios de rede

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

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

Atenção

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.

Nota

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

5.3.7 Configurando o cluster Kubernetes e as cargas de trabalho do usuário #

 

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

Nota

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.

5.3.8 Configurando a rede #

 

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

Atenção

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 (Capítulo 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.

Nota

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

Agora que temos uma imagem base e uma definição de imagem para o EIB consumir, vamos prosseguir e criar a imagem. Para isso, usamos simplesmente 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.6/edge-image-builder:1.3.3.1 \
build --definition-file iso-definition.yaml

A saída do comando deve ser semelhante a:

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 compilação cria uma pasta com carimbo de data/hora em $CONFIG_DIR/_build/ que inclui os logs da compilação, os artefatos usados durante a compilação, e os diretórios combustion e artefacts, que contêm todos os scripts e artefatos que são adicionados à imagem CRB.

O conteúdo deste diretório deve ser semelhante a:

├── 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 a compilação falhar, eib-build.log é o primeiro log que contém informações. A partir daí, ele o direcionará para o componente que falhou para depuração.

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

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

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

O Rancher fornece várias funcionalidades principais para a pilha SUSE Telco Cloud:

O SUSE Telco Cloud está usando o Capítulo 12, Edge Image Builder para personalizar imagens base do sistema operacional SUSE Linux Micro. Siga Seção 63.6, “Instalação do Rancher” para uma instalação air-gapped do Rancher sobre clusters Kubernetes provisionados pelo EIB.

Todos os componentes SUSE Telco Cloud 3.6, incluindo extensões do Dashboard, são distribuídos como artefatos OCI. Para instalar as Extensões SUSE Telco Cloud, você pode usar a interface do Dashboard do Rancher, Helm ou Fleet:

7.1.2 Instalando com Helm #

 

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

Nota

As extensões precisam ser instaladas no namespace cattle-ui-plugin-system.

Nota

Após a instalação de uma extensão, a interface do Dashboard do Rancher precisa ser recarregada.

7.1.3 Instalando com Fleet #

 

A instalação de extensões do Dashboard com Fleet requer a definição de um recurso gitRepo que aponte para um repositório Git com arquivo(s) de configuração de bundle fleet.yaml personalizado(s).

# 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: "306.0.4+up1.3.3"

Nota

A propriedade releaseName é obrigatória e precisa corresponder ao nome da extensão para que ela seja instalada 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/
EOF

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

Uma vez que as extensões estejam instaladas, elas são listadas na seção Extensions sob as guias Installed. Como elas não são instaladas via Apps/Marketplace, elas são marcadas com o rótulo Third-Party.

A extensão do KubeVirt fornece gerenciamento básico de máquinas virtuais para a interface do Dashboard do Rancher. Suas capacidades estão descritas em Seção 19.7.2, “Usando a Extensão do Painel do Rancher para KubeVirt”.

A pilha SUSE Telco Cloud fornece um gráfico helm rancher-turtles-providers que habilita determinados provedores CAPI por meio da CAPIProvider API:

Apenas os provedores padrão instalados por meio do agrupador são suportados – provedores alternativos de plano de controle, de inicializar e de infraestrutura não são suportados atualmente como parte da pilha SUSE Telco Cloud.

Desde o Rancher 2.13, o Rancher Turtles é habilitado por padrão ao instalar o Rancher.

Os Provedores do Rancher Turtles podem ser instalados seguindo o guia Metal3 Quickstart (Capítulo 4, Implantações automatizadas de BMC com Metal³) ou a documentação do Management Cluster (Parte V, “Configurando o cluster de gerenciamento”).

O Fleet vem incorporado ao Rancher, mas também pode ser instalado como um aplicativo independente em qualquer cluster Kubernetes usando Helm.

O Rancher usa o Fleet para implantar aplicativos em clusters gerenciados. A entrega contínua com o Fleet introduz o GitOps em escala, projetado para gerenciar aplicativos em execução em um grande número de clusters.

O Fleet se destaca como uma parte integrada do Rancher. Os clusters gerenciados com o Rancher recebem automaticamente o Fleet agent implantado como parte do processo de instalação/importação e o cluster fica imediatamente disponível para ser gerenciado pelo Fleet.

O Fleet vem incorporado no Rancher e é gerenciado pela opção Entrega contínua na interface do usuário do Rancher.

A seção Entrega contínua consiste nos seguintes itens:

A seção de navegação "Avançado" fornece visões gerais de recursos de nível inferior do Fleet. Um bundle é um recurso interno usado para a orquestração de recursos a partir do Git. Quando um repositório Git é verificado, ele produz um ou mais bundles.

Para encontrar bundles relevantes para um repositório específico, vá para 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 é criado. Para visualizar os detalhes do BundleDeployment, clique no botão Graph no canto superior direito da página de detalhes do repositório Git. Um gráfico de Repositório > Bundles > BundleDeployments é carregado. Clique no BundleDeployment no gráfico para ver seus detalhes e clique em Id para visualizar o YAML do BundleDeployment.

Para obter informações adicionais sobre dicas de solução de problemas do Fleet, consulte aqui.

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

O projeto Fleet inclui um repositório fleet-examples que cobre todos os casos de uso para estrutura de repositório Git.

Usamos o SUSE Linux Micro como o sistema operacional base para nossa pilha de plataforma. Isso nos fornece uma base segura, estável e mínima para construir.

O SUSE Linux Micro é único em seu uso de instantâneos do sistema de arquivos (Btrfs) para permitir rollbacks fáceis caso algo dê errado durante o fazer upgrade. Isso permite fazer upgrade remoto para toda a plataforma, mesmo sem acesso físico em caso de problemas.

O SUSE Telco Cloud usa o Metal³ para gerenciar o ciclo de vida de hardware físico, como servidores. O hardware precisa oferecer suporte a um protocolo de gerenciamento fora de banda que seja suportado pelo Metal³ (por exemplo, Redfish). Quando um cluster de gerenciamento SUSE Telco Cloud provisiona ou desprovisiona clusters downstream, o Metal³ interagirá com o BMC de um servidor via Redfish. As seguintes ações geralmente fazem parte dessa interação:

Essa abordagem é útil para cenários onde o hardware de destino oferece suporte a gerenciamento fora de banda e um fluxo de gerenciamento de infraestrutura totalmente automatizado é desejado.

O Metal³ e o CAPI fornecem APIs declarativas que permitem o gerenciamento de inventário e estado de servidores bare-metal, incluindo inspeção, limpeza e provisionamento/desprovisionamento automatizados.

SUSE Telco Cloud usa o EIB para a configuração simplificada e rápida de imagens personalizadas do SUSE Linux Micro para uma variedade de cenários. Esses cenários incluem o bootstrapping de máquinas virtuais e bare metal:

Documentação abrangente para o uso e teste do Edge Image Builder pode ser encontrada aqui.

Adicionalmente, veja Capítulo 5, Clusters autônomos com o Edge Image Builder cobrindo um cenário básico de implantação.

Assim que estiver familiarizado com esta ferramenta, encontre mais informações úteis em nossa página seção de Dicas e Truques do EIB (Parte X, “Dicas e truques”).

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

O NetworkManager armazena 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/.

Detalhes sobre o NetworkManager podem ser encontrados na documentação do SUSE Linux Micro.

O nmstate é uma biblioteca amplamente adotada (com uma ferramenta de CLI associada) que oferece uma API declarativa para configurações de rede por meio de um esquema predefinido.

Detalhes sobre o nmstate podem ser encontrados na documentação upstream.

As opções de personalização de rede disponíveis no SUSE Telco Cloud são obtidas por meio de uma ferramenta de CLI chamada NetworkManager Configurator ou nmc, para abreviar. Ela aproveita a funcionalidade fornecida pela biblioteca nmstate e, como tal, é totalmente capaz de configurar endereços IP estáticos, servidores DNS, VLANs, vínculo de rede, bridges, etc. Esta ferramenta nos permite gerar configurações de rede a partir de estados desejados predefinidos e aplicá-las em muitos nós diferentes de forma automatizada.

Detalhes sobre o NetworkManager Configurator (nmc) podem ser encontrados no repositório upstream.

O SUSE Telco Cloud utiliza o nmc para as personalizações de rede nos vários modelos de provisionamento diferentes: * Configurações de rede personalizadas nos cenários de provisionamento de rede direcionado (Capítulo 4, Implantações automatizadas de BMC com Metal³) * Configurações estáticas declarativas nos cenários de Provisionamento Baseado em Imagem (Capítulo 5, Clusters autônomos com o Edge Image Builder)

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

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

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

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

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

cat << EOF > $CONFIG_DIR/definition.yaml
apiVersion: 1.3
image:
  arch: x86_64
  imageType: raw
  baseImage: SL-Micro.x86_64-6.2-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.2-Base-GM.raw

13.5.5 Definindo as configurações de rede #

 

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

mkdir -p $CONFIG_DIR/network

Como mencionado anteriormente, a ferramenta NetworkManager Configurator (nmc) espera uma entrada na forma de um esquema predefinido. Você pode encontrar como configurar uma ampla variedade de diferentes opções de rede na documentação de exemplos upstream do NMState.

Este guia explicará 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 uma ponte de rede

Atenção

O uso de configurações de rede completamente diferentes não é recomendado em compilações de produção, especialmente se estiver configurando clusters Kubernetes. As configurações de rede geralmente devem ser homogêneas entre os nós ou, pelo menos, entre as funções dentro de um determinado cluster. Este guia inclui várias opções diferentes apenas para servir como uma referência de exemplo.

Nota

O seguinte pressupõe uma rede libvirt padrão com um intervalo de endereços IP 192.168.122.1/24. Ajuste de acordo se isso for diferente em seu ambiente.

Vamos criar os estados desejados para o primeiro nó que chamaremos 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: 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: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

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

Atenção

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

A seguir, temos o segundo nó, que chamaremos de node2.suse.com e que 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: 192.168.122.1
      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

Neste exemplo, definimos um estado desejado de duas interfaces Ethernet (eth0 e eth1) que não estão habilitando o endereçamento IP, bem como um vínculo de rede com uma política round-robin e seu respectivo endereço, que será usado para encaminhar o tráfego de rede.

Por último, criaremos o terceiro e último arquivo de estado desejado, que utilizará uma ponte de rede e que chamaremos 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: 192.168.122.1
      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

O diretório de configuração neste ponto deve estar assim:

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

Nota

Os nomes dos arquivos no diretório network/ são intencionais. Eles 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.6/edge-image-builder:1.3.3.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.6/edge-image-builder:1.3.3.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

13.5.9 Configurações de rede personalizadas #

 

Já cobrimos a configuração de rede padrão para o Edge Image Builder, que depende do NetworkManager Configurator. No entanto, também existe a opção de modificá-la por meio de um script personalizado. Embora essa opção seja muito flexível e também não dependa do endereço MAC, sua limitação decorre do fato de que usá-la é muito menos conveniente ao inicializar vários nós com uma única imagem.

Nota

Recomenda-se usar a configuração de rede padrão por meio de arquivos que descrevem os estados de rede desejados no diretório /network. Opte pelo script personalizado apenas quando esse comportamento não for aplicável ao seu caso de uso.

Vamos construir e provisionar um nó de borda usando uma estrutura de configuração diferente. Siga todos os passos começando de Seção 13.5.3, “Criando o diretório de configuração da imagem” até Seção 13.5.5, “Definindo as configurações de rede”.

Neste exemplo, criaremos um script personalizado que aplica uma configuração estática para a interface eth0 em todos os nós provisionados, além de remover e desabilitar as conexões com fio criadas automaticamente pelo NetworkManager. Isso é benéfico em situações em que você deseja garantir que cada nó em seu cluster tenha uma configuração de rede idêntica e, como tal, você não precisa se preocupar com o endereço MAC de cada nó antes da criação da imagem.

Vamos começar armazenando 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

Agora que a configuração estática foi criada, também criaremos 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

O binário nmc ainda será incluído por padrão, portanto, ele também pode ser usado no script configure-network.sh, se necessário.

Atenção

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

O diretório de configuração neste ponto deve estar assim:

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

Vamos construir a imagem:

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

Assim que a imagem for construída com sucesso, vamos criar uma máquina virtual usando-a:

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. Assim que terminar, faça login no sistema com as credenciais fornecidas.

Verifique se o roteamento está configurado corretamente:

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 está configurada estaticamente usando nosso arquivo de conexão e se 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

O K3s é uma distribuição Kubernetes totalmente compatível e leve, focada em Edge, IoT, ARM - otimizada para facilidade de uso e ambientes com recursos limitados.

O RKE2 combina o melhor dos dois mundos da versão 1.x do RKE (doravante denominada RKE1) e do 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 pontos, o K3s divergiu do Kubernetes upstream para otimizar implantações de edge, mas o RKE1 e o RKE2 podem permanecer estreitamente alinhados com o upstream.

O RKE2 é uma peça fundamental da pilha SUSE Telco Cloud. Ele fica sobre o SUSE Linux Micro (Capítulo 10, SUSE Linux Micro), fornecendo uma interface Kubernetes padrão necessária para implantar cargas de trabalho de Edge.

Se você está seguindo este guia, ele pressupõe que você já tenha o seguinte disponível:

O SUSE Storage utiliza recursos do Kubernetes chamados StorageClass para provisionar automaticamente objetos PersistentVolume para pods. Pense em StorageClass como uma maneira de os administradores descreverem as classes ou perfis de armazenamento que 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 nosso StorageClass disponível, precisamos de um PersistentVolumeClaim referenciando-o. Uma PersistentVolumeClaim (PVC) é uma solicitação de armazenamento feita por um usuário. PVCs consomem recursos de PersistentVolume. As solicitações podem pedir tamanhos e modos de acesso específicos (por exemplo, podem ser montadas uma vez como leitura/gravação ou várias vezes como somente leitura).

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

É isso! Assim que tivermos o PersistentVolumeClaim criado, podemos prosseguir com a anexação dele a um Pod. Quando o Pod é implantado, o Kubernetes cria o volume Longhorn e o vincula ao Pod se houver 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, mas importante. Mencionamos brevemente alguns dos recursos mais comuns do Kubernetes, no entanto, sugerimos que você se familiarize com a documentação de terminologia que o Longhorn oferece.

Neste exemplo, o resultado deve ser semelhante a isto:

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 SUSE Storage com kubectl ou Helm, precisará configurar um controlador Ingress para permitir tráfego externo no cluster. A autenticação não está habilitada por padrão. Se o aplicativo de catálogo do Rancher foi usado, o Rancher criou automaticamente um controlador Ingress com controle de acesso (o rancher-proxy).

O SUSE Telco Cloud está usando o Capítulo 12, Edge Image Builder para personalizar imagens base do SUSE Linux Micro OS. Vamos demonstrar como fazer isso para provisionar um cluster RKE2 com o SUSE Storage sobre ele.

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.3
image:
  imageType: iso
  baseImage: SL-Micro.x86_64-6.2-Base-SelfInstall-GM.install.iso
  arch: x86_64
  outputImageName: eib-image.iso
kubernetes:
  version: v1.35.4+rke2r1
  helm:
    charts:
      - name: suse-storage
        releaseName: longhorn
        version: 1.11.2
        repositoryName: rancher-application-collection
        targetNamespace: longhorn-system
        createNamespace: true
        installationNamespace: kube-system
    repositories:
      - name: rancher-application-collection
        url: oci://dp.apps.rancher.io/charts
        authentication:
          username: $APPS.RANCHER.IO_USERNAME
          password: $APPS.RANCHER.IO_ACCESS_TOKEN
embeddedArtifactRegistry:
  registries:
    - uri: dp.apps.rancher.io
      authentication:
        username: $APPS.RANCHER.IO_USERNAME
        password: $APPS.RANCHER.IO_ACCESS_TOKEN
  images:
    - name: dp.apps.rancher.io/containers/kubernetes-csi-external-attacher:4.11.0-13.2
    - name: dp.apps.rancher.io/containers/kubernetes-csi-external-provisioner:5.3.0-14.1
    - name: dp.apps.rancher.io/containers/kubernetes-csi-external-resizer:2.1.0-6.2
    - name: dp.apps.rancher.io/containers/kubernetes-csi-external-snapshotter:8.5.0-13.2
    - name: dp.apps.rancher.io/containers/kubernetes-csi-livenessprobe:2.18.0-13.2
    - name: dp.apps.rancher.io/containers/kubernetes-csi-node-driver-registrar:2.16.0-13.2
    - name: dp.apps.rancher.io/containers/longhorn-backing-image-manager:1.11.2-4.1
    - name: dp.apps.rancher.io/containers/longhorn-engine:1.11.2-4.2
    - name: dp.apps.rancher.io/containers/longhorn-instance-manager:1.11.2-4.3
    - name: dp.apps.rancher.io/containers/longhorn-manager:1.11.2-4.2
    - name: dp.apps.rancher.io/containers/longhorn-share-manager:1.11.2-4.1
    - name: dp.apps.rancher.io/containers/longhorn-ui:1.11.2-4.1
    - name: dp.apps.rancher.io/containers/rancher-support-bundle-kit:0.0.84-9.4
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 por meio de 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.6/edge-image-builder:1.3.3.1 build --definition-file $CONFIG_DIR/iso-definition.yaml

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

Certifique-se de que o SUSE Storage tenha sido 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

Esta instalação não funcionará para ambientes totalmente air-gapped. Nesses casos, consulte Seção 63.8, “Instalação do SUSE Storage”.

O SUSE Telco Cloud fornece uma configuração mais enxuta do SUSE Security como ponto de partida para implantações de borda.

SUSE Telco Cloud está usando Capítulo 12, Edge Image Builder para personalizar imagens base do SUSE Linux Micro OS. Siga Seção 63.7, “Instalação do SUSE Security” para uma instalação air-gapped do SUSE Security sobre clusters Kubernetes provisionados pelo EIB.

O SUSE Telco Cloud usa o MetalLB de três maneiras principais:

Nota

Para ser possível expor a API, o Endpoint Copier Operator (Capítulo 18, Operador Endpoint Copier) é usado para manter sincronizados os endpoints da API do K8s do serviço kubernetes para um serviço kubernetes-vip LoadBalancer.

A instalação do MetalLB no modo L2 é descrita em Capítulo 60, MetalLB no K3s (usando o modo camada 2) e para o modo L3 em Capítulo 61, MetalLB no K3s (usando modo de camada 3).

Um guia sobre a instalação do MetalLB à frente do kube-api-server para obter uma topologia de alta disponibilidade pode ser encontrado em Capítulo 62, MetalLB na frente do servidor de API do Kubernetes.

Na SUSE Telco Cloud, o Operador Endpoint Copier desempenha um papel crucial na obtenção de uma configuração de Alta Disponibilidade (HA) para clusters K3s/RKE2. Isso é realizado criando um serviço kubernetes-vip do tipo LoadBalancer, garantindo que seu Endpoint permaneça em sincronização constante com o Endpoint do Kubernetes. MetalLB (Capítulo 17, MetalLB) é utilizado para gerenciar o serviço kubernetes-vip, já que o endereço IP exposto é usado por outros nós para ingressar no cluster.

A documentação abrangente para usar o Operador Endpoint Copier pode ser encontrada aqui.

Além disso, consulte nosso guia (Capítulo 60, MetalLB no K3s (usando o modo camada 2)) sobre como obter uma configuração de HA para K3s/RKE2 usando o Operador Endpoint Copier e MetalLB.

Atualmente, o Operador Endpoint Copier está limitado a trabalhar com apenas um Serviço/Endpoint. Melhorias para oferecer suporte a múltiplos Serviços/Endpoints estão planejadas para o futuro.

O KubeVirt permite gerenciar Máquinas Virtuais com o Kubernetes juntamente com o restante de suas cargas de trabalho conteinerizadas. Ele faz isso executando a parte do espaço do usuário da pilha de virtualização do Linux em um contêiner. Isso minimiza os requisitos no sistema host, permitindo uma configuração e gerenciamento mais fáceis.

Se você está seguindo este guia, presumimos que você já tenha o seguinte disponível:

Este guia não o conduzirá pela implantação do Kubernetes, mas pressupõe que você tenha instalado a versão apropriada do SUSE Telco Cloud de K3s ou RKE2 e que você tenha seu kubeconfig configurado adequadamente para que comandos kubectl padrão possam ser executados como superusuário. Presumimos que seu nó forma um cluster de nó único, embora não sejam esperadas diferenças significativas para implantação de vários nós.

SUSE Telco Cloud A virtualização é implantada por meio de três charts Helm separados, especificamente:

Cada um desses gráficos Helm é versionado de acordo com a versão do SUSE Telco Cloud que você está usando atualmente. Para uso em produção/suportado, empregue os artefatos que podem ser encontrados no Registro SUSE.

Primeiro, certifique-se de que seu acesso kubectl esteja funcionando:

$ kubectl get nodes

Isso deve mostrar 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 prosseguir para instalar os gráficos Helm KubeVirt e Importador de Dados Conteinerizados (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, você deverá ter todos os componentes do KubeVirt e do CDI implantados. Você pode validar isso verificando todos os recursos implantados nos namespaces kubevirt-system e cdi-system.

Verifique os recursos do KubeVirt:

$ kubectl get all -n kubevirt-system

Isso deve mostrar 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

Isso deve mostrar 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) VirtualMachine estão implantadas, você pode validar com:

$ kubectl explain virtualmachine

Isso deve imprimir a definição do objeto VirtualMachine, que deve ser exibida da seguinte forma:

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 o KubeVirt e o CDI estão implantados, vamos definir uma máquina virtual simples baseada no openSUSE Tumbleweed. Esta máquina virtual tem a mais simples das configurações, usando "rede de pod" padrão para uma configuração de rede idêntica a qualquer outro pod. Ela também emprega armazenamento não persistente, garantindo que o armazenamento seja efêmero, assim como em qualquer contêiner que não possua um PVC.

$ cat <<EOF > user-data.yaml
#cloud-config
disable_root: false
ssh_pwauth: True
users:
  - default
  - name: suse
    groups: sudo
    shell: /bin/bash
    sudo:  ALL=(ALL) NOPASSWD:ALL
    lock_passwd: False
    plain_text_passwd: 'suse'
EOF
$ 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: quay.io/containerdisks/opensuse-tumbleweed:1.0.0
        name: tumbleweed-containerdisk-0
      - cloudInitNoCloud:
          userDataBase64: $(cat user-data.yaml | base64 -w 0)
        name: cloudinitdisk
EOF

Isso deve exibir que um VirtualMachine foi criado:

virtualmachine.kubevirt.io/tumbleweed created

Esta definição de VirtualMachine é mínima, especificando pouco sobre a configuração. Ela simplesmente descreve que é um tipo de máquina "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 que é armazenada em uma imagem de contêiner de um repositório de imagens remoto), e especifica um disco cloudInit codificado em base64, que usamos apenas para criação de usuário e imposição de senha no momento da inicialização (use base64 -d para decodificá-lo).

Esta máquina leva alguns minutos para inicializar, pois precisa baixar a imagem de disco do openSUSE Tumbleweed, mas assim que o fizer, você poderá visualizar mais detalhes sobre a máquina virtual verificando as informações da máquina virtual:

$ kubectl get vmi

Isso deve exibir o nó no qual a máquina virtual foi iniciada e o endereço IP da máquina virtual. Lembre-se, como ela usa rede de pod, o endereço IP relatado será igual ao de qualquer outro pod, e roteável como tal:

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 que roteia o tráfego diretamente para os pods (por exemplo, Cilium), você deve conseguir ssh diretamente para a própria 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")

Uma vez dentro desta máquina virtual, você pode explorar, mas lembre-se de que ela é limitada em termos de recursos e possui apenas 1 GB de espaço em disco. Quando terminar, Ctrl-D ou exit para desconectar da sessão SSH.

O processo da máquina virtual ainda está envolvido em um pod padrão do Kubernetes. O CRD VirtualMachine é uma representação da máquina virtual desejada, mas o processo no qual a máquina virtual é realmente iniciada é via pod virt-launcher, um pod padrão do Kubernetes, assim como qualquer outra aplicação. Para cada máquina virtual iniciada, você pode ver que existe um pod virt-launcher:

$ kubectl get pods

Isso deve mostrar o único pod virt-launcher para a máquina Tumbleweed que definimos:

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

Se dermos uma olhada neste pod virt-launcher, você verá que ele está executando os processos libvirt e qemu-kvm. Podemos entrar no próprio pod e dar uma olhada nos bastidores, observando que você precisa adaptar o seguinte comando para o nome do seu pod:

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

Assim que estiver no pod, tente executar comandos virsh juntamente com a observação dos processos. Você verá o binário qemu-system-x86_64 em execução, juntamente com certos processos para monitorar a máquina virtual. Você também verá a localização 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

Finalmente, vamos excluir esta máquina virtual para limpar:

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

Junto com as ferramentas de CLI padrão do Kubernetes, isto é, kubectl, o KubeVirt vem com um utilitário de CLI complementar que permite interagir com seu cluster de uma maneira que preenche algumas lacunas entre o mundo da virtualização e o mundo para o qual o Kubernetes foi projetado. Por exemplo, a ferramenta virtctl oferece a capacidade de gerenciar o ciclo de vida de máquinas virtuais (iniciar, parar, reiniciar etc.), fornecendo acesso aos consoles virtuais, fazendo upload de imagens de máquinas virtuais, bem como interagindo com recursos do Kubernetes, como serviços, sem usar a API ou os CRDs diretamente.

Vamos baixar a versão estável mais recente da ferramenta virtctl:

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

Se você estiver usando uma arquitetura diferente ou uma máquina que não seja Linux, poderá encontrar outras versões aqui. Você precisa tornar isso executável antes de prosseguir, e pode ser útil movê-lo para um local dentro do seu $PATH:

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

Você pode então usar a ferramenta de linha de comando virtctl para criar máquinas virtuais. Vamos replicar nossa máquina virtual anterior, observando que estamos enviando a saída diretamente para o kubectl apply:

$ cat <<EOF >  user-data.yaml
#cloud-config
disable_root: false
ssh_pwauth: True
users:
  - default
  - name: suse
    groups: sudo
    shell: /bin/bash
    sudo:  ALL=(ALL) NOPASSWD:ALL
    lock_passwd: False
    plain_text_passwd: 'suse'
EOF
$ alias virtctl=echo
$ virtctl create vm --name virtctl-example --memory=1Gi \
    --volume-containerdisk=src:quay.io/containerdisks/opensuse-tumbleweed:1.0.0 \
    --cloud-init-user-data "$(cat user-data.yaml | base64 -w 0)"

Isso deve mostrar a máquina virtual em execução (ela deve iniciar muito mais rápido desta vez, já que a imagem do contêiner estará em cache):

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

Agora podemos usar virtctl para conectar diretamente à máquina virtual:

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

Existem muitos outros comandos que podem ser usados pela virtctl. Por exemplo, virtctl console pode lhe dar acesso ao console serial se a rede não estiver funcionando, e você pode usar virtctl guestosinfo para obter informações abrangentes do SO, desde que o convidado tenha o qemu-guest-agent instalado e em execução.

Finalmente, vamos pausar e retomar a máquina virtual:

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

Você descobre que o objeto VirtualMachine aparece como Pausada e o objeto VirtualMachineInstance aparece como Em execução, mas READY=False:

$ 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

Você também descobre que não consegue mais 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 ser capazes de restabelecer uma conexão:

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

Finalmente, vamos remover a máquina virtual:

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

Nesta seção, mostramos como você pode expor máquinas virtuais como serviços padrão do Kubernetes e disponibilizá-las por meio do serviço de entrada do Kubernetes, por exemplo, Traefik com RKE2 ou Traefik com K3s. Este documento pressupõe que esses componentes já estejam configurados adequadamente e que você tenha um ponteiro DNS apropriado, por exemplo, via curinga, para apontar para seus nós de servidor Kubernetes ou seu IP virtual de entrada para a resolução de entrada adequada.

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

Vamos criar esta máquina virtual agora:

$ cat <<EOF > user-data.yaml
#cloud-config
disable_root: false
ssh_pwauth: True
users:
  - default
  - name: suse
    groups: sudo
    shell: /bin/bash
    sudo:  ALL=(ALL) NOPASSWD:ALL
    lock_passwd: False
    plain_text_passwd: 'suse'
EOF
$ 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: quay.io/containerdisks/opensuse-tumbleweed:1.0.0
        name: tumbleweed-containerdisk-0
      - cloudInitNoCloud:
          userDataBase64: $(cat user-data.yaml | base64 -w 0)
        name: cloudinitdisk
EOF

Quando esta máquina virtual tiver iniciado com sucesso, podemos usar o comando virtctl para expor a VirtualMachineInstance com uma porta externa de 8080 e uma porta de destino de 80 (onde o NGINX escuta por padrão). Usamos o comando virtctl aqui, pois ele entende o mapeamento entre o objeto da máquina virtual e o pod. Isso cria um novo serviço para nós:

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

Teremos então um serviço apropriado 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

Em seguida, se você usar kubectl create ingress, podemos criar um objeto ingress que aponte para este serviço. Adapte a URL (conhecida como "host" no objeto ingress) aqui para corresponder à sua configuração de DNS e certifique-se de apontá-la para a porta 8080:

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

Com o DNS configurado corretamente, você deve conseguir usar o curl na URL imediatamente:

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

Vamos fazer uma limpeza removendo esta máquina virtual e seus recursos de serviço e ingress:

$ 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

SUSE Telco Cloud A extensão de Virtualização fornece uma extensão da interface do usuário para o Rancher Manager, permitindo o gerenciamento básico de máquinas virtuais usando o painel do Rancher.

19.7.2 Usando a Extensão do Painel do Rancher para KubeVirt #

 

A extensão introduz uma nova seção KubeVirt ao Cluster Explorer. Esta seção é adicionada a qualquer cluster gerenciado que tenha o KubeVirt instalado.

A extensão permite que você interaja diretamente com os recursos de Máquina Virtual do KubeVirt para gerenciar o ciclo de vida das Máquinas Virtuais.

19.7.2.1 Criando uma máquina virtual #

 

1. Navegue até Cluster Explorer clicando em um cluster gerenciado habilitado para KubeVirt na navegação à esquerda.

2. Navegue até a página KubeVirt > Virtual Machines e clique em Create from YAML no canto superior direito da tela.

3. Preencha ou cole uma definição de máquina virtual e pressione Create. Use a definição de máquina virtual da seção Implantando Máquinas Virtuais como inspiração.

19.7.2.2 Ações de Máquina Virtual #

 

Você pode usar o menu de ações acessado a partir da lista suspensa ⋮ à direita de cada máquina virtual para realizar ações de iniciar, parar, pausar ou reinicialização suave. Alternativamente, você também pode usar ações em grupo na parte superior da lista selecionando as máquinas virtuais nas quais deseja realizar a ação.

A execução das ações pode ter um efeito na Estratégia de Execução da Máquina Virtual. Consulte a tabela na documentação do KubeVirt para obter mais detalhes.

19.7.2.3 Acessando o console da máquina virtual #

 

A lista de "Máquinas virtuais" fornece uma lista suspensa Console que permite conectar à máquina usando VNC ou Console Serial. Esta ação só está disponível para máquinas em execução.

Em alguns casos, leva um pouco de tempo até que o console esteja acessível em uma máquina virtual recém-iniciada.

SUSE Telco Cloud está usando Capítulo 12, Edge Image Builder para personalizar imagens base do SUSE Linux Micro OS. Siga Seção 63.9, “Instalação do KubeVirt e CDI” para uma instalação air-gapped do KubeVirt e do CDI sobre clusters Kubernetes provisionados pelo EIB.

O SUSE Telco Cloud usa o SUC para facilitar várias operações de "Dia 2" relacionadas a atualizações de versão do SO e do Kubernetes em clusters de gerenciamento e downstream.

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

O SUC também é usado dentro do Capítulo 21, Upgrade Controller. Para saber mais sobre as principais diferenças entre o SUC e o Upgrade Controller, consulte Seção 21.2, “Upgrade Controller vs 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 for gerenciado pelo Rancher, ou se a sua versão do Rancher for inferior a v2.10.0.

Recomendamos que você instale o SUC por meio do Fleet (Capítulo 9, Fleet) localizado no repositório suse-edge/fleet-examples.

Nota

Os recursos oferecidos pelo repositório suse-edge/fleet-examples devem ser sempre usados a partir de uma versão do fleet-examples válida. Para determinar qual versão você precisa usar, consulte as Notas de Versão (Capítulo 75, Notas de versão).

Se você não puder usar o Fleet para a instalação do SUC, poderá instalá-lo através do repositório de Helm charts do Rancher ou incorporar o Helm chart do Rancher em seu próprio fluxo de trabalho GitOps de terceiros.

Esta seção aborda:

20.2.1 Instalação do Upgrade Controller do Sistema via Fleet #

 

Usando o Fleet, existem dois recursos possíveis que podem ser usados para implantar o SUC:

• Recurso GitRepo - para casos de uso onde um servidor Git externo/local está disponível. Para instruções de instalação, consulte Instalação do Upgrade Controller - GitRepo (Seção 20.2.1.1, “Instalação do Upgrade Controller - GitRepo”).

• Recurso Bundle - para casos de uso air-gapped que não suportam uma opção de servidor Git local. Para instruções de instalação, consulte Instalação do Upgrade Controller - Bundle (Seção 20.2.1.2, “Instalação do Upgrade Controller - Bundle”).

20.2.1.1 Instalação do Upgrade Controller - GitRepo #

 

Nota

Este processo também pode ser feito através da interface do usuário do Rancher, caso esteja disponível. Para mais informações, consulte Acessar o Fleet na interface do usuário do Rancher.

No seu cluster de gerenciamento:

1. Determine em quais clusters você deseja implantar o SUC. Isso é feito implantando um recurso GitRepo do SUC no workspace do Fleet correto em seu cluster de gerenciamento. Por padrão, o Fleet possui dois workspaces:

   • 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 os workspaces do Fleet, consulte a documentação upstream.

2. Implante o recurso GitRepo:

   • Para implantar o SUC em seu 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.6.1
       paths:
       - fleets/day2/system-upgrade-controller
       repo: https://github.com/suse-edge/fleet-examples.git
     EOF

   • Para implantar o SUC em seus clusters downstream:

     

     Nota

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

     kubectl apply -n fleet-default -f - <<EOF
     apiVersion: fleet.cattle.io/v1alpha1
     kind: GitRepo
     metadata:
       name: system-upgrade-controller
     spec:
       revision: release-3.6.1
       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 se o recurso GitRepo está 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.6.1   1/1

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

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

20.2.1.2 Instalação do Upgrade Controller - Bundle #

 

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

1. Em uma máquina com acesso à rede, baixe o fleet-cli:

   

   Nota

   Certifique-se de que a versão do fleet-cli que você baixar corresponda à versão do Fleet que foi implantada em seu cluster.

   • Para usuários de Mac, existe uma fleet-cli Homebrew Formulae.

   • Para usuários de Linux e Windows, os binários estão presentes como assets em cada release do Fleet.

     • Linux AMD:

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

     • Linux ARM:

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

2. Torne o fleet-cli executável:

   chmod +x fleet-cli

3. Clone a suse-edge/fleet-examples release que você deseja usar:

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

4. Navegue até o fleet do SUC, localizado no repositório fleet-examples:

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

5. Determine em quais clusters você deseja implantar o SUC. Isso é feito implantando o SUC Bundle no workspace do Fleet correto dentro do seu cluster de gerenciamento. Por padrão, o Fleet possui dois workspaces:

   • 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 os workspaces do Fleet, consulte a documentação upstream.

6. Se você pretende implantar o SUC apenas em clusters downstream, crie um arquivo targets.yaml que corresponda 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

7. Prossiga para a construção do Bundle:

   

   Nota

   Certifique-se de não baixar o fleet-cli no diretório fleet-examples/fleets/day2/system-upgrade-controller, caso contrário, ele será empacotado com o Bundle, o que não é recomendado.

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

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

   • Para implantar o SUC nos seus clusters downstream, execute:

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

     Para mais informações sobre este processo, consulte Convert a Helm Chart into a Bundle.

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

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

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

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

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

10. No seu cluster de gerenciamento, valide se o Bundle está 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. Com base no workspace do Fleet no qual você implantou seu 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

Os Planos SUC podem ser visualizados das seguintes maneiras:

Importante

Os Pods implantados para Planos SUC são mantidos ativos por 15 minutos após uma execução bem-sucedida. Após esse período, eles são removidos pelo Job correspondente que os criou. Para ter acesso aos logs do Pod após esse período, você deve habilitar o registro em log para seu cluster. Para obter informações sobre como fazer isso no Rancher, consulte Rancher Integration with Logging Services.

20.3.2 Monitoramento de Planos do Upgrade Controller do Sistema - Manual #

 

Nota

As etapas abaixo pressupõem que kubectl foi configurado para se conectar ao cluster onde os Planos SUC foram implantados.

1. Liste os Planos SUC implantados:

   kubectl get plans -n cattle-system

2. Obtenha o Pod para o plano SUC:

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

   

   Nota

   Podem existir tanto Completed Pods quanto Unknown para um Plano SUC específico. Isso é esperado e acontece devido à natureza de alguns dos upgrades.

3. Obtenha os logs para o Pod:

   kubectl logs <pod_name> -n cattle-system

O Upgrade Controller é essencial na automação das operações de "Dia 2" (anteriormente manuais) necessárias para atualizar clusters de gerenciamento de uma versão de lançamento SUSE Telco Cloud para a próxima.

Para alcançar essa automação, o Upgrade Controller utiliza ferramentas como o System Upgrade Controller (Capítulo 20, Upgrade Controller do Sistema) e o Helm Controller.

Para mais detalhes sobre como o Upgrade Controller funciona, consulte Seção 21.5, “Como funciona o Upgrade Controller?”.

Para limitações conhecidas que o Upgrade Controller possui, consulte Seção 21.8, “Limitações conhecidas”.

Para obter informações sobre a diferença entre o Upgrade Controller e o System Upgrade Controller, consulte Seção 21.2, “Upgrade Controller vs System Upgrade Controller”.

O System Upgrade Controller (SUC) (Capítulo 20, Upgrade Controller do Sistema) é uma ferramenta de propósito geral que propaga instruções de atualização para nós específicos do Kubernetes.

Embora ele suporte algumas operações de "Dia 2" para a plataforma SUSE Telco Cloud, ele não cobre todas elas. Além disso, mesmo para operações suportadas, os usuários precisam configurar, manter e implantar manualmente múltiplos SUC Plans — um processo sujeito a erros que pode levar a problemas inesperados.

Isso levou à necessidade de uma ferramenta que automatize e abstraia a complexidade de gerenciar várias operações de "Dia 2" para a plataforma SUSE Telco Cloud. Assim, o Upgrade Controller foi desenvolvido. Ele simplifica o processo de atualização ao introduzir um único user-facing resource que conduz a atualização. Os usuários só precisam gerenciar esse recurso, enquanto o Upgrade Controller cuida do resto.

Como alternativa à instalação manual descrita acima, é possível instalar o Upgrade Controller como parte da implantação inicial orquestrada pelo Edge Image Builder (Capítulo 12, Edge Image Builder).

Nesse caso, é necessário adicionar a seguinte configuração de chart helm ao arquivo de configuração do EIB:

kubernetes:
  helm:
    charts:
      - name: cert-manager
        repositoryName: jetstack
        version: {version-cert-manager}
        targetNamespace: cert-manager
        valuesFile: certmanager-values.yaml
        createNamespace: true
        installationNamespace: kube-system
      - name: upgrade-controller
        version: {version-upgrade-controller-chart}
        repositoryName: suse-edge-charts
        targetNamespace: upgrade-controller-system
        createNamespace: true
        installationNamespace: kube-system

Para realizar uma atualização de versão do Edge, o Upgrade Controller introduz dois novos recursos personalizados do Kubernetes:

O Upgrade Controller prossegue criando um recurso ReleaseManifest que contém os dados do componente para a versão de lançamento do Edge especificada pelo usuário na propriedade releaseVersion no recurso UpgradePlan.

Usando os dados do componente do ReleaseManifest, o Upgrade Controller prossegue com a atualização dos componentes da versão do Edge na seguinte ordem:

Nota

Durante o processo de atualização, o Upgrade Controller gera continuamente informações de atualização para o UpgradePlan criado. Para obter mais informações sobre como acompanhar o processo de atualização, consulte Acompanhando o processo de atualização (Seção 21.7, “Acompanhando o processo de atualização”).

21.5.1 Atualização do Sistema operacional #

 

Para atualizar o sistema operacional, o Upgrade Controller cria planos SUC (Capítulo 20, Upgrade Controller do Sistema) que possuem o seguinte modelo de nomenclatura:

• Para planos SUC relacionados a atualizações do SO dos nós do plano de controle - control-plane-<os-name>-<os-version>-<suffix>.

• Para planos SUC relacionados a atualizações do SO dos nós de trabalho - workers-<os-name>-<os-version>-<suffix>.

Com base nesses planos, o SUC prossegue criando cargas de trabalho em cada nó do cluster que realizam a atualização do SO propriamente dita.

Dependendo do ReleaseManifest, a atualização do SO pode incluir:

• Atualizações apenas de pacotes - para casos de uso em que a versão do SO não muda entre as versões do Edge.

• Migração completa do SO - para casos de uso em que a versão do SO muda entre as versões do Edge.

A atualização é executada um nó por vez, começando pelos nós do plano de controle. Somente se a atualização do nó do plano de controle terminar, os nós de trabalho começarão a ser atualizados.

Nota

O Controlador de Atualização configura os Planos SUC do SO para realizar um dreno dos nós do cluster se o cluster tiver mais de um nó do tipo especificado.

Para clusters onde os nós do plano de controle são maiores que um e há apenas um nó de trabalho, um dreno será realizado apenas para os nós do plano de controle e vice-versa.

Para obter informações sobre como desativar completamente os drenos de nós, consulte a seção UpgradePlan (Seção 21.6.1, “UpgradePlan”).

21.5.2 Fazer upgrade do Kubernetes #

 

Para fazer upgrade da distribuição Kubernetes de um cluster, o Upgrade Controller cria Planos SUC (Capítulo 20, Upgrade Controller do Sistema) que possuem o seguinte modelo de nomenclatura:

• Para Planos SUC relacionados a atualizações do Kubernetes de nós do plano de controle - control-plane-<k8s-version>-<suffix>.

• Para Planos SUC relacionados a atualizações do Kubernetes de nós de trabalho - workers-<k8s-version>-<suffix>.

Com base nesses planos, o SUC prossegue criando cargas de trabalho em cada nó do cluster que realizam a atualização real do Kubernetes.

A atualização do Kubernetes ocorrerá um nó por vez, começando pelos nós do plano de controle. Somente se a atualização do nó do plano de controle terminar, os nós de trabalho começarão a ser atualizados.

Nota

O Controlador de Atualização configura os Planos SUC do Kubernetes para realizar um dreno dos nós do cluster se o cluster tiver mais de um nó do tipo especificado.

Para clusters onde os nós do plano de controle são maiores que um e há apenas um nó de trabalho, um dreno será realizado apenas para os nós do plano de controle e vice-versa.

Para obter informações sobre como desativar completamente os drenos de nós, consulte Seção 21.6.1, “UpgradePlan”.

Extensões para a API do Kubernetes introduzidas pelo Upgrade Controller.

21.6.2 ReleaseManifest #

 

O Upgrade Controller introduz um novo recurso personalizado do Kubernetes chamado ReleaseManifest.

O recurso ReleaseManifest é criado pelo Upgrade Controller e mantém dados de componentes para uma versão de lançamento do Edge específica. Isso significa que cada upgrade da versão de lançamento do Edge será representado por um recurso ReleaseManifest diferente.

Atenção

O Manifesto de Lançamento deve ser sempre criado pelo Upgrade Controller.

Não é aconselhável criar ou editar manualmente os recursos ReleaseManifest. Usuários que decidirem fazer isso devem fazê-lo por sua própria conta e risco.

Os dados do componente que o Manifesto de Lançamento envia incluem, mas não estão limitados a:

• Dados do Sistema Operacional - versão, arquiteturas suportadas, dados adicionais de atualização, etc.

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

• Dados de componentes adicionais - dados do gráfico Helm da SUSE (localização, versão, nome, etc.)

Para um exemplo de como um Manifesto de Lançamento pode parecer, consulte a https://github.com/suse-edge/upgrade-controller/blob/main/config/samples/lifecycle_v1alpha1_releasemanifest.yamldocumentação [upstream]. Observe que este é apenas um exemplo e não se destina a ser criado como um recurso ReleaseManifest válido.

Esta seção serve como um meio para rastrear e depurar o processo de atualização que o Controlador de Atualização inicia assim que o usuário cria um recurso UpgradePlan.

kubectl get upgradeplan <upgradeplan_name> -n upgrade-controller-system -o yaml

apiVersion: lifecycle.suse.com/v1alpha1
kind: UpgradePlan
metadata:
  name: upgrade-plan-mgmt
  namespace: upgrade-controller-system
spec:
  releaseVersion: 3.6
status:
  conditions:
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: Control plane nodes are being upgraded
    reason: InProgress
    status: "False"
    type: OSUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: Kubernetes upgrade is not yet started
    reason: Pending
    status: Unknown
    type: KubernetesUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: Rancher upgrade is not yet started
    reason: Pending
    status: Unknown
    type: RancherUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: Longhorn upgrade is not yet started
    reason: Pending
    status: Unknown
    type: LonghornUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: MetalLB upgrade is not yet started
    reason: Pending
    status: Unknown
    type: MetalLBUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: CDI upgrade is not yet started
    reason: Pending
    status: Unknown
    type: CDIUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: KubeVirt upgrade is not yet started
    reason: Pending
    status: Unknown
    type: KubeVirtUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: NeuVector upgrade is not yet started
    reason: Pending
    status: Unknown
    type: NeuVectorUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: EndpointCopierOperator upgrade is not yet started
    reason: Pending
    status: Unknown
    type: EndpointCopierOperatorUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: Elemental upgrade is not yet started
    reason: Pending
    status: Unknown
    type: ElementalUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: SRIOV upgrade is not yet started
    reason: Pending
    status: Unknown
    type: SRIOVUpgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: Metal3 upgrade is not yet started
    reason: Pending
    status: Unknown
    type: Metal3Upgraded
  - lastTransitionTime: "2024-10-01T06:26:27Z"
    message: RancherTurtles upgrade is not yet started
    reason: Pending
    status: Unknown
    type: RancherTurtlesUpgraded
  observedGeneration: 1
  sucNameSuffix: 90315a2b6d

apiVersion: lifecycle.suse.com/v1alpha1
kind: UpgradePlan
metadata:
  name: upgrade-plan-mgmt
  namespace: upgrade-controller-system
spec:
  releaseVersion: 3.6
status:
  conditions:
  - lastTransitionTime: "2024-10-01T06:26:48Z"
    message: All cluster nodes are upgraded
    reason: Succeeded
    status: "True"
    type: OSUpgraded
  - lastTransitionTime: "2024-10-01T06:26:59Z"
    message: All cluster nodes are upgraded
    reason: Succeeded
    status: "True"
    type: KubernetesUpgraded
  - lastTransitionTime: "2024-10-01T06:27:13Z"
    message: Chart rancher upgrade succeeded
    reason: Succeeded
    status: "True"
    type: RancherUpgraded
  - lastTransitionTime: "2024-10-01T06:27:13Z"
    message: Chart longhorn is not installed
    reason: Skipped
    status: "False"
    type: LonghornUpgraded
  - lastTransitionTime: "2024-10-01T06:27:13Z"
    message: Specified version of chart metallb is already installed
    reason: Skipped
    status: "False"
    type: MetalLBUpgraded
  - lastTransitionTime: "2024-10-01T06:27:13Z"
    message: Chart cdi is not installed
    reason: Skipped
    status: "False"
    type: CDIUpgraded
  - lastTransitionTime: "2024-10-01T06:27:13Z"
    message: Chart kubevirt is not installed
    reason: Skipped
    status: "False"
    type: KubeVirtUpgraded
  - lastTransitionTime: "2024-10-01T06:27:13Z"
    message: Chart neuvector-crd is not installed
    reason: Skipped
    status: "False"
    type: NeuVectorUpgraded
  - lastTransitionTime: "2024-10-01T06:27:14Z"
    message: Specified version of chart endpoint-copier-operator is already installed
    reason: Skipped
    status: "False"
    type: EndpointCopierOperatorUpgraded
  - lastTransitionTime: "2024-10-01T06:27:14Z"
    message: Chart elemental-operator upgrade succeeded
    reason: Succeeded
    status: "True"
    type: ElementalUpgraded
  - lastTransitionTime: "2024-10-01T06:27:15Z"
    message: Chart sriov-crd is not installed
    reason: Skipped
    status: "False"
    type: SRIOVUpgraded
  - lastTransitionTime: "2024-10-01T06:27:19Z"
    message: Chart metal3 is not installed
    reason: Skipped
    status: "False"
    type: Metal3Upgraded
  - lastTransitionTime: "2024-10-01T06:27:27Z"
    message: Chart rancher-turtles is not installed
    reason: Skipped
    status: "False"
    type: RancherTurtlesUpgraded
  lastSuccessfulReleaseVersion: 3.6
  observedGeneration: 1
  sucNameSuffix: 90315a2b6d

21.7.2 Helm Controller #

 

Esta seção aborda como rastrear recursos criados pelo helm-controller.

Nota

As etapas abaixo pressupõem que o kubectl foi configurado para se conectar ao cluster onde o Upgrade Controller foi implantado.

1. Localize o recurso HelmChart para o componente específico:

   kubectl get helmcharts -n kube-system

2. Usando o nome do recurso HelmChart, localize o Pod de fazer upgrade que foi criado pelo helm-controller:

   kubectl get pods -l helmcharts.helm.cattle.io/chart=<helmchart_name> -n kube-system
   
   # Example for Rancher
   kubectl get pods -l helmcharts.helm.cattle.io/chart=rancher -n kube-system
   NAME                         READY   STATUS      RESTARTS   AGE
   helm-install-rancher-tv9wn   0/1     Completed   0          16m

3. Visualize os logs do pod específico de fazer upgrade do componente:

   kubectl logs <pod_name> -n kube-system

A tabela a seguir lista as portas abertas nos nós que executam o cluster de gerenciamento:

Nota

Para portas relacionadas ao plug-in CNI, consulte requisitos de porta específicos do CNI (Seção 24.3, “Requisitos de porta específicos de CNI”).

⁽¹⁾ BMC: Baseboard Management Controller
⁽²⁾ IPA: Ironic Python Agent

No SUSE Telco Cloud, antes que qualquer servidor downstream se torne parte de um cluster Kubernetes downstream em execução (ou execute um cluster Kubernetes downstream de nó único), é necessário passar por alguns dos estados de provisionamento BaremetalHost.

Espera-se que as seguintes portas sejam expostas pelo BMC (elas podem diferir dependendo do hardware exato):

Nota

Para portas relacionadas ao plug-in CNI, consulte requisitos de porta específicos do CNI (Seção 24.3, “Requisitos de porta específicos de CNI”).