この方法は、ターゲットハードウェアがアウトオブバンド管理をサポートしていて、完全に自動化されたインフラストラクチャ管理フローが望まれるシナリオで役立ちます。

管理クラスタは宣言型APIを提供するように設定されており、このAPIによってダウンストリームクラスタのベアメタルサーバのインベントリと状態を管理できます。これには、自動検査、クリーニング、プロビジョニング/プロビジョニング解除も含まれます。

ダウンストリームクラスタのサーバハードウェアとネットワーキングに関連する固有の制約がいくつかあります。

ツールがいくつか必要です。ツールは管理クラスタにインストールするか、管理クラスタにアクセス可能なホストにインストールできます。

SL-Micro.x86_64-6.1-Base-GM.raw OSイメージファイルはSUSE Customer CenterまたはSUSEダウンロードページからダウンロードする必要があります。

1.3.1 管理クラスタのセットアップ #

 

管理クラスタをインストールし、Metal³を使用する基本的な手順は次のとおりです。

1. RKE2管理クラスタをインストールします。

2. Rancherのインストール

3. ストレージプロバイダをインストールします(オプション)。

4. Metal³の依存関係をインストールします。

5. Rancher Turtles経由でCAPIの依存関係をインストールします。

6. ダウンストリームクラスタホスト用のSLEMicro OSイメージを構築します。

7. BareMetalHost CRを登録し、ベアメタルのインベントリを定義します。

8. CAPIリソースを定義して、ダウンストリームクラスタを作成します。

このガイドでは、既存のRKE2クラスタとRancher (cert-managerを含む)が、たとえばEdge Image Builder (第11章 「Edge Image Builder」)を使用してインストールされていることを前提としています。

ヒント

ここでの手順は、管理クラスタのドキュメント(第40章 「管理クラスタの設定」)で説明されているように、完全に自動化することもできます。

1.3.2 Metal³の依存関係のインストール #

 

cert-managerがまだRancherのインストールの一部としてインストールされていない場合は、cert-managerをインストールして実行する必要があります。

永続ストレージプロバイダをインストールする必要があります。SUSE Storageを推奨しますが、開発/PoC環境ではlocal-path-provisionerを使用することもできます。以下の手順は、StorageClassがデフォルトとしてマークされていることを前提としています。マークされていない場合は、Metal³チャートに追加の設定が必要です。

追加のIPが必要です。このIPはMetalLBによって管理され、Metal³管理サービスに一貫したエンドポイントを提供します。このIPは、コントロールプレーンサブネットに属していて、静的設定用に予約されている必要があります(どのDHCPプールにも属していてはなりません)。

ヒント

管理クラスタがシングルノードである場合、MetalLBを介して管理されるフローティングIPを追加する必要はありません。1.6.1項 「シングルノード設定」を参照してください。

1. まず、MetalLBをインストールします。

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

2. 続いて、次のように、STATIC_IRONIC_IPとして定義された予約済みIPを使用して 、IPAddressPoolと L2Advertisementを定義します。

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

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

3. これでMetal³をインストールできます。

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

4. initコンテナがこのデプロイメントで実行されるまで約2分かかる場合があるため、続行する前にPodがすべて実行されていることを確認します。

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

警告

metal3-systemネームスペースのすべてのPodが実行されるまで、以下の手順に進まないでください。

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

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

1.3.4 ダウンストリームクラスタイメージの準備 #

 

Kiwi (第28章 「Kiwiを使用したSUSE Linux Microの更新イメージの構築」)とEdge Image Builder (第11章 「Edge Image Builder」)を使用して、ダウンストリームクラスタホスト上にプロビジョニングされる、変更されたSLEMicroゴールデンイメージを準備します。

このガイドではダウンストリームクラスタをデプロイするために必要な最小限の設定について説明します。

1.3.4.1 イメージの設定 #

 

注記

クラスタの作成に必要な最初の手順として、まず第28章 「Kiwiを使用したSUSE Linux Microの更新イメージの構築」に従って、新しいイメージを構築してください。

Edge Image Builderを実行すると、そのホストからディレクトリがマウントされるため、ターゲットイメージの定義に使用する設定ファイルを保存するディレクトリ構造を作成する必要があります。

• downstream-cluster-config.yamlはイメージ定義ファイルです。詳細については、第3章 「Edge Image Builderを使用したスタンドアロンクラスタ」を参照してください。

• ダウンロードされたゴールデンイメージはxzで圧縮されているので、unxzで展開し、base-imagesフォルダの下にコピー/移動する必要があります。

• networkフォルダはオプションです。詳細については、1.3.5.1.1項 「静的ネットワーク設定用の追加スクリプト」を参照してください。

• custom/scriptsディレクトリには、初回ブート時に実行するスクリプトが含まれます。現在、デプロイメントのOSルートパーティションのサイズを変更するには、01-fix-growfs.shスクリプトが必要です。

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

1.3.4.1.1 ダウンストリームクラスタイメージ定義ファイル #

 

downstream-cluster-config.yamlファイルは、ダウンストリームクラスタイメージの主要な設定ファイルです。次に、Metal³を介したデプロイメントの最小例を示します。

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

ここで、$SCC_REGISTRATION_CODEはSUSE Customer Centerからコピーした登録コードで、パッケージリストには必要なjqが含まれています。

$ROOT_PASSWORDはルートユーザの暗号化パスワードで、テスト/デバッグに役立ちます。このパスワードは、openssl passwd -6 PASSWORDコマンドで生成できます。

運用環境では、$USERKEY1を実際のSSHキーに置き換えて、usersブロックに追加できるSSHキーを使用することをお勧めします。

注記

net.ifnames=1は、Predictable Network Interface Namingを有効にします。

これはMetal³チャートのデフォルト設定と一致しますが、この設定は、設定されたチャートのpredictableNicNamesの値と一致する必要があります。

また、ignition.platform.id=openstackは必須であり、この引数がないと、Metal³の自動化フローでIgnitionによるSUSE Linux Microの設定が失敗することにも注意してください。

timeセクションはオプションですが、証明書とクロックスキューに関する潜在的な問題を避けるために、設定することを強くお勧めします。この例で指定されている値は説明のみを目的としています。ご自身の特定の要件に合わせて調整してください。

1.3.4.1.2 Growfsスクリプト #

 

現在、プロビジョニング後の初回ブート時にディスクサイズに合わせてファイルシステムを拡張するには、カスタムスクリプト(custom/scripts/01-fix-growfs.sh)が必要です。01-fix-growfs.shスクリプトには次の情報が含まれます。

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

注記

同じアプローチを使用して、プロビジョニングプロセス中に実行する独自のカスタムスクリプトを追加します。詳細については、第3章 「Edge Image Builderを使用したスタンドアロンクラスタ」を参照してください。

1.3.4.2 イメージの作成 #

 

これまでのセクションに従ってディレクトリ構造を準備したら、次のコマンドを実行してイメージを構築します。

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

これにより、上記の定義に基づいて、SLE-Micro-eib-output.rawという名前の出力イメージファイルが作成されます。

その後、この出力イメージをWebサーバ経由で利用できるようにする必要があります。その際、Metal3チャートを使用して有効にしたメディアサーバコンテナ(注記)か、ローカルにアクセス可能な他のサーバのいずれかを使用します。以下の例では、このサーバをimagecache.local:8080として参照します。

注記

EIBイメージをダウンストリームクラスタにデプロイする際は、Metal3MachineTemplateオブジェクトにイメージのSHA256ハッシュ値を含める必要があります。これは次のように生成できます:

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

1.3.5 BareMetalHostインベントリの追加 #

 

自動デプロイメント用にベアメタルサーバを登録するには、リソースを2つ作成する必要があります。BMCアクセス資格情報を保存するシークレットと、BMC接続とその他の詳細を定義するMetal³ BareMetalHostリソースです。

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

次の点に注意してください。

• シークレットのユーザ名/パスワードはbase64でエンコードされている必要があります。また、末尾に改行を含めないでください(たとえば、単なるechoではなく、echo ‑nを使用してください)。

• cluster-roleラベルは、この時点で設定することも、後でクラスタの作成時に設定することもできます。以下の例では、control-planeまたはworkerを想定しています。

• bootMACAddressは、ホストのコントロールプレーンNICに一致する有効なMACである必要があります。

• bmcのアドレスはBMC管理APIへの接続です。次のアドレスがサポートされています。

  • redfish-virtualmedia://<IP ADDRESS>/redfish/v1/Systems/<SYSTEM ID>: Redfish仮想メディア(たとえば、SuperMicro)

  • idrac-virtualmedia://<IP ADDRESS>/redfish/v1/Systems/System.Embedded.1: Dell iDRAC

• BareMetalHost APIの詳細については、アップストリームのAPIドキュメントを参照してください。

1.3.5.1 静的IPの設定 #

 

上記のBareMetalHostの例では、DHCPでコントロールプレーンネットワークの設定を提供することを想定していますが、静的IPなどの手動設定が必要なシナリオでは、以下に説明するように追加の設定を指定できます。

1.3.5.1.1 静的ネットワーク設定用の追加スクリプト #

 

Edge Image Builderでゴールデンイメージを作成する際には、networkフォルダ内に次のconfigure-network.shファイルを作成します。

このファイルにより、初回ブート時に設定ドライブのデータを使用して、NM Configuratorツールを使ってホストネットワーキングを設定します。

#!/bin/bash

set -eux

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

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

mount -o ro $CONFIG_DRIVE /mnt

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

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

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

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

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

1.3.5.1.2 ホストネットワーク設定の追加シークレット #

 

NM Configurator (第12章 「Edgeネットワーキング」)でサポートされているnmstate形式のデータを含む追加シークレットをホストごとに定義できます。

その後、このシークレットは、BareMetalHostリソースでpreprovisioningNetworkDataNameの指定フィールドを使用して参照されます。

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

注記

状況によっては、MACアドレスが省略される場合があります。詳細については、12.5.8項 「統合されたノード設定」を参照してください。

1.3.5.2 BareMetalHostの準備 #

 

上記の説明に従ってBareMetalHostリソースと関連するシークレットを作成すると、次のようにホスト準備ワークフローがトリガされます。

• ターゲットホストのBMCに接続された仮想メディアによってramdiskイメージがブートされる

• ramdiskがハードウェア詳細を検査し、ホストをプロビジョニング用に準備する(たとえば、ディスクから以前のデータを消去する)

• このプロセスが完了すると、BareMetalHostのstatus.hardwareフィールドのハードウェア詳細が更新され、検証可能になる

このプロセスには数分かかる場合がありますが、完了すると、BareMetalHostの状態がavailableになります。

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

1.3.7 コントロールプレーンのデプロイメント #

 

コントロールプレーンをデプロイするために、以下のリソースを含む次のようなyamlマニフェストを定義します。

• クラスタリソースでは、クラスタ名、ネットワーク、およびコントロールプレーン/インフラストラクチャプロバイダのタイプ(この場合はRKE2/Metal3)を定義します。

• Metal3Clusterでは、コントロールプレーンのエンドポイント(シングルノードの場合はホストIP、マルチノードの場合はLoadBalancerエンドポイント。この例ではシングルノードを想定)を定義します。

• RKE2ControlPlaneでは、RKE2のバージョンと、クラスタのブートストラップ時に必要な追加設定を定義します。

• Metal3MachineTemplateではBareMetalHostリソースに適用するOSイメージを定義し、hostSelectorでは使用するBareMetalHostを定義します。

• Metal3DataTemplateでは、BareMetalHostに渡す追加のメタデータを定義します(networkDataは現在のところEdgeソリューションではサポートされていないことに注意してください)。

注記

