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

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

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

5.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.

5.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 6, 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 17.7.2, “Usando a Extensão do Painel do Rancher para KubeVirt”.

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.

SUSE Edge 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 2, 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 IV, “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 Edge 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 Edge utiliza o nmc para as personalizações de rede nos vários modelos de provisionamento diferentes: * Configurações estáticas declarativas nos cenários de Provisionamento Baseado em Imagem (Capítulo 2, 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

9.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

9.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 9.5.3, “Criando o diretório de configuração da imagem” até Seção 9.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

Usamos partes do Elemental para gerenciar dispositivos remotos onde o Metal³ não é uma opção (por exemplo, não há BMC, ou o dispositivo está atrás de um gateway NAT). Essa ferramenta permite que um operador inicialize seus dispositivos em um laboratório antes de saber quando ou para onde eles serão enviados. Ou seja, aproveitamos os componentes elemental-register e elemental-system-agent para permitir a integração de hosts SUSE Linux Micro ao Rancher para casos de uso de provisionamento de rede "phone home". Ao usar o Edge Image Builder (EIB) para criar imagens de implantação, o registro automático através do Rancher via Elemental pode ser alcançado especificando a configuração de registro no diretório de configuração do EIB.

Nota

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

O K3s pode ser usado como a distribuição Kubernetes que sustenta a pilha SUSE Edge. Ele foi projetado para ser instalado em um sistema operacional SUSE Linux Micro.

O uso do K3s como a distribuição Kubernetes da pilha SUSE Edge só é recomendado quando o etcd como backend não atende às suas restrições. Se o etcd como backend for possível, é melhor usar o RKE2 (Capítulo 12, RKE2).

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 Edge. Ele fica sobre o SUSE Linux Micro (Capítulo 7, 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 Edge está usando o Capítulo 8, 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 25.8, “Instalação do SUSE Storage”.

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

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

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

Nota

Para ser possível expor a API, o Endpoint Copier Operator (Capítulo 16, 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 21, MetalLB no K3s (usando o modo camada 2) e para o modo L3 em Capítulo 22, 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 24, MetalLB na frente do servidor de API do Kubernetes.

Na SUSE Edge, 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 15, 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 21, 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 Edge 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 Edge 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 Edge 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 Edge 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.

17.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.

17.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.

17.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.

17.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 Edge está usando Capítulo 8, Edge Image Builder para personalizar imagens base do SUSE Linux Micro OS. Siga Seção 25.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 Edge 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 19, Upgrade Controller. Para saber mais sobre as principais diferenças entre o SUC e o Upgrade Controller, consulte Seção 19.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 6, 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 41, 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:

18.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 18.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 18.2.1.2, “Instalação do Upgrade Controller - Bundle”).

18.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

18.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.

18.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 Edge para a próxima.

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

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

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

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

O System Upgrade Controller (SUC) (Capítulo 18, 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 Edge, 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 Edge. 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 8, 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 19.7, “Acompanhando o processo de atualização”).

19.5.1 Atualização do Sistema operacional #

 

Para atualizar o sistema operacional, o Upgrade Controller cria planos SUC (Capítulo 18, 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 19.6.1, “UpgradePlan”).

19.5.2 Fazer upgrade do Kubernetes #

 

Para fazer upgrade da distribuição Kubernetes de um cluster, o Upgrade Controller cria Planos SUC (Capítulo 18, 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 19.6.1, “UpgradePlan”.

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

19.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

19.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