Uploaded image for project: 'Openshift sandboxed containers'
  1. Openshift sandboxed containers
  2. KATA-450

Installing Kata Containers Artifacts (QEMU + Kata binaries) for Sandboxed Containers



    • Installing Kata Containers Artifacts (QEMU + Kata) for Sandboxed Containers
    • OCPPLAN-8485Operator E2E Enablement
    • True
    • Kubernetes-native Infrastructure
    • qe-ack
    • 0
    • 0



      The current version of the operator is manually installing RPMs on the host, this method can prove problematic in the future for multiple reasons:

      • The operator deviates from what it should be really doing and instead maintains the lifecycle of kata packages it self.
      • There is no standard mechanism for installs, upgrades, and removals.
      • Extra space used on the host even if the packages are not needed or if Kata containers do not need to be installed (hence, kata containers is not the default runtime).

      The idea is to handle the lifecycle of Qemu packages and Kata artifacts in a consistent manner and not manually in the operator as it is not intended to do so. Additionally, the sandboxed containers operator currently takes care of getting Kata artifacts and binaries into the host, this is also a manual process taken care of by the operator atm. 

      This is useful also for consolidating package updates (since they would point to a repo) instead of chroot'ing to host, unpacking a payload image, and installing RPMs. Finally, Kata is intended as a day 2 runtime (i.e., it is not the default cluster runtime, runcC is our default), and it makes sense to use packages when they are truly needed.


      • RHEL-AV depends on libraries and other tools which are all available as RPMs. Turning this into a static image instead of RPMs creates a huge single binary which we avoid with extensions
      • RHEL-AV has been tested/validated as RPMs and not a single binary which means we saves the extra overhead
      • RHEL-AV RPMs can be installed only by the customers who would be interested in using the kata runtime. QEMU (and its dependencies) get updated as part of the machine-os-content updates
      • There’s no extra work related to properly loading qemu-kvm-core dependencies, as all the packages would be installed in the same PATH its build in
      • Better control of the versions that are installed both for qemu (specific version for a given host) and for the dependencies (tracked by rpm)

      User Stories

      • As a cluster-admin I don't want to worry about how virtualization and Kata packages/binaries are installed, upgraded, or maintained on cluster nodes.
      • As a support specialist, I know how to debug missing packages the same way I do for the rest of the extensions defined in the machine-os-content.

      Depends On: 


      • All required implementations in the Machine-config-operator MUST be finalized.
      • The Openshift Sandboxed Containers operator MUST create a machine config for the extensions.
      • The extension mechanism MUST be tested.



        Issue Links



              jfreiman Jens Freimann
              azaalouk Adel Zaalouk
              Cameron Meadors Cameron Meadors
              0 Vote for this issue
              5 Start watching this issue