簡潔にするため、この例では、BareMetalHostのIPアドレスが192.168.125.200で設定されている単一ノードのコントロールプレーンを想定しています。より高度なマルチノードの例については、第42章 「完全に自動化されたダイレクトネットワークプロビジョニング」を参照してください。

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

自身の環境に合わせて調整したら、kubectlを使用して例を適用し、その後 clusterctlを使用してクラスタのステータスを監視できます。

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

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

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

% kubectl apply -f rke2-agent.yaml

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

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

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

...

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

SUSE Edge for Telcoドキュメント(第37章 「SUSE Edge for Telco」)には、通信事業者のユースケースにおける Metal³のより高度な使用例が記載されています。

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

global:
  enable_vmedia_tls: false

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

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

このクイックスタートを実行するためのシステムと環境の最小要件を次に示します。

注記

ターゲットマシンにある既存のデータはこのプロセスの一環として上書きされます。ターゲットデプロイメントノードに接続されているUSBストレージデバイスやディスク上のデータは、必ずバックアップしてください。

このガイドは、アップストリームクラスタをホストするためにDigital Oceanドロップレットを使用し、ダウンストリームデバイスとしてIntel NUCを使用して作成されています。インストールメディアの構築には、SUSE Linux Enterprise Serverを使用しています。

まず、RancherとElementalをホストできるクラスタを作成します。このクラスタは、ダウンストリームノードが接続されているネットワークからルーティングできる必要があります。

2.3.2 DNSの設定 #

 

続行する前に、クラスタへのアクセスを設定する必要があります。クラスタ自体のセットアップと同様に、DNSの設定方法は、クラスタがホストされている場所によって異なります。

ヒント

DNSレコードの設定を扱わない場合(たとえば、これが一時的なテストサーバである場合)、代わりにsslip.ioなどのサービスを使用できます。このサービスを使用すると、<address>.sslip.ioを使用して任意のIPアドレスを解決できます。

Rancherをインストールするには、作成したクラスタのKubernetes APIにアクセスする必要があります。これは、使用しているKubernetesのディストリビューションによって異なります。

RKE2の場合、kubeconfigファイルは/etc/rancher/rke2/rke2.yamlに書き込まれます。このファイルをローカルシステムに~/.kube/configとして保存します。このファイルを編集して、外部にルーティング可能な正しいIPアドレスまたはホスト名を含めなければならない場合があります。

Rancherのドキュメントに記載されているコマンドを使用して、Rancherを簡単にインストールできます。

cert-managerをインストールします。

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

次に、Rancher自体をインストールします。

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

注記

