Provisioning Fedora CoreOS on KubeVirt

This guide shows how to provision new Fedora CoreOS (FCOS) nodes on any KubeVirt-enabled Kubernetes cluster.

Pré-requisitos

Antes de provisionar uma máquina FCOS, você deve ter um arquivo de configuração do Ignition contendo suas personalizações. Se você não tiver um, consulte Produzindo um arquivo de Ignition.

You also need to have access to a Kubernetes environment with KubeVirt installed.

Referencing the KubeVirt Image

O Fedora CoreOS é projetado para ser atualizado automaticamente, com horários diferentes por fluxo.

The image for each stream can directly be referenced from the official registry:

  • quay.io/fedora/fedora-coreos-kubevirt:stable

  • quay.io/fedora/fedora-coreos-kubevirt:testing

  • quay.io/fedora/fedora-coreos-kubevirt:next

Creating an Ignition config secret

There are various ways to expose userdata to Kubevirt VMs that are covered in the KubeVirt user guide. In this example we’ll use the Ignition config stored in local file example.ign to create a secret named ignition-payload. We’ll then use this secret when defining our virtual machine in the examples below.

Creating the secret
kubectl create secret generic ignition-payload --from-file=userdata=example.ign
If the user prefers, they can use oc instead of kubectl in the commands throughout this guide.

Launching a virtual machine

Given the quay.io/fedora/fedora-coreos-kubevirt images you can create a VM definition and combine that with the Ignition secret reference to launch a virtual machine.

Launching a VM instance referencing the secret
STREAM="stable" # or "testing" or "next"
cat <<END > vm.yaml
---
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: my-fcos
spec:
  runStrategy: Always
  template:
    spec:
      domain:
        devices:
          disks:
          - name: containerdisk
            disk:
              bus: virtio
          - name: cloudinitdisk
            disk:
              bus: virtio
          rng: {}
        resources:
          requests:
            memory: 2048M
      volumes:
      - name: containerdisk
        containerDisk:
          image: quay.io/fedora/fedora-coreos-kubevirt:${STREAM}
          imagePullPolicy: Always
      - name: cloudinitdisk
        cloudInitConfigDrive:
          secretRef:
            name: ignition-payload
END
kubectl create -f vm.yaml

Now you should be able to SSH into the instance. If you didn’t change the defaults, the username is core.

Accessing the VM instance using virtctl via ssh
virtctl ssh core@my-fcos

Launching a virtual machine with persistent storage

The above example will give you a VM that will lose any changes made to it if it is stopped and started again. You can instruct the cluster to import a containerdisk into a Physical Volume when provisioning in order to have virtual machine will have persistence of the OS disk across stop/start operations.

The positive to this approach is that the machine behaves much more like a traditional virtual machine. The drawback is that the cluster needs to offer Block PV storage and not all clusters may do that.

You may have to specify a storageClassName parameter in the spec.dataVolumeTemplates.spec.storage section of the config if your cluster doesn’t offer a default. See the API docs.
Launching a VM with persistent storage
STREAM="stable" # or "testing" or "next"
DISK=10
cat <<END > vm.yaml
---
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: my-fcos
spec:
  runStrategy: Always
  dataVolumeTemplates:
  - metadata:
      name: fcos-os-disk-volume
    spec:
      source:
        registry:
          url:
           docker://quay.io/fedora/fedora-coreos-kubevirt:${STREAM}
      storage:
        volumeMode: Block
        resources:
          requests:
            storage: ${DISK}Gi
        accessModes:
          - ReadWriteOnce
  template:
    spec:
      domain:
        devices:
          disks:
          - name: fcos-os-disk
            disk:
              bus: virtio
          - name: cloudinitdisk
            disk:
              bus: virtio
            name: cloudinitdisk
          rng: {}
        resources:
          requests:
            memory: 2048M
      volumes:
      - name: fcos-os-disk
        dataVolume:
          name: fcos-os-disk-volume
      - name: cloudinitdisk
        cloudInitConfigDrive:
          secretRef:
            name: ignition-payload
END
kubectl create -f vm.yaml
The data volume import into the PVC from the container registry may take some time. You can monitor the import by watching the logs of the importer-fcos-os-disk-volume pod.

After the machine is up you can connect to it using virtctl as shown in the previous example.

Mirroring the image for use in private registries

If a private registry in air-gapped installations is used, the image can be mirrored to that registry using skopeo.

Mirroring a stable stream FCOS image
skopeo copy docker://quay.io/fedora/fedora-coreos-kubevirt:stable docker://myregistry.io/myorg/fedora-coreos-kubevirt:stable