Feature Overview

The katacontainers upstream project has so far been (and still is) the basic building block for our Openshift Sandboxed Containers product offering. Recently, version 2.x of the project has been released, with it many features, changes, refactoring took place. Below are some of the pros and cons of v2.x of the upstream katacontainers project.

Pros (Enablers for our product goal with Sandboxed Containers)

• Kata agent written in Rust - reducing the attack surface and reducing the size from 11MB to 300KB
• Observability and manageability improvements - Provides metrics for the runtime, the VMM and the guest kernel in a Prometheus format. A key piece when talking about a complete product.
• Kata-agent-ctl - a tool for agent API debugging has been added
• Support = Migration: If we were to go into tech-preview / GA with 1.x we would need to provide customers with an update/upgrade path, moving to kata 2.0 before going into a support release, saves us the efforts of doing so, migration would simply be a replacement process.
• Dodge Deprecation: the plan upstream is to deprecate v1.x by May 2021. Upgrading soon will save us a lot of maintenance efforts both upstream and downstream

Cons (Limitations with kata 2.x that we would need to consider)

• Kata agent written in Rust - In-house knowledge of Rust is limited.
• Kata 2.x upstream CI small - Upstream CI for 2.x is significantly smaller than the 1.x releases. This means that CI coverage will be smaller and thus more effort in CI will be required to reach parity.
• Kata 2.x stability - Not much company coverage upstreams, which means Kata 2.0 will likely be targeted towards specific use-cases (e.g., Ant-financial)
• Podman in kata 2.x - Podman-shimv2 is lacking, this is not a serious concern/limitation but we need to figure out how to build our dev-setup with Podman AND without.

Based on the above pros and cons, the team has decided to move forward and support all the needed changes to support Kata 2.x with the Openshift Sandboxed Containers product.

Background, and strategic fit

Kata 2.0 unlocks many features that could benefit the product long-term. For example, with 2.0 each Kata component would expose metrics in prometheus format, this will help us in the following aspects in terms of usability and strategy:

• More visibility into kata components (e.g., kata-agent), and thus faster problem resolution (faster debugging, faster resolution).
• Establish KPIs around the usage of Kata, which could help all Kata stakeholders, and would help in decision making around the product.
• Customized dashboards for any interested party.

Goal(s)

The goal of this feature is to make full-use of Kata 2.0 and support all its components in our product.

• Finalize and verify related packaging efforts.
• Validate and qualify Kata 2.0 with Openshift and the Kata operator
• Make sure that the main components are tested (e.g., CoreOs, agent, ...)

Documentation Considerations

Questions to be addressed:

• What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)?
• Does this feature have doc impact?
• New Content, Updates to existing content, Release Note, or No Doc Impact
• If unsure and no Technical Writer is available, please contact Content Strategy.
• What concepts do customers need to understand to be successful in [action]?
• How do we expect customers will use the feature? For what purpose(s)?
• What reference material might a customer want/need to complete [action]?
• Is there source material that can be used as a reference for the Technical Writer in writing the content? If yes, please link if available.
• What is the doc impact (New Content, Updates to existing content, or Release Note)?