これを運用システムにする予定の場合は、cert-managerを使用して、実際の証明書(Let's Encryptの証明書など)を設定してください。

設定したホスト名をブラウズし、使用したbootstrapPasswordでRancherにログインします。ガイドに従って簡単なセットアッププロセスを完了します。

Rancherをインストールしたら、続いてElementalのオペレータと必要なCRDをインストールできます。Elemental用のHelmチャートはOCIアーティファクトとして公開されているため、インストールは他のチャートよりも若干シンプルです。Rancherのインストールに使用したものと同じシェルからインストールすることも、ブラウザでRancherのシェル内からインストールすることもできます。

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

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

シンプルにするために、変数$ELEMを、設定ディレクトリを配置する場所のフルパスに設定することをお勧めします。

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

マシンがElementalに登録できるようにするために、fleet-defaultネームスペースにMachineRegistrationオブジェクトを作成する必要があります。

このオブジェクトの基本的なバージョンを作成してみましょう。

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

kubectl apply -f $ELEM/registration.yaml

注記

このcatコマンドでは、各$をバックスラッシュ(\)でエスケープしています。このため、バッシュではテンプレート化されていません。手動でコピーする場合は、バックスラッシュを削除してください。

オブジェクトが作成されたら、割り当てられるエンドポイントを見つけてメモを取ります。

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

または、UIからこの操作を実行することもできます。

Elementalの現在のバージョンには独自のインストールメディアを構築する方法が用意されていますが、SUSE Edge 3.3.1では代わりにKiwiとEdge Image Builderでインストールメディアを構築します。したがって、生成されるシステムは、SUSE Linux Microをベースオペレーティングシステムとして構築されます。

ヒント

Kiwiの詳細については、まずKiwi Image Builderプロセス(第28章 「Kiwiを使用したSUSE Linux Microの更新イメージの構築」)に従って、新しいイメージを構築してください。また、Edge Image Builderについては、Edge Image Builder導入ガイド(第3章 「Edge Image Builderを使用したスタンドアロンクラスタ」)のほかに、コンポーネントのドキュメント(第11章 「Edge Image Builder」)も参照してください。

PodmanをインストールしたLinuxシステムで、ディレクトリを作成し、Kiwiによって構築されるゴールデンイメージを配置します。

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

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

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

注記

• timeセクションはオプションですが、証明書とクロックスキューに関する潜在的な問題を避けるために、設定することを強くお勧めします。この例で指定されている値は説明のみを目的としています。ご自身の特定の要件に合わせて調整してください。

• エンコードされていないパスワードはeibです。

• sccRegistrationCodeは、公式なソースから必要なRPMをダウンロードしてインストールするために必要です(または、代わりにelemental-registerおよびelemental-system-agentのRPMを手動でサイドロードすることもできます)。

• このcatコマンドでは、各$をバックスラッシュ(\)でエスケープしています。このため、バッシュではテンプレート化されていません。手動でコピーする場合は、バックスラッシュを削除してください。

• インストールデバイスは、インストール中に消去されます。

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

物理デバイスをブートする場合は、イメージをUSBフラッシュ ドライブに書き込む必要があります。これは、次のコマンドで実行できます。

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

インストールメディアを作成したので、それを使用してダウンストリームノードをブートできます。

Elementalで制御するシステムごとに、インストールメディアを追加してデバイスをブートします。インストールが完了すると、デバイスは再起動して自身を登録します。

UI拡張機能を使用している場合は、［Inventory of Machines (マシンのインベントリ)］にノードが表示されます。

注記

ログインプロンプトが表示されるまでインストールメディアを取り外さないでください。初回ブート時には、USBスティック上のファイルにアクセスしたままになります。

Elementalを使用して新しいクラスタをプロビジョニングする際に作成する必要があるオブジェクトが2つあります。

これらのオブジェクトを作成したら、先ほどインストールした新しいノードを使用して新しいKubernetesクラスタがスピンアップするはずです。

SUSE Rancher Elementalは、「ノードリセット」を実行する機能をサポートしています。ノードリセットは、Rancherからクラスタ全体が削除されたとき、クラスタからシングルノードが削除されたとき、またはマシンインベントリからノードが手動で削除されたときに任意でトリガできます。これは、孤立したリソースをリセットしてクリーンアップし、クリーンアップされたノードを自動的にマシンインベントリに戻して再利用可能にする場合に役立ちます。ノードリセットはデフォルトでは有効になっていないため、削除されたシステムはクリーンアップされず(つまり、データは削除されず、Kubernetesクラスタリソースはダウンストリームクラスタで動作し続けます)、データを消去してマシンをElemental経由でRancherに再登録するには手動操作が必要となります。

この機能をデフォルトで有効にするには、​MachineRegistrationに​config.elemental.reset.enabled: trueを追加して明示的に有効にする必要があります。例:

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

その後、このMachineRegistrationに登録されているすべてのシステムが自動的にelemental.cattle.io/resettable:'true'のアノテーションを受け取って設定に反映します。既存のMachineInventoryにこのアノテーションがない場合や、すでにノードをデプロイ済みである場合などに、個々のノードで手動でこの操作を実行する場合は、MachineInventoryを変更し、resettable設定を追加します。例:

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

SUSE Edge 3.1では、Elemental Operatorによってオペレーティングシステム上にマーカが配置され、これによってクリーンアッププロセスが自動的にトリガされます。クリーンアッププロセスは、すべてのKubernetesサービスを停止して永続データをすべて削除し、すべてのKubernetesサービスをアンインストールして、残っているKubernetes/Rancherディレクトリをクリーンアップし、元のElemental MachineRegistration設定を使用して強制的にRancherに再登録します。これは自動的に行われるため、手動での操作は必要ありません。呼び出されるスクリプトは/opt/edge/elemental_node_cleanup.shにあり、マーカが配置されるとすぐにsystemd.pathを介してトリガされるため、直ちに実行されます。

警告

resettable機能を使用する場合、Rancherからノード/クラスタを削除する際の望ましい動作は、データを消去して再登録を強制することであると想定されています。この状況ではデータが確実に失われるため、この機能は、自動リセットを実行することがわかっている場合にのみ使用してください。

このガイドの使用後に調べるべき推奨リソースを次に示します。

EIBはコンテナ内で動作するため、ホストから設定ディレク トリをマウントして、必要な設定を指定できるようにする必要があります。ビルドプロセス中に、EIBは必要な入力ファイルやサポートアーティファクトすべてにアクセスできます。このディレクトリは、特定の構造に従う必要があります。このディレクトリがホームディレクトリに存在し、「eib」という名前であると仮定して、ディレクトリを作成してみましょう。

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

前の手順でSUSE Linux Micro 6.1入力イメージをホストする「base-images」ディレクトリを作成しました。このイメージが設定ディレクトリにコピーされていることを確認しましょう。

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

注記

EIBの実行中に元のゴールデンイメージは変更されません。EIBの設定ディレクトリのルートに、目的の設定でカスタマイズされた新しいバージョンが作成されます。

この時点では、設定ディレクトリは次のようになっているはずです。

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

定義ファイルには、Edge Image Builderがサポートする設定可能なオプションの大部分が記述されています。オプションの完全な例については、こちらを参照してください。以下で説明する例よりも広範な例については、 アップストリームのイメージ構築ガイドを参照することをお勧めします。まずは、OSイメージの非常に基本的な定義ファイルから始めましょう。

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

この定義では、AMD64/Intel 64ベースのシステム用の出力イメージを生成するように指定しています。さらに変更を加えるためのベースとして使用するイメージは、slemicro.isoという名前のisoイメージであり、$CONFIG_DIR/base-images/slemicro.isoにあることが想定されています。また、EIBがイメージの変更を完了すると、出力イメージはeib-image.isoという名前になり、デフォルトでは$CONFIG_DIRに存在することも記述されています。

これで、ディレクトリ構造は次のようになります。

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

以降のセクションでは、一般的な操作の例をいくつか紹介していきます。

3.3.1 OSユーザの設定 #

 

EIBを使用すると、パスワードやSSHキーなどのログイン情報を事前にユーザに設定できます(固定されたルートパスワードの設定も含む)。この例の一部として、ルートパスワードを修正します。最初の手順は、OpenSSLを使用して一方向暗号化パスワードを作成することです。

openssl passwd -6 SecurePassword

これは次のような出力になります。

$6$G392FCbxVgnLaFw1$Ujt00mdpJ3tDHxEg1snBU3GjujQf6f8kvopu7jiCBIhRbRvMmKUqwcmXAKggaSSKeUUOEtCP3ZUoZQY7zTXnC1

次に、定義ファイルにoperatingSystemというセクションを追加し、その中にusers配列を含めます。作成したファイルは次のようになります。

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

注記

ユーザの追加、ホームディレクトリの作成、ユーザIDの設定、ssh-key認証の追加、グループ情報の変更も行うことができます。他の例については、アップストリームのイメージ構築ガイドを参照してください。

3.3.2 OSの時刻の設定 #

 

timeセクションはオプションですが、証明書とクロックスキューに関する潜在的な問題を避けるために、設定することを強くお勧めします。EIBは、chronydと/etc/localtimeをここのパラメータに応じて設定します。

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

• timezoneでは、タイムゾーンを「地域/都市」(例: 「Europe/London」)の形式で指定します。完全なリストを確認するには、Linuxシステム上でtimedatectl list-timezonesを実行します。

• ntp - NTPの設定(chronydを使用)に関連する属性を定義します。

• forceWait - 他のサービスを開始する前にchronydが時刻ソースの同期を試行するよう要求します。タイムアウトは180秒です。

• pools - chronydがデータソースとして使用するプールのリストを指定します(iburstを使用すると、最初の同期にかかる時間を短縮できます)。

• servers - chronydがデータソースとして使用するサーバのリストを指定します(iburstを使用すると、最初の同期にかかる時間を短縮できます)。

注記

この例で指定されている値は説明のみを目的としています。ご自身の特定の要件に合わせて調整してください。

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

3.3.4 RPMパッケージの設定 #

 

EIBの主な特徴の1つは、イメージにソフトウェアパッケージを追加するメカニズムを備えていることです。このため、インストールが完了した時点で、システムはインストールされたパッケージをすぐに利用できます。EIBでは、ユーザは以下を行うことができます。

• イメージ定義のリスト内の名前でパッケージを指定する

• これらのパッケージを検索するネットワークリポジトリを指定する

• 一覧にされたパッケージをSUSEの公式リポジトリで検索するためのSUSE Customer Center (SCC)資格情報を指定する

• $CONFIG_DIR/rpmsディレクトリ経由で、ネットワークリポジトリに存在しないカスタムRPMをサイドロードする

• 同じディレクトリ($CONFIG_DIR/rpms/gpg-keys)経由で、サードパーティ製パッケージの検証を有効にするためにGPGキーを指定する

これにより、EIBは、イメージの構築時にパッケージ解決プロセスを実行し、ゴールデンイメージを入力として受け取り、提供されているパッケージ(リストで指定されているか、ローカルで提供されているパッケージ)をすべてプルしてインストールしようと試みます。EIBは、依存関係を含むすべてのパッケージを出力イメージ内に存在するリポジトリにダウンロードし、そのパッケージを初回ブートプロセス中にインストールするようにシステムに指示します。イメージの構築中にこのプロセスを実行することで、初回ブート時にパッケージが目的のプラットフォーム(エッジのノードなど)に正常にインストールされることが保証されます。これは、操作時に追加パッケージをネットワーク経由でプルするのではなく、イメージに事前に書き込んでおきたい環境でも便利です。たとえば、エアギャップ環境や、ネットワークが制限された環境です。

これを示すシンプルな例として、サードパーティベンダがサポートするNVIDIAリポジトリにあるnvidia-container-toolkit RPMパッケージをインストールします。

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

生成される定義ファイルは次のようになります。

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

上記はシンプルな例ですが、完全を期するために、イメージ生成を実行する前にNVIDIAパッケージ署名キーをダウンロードしてください。

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

警告

この方法でRPMを追加することは、サポートされているサードパーティコンポーネント、またはユーザが提供(および保守)するパッケージを追加することを目的としています。このメカニズムは、通常ではSUSE Linux Microでサポートされないパッケージを追加する目的では使用しないでください。このメカニズムを使用して、openSUSEのリポジトリから新しいリリースやサービスパックなどのコンポーネントを追加した場合(この操作はサポートされません)、最終的にサポート対象外の設定になるおそれがあります。特に、依存関係の解決によってオペレーティングシステムのコア部分が置き換えられる場合は、作成されたシステムが期待どおりに機能しているように見えても注意が必要です。確信が持てない場合は、SUSEの担当者に連絡してサポートを依頼し、目的の設定がサポート可能かどうかを判断してください。

注記

追加の例を含む総合的なガイドについては、アップストリームのパッケージインストールガイドを参照してください。

3.3.5 Kubernetesクラスタとユーザワークロードの設定 #

 

EIBのもう1つの特徴は、EIBを使用すると、「インプレースでブートストラップ」する(つまり調整のためにどのような形態の集中管理インフラストラクチャも必要としない)シングルノードとマルチノード両方の高可用性Kubernetesクラスタのデプロイメントを自動化できることです。このアプローチは主にエアギャップデプロイメント、すなわちネットワークが制限された環境のためのものですが、ネットワークに制限なく完全にアクセスできる場合であっても、スタンドアロンクラスタを迅速にブートストラップする方法として役立ちます。

この方法を使用すると、カスタマイズされたオペレーティングシステムをデプロイできるだけでなく、Kubernetesの設定を指定したり、Helmチャートを介して追加の階層化コンポーネントを指定したり、指定したKubernetesマニフェストを介してユーザワークロードを指定したりすることもできます。ただしこの方法を使用する場合、その背景にある設計理念として、ユーザがエアギャップ化を望んでいるとデフォルトで想定します。したがって、イメージ定義で指定されているすべての項目を、ユーザが指定したワークロードを含めてイメージにプルします。その際に、EIBは、提供された定義で要求されている検出済みイメージをすべてローカルにコピーし、作成されたデプロイ済みシステムの組み込みのイメージレジストリで提供します。

次の例では、既存のイメージ定義を使用してKubernetesの設定を指定します(この例では、複数のシステムとその役割が一覧にされていないため、デフォルトでシングルノードを想定します)。この設定により、シングルノードのRKE2 KubernetesクラスタをプロビジョニングするようにEIBに指示します。ユーザが指定したワークロード(マニフェストを使用)と階層化コンポーネント(Helmを使用)の両方のデプロイメントの自動化を説明するために、SUSE EdgeのHelmチャートを使用してKubeVirtをインストールし、Kubernetesマニフェストを使用してNGINXをインストールします。既存のイメージ定義に追加する必要がある設定は次のとおりです。

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

作成された完全な定義ファイルは次のようになります。

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

注記

マルチノードデプロイメント、カスタムネットワーキング、Helmチャートのオプション/値など、オプションの他の例については、アップストリームドキュメントを参照してください。

3.3.6 ネットワークの設定 #

 

このクイックスタートの最後の例では、EIBで生成したイメージを使ってシステムをプロビジョニングした場合に作成されるネットワークを設定しましょう。ネットワーク設定を指定しない限り、ブート時に検出されたすべてのインタフェースでDHCPが使用されるのがデフォルトのモデルであることを理解することが重要です。ただし、これが常に望ましい設定であるとは限りません。これは特に、DHCPが利用できず静的な設定を指定する必要がある場合や、より複雑なネットワーキング構造(ボンド、LACP、VLANなど)を設定する必要がある場合、特定のパラメータ(ホスト名、DNSサーバ、ルートなど)を上書きする必要がある場合に該当します。

EIBでは、ノードごとの設定を指定することも(対象のシステムをMACアドレスで一意に識別します)、上書きによって各マシンに同一の設定を指定することもできます(システムのMACアドレスが不明な場合に便利です)。またEIBでは、Network Manager Configurator (nmc)というツールも追加で使用されます。Network Manager ConfiguratorはSUSE Edgeチームによって構築されたツールであり、nmstate.ioの宣言型ネットワークスキーマに基づいてカスタムネットワーキング設定を適用できるようにします。また、ブートしているノードをブート時に識別し、必要なネットワーク設定をサービス開始前に適用します。

ここでは、1つのインタフェースを持つシステムに静的ネットワーク設定を適用します。そのために、ネットワークの望ましい状態を、必要なnetworkディレクトリ内にある(目的のホスト名に基づく)ノード固有のファイルに記述します。

mkdir $CONFIG_DIR/network

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

警告

上記の例は、テストを仮想マシン上で実行すると仮定して、デフォルトの192.168.122.0/24サブネット用に設定されています。ご使用の環境に合わせて、MACアドレスも忘れずに変更してください。同じイメージを使用して複数のノードをプロビジョニングできるため、 EIBで(nmcを介して)設定されたネットワーキングは、各ノードをMACアドレスで一意に識別できるかどうかに依存しており、その後、ブート中にnmcは正しいネットワーキング設定を各マシンに適用します。つまり、インストール先のシステムのMACアドレスを把握する必要があります。また、デフォルトの動作ではDHCPに依存しますが、configure-network.shフックを利用して、すべてのノードに共通の設定を適用することもできます。詳細については、ネットワーキングのガイド(第12章 「Edgeネットワーキング」)を参照してください。

作成されるファイル構造は、次のようになります。

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

作成したネットワーク設定が解析され、必要なNetworkManager接続ファイルが自動的に生成されて、EIBが作成する新しいインストールイメージに挿入されます。これらのファイルはホストのプロビジョニング中に適用され、完全なネットワーク設定が生成されます。

注記

上記の設定のより包括的な説明と、この機能の例については、Edgeネットワーキングのコンポーネント(第12章 「Edgeネットワーキング」)を参照してください。

EIBで使用するゴールデンイメージとイメージ定義ができたので、イメージを構築してみましょう。これには、podmanを使用し、定義ファイルを指定して「build」コマンドでEIBコンテナを呼び出すだけです。

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

コマンドの出力は次のようになります。

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

構築されたISOイメージは$CONFIG_DIR/eib-image.isoに保存されます。

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

ビルドごとに、$CONFIG_DIR/_build/内にタイムスタンプ付きのフォルダが作成されます。このフォルダには、ビルドのログ、ビルド中に使用されたアーティファクト、およびCRBイメージに追加されたすべてのスクリプトとアーティファクトを含むcombustionディレクトリとartefactsディレクトリが含まれます。

このディレクトリの内容は次のようになります。

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

ビルドが失敗した場合、情報が含まれる最初のログはeib-build.logです。そこから、失敗したコンポーネントに移動してデバッグを行います。

この時点で、以下を行う、すぐに使用できるイメージができているはずです。

イメージ構築プロセスが失敗する場合は、アップストリームのデバッグガイドを参照してください。

新しく構築されたCRBイメージをテストする方法については、アップストリームのイメージテストガイドを参照してください。

最新バージョンのSUSE Multi-Linux Manager 5.0のインスタンスをすでに実行している場合は、この手順をスキップできます。

SUSE Multi-Linux Manager Serverは、専用の物理サーバ、自身のハードウェア上の仮想マシン、またはクラウドで実行できます。SUSE Multi-Linux Serverの事前に設定された仮想マシンイメージはサポートされているパブリッククラウド用に提供されています。

このクイックスタートでは、 AMD64/Intel 64用の「qcow2」イメージSUSE-Manager-Server.x86_64-5.0.2-Qcow-2024.12.qcow2を使用しています。このイメージは、https://www.suse.com/download/suse-manager/またはSUSE Customer Centerで入手できます。このイメージは、KVMなどのハイパーバイザー上の仮想マシンとして機能します。イメージの最新バージョンを常に確認して、新しいインストールに使用してください。

SUSE Multi-Linux Manager Serverを他のサポートされているハードウェアアーキテクチャにもインストールできます。その場合は、ハードウェアアーキテクチャに合ったイメージを選択してください。

イメージをダウンロードしたら、次の最小ハードウェア仕様を満たす仮想マシンを作成します。

qcow2イメージでは、オペレーティングシステムをインストールする必要はありません。イメージをルートパーティションとして直接アタッチできます。

後でエッジノードが完全修飾ドメイン名(「FQDN」)を含むホスト名でSUSE Multi-Linux Manager Serverにアクセスできるように、ネットワークを設定する必要があります。

SUSE Multi-Linux Managerを初めてブートする際には、いくつかの初期設定を実行する必要があります。

次の各手順は「ルート」ユーザとして実行する必要があります。

次の手順では、SUSE Customer Centerで入手できる次の2つの登録コードが必要です。

SUSE Linux Microを登録します。

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

SUSE Multi-Linux Managerを登録します。

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

製品文字列は、ハードウェアアーキテクチャによって異なります。たとえば、64ビットArmシステムでSUSE Multi-Linux Managerを使用している場合、文字列は「SUSE-Manager-Server/5.0/aarch64」になります。

再起動します。

システムを更新します。

transactional-update

変更がなければ、再起動して更新を適用します。

SUSE Multi-Linux Managerは、Podmanによって管理されるコンテナを介して提供されます。mgradmコマンドがセットアップと設定を自動的に行います。

警告

SUSE Multi-Linux Manager Serverのホスト名が、管理対象のエッジノードがネットワークで適切に解決できる完全修飾ドメイン名(「FQDN」)で設定されていることが非常に重要です。

SUSE Multi-Linux Manager Serverコンテナをインストールして設定する前に、以前に追加したブロックデバイスを準備しておく必要があります。そのためには、仮想マシンがデバイスに付けた名前を知っておく必要があります。たとえば、ブロックデバイスが/dev/vdbの場合、次のコマンドを使用してSUSE Multi-Linux Managerで使用するように設定できます。

mgr-storage-server /dev/vdb

SUSE Multi-Linux Managerをデプロイします。

mgradm install podman <FQDN>

CA証明書のパスワードを入力します。このパスワードはログインパスワードとは異なる必要があります。通常は後で入力する必要はありませんが、メモしておいてください。

「admin」ユーザのパスワードを入力します。これは、SUSE Multi-Linux Managerにログインするための初期ユーザです。後で完全な権利または制限された権利を持つ追加のユーザを作成できます。

デプロイメントが完了したら、先ほど指定したホスト名を使用して、SUSE Multi-Linux Manager Web UIにログインできます。初期ユーザは「admin」です。前の手順で指定したパスワードを使用します。

次の手順では、SUSE Customer Centerの組織の「ユーザ」タブの2番目のサブタブにある組織の資格情報が必要です。これらの資格情報を使用して、SUSE Multi-Linux Managerはサブスクリプションを持つすべての製品を同期できます。

管理 › セットアップウィザードの順に選択します。

組織の資格情報タブで、SUSE Customer Centerにあるユーザ名とパスワードを使用して新しい資格情報を作成します。

次のタブ［SUSE製品］に移動します。 SUSE Customer Centerとの最初のデータ同期が完了するまで待つ必要があります。

リストが入力されたら、フィルタを使用して「Micro 6」のみを表示します。 エッジノードが実行されるハードウェアアーキテクチャ(x86_64またはaarch64)に対応するSUSE Linux Micro 6.1のチェックボックスをオンにします。

［製品の追加］をクリックします。これにより、SUSE Linux Microのメインパッケージリポジトリ(「チャンネル」)が追加され、SUSE Managerクライアントツールのチャンネルがサブチャンネルとして自動的に追加されます。

インターネット接続によっては、最初の同期にしばらく時間がかかります。次の手順からすぐに開始できます。

［システム］ >［システムグループ］で、システムがオンボード時に自動的に参加するグループを少なくとも1つ作成します。グループはシステムを分類する重要な方法であり、設定やアクションをシステムセット全体に一度に適用できます。概念的には、Kubernetesのラベルに似ています。

［+グループの作成］をクリックします。

短い名前(「エッジノード 」など)と長い説明を入力します。

［システム］ >［アクティベーションキー］で、少なくとも1つのアクティベーションキーを作成します。アクティベーションキーは、システムが SUSE Multi-Linux Managerにオンボードされたときに自動的に適用される設定プロファイルと考えることができます。特定のエッジノードを異なるグループに追加したり、異なる設定を使用したりする場合は、それら用に個別のアクティベーションキーを作成し、後でEdge Image Builderでカスタマイズしたインストールメディアを作成する際に使用できます。

アクティベーションキーの典型的な高度なユースケースは、テストクラスタを最新の更新を含むソフトウェアチャンネルに割り当て、運用クラスタを、テストクラスタでテストした後にのみ最新の更新を取得するソフトウェアチャンネルに割り当てることです。

［+キーの作成］をクリックします。

短い説明を選択します(「エッジノード」など)。キーを識別する一意の名前を指定します(AMD64/Intel 64ハードウェアアーキテクチャを備えたエッジノードの場合は 「edge-x86_64 」など)。 番号のプレフィックスが自動的にキーに追加されます。デフォルトの組織の場合、番号は常に「1」です。SUSE Multi-Linux Managerで追加の組織を作成し、これらの組織のキーを作成する場合、この番号は異なる可能性があります。

クローンソフトウェアチャンネルを作成していない場合は、ベースチャンネルの設定を「SUSE Managerの既定値」のままにしておくことができます。これにより、エッジノードに正しいSUSE更新リポジトリが自動的に割り当てられます。

「子チャンネル」として、アクティベーションキーが使用されているハードウェアアーキテクチャの［推奨を含める］スライダを選択します。これにより、「SUSE-Manager-Tools-For-SL-Micro-6.1」チャンネルが追加されます。

［グループ］タブで、以前に作成したグループを追加します。このアクティベーションキーを使用してオンボードされたすべてのノードがそのグループに自動的に追加されます。

Edge Image Builderを使用するには、PodmanでLinuxベースのコンテナを起動できる環境のみが必要です。

最小限のラボのセットアップでは、SUSE Multi-Linux Manager Serverが実行しているのと同じ仮想マシンを実際に使用できます。仮想マシンに十分なディスク容量があることを確認してください。これは運用環境での使用には推奨されないセットアップです。Edge Image Builderをテストしたホストオペレーティングシステムについては、 3.1項 「前提条件」を参照してください。

SUSE Multi-Linux Managerサーバホストにrootとしてログインします。

Edge Image Builderコンテナをプルします。

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

ディレクトリ/opt/eibとサブディレクトリbase-imagesを作成します。

mkdir -p /opt/eib/base-images

このクイックスタートでは、SUSE Linux Microイメージの「セルフインストール」フレーバーを使用しています。このイメージは、後で物理USBメモリに書き込んで、物理サーバにインストールするために使用できます。ご使用のサーバにBMC (ベースボード管理コントローラ)経由でインストールISOをリモートアタッチするオプションがある場合は、その方法も使用できます。また、このイメージはほとんどの仮想化ツールでも使用できます。

イメージを物理ノードに直接プリロードする場合、またはVMから直接起動する場合は、「生」イメージフレーバーを使用することもできます。

これらのイメージはSUSE Customer Centerまたはhttps://www.suse.com/download/sle-micro/にあります。

イメージ SL-Micro.x86_64-6.1-Default-SelfInstall-GM.install.isoをbase-imagesディレクトリにダウンロードまたはコピーして、「slemicro.iso」という名前を付けます。

Armベースの構築ホスト上でのAArch64イメージの構築は、SUSE Edge 3.3.1の技術プレビュー対象です。おそらく動作しますが、まだサポートされていません。お試しいただく場合は、64ビットのArmマシンでPodmanを実行し、すべての例とコードスニペットの「x86_64」を「aarch64」に置き換える必要があります。

/opt/eibに、iso-definition.yamlというファイルを作成します。これはEdge Image Builderのビルド定義です。

ここでは、SL Micro 6.1をインストールし、ルートパスワードとキーマップを設定して、CockpitグラフィカルUIを起動し、ノードをSUSE Multi-Linux Managerに登録するシンプルな例を示します。

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

Edge Image Builderは、ネットワークを設定し、ノードにKubernetesを自動的にインストールして、Helmチャート経由でアプリケーションをデプロイすることもできます。より包括的な例については、第3章 「Edge Image Builderを使用したスタンドアロンクラスタ」を参照してください。

baseImageには、使用するbase-imagesディレクトリ内のISOの実際の名前を指定します。

この例では、ルートパスワードは「root」になります。使用する安全なパスワードのパスワードハッシュを作成する方法については、3.3.1項 「OSユーザの設定」を参照してください。

キーマップを、インストール後にシステムが使用する実際のキーボードレイアウトに設定します。

注記

SUSEではRPMパッケージのチェックにGPGキーを提供しないため、 オプションnoGPGCheck: trueを使用しています。運用環境での使用に推奨するより安全なセットアップに関する包括的なガイドについては、アップストリームのパッケージインストールガイドを参照してください。

何度か言及したように、SUSE Multi-Linux Managerホストには、エッジノードがブートするネットワークで解決できる完全修飾ホスト名が必要です。

activationKeyの値は、SUSE Multi-Linux Managerで作成したキーと一致する必要があります。

インストール後にエッジノードをSUSE Multi-Linux Managerに自動的に登録するインストールイメージを構築するには、次の2つのアーティファクトを準備する必要もあります。

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

/opt/eibに、サブディレクトリcertificatesを作成します。

SUSE Multi-Linux ManagerからそのディレクトリにCA証明書をダウンロードします。

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

警告

証明書の名前をRHN-ORG-TRUSTED-SSL-CERT.crtに変更する必要があります。その後、Edge Image Builderは、インストール時に証明書がエッジノードにインストールされ、アクティブ化されていることを確認します。

これでEdge Image Builderを実行できます。

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

YAML定義ファイルに別の名前を使用している場合や別のバージョンのEdge Image Builderを使用する場合は、それに応じてコマンドを調整する必要があります。

ビルドが完了したら、 /opt/eibディレクトリにインストールISOがeib-image.isoとして保存されます。

Rancherは、SUSE Edgeスタックに複数のコア機能を提供します。

SUSE Edgeは、SUSE Linux Micro OSのゴールデンイメージをカスタマイズするために第11章 「Edge Image Builder」を使用しています。EIBでプロビジョニングしたKubernetesクラスタ上にRancherをエアギャップインストールするには、27.6項 「Rancherのインストール」に従ってください。

ダッシュボード拡張機能を含むすべてのSUSE Edge 3.3.1コンポーネントは、OCIアーティファクトとして配布されます。SUSE Edge拡張機能をインストールするには、Rancher Dashboard UI、Helm、またはFleetを使用できます。

6.1.2 Helmを使用したインストール #

 

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

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

注記

拡張機能はcattle-ui-plugin-systemネームスペースにインストールする必要があります。

注記

拡張機能がインストールされたら、Rancher Dashboard UIを再ロードする必要があります。

6.1.3 Fleetを使用したインストール #

 

Fleetを使用してダッシュボード拡張機能をインストールするには、カスタムのfleet.yamlバンドル設定ファイルを使用して、Gitリポジトリを指すgitRepoリソースを定義する必要があります。

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

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

注記

拡張機能を正しくインストールするには、releaseNameプロパティが必須であり、拡張機能名と一致している必要があります。

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

詳細については、 第8章 「Fleet」とfleet-examplesリポジトリを参照してください。

拡張機能がインストールされると、その拡張機能が［Extensions (拡張機能)］セクションの［Installed (インストール済み)］タブに表示されます。拡張機能はApps/Marketplace経由でインストールされたものではないため、「Third-Party (サードパーティ)」というラベルが付きます。

KubeVirt拡張機能は、Rancher Dashboard UIに基本的な仮想マシン管理機能を提供します。その機能については、21.7.2項 「KubeVirt Rancher Dashboard拡張機能の使用」を参照してください。

Akriは、異種リーフデバイス(IPカメラやUSBデバイスなど)をKubernetesクラスタのリソースとして簡単に公開できると同時に、GPUやFPGAなどの組み込みハードウェアリソースの公開もサポートするKubernetesリソースインタフェースです。Akriは、このようなデバイスにアクセスできるノードを継続的に検出し、それらに基づいてワークロードをスケジュールします。

Akriダッシュボード拡張機能を使用すると、Rancher Dashboardユーザインタフェースを使用して、リーフデバイスを管理および監視し、デバイスが検出されたらワークロードを実行できます。

拡張機能については、14.5項 「Akri Rancher Dashboard拡張機能」で詳しく説明されています。

SUSE Edgeスタックは、Rancher Turtlesを次のコンポーネントを有効にする特定の設定でインストールするhelmラッパーチャートを提供します。

ラッパーチャートを介してインストールされるデフォルトプロバイダのみがサポートされます。代替コントロールプレーン、ブートストラップ、およびインフラストラクチャプロバイダは現在、SUSE Edgeスタックの一部としてサポートされていません。

Rancher Turtlesは、Metal3クイックスタート(第1章 「Metal³を使用したBMCの自動デプロイメント」)ガイド、または管理クラスタ(第40章 「管理クラスタの設定」)ドキュメントに従ってインストールできます。

FleetはRancherにビルトインされていますが、Helmを使用して、スタンドアロンアプリケーションとして任意のKubernetesクラスタにインストールすることもできます。

Rancherは、Fleetを使用してアプリケーションを管理対象クラスタ全体にデプロイします。Fleetを使用した継続的デリバリにより、大量のクラスタで実行されるアプリケーションを管理するために設計された、大規模なGitOpsが導入されます。

FleetはRancherと統合してその一部として機能します。Rancherで管理されるクラスタには、インストール/インポートプロセスの一部としてFleetエージェントが自動的にデプロイされるため、クラスタはすぐにFleetで管理できるようになります。

FleetはRancherにプリインストールされており、Rancher UIの［Continuous Delivery (継続的デリバリ)］オプションで管理されます。

［Continuous Delivery (継続的デリバリ)］セクションは次の項目で構成されます。

ナビゲーションの［Advanced (詳細)］セクションでは、下位レベルのFleetリソースの概要が表示されます。バンドルは、Gitからのリソースのオーケストレーションに使用される内部リソースです。Gitリポジトリがスキャンされると、バンドルが1つ以上生成されます。

特定のリポジトリに関連するバンドルを見つけるには、［Git Repos (Gitリポジトリ)］の［Detail (詳細)］ページに移動し、［Bundles (バンドル)］タブをクリックします。

クラスタごとに、作成されたBundleDeploymentリソースにバンドルが適用されます。BundleDeploymentの詳細を表示するには、［Git Repos (Gitリポジトリ)］の［Detail (詳細)］ページの右上にある ［Graph (グラフ)］ボタンをクリックします。［Repo (リポジトリ) ］>［Bundles (バンドル)］>［BundleDeployments］のグラフがロードされます。グラフ内のBundleDeploymentをクリックすると詳細が表示され、［Id (ID)］をクリックするとBundleDeployment YAMLが表示されます。

Fleetのトラブルシューティングのヒントに関する追加情報については、こちらを参照してください。

Edgeチームは、Fleetを使用してEdgeプロジェクトをインストールする例を含むリポジトリを維持しています。

Fleetプロジェクトには、Gitリポジトリ構造のすべてのユースケースをカバーするfleet-examplesリポジトリが含まれています。

SUSEでは、SUSE Linux Microをプラットフォームスタックのベースオペレーティングシステムとして使用します。これにより、構築基盤となる、安全で安定した最小限のベースが提供されます。

SUSE Linux Microでは、独自の方法でファイルシステム(Btrfs)スナップショットを使用しており、アップグレードで問題が発生した場合に簡単にロールバックできます。これにより、問題が発生した場合、物理的にアクセスしなくてもプラットフォーム全体をリモートで安全にアップグレードできます。

この方法は、ターゲットハードウェアがアウトオブバンド管理をサポートしていて、完全に自動化されたインフラストラクチャ管理フローが望まれるシナリオで役立ちます。

この方法では宣言型APIが提供されており、このAPIを使用することで、検査、クリーニング、プロビジョニング/プロビジョニング解除の自動化を含む、ベアメタルサーバのインベントリと状態の管理が可能になります。

SUSE Edgeでは、さまざまなシナリオ用にカスタマイズされたSUSE Linux Microイメージをシンプルかつ迅速に設定するためにEIBを使用します。これらのシナリオには、以下を使用する仮想マシンとベアメタルマシンのブートストラップが含まれます。

Edge Image Builderの使用とテストに関する包括的なドキュメントについては、こちらを参照してください。

また、基本的なデプロイメントシナリオを説明している第3章 「Edge Image Builderを使用したスタンドアロンクラスタ」を参照してください。

このツールに慣れたら、ヒントとコツページでさらに役立つ情報を見つけてください。

NetworkManagerは、プライマリネットワーク接続と他の接続インタフェースを管理するツールです。

NetworkManagerは、ネットワーク設定を、望ましい状態が含まれる接続ファイルとして保存します。これらの接続は、/etc/NetworkManager/system-connections/ディレクトリにファイルとして保存されます。

NetworkManagerの詳細については、SUSE Linux Microのドキュメントを参照してください。

nmstateは広く採用されているライブラリ(CLIツールが付属)であり、定義済みスキーマを使用したネットワーク設定用の宣言型APIを提供します。

nmstateの詳細については、アップストリームドキュメントを参照してください。

SUSE Edgeで利用可能なネットワークのカスタマイズオプションは、NetworkManager Configurator (短縮名はnmc)と呼ばれるCLIツールを使用して実行します。このツールはnmstateライブラリによって提供される機能を利用しているため、静的IPアドレス、DNSサーバ、VLAN、ボンディング、ブリッジなどを完全に設定できます。このツールを使用して、事前定義された望ましい状態からネットワーク設定を生成し、その設定を多数のノードに自動的に適用できます。

NetworkManager Configurator (nmc)の詳細については、アップストリームリポジトリを参照してください。

SUSE Edgeは、nmcを利用して次のようなさまざまなプロビジョニングモデルでネットワークをカスタマイズします。

Edge Image Builder (EIB)は、1つのOSイメージで複数のホストを設定できるツールです。このセクションでは、宣言型アプローチを使用して、どのように目的のネットワーク状態を記述するかと、それらがどのように各NetworkManager接続に変換され、プロビジョニングプロセス中に適用されるかを示します。

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

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

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

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

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

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

12.5.5 ネットワーク設定の定義 #

 

先ほど作成したイメージ定義ファイルには、望ましいネットワーク設定が含まれていません。そこで、network/という特別なディレクトリの下にその設定を入力します。では、作成してみましょう。

mkdir -p $CONFIG_DIR/network

前述のように、NetworkManager Configurator (nmc)ツールでは、事前定義されたスキーマの形式での入力が必要です。さまざまなネットワーキングオプションの設定方法については、アップストリームのNMStateの例のドキュメントを参照してください。

このガイドでは、次の3つの異なるノードでネットワーキングを設定する方法について説明します。

• 2つのEthernetインタフェースを使用するノード

• ネットワークボンディングを使用するノード

• ネットワークブリッジを使用するノード

警告

特にKubernetesクラスタを設定する場合、まったく異なるネットワークセットアップを運用ビルドで使用することは推奨されません。ネットワーキング設定は通常、特定のクラスタ内のノード間、または少なくともロール間で同種にすることをお勧めします。このガイドにはさまざまな異なるオプションが含まれていますが、これは参考例として提供することのみを目的としています。

注記

以下では、IPアドレス範囲192.168.122.1/24を使用するデフォルトのlibvirtネットワークを想定しています。ご自身の環境でこの範囲が異なる場合は、適宜調整してください。

node1.suse.comという名前の最初のノードに対して、望ましい状態を作成しましょう。

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

この例では、2つのEthernetインタフェース(eth0とeth3)、要求されたIPアドレス、ルーティング、およびDNS解決の望ましい状態を定義しています。

警告

必ず、すべてのEthernetインタフェースのMACアドレスを記述してください。これらのMACアドレスは、プロビジョニングプロセス中にノードの識別子として使用され、どの設定を適用すべきかを判断するのに役立ちます。このようにして、1つのISOまたはRAWイメージを使用して複数のノードを設定できます。

次は、node2.suse.comという名前の2つ目のノードです。このノードではネットワークボンディングを使用します。

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

この例では、IPアドレス指定を有効にしていない2つのEthernetインタフェース(eth0とeth1)の望ましい状態と、ラウンドロビンポリシーによるボンディング、およびネットワークトラフィックを転送するために使用する各アドレスを定義します。

最後に、3つ目となる、望ましい状態の最後のファイルを作成します。これはネットワークブリッジを利用し、node3.suse.comという名前です。

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

この時点では、設定ディレクトリは次のようになっているはずです。

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

注記

network/ディレクトリにあるファイル名は意図的なものです。これらの名前は、プロビジョニングプロセス中に設定されるホスト名に対応しています。

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

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

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

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

Starting install...
Creating domain...

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


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

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


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

node1 login:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

mkdir -p $CONFIG_DIR/network

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

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

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

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

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

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

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

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

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

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

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

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

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

12.5.9 カスタムネットワーク設定 #

 

ここまでは、NetworkManager Configuratorを利用した、Edge Image Builderのデフォルトのネットワーク設定について説明してきました。一方で、カスタムスクリプトを使用してネットワーク設定を変更するオプションもあります。このオプションは非常に柔軟性が高く、MACアドレスにも依存しませんが、1つのイメージで複数のノードをブートストラップする場合に使用してもあまり便利ではないという制限があります。

注記

/networkディレクトリにある、望ましいネットワーク状態を記述したファイルを介して、デフォルトのネットワーク設定を使用することをお勧めします。カスタムスクリプトを選択するのは、デフォルト設定の動作がユースケースに当てはまらない場合のみにしてください。

異なる設定構造を使用して、エッジノードを構築およびプロビジョニングします。12.5.3項 「イメージ設定ディレクトリの作成」から12.5.5項 「ネットワーク設定の定義」のすべての手順に従います。

この例では、プロビジョニングされたすべてのノードでeth0インタフェースに静的設定を適用し、NetworkManagerによって自動的に作成された有線接続を削除して無効にするカスタムスクリプトを作成します。これは、クラスタ内のすべてのノードに同一のネットワーキング設定を確実に適用したい場合に便利です。その結果、イメージの作成前に各ノードのMACアドレスを気にする必要がなくなります。

まず、/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

静的設定が作成されたので、カスタムネットワークスクリプトも作成します。

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

注記

nmcのバイナリはこれまで同様にデフォルトで含まれるため、必要に応じてconfigure-network.shスクリプトで使用することもできます。

警告

カスタムスクリプトは常に設定ディレクトリの/network/configure-network.shで提供する必要があります。このファイルが存在する場合、他のファイルはすべて無視されます。YAML形式の静的設定とカスタムスクリプトの両方を同時に使用してネットワークを設定することはできません。

この時点では、設定ディレクトリは次のようになっているはずです。

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

イメージを構築してみましょう。

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

イメージが正常に構築されたら、それを使用して仮想マシンを作成しましょう。

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

プロビジョニングプロセスには数分かかる場合があります。終了したら、指定された資格情報でシステムにログインします。

ルーティングが適切に設定されていることを確認します。

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

インターネット接続が利用できることを確認します。

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

接続ファイルを使用してEthernetインタフェースが静的に設定されていて、アクティブであることを確認します。

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

SUSEでは、Metal³を選択できないリモートデバイス(たとえば、BMCがない、デバイスがNATゲートウェイの背後にあるなど)の管理にElementalの一部を使用しています。このツールにより、オペレータは、デバイスがいつどこに配置されるかがわかる前に、ラボでデバイスをブートストラップできます。すなわち、elemental-registerとelemental-system-agentコンポーネントを利用して、「Phone Home」ネットワークプロビジョニングのユースケースでSUSE Linux MicroホストをRancherにオンボードできます。Edge Image Builder (EIB)を使用してデプロイメントイメージを作成する場合、EIBの設定ディレクトリで登録設定を指定することで、Rancherを使用してElemental経由で自動登録を行うことができます。

注記

SUSE Edge 3.3.1では、Elementalのオペレーティングシステム管理の側面を利用していないため、Rancher経由でオペレーティングシステムのパッチを管理することはできません。SUSE Edgeでは、Elementalツールを使用してデプロイメントイメージを構築する代わりに、登録設定を使用するEdge Image Builderツールを使用します。

警告

Akriは現在、SUSE Edgeスタックでの技術プレビュー中です。

Akriは、リーフデバイスに対するワークロードの検出とスケジューリングが必要な場合はいつでも、Edgeスタックの一部として利用できます。

AkriはEdge Helmリポジトリ内でHelmチャートとして利用できます。Akriを設定するための推奨方法は、指定したHelmチャートを使用してさまざまなコンポーネント(エージェント、コントローラ、ディスカバリハンドラ)をデプロイし、好みのデプロイメントメカニズムを使用してAkriの設定CRDをデプロイすることです。

Akriは、akri.sh/Configurationオブジェクトを使用して設定します。このオブジェクトは、デバイスの検出方法、および一致するデバイスが検出されたときの処理に関するすべての情報を取得します。

以下に、設定例の内訳を示し、すべてのフィールドについて説明します。

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

次の部分では、ディスカバリハンドラの設定を記述しています。ディスカバリハンドラの名前を指定する必要があります(Akriのチャートの一部として利用可能なハンドラは、udev、opcua、onvifです)。discoveryDetailsはハンドラ固有です。設定方法については、ハンドラのドキュメントを参照してください。

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

次のセクションでは、検出された各デバイスに対してデプロイするワークロードを定義します。この例では、brokerPodSpecでPod設定の最小バージョンが示されています。ここでは、Podの仕様の通常のフィールドをすべて使用できます。また、resourcesセクションに、デバイスを要求するためのAkri固有の構文も示されています。

または、Podの代わりにJobを使用することもできます。その場合は、代わりにbrokerJobSpecキーを使用し、そこにJobの仕様部分を指定します。

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

次の2つのセクションは、ブローカごとにサービスをデプロイするようにAkriを設定するか(instanceService)、またはすべてのブローカを指すようにAkriを設定する(configurationService)方法を示しています。これらには、通常のサービスに関連する要素がすべて含まれています。

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

brokerPropertiesフィールドは、検出されたデバイスを要求するPodに追加の環境変数として公開されるキー/値ストアです。

capacityは、検出されたデバイスの許容される同時ユーザ数です。

  brokerProperties:
    key: value
  capacity: 1

デバイスで使用されているプロトコルが既存のディスカバリハンドラでカバーされていない場合は、ハンドラ開発ガイドを使用して、独自に記述できます。

Akriダッシュボード拡張機能を使用すると、Rancher Dashboardユーザインタフェースを使用して、リーフデバイスを管理および監視し、デバイスが検出されたらワークロードを実行できます。

インストールのガイダンスについては、第6章 「Rancher Dashboard拡張機能」を参照してください。

拡張機能をインストールしたら、クラスタエクスプローラを使用してAkri対応の管理対象クラスタに移動できます。［Akri］ナビゲーショングループの下に［Configurations (設定)］］セクションと［Instances (インスタンス)］セクションがあります。

［Configurations (設定)］リストには、設定ディスカバリハンドラとインスタンス数に関する情報が表示されます。名前をクリックすると、設定の詳細ページが開きます。

設定の編集や新規作成も行うことができます。拡張機能を使用すると、ディスカバリハンドラの選択、ブローカPodやブローカJobの設定、設定サービスやインスタンスサービスのカスタマイズ、および設定容量の設定を行うことができます。

検出されたデバイスが ［Instances (インスタンス)］リストに一覧にされます。

インスタンス名をクリックすると、詳細ページが開き、ワークロードおよびインスタンスサービスを表示できます。

K3sは、SUSE Edgeスタックを支えるKubernetesディストリビューションとして使用できます。K3sはSUSE Linux Microオペレーティングシステムにインストールすることが意図されています。

K3sをSUSE EdgeスタックのKubernetesディストリビューションとして使用することは、etcdをバックエンドとして使用したのでは制約に合わない場合にのみ推奨します。etcdをバックエンドとして使用できる場合は、RKE2 (第16章 「RKE2」)を使用することをお勧めします。

K3sはエッジ、loT、ARMに焦点を当てた、完全準拠の軽量なKubernetes ディストリビューションであり、使いやすさとリソースに制約のある環境向けに最適化されています。

RKE2は、RKEの1.xバージョン(以下「RKE1」)とK3sの両方の長所を兼ね備えています。

RKE2は、K3sから使いやすさ、操作のしやすさ、およびデプロイメントモデルを継承しています。

RKE1から継承しているのは、アップストリームのKubernetesとの緊密な連携です。K3sはエッジデプロイメントに合わせて最適化されているため、アップストリームのKubernetesとは各所で異なりますが、RKE1とRKE2はアップストリームと緊密な連携を保つことができます。

RKE2はSUSE Edgeスタックの基礎を成す部分です。RKE2はSUSE Linux Micro (第9章 「SUSE Linux Micro」)上に位置し、Edgeワークロードをデプロイするために必要な標準Kubernetesインタフェースを提供します。

このガイドに従って操作を進める場合、以下がすでに用意されていることを想定しています。

SUSE Storageは、StorageClassというKubernetesリソースを利用して、PodのPersistentVolumeオブジェクトを自動的にプロビジョニングします。StorageClassは、管理者が、自身が提供するクラスまたはプロファイルを記述する方法だと考えてください。

デフォルトのオプションをいくつか使用してStorageClassを作成しましょう。

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

StorageClassを作成したので、それを参照するPersistentVolumeClaimが必要です。PersistentVolumeClaim (PVC)は、ユーザによるストレージの要求です。PVCはPersistentVolumeリソースを使用します。クレームでは、特定のサイズとアクセスモードを要求できます(たとえば、1つのノードで読み取り/書き込み可能でマウントすることも、複数のノードで読み取り専用でマウントすることもできます)。

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

完了です。PersistentVolumeClaimを作成したら、それをPodにアタッチする手順に進むことができます。Podがデプロイされると、KubernetesはLonghornボリュームを作成し、ストレージが利用可能な場合はPodにバインドします。

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

ヒント

Kubernetesにおけるストレージの概念は複雑であると同時に重要なトピックです。最も一般的なKubernetesリソースのいくつかを簡単に説明しましたが、Longhornが提供している用語のドキュメントをよく理解しておくことをお勧めします。

この例では、結果は次のようになります。

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

kubectlまたはHelmを使用してLonghornをインストールした場合は、クラスタへの外部トラフィックを許可するようにIngressコントローラを設定する必要があります。認証はデフォルトでは有効になっていません。Rancherカタログアプリを使用していた場合、IngressコントローラはRancherによって自動的に作成され、アクセス制御が設定されています(rancher-proxy)。

SUSE Edgeは、第11章 「Edge Image Builder」を使用して、ベースとなるSUSE Linux Micro OSイメージをカスタマイズしています。ここでは、イメージをカスタマイズしてRKE2クラスタとLonghornをSUSE Linux Micro上にプロビジョニングする方法について説明します。

定義ファイルを作成しましょう。

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

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

注記

Helmチャートの値のカスタマイズは、helm.charts[].valuesFileで提供されている別個のファイルを使用して実行できます。詳細については、アップストリームドキュメントを参照してください。

イメージを構築してみましょう。

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

イメージが構築されたら、それを使用して物理ホストまたは仮想ホストにOSをインストールできます。プロビジョニングが完了すると、root:eibの資格情報ペアを使用してシステムにログインできます。

Longhornが正常にデプロイされていることを確認します。

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

注記

このインストールは、完全なエアギャップ環境では動作しません。このような場合は、27.8項 「SUSE Storageのインストール」を参照してください。

SUSE Edgeは、エッジデプロイメントの開始点として簡潔なSUSE Security設定を提供します。

SUSE Edgeは、SUSE Linux Micro OSのゴールデンイメージをカスタマイズするために第11章 「Edge Image Builder」を使用しています。EIBでプロビジョニングしたKubernetesクラスタ上にSUSE Securityをエアギャップインストールするには、27.7項 「SUSE Securityのインストール」に従ってください。

SUSE Edgeでは、主に次の2つの方法でMetalLBを使用します。

注記

APIを公開できるようにするため、Endpoint Copier Operator (第20章 「Endpoint Copier Operator」)を使用して、 kubernetesサービスからkubernetes-vip LoadBalancerサービスへのK8s APIエンドポイントの同期を維持します。

L2モードでのMetalLBのインストールについては、第25章 「K3s上のMetalLB (レイヤ2モードを使用)」で説明されています。

kube-api-serverの前面にインストールして高可用性トポロジを実現する方法のガイドについては、第26章 「Kubernetes APIサーバの前面のMetalLB」を参照してください。

SUSE Edgeでは、Endpoint Copier OperatorがK3s/RKE2クラスタの高可用性(HA)セットアップを実現するために重要な役割を果たします。これは、LoadBalancerタイプのkubernetes-vipサービスを作成することで達成され、そのエンドポイントがkubernetesエンドポイントと常に同期を維持するようにします。公開されているIPアドレスはクラスタに参加するために他のノードから使用されるため、MetalLB (第19章 「MetalLB」)は kubernetes-vipサービスを管理するために活用されます。

Endpoint Copier Operatorの使用に関する包括的なドキュメントについては、こちらをご覧ください。

また、Endpoint Copier OperatorとMetalLBを使用してK3s/RKE2HA セットアップを実行するする方法については、SUSEのガイド(第25章 「K3s上のMetalLB (レイヤ2モードを使用)」)を参照してください。

現在、Endpoint Copier Operatorは1つのサービス/エンドポイントにのみ対応しています。今後、複数のサービス/エンドポイントをサポートする機能拡張が予定されています。

KubeVirtでは、仮想マシンと他のコンテナ化ワークロードを併せてKubernetesで管理できます。これを実現するために、Linux仮想化スタックのユーザスペース部分をコンテナ内で実行します。これにより、ホストシステムの要件が最小限に抑えられ、セットアップと管理が容易になります。

このガイドに従って操作を進める場合、以下がすでに用意されていることを想定しています。

このガイドでは、Kubernetesのデプロイメント手順については説明しませんが、SUSE Edgeに適したバージョンのK3sまたはRKE2がインストールされていること、およびkubeconfigが適切に設定されていて標準のkubectlコマンドをスーパーユーザとして実行できることを想定しています。また、シングルノードクラスタを形成することを想定していますが、マルチノードのデプロイメントでも大きな違いはないと考えられます。

SUSE Edge Virtualizationは、3つの別個のHelmチャートを使用してデプロイします。具体的には次のとおりです。

これらの各Helmチャートは、現在使用しているSUSE Edgeのリリースに従ってバージョン管理されています。運用での使用/サポートされる使用のためには、SUSEレジストリにあるアーティファクトを使用してください。

まず、 kubectlのアクセスが機能していることを確認します。

$ kubectl get nodes

次のような画面が表示されます。

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

これで、KubeVirtおよびContainerized Data Importer (CDI)のHelmチャートのインストールに進むことができます。

$ 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

数分ですべてのKubeVirtおよびCDIコンポーネントがデプロイされるはずです。これを検証するには、kubevirt-systemおよびcdi-systemのネームスペース内にデプロイされたすべてのリソースを確認します。

KubeVirtリソースを確認します。

$ kubectl get all -n kubevirt-system

次のような画面が表示されます。

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

CDIリソースを確認します。

$ kubectl get all -n cdi-system

次のような画面が表示されます。

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

VirtualMachineカスタムリソース定義(CRD)がデプロイされていることを確認するには、次のコマンドで検証できます。

$ kubectl explain virtualmachine

VirtualMachineオブジェクトの定義が出力され、次のような画面が表示されます。

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)

KubeVirtとCDIがデプロイされたので、openSUSE Tumbleweedに基づくシンプルな仮想マシンを定義してみましょう。この仮想マシンは最もシンプルな設定であり、標準の「Podネットワーキング」を使用して、他のPodと同じネットワーキング設定を行います。また、非永続ストレージを使用するため、PVCを持たないコンテナと同様に、ストレージは一時的なものになります。

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

これにより、VirtualMachineが作成されたことを示すメッセージが出力されます。

virtualmachine.kubevirt.io/tumbleweed created

このVirtualMachine定義は最小限であり、設定はほとんど指定されていません。この定義は単に、この仮想マシンが、一時的なcontainerDiskに基づくディスクイメージ(つまり、リモートイメージリポジトリからのコンテナイメージに保存されるディスクイメージ)を使用する、2GBのメモリを備えたマシンタイプ「q35」であることを示しています。また、base64でエンコードされたcloudInitディスクを指定しており、このディスクはブート時にユーザを作成してパスワードを適用する目的にのみ使用します(デコードにはbase64 -dを使用します)。

このマシンは、openSUSE Tumbleweedのディスクイメージをダウンロードする必要があるためブートに数分かかりますが、ブートが完了したら、次のコマンドで仮想マシンの情報をチェックして、仮想マシンの詳細を確認できます。

$ kubectl get vmi

これにより、仮想マシンが起動されたノードと、仮想マシンのIPアドレスが出力されます。Podネットワーキングを使用しているため、報告されるIPアドレスは他のPodと同様であり、ルーティング可能であることに注意してください。

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

これらのコマンドをKubernetesクラスタノード自体で実行する場合は、トラフィックをPodに直接ルーティングするCNI (Ciliumなど)を使用して、マシン自体に直接sshで接続できるはずです。次のIPアドレスを、仮想マシンに割り当てられているIPアドレスに置き換えます。

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

この仮想マシンに接続すると、さまざまな操作を試すことができますが、リソースの点で制限があり、ディスク容量は1GBしかないことに注意してください。終了したら、Ctrl-DまたはexitでSSHセッションを切断します。

仮想マシンプロセスは、依然として標準のKubernetes Podでラップされています。VirtualMachine CRDは目的の仮想マシンを表していますが、仮想マシンが実際に起動されるプロセスは、他のアプリケーションと同様に、標準のKubernetes Podであるvirt-launcher Podを介して行われます。起動されたすべての仮想マシンに対して、virt-launcher Podが存在することがわかります。

$ kubectl get pods

次に、定義したTumbleweedマシンの1つのvirt-launcher Podが表示されます。

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

このvirt-launcher Podを調べてみると、libvirtプロセスとqemu-kvmプロセスを実行していることがわかります。このPod自体を起動して詳細を確認できます。次のコマンドは、使用しているPodの名前に合わせて調整する必要があることに注意してください。

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

Podが起動したら、virshコマンドを実行するのと併せて、プロセスを確認してみます。qemu-system-x86_64バイナリに加え、仮想マシンを監視するための特定のプロセスも実行されていることがわかります。 また、ディスクイメージの場所と、ネットワーキングが(タップデバイスとして)どのように接続されているかもわかります。

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

最後に、この仮称マシンを削除して、クリーンアップしましょう。

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

KubeVirtには、標準のKubernetes CLIツールであるkubectlとともに、仮想化の世界とKubernetesが設計された世界との間のギャップを埋める方法でクラスタとのインタフェースを可能にするCLIユーティリティが付属しています。たとえば、 virtctlツールは、APIやCRDを直接使用することなく、仮想マシンのライフサイクル(起動、停止、再起動など)の管理、仮想コンソールへのアクセスの提供、仮想マシンイメージのアップロード、サービスなどのKubernetesコンストラクトとのインタフェースを行う機能を提供します。

virtctlツールの最新の安定バージョンをダウンロードしましょう。

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

別のアーキテクチャまたはLinux以外のマシンを使用している場合は、他のリリースをこちらで見つけることができます。続行する前に、この実行可能ファイルを作成する必要があります。また、実行可能ファイルを$PATH内の特定の場所に移動すると便利な場合があります。

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

その後、virtctlコマンドラインツールを使用して、仮想マシンを作成できます。出力をkubectl applyに直接パイプしていることに注意して、前の仮想マシンを複製してみましょう。

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

これで、仮想マシンが実行されているのがわかります(コンテナイメージがキャッシュされるため、今回はかなり早く起動するはずです)。

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

これで、 virtctlを使用して仮想マシンに直接接続できるようになりました。

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

virtctlで使用可能なコマンドはほかにも多数あります。たとえば、 virtctl consoleを使用すると、ネットワーキングが機能していない場合にシリアルコンソールにアクセスでき、virtctl guestosinfoを使用すると、ゲストにqemu-guest-agentがインストールされていて実行されていれば、包括的なOS情報を取得できます。

最後に、仮想マシンを一時停止し、再開してみましょう。

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

VirtualMachineオブジェクトが「Paused」と表示され、VirtualMachineInstanceオブジェクトは「Running」ですが「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

また、仮想マシンに接続できなくなっていることもわかります。

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

仮想マシンを再開して、もう一度試してみましょう。

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

これで、接続を再確立できるはずです。

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

最後に、仮想マシンを削除しましょう。

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

このセクションでは、仮想マシンを標準のKubernetesサービスとして公開し、NGINXとRKE2、TraefikとK3sなどのKubernetes Ingressサービスを介して利用可能にする方法を示します。このドキュメントでは、これらのコンポーネントがすでに適切に設定されていること、およびKubernetesサーバノードまたはIngress仮想IPを指す適切なDNSポインタが設定されていて(ワイルドカードを使用するなど)、Ingressを適切に解決できることを前提としています。

この例の環境では、別のopenSUSE Tumbleweed仮想マシンをデプロイし、cloud-initを使用して、ブート時にNGINXをシンプルなWebサーバとしてインストールしています。また、呼び出しの実行時に期待どおりに動作することを確認するためにシンプルなメッセージを返すように設定しています。この処理を確認するには、以下の出力のcloud-initのセクションに対してbase64 -dを実行するだけです。

では、この仮想マシンを作成してみましょう。

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

この仮想マシンが正常に起動したら、virtctlコマンドを使用して、外部ポート8080とターゲットポート80 (NGINXがデフォルトでリスンするポート)でVirtualMachineInstanceを公開できます。virtctlコマンドは、仮想マシンオブジェクトとPodのマッピングを理解しているため、ここではこのコマンドを使用します。これにより、新しいサービスが作成されます。

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

これで、適切なサービスが自動的に作成されます。

$ 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

次に、kubectl create ingressを使用すると、このサービスを指すIngressオブジェクトを作成できます。ここでURL (Ingressオブジェクトの「ホスト」として知られている)をDNS設定に合わせて調整し、ポート8080を指すようにします。

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

DNSが正しく設定されたら、URLに対してすぐにcurlを実行できます。

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

この仮想マシンとそのサービス、および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 VirtualizationはRancher Manager用のUI拡張機能を提供しており、Rancher Dashboard UIを使用して基本的な仮想マシン管理を行うことができます。

21.7.2 KubeVirt Rancher Dashboard拡張機能の使用 #

 

この拡張機能により、Cluster Explorerに新たに［KubeVirt］セクションが導入されます。このセクションは、KubeVirtがインストールされている管理対象クラスタに追加されます。

この拡張機能を使用すると、KubeVirt仮想マシンリソースを直接操作し、仮想マシンのライフサイクルを管理できます。

21.7.2.1 仮想マシンの作成 #

 

1. 左側のナビゲーションでKubeVirtが有効な管理対象クラスタをクリックして、［Cluster Explorer］に移動します。

2. ［KubeVirt］ > ［Virtual Machines (仮想マシン)］ページで、画面の右上にある［ Create from YAML (YAMLから作成)］をクリックします。

3. 仮想マシンの定義を入力するか貼り付けて、［Create (作成)］を押します。「仮想マシンのデプロイ 」セクションの仮想マシンの定義を参考にしてください。

21.7.2.2 仮想マシンのアクション #

 

各仮想マシンの右側にある ⋮ ドロップダウンリストからアクセスできるアクションメニューを使用して、起動、停止、一時停止、またはソフト再起動のアクションを実行できます。または、アクションを実行する仮想マシンを選択して、リストの一番上にあるグループアクションを使用することもできます。

アクションを実行すると、仮想マシン実行戦略に影響する場合があります。詳細についてはKubeVirtドキュメントの表を参照 してください。

21.7.2.3 仮想マシンコンソールへのアクセス #

 

［Virtual Machines (仮想マシン)］リストには［Console (コンソール)］ドロップダウンリストがあり、ここからVNCまたはシリアルコンソールを使用してマシンに接続できます。このアクションは、実行中のマシンでのみ使用できます。

新しく起動した仮想マシンでは、コンソールにアクセスできるようになるまでにしばらく時間がかかることがあります。

SUSE Edgeは、SUSE Linux Micro OSのゴールデンイメージをカスタマイズするために第11章 「Edge Image Builder」を使用しています。EIBでプロビジョニングしたKubernetesクラスタ上にKubeVirtとCDIの両方をエアギャップインストールするには、 27.9項 「KubeVirtとCDIのインストール」に従ってください。

SUSE Edgeでは、SUCを使用して、管理クラスタとダウンストリームクラスタでのOSとKubernetesのバージョンアップグレードに関連するさまざまな「Day 2」操作を容易にします。

「Day 2」操作は、SUC Planによって定義されます。これらのプランに基づき、SUCは各ノードにワークロードをデプロイし、それぞれの「Day 2」操作を実行します。

SUCは、第23章 「Upgrade Controller」内でも使用されます。SUCとUpgrade Controllerの主な違いに関する詳細については、 23.2項 「Upgrade ControllerとSystem Upgrade Controller」を参照してください。

重要

Rancher v2.10.0以降、System Upgrade Controllerは自動的にインストールされます。

ご使用の環境がRancherによって管理されていない場合、またはRancherのバージョンがv2.10.0より前の場合にのみ、以下の手順に従ってください。

suse-edge/fleet-examplesリポジトリにあるFleet (第8章 「Fleet」)からSUCをインストールすることをお勧めします。

注記

suse-edge/fleet-examplesリポジトリで提供されるリソースは常に有効なfleet-examples releaseから使用される必要があります。使用する必要のあるリリースを確認するには、リリースノート(52.1項 「要約」)を参照してください。

SUCのインストールにFleetを使用できない場合は、RancherのHelmチャートリポジトリからインストールするか、独自のサードパーティGitOpsワークフローにRancherのHelmチャートを組み込むことができます。

このセクションでは以下の内容を取り上げます。

22.2.1 System Upgrade Controller Fleetのインストール #

 

Fleetを使用して、SUCをデプロイするために使用できるリソースは2つあります。

• GitRepoリソース - 外部/ローカルGitサーバが利用できるユースケース用。インストール手順については、「System Upgrade Controllerのインストール – GitRepo」(22.2.1.1項 「System Upgrade Controllerのインストール - GitRepo」)を参照してください。

• バンドルリソース - ローカルGitサーバオプションをサポートしないエアギャップ環境のユースケース用。インストール手順については、「System Upgrade Controllerのインストール - バンドル」(22.2.1.2項 「System Upgrade Controllerのインストール - バンドル」)を参照してください。

22.2.1.1 System Upgrade Controllerのインストール - GitRepo #

 

注記

このプロセスは、使用できる場合はRancher UIから実行することもできます。詳細については、「Rancher UIでのFleetへのアクセス」を参照してください。

管理クラスタで、次の操作を実行します。

1. SUCをデプロイするクラスタを決定します。これは、管理クラスタ内の適切な FleetワークスペースにSUC GitRepoリソースをデプロイすることで実行されます。デフォルトでは、Fleetには2つのワークスペースがあります。

   • fleet-local - 管理クラスタにデプロイする必要があるリソース用。

   • fleet-default - ダウンストリームクラスタにデプロイする必要があるリソース用。

     Fleetワークスペースの詳細については、アップストリームドキュメントを参照してください。

2. GitRepoリソースをデプロイします。

   • 管理クラスタにSUCをデプロイするには:

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

   • ダウンストリームクラスタにSUCをデプロイするには:

     

     注記

     以下のリソースをデプロイする前に、有効なターゲット設定を提供する必要があります。Fleetがリソースをデプロイするダウンストリームクラスタを認識できるようにするためです。ダウンストリームクラスタへのマッピング方法については、「 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.3.0
       paths:
       - fleets/day2/system-upgrade-controller
       repo: https://github.com/suse-edge/fleet-examples.git
       targets:
       - clusterSelector: CHANGEME
       # Example matching all clusters:
       # targets:
       # - clusterSelector: {}
     EOF

3. GitRepoリソースがデプロイされていることを検証します。

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

4. System Upgrade Controllerのデプロイメントを検証します。

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

22.2.1.2 System Upgrade Controllerのインストール - バンドル #

 

このセクションでは、fleet-cliを使用して、標準のFleet設定からバンドルリソースをビルドしてデプロイする方法を説明します。

1. ネットワークにアクセスできるマシンで、fleet-cliをダウンロードします。

   

   注記

   ダウンロードしたfleet-cliのバージョンが、クラスタにデプロイされているFleetのバージョンと一致していることを確認してください。

   • Macユーザの場合、fleet-cli Homebrew Formulaeがあります。

   • LinuxおよびWindowsユーザの場合、Fleetリリースごとにアセットとしてバイナリが存在します。

     • Linux AMD:

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

     • Linux ARM:

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

2. fleet-cliを実行可能にします。

   chmod +x fleet-cli

3. 使用するsuse-edge/fleet-examples リリースのクローンを作成します。

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

4. fleet-examplesリポジトリにある、SUC Fleetに移動します。

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

5. SUCをデプロイするクラスタを決定します。これは、管理クラスタ内の適切な FleetワークスペースにSUCバンドルをデプロイすることで実行されます。デフォルトでは、Fleetには2つのワークスペースがあります。

   • fleet-local - 管理クラスタにデプロイする必要があるリソース用。

   • fleet-default - ダウンストリームクラスタにデプロイする必要があるリソース用。

     Fleetワークスペースの詳細については、アップストリームドキュメントを参照してください。

6. ダウンストリームクラスタにのみSUCをデプロイする場合は、特定のクラスタに一致するtargets.yamlファイルを作成します。

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

   ダウンストリームクラスタへのマッピング方法については、「Mapping to Downstream Clusters (ダウンストリームクラスタへのマッピング)」を参照してください。

7. バンドルの構築に進みます。

   

   注記

   fleet-examples/fleets/day2/system-upgrade-controllerディレクトリのfleet-cliをダウンロードしていないことを確認してください。これをダウンロードすると、バンドルでパッケージ化され、これは推奨されません。

   • 管理クラスタにSUCをデプロイするには、次のコマンドを実行します。

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

   • ダウンストリームクラスタにSUCをデプロイするには、次のコマンドを実行します。

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

     このプロセスの詳細については、「Convert a Helm Chart into a Bundle (Helmチャートをバンドルに変換する)」を参照してください。

     fleet-cli applyコマンドの詳細については、「fleet apply」を参照してください。

8. system-upgrade-controller-bundle.yamlバンドルを管理クラスタマシンに転送します。

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

9. 管理クラスタで、system-upgrade-controller-bundle.yamlバンドルをデプロイします。

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

10. 管理クラスタで、バンドルがデプロイされていることを検証します。

    # 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. バンドルをデプロイしたFleetワークスペースに基づいて、クラスタに移動し、SUCデプロイメントを検証します。

    

    注記

    SUCは常に、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

SUC Planは次の方法で確認できます。

重要

SUC Plan用にデプロイされたPodは正常実行後、15分間維持されます 。その後、作成元の対応するJobによって削除されます。この時間後もPodのログにアクセスできるようにするには、クラスタのログ記録を有効にする必要があります。Rancherでこれを実行する方法については、「Rancher Integration with Logging Services (Rancherとログ記録サービスの統合)」を参照してください。

22.3.2 System Upgrade Controller Planのモニタリング - 手動 #

 

注記

以下の手順は、 kubectlが、SUC Planがデプロイされたクラスタに接続するように設定されていることを前提としています。

1. デプロイしたSUC Planを一覧にします。

   kubectl get plans -n cattle-system

2. SUC Plan用Podを入手します。

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

   

   注記

   特定のSUC Planに対して［Completed (完了)］Podと［Unknown (不明)］Podの両方が存在する場合があります。これは予期されており、一部のアップグレードの性質により発生します。

3. Podのログを取得します。

   kubectl logs <pod_name> -n cattle-system

Upgrade Controllerは、管理クラスタをあるSUSE Edgeリリースバージョンから次のバージョンにアップグレードするために必要な(以前は手動の)「Day 2」操作を自動化するために必要不可欠です。

この自動化のために、Upgrade ControllerはSystem Upgrade Controller (第22章 「System Upgrade Controller」)やHelm Controllerなどのツールを利用します。

Upgrade Controllerの仕組みの詳細については、23.4項 「Upgrade Controllerの仕組み」を参照してください。

Upgrade Controllerの既知の制限事項については、23.7項 「既知の制限事項」を参照してください。

Upgrade ControllerとSystem Upgrade Controllerの違いについては、23.2項 「Upgrade ControllerとSystem Upgrade Controller」を参照してください。

System Upgrade Controller (SUC) (第22章 「System Upgrade Controller」)は、アップグレード手順を特定のKubernetesノードに伝播する汎用ツールです。

System Upgrade ControllerはSUSE Edgeプラットフォームの一部の「Day 2」操作をサポートしていますが、すべてをカバーしているわけではありません。また、サポートされている操作であっても、ユーザは複数のSUC Planを手動で設定、維持、およびデプロイする必要があります。これはエラーが発生しやすいプロセスであり、予期しない問題が発生する可能性があります。

これにより、SUSE Edgeプラットフォームのさまざまな「Day 2」操作の複雑さを自動化および抽象化するツールが必要になりました。こうしてUpgrade Controllerが 開発されました。Upgrade Controllerは、アップグレードを推進する単一のユーザ向けリソースを導入することで、アップグレードプロセスをシンプルにします。ユーザはこのリソースを管理する必要があるのみで、 Upgrade Controllerが残りの作業を行います。

Edgeリリースのアップグレードを実行するため、Upgrade Controllerでは2つの新しいKubernetesカスタムリソースが導入されました。

Upgrade Controllerは、 UpgradePlanリソースのreleaseVersionプロパティでユーザによって指定されたEdgeリリースバージョンのコンポーネントデータを保持するReleaseManifestリソースの作成に進みます。

Upgrade Controllerは、ReleaseManifestのコンポーネントデータを使用して、次の順序のEdgeリリースコンポーネントのアップグレードに進みます。

注記

アップグレードプロセス中に、Upgrade Controllerは、作成したUpgradePlanにアップグレード情報を絶えず出力します。アップグレードプロセスを追跡する方法の詳細については、 「アップグレードプロセスの追跡」(23.6項 「アップグレードプロセスの追跡」)を参照してください。

23.4.1 オペレーティングシステムのアップグレード #

 

オペレーティングシステムをアップグレードするため、Upgrade Controllerは、次の命名テンプレートを持つSUC (第22章 「System Upgrade Controller」) Planを作成します。

• コントロールプレーンノードのOSアップグレードに関連するSUC Planの場合 - control-plane-<os-name>-<os-version>-<suffix>

• ワーカーノードのOSアップグレードに関連するSUC Planの場合 - workers-<os-name>-<os-version>-<suffix>

これらのプランに基いて、SUCは、実際のOSアップグレードを実行するクラスタの各ノードにワークロードを作成します。

ReleaseManifestによって、OSアップグレードには次のものが含まれる場合があります。

• Package only updates (パッケージのみの更新) - OSバージョンがEdgeリリース間で変更されないユースケース用。

• Full OS migration (完全なOSマイグレーション) - OSバージョンがEdgeリリース間で変更されるユースケース用。

アップグレードは、コントロールプレーンノードから順に一度に1台のノードが実行されます。コントロールプレーンノードのアップグレードが終了した場合にのみ、ワーカーノードのアップグレードが開始されます。

注記

クラスタに特定のタイプの1台を超えるノードがある場合、 Upgrade Controllerは、クラスタノードのdrainを実行するようにOS SUC Planを設定します。

コントロールノードが1台を超え 、 1台のみワーカーノードがあるクラスタでは、コントロールプレーンノードに対してのみdrainが実行されます。その逆も同様です。

ノードのdrainを完全に無効にする方法については、「UpgradePlan」(23.5.1項 「UpgradePlan」)のセクションを参照してください。

23.4.2 Kubernetesのアップグレード #

 

クラスタのKubernetesディストリビューションをアップグレードするため、Upgrade Controllerは、次の命名テンプレートを持つSUC (第22章 「System Upgrade Controller」) Planを作成します。

• コントロールプレーンノードのKubernetesアップグレードに関連するSUC Planの場合 - control-plane-<k8s-version>-<suffix>。

• ワーカーノードのKubernetesアップグレードに関連するSUC Planの場合 - workers-<k8s-version>-<suffix>。

これらのプランに基づいて、SUCは、実際のKubernetesアップグレードを実行するクラスタの各ノードにワークロードを作成します。

Kubernetesアップグレードは、コントロールプレーンノードから順に一度に1台のノードが実行されます。コントロールプレーンノードのアップグレードが終了した場合にのみ、ワーカーノードのアップグレードが開始されます。

注記

クラスタに特定のタイプの1台を超えるノードがある場合、 Upgrade Controllerは、クラスタノードのdrainを実行するようにKubernetes SUC Planを設定します。

コントロールノードが1台を超え 、 1台のみワーカーノードがあるクラスタでは、コントロールプレーンノードに対してのみdrainが実行されます。その逆も同様です。

ノードのdrainを完全に無効にする方法については、23.5.1項 「UpgradePlan」を参照してください。

Upgrade Controllerによって導入されたKubernetes APIの拡張機能。

23.5.2 ReleaseManifest #

 

Upgrade Controllerは、ReleaseManifestと呼ばれる新たなKubernetesカスタムリソースを導入しました。

ReleaseManifestリソースは、Upgrade Controllerによって作成され、1つの特定のEdgeリリースバージョンのコンポーネントデータを保持します。つまり、各Edgeリリースバージョンのアップグレードは、異なるReleaseManifestリソースによって表されます。

警告

Release Manifestは常に、Upgrade Controllerによって作成される必要があります。

ReleaseManifestリソースを手動で作成または編集することはお勧めしていません。 ユーザが手動で作成または編集することを決めた場合は、自己責任で行う必要があります。

Release Manifestが提供するコンポーネントデータには、以下が含まれますが、これに制限されません。

• オペレーティングシステムデータ - バージョン、サポートされているアーキテクチャ、追加のアップグレードデータなど

• Kubernetesディストリビューションデータ - RKE2/K3sでサポートされているバージョン

• 追加のコンポーネントデータ - SUSE Helmチャートデータ(場所、バージョン、名前など)

ReleaseManifestの例については、アップストリームドキュメントを参照してください。これは単なる例であって、有効なReleaseManifestリソースとして作成することを目的としたものではないことに注意してください。