Project Lightning Talk: youki: What’s New and What’s Next? - Yusuke Sakurai, Reviewer

In this talk, Yusuke Sakai provides an update on Yoki, an OCI runtime that functions as a low-level container runtime, similar to other runtimes like containerd and runc. He discusses recent enhancements, including the addition of support for network devices and Linux memory policies, which are crucial for AI, machine learning, and high-performance workloads. Enhanced compatibility with the OCI specification and improvements in testing are also covered, alongside ongoing bug fixes and security updates. Looking ahead, Sakai outlines the roadmap for Yoki 1.0.0, highlighting the aim to increase Kubernetes adoption by simplifying installation and configuration processes, as well as exploring the integration of lightweight VM-based container execution models.

Hello everyone. I'm Yusuke Sakai. I'm one of the maintenance of Yoki. Today I'd like to give a quick update on Yoki, what's new and what's next. In this talk, I'd briefly explain Yoki, what Yoki is, talk about some recent updates, and then look at a few load map items toward 1.0.0. First a very quick introduction. Yoki is an OCI runtime little in last. It is a lowle

content runtime similar to runtimes like lanchi or shean. The project has around 7.3,000 GitHub stars and became a shen C shandbox project in October 2024. So Yoki is not just an experimental runtime anymore. It is growing as part of the BL cloud native runtime exist. Here are a few examples where Yoki is already being used. This shows where Yoki sits in the Kubernetes execution flow. Kubernetes does

not invoke a low-level runtime directory. Instead, cubate talks to a C runtime such as content or kio which then invok time like s or yoki. So yi sits in at the low runtime layer. Now let's look at recent updates. First, new features. Yogi added support for net devices and Linux memory policy. These are newer additions to the OCI runtime specification. Support for Net devices matters because newer

Kubernetes networking models increasingly needed declarative attachment of network interfaces especially for AI, ML and other high performance workloads. The memory policy matters for numer workloads. Second, better compatibility. Yoki improved alignment with lanchi behavior and the OCI specification. Third, testing. The project has expanded OCI per conformance test and impatibility test. And finally, bug fixes and security improvements include general stability bug and sh related fixes. Above all, these

updates shows that the project is steady becoming more practical and more reliable. Look ahead. The road map to Yoki 1.0.0 is really about making Yoki more practical for the adult use. That includes better compatibility, more flexible execution models, and easier Kubernetes adoption. First, the first road map item is improving compatibility with lanchi. Low level times are based on the OCI landtime specification. However, real world compatibility requires

more than spec compliance. Some commonly used features such as exec update and checkpoint are outside the and the runtime behavior can also define in certain ways. So the goal here is to improve the compatibility with launch sheet especially in real world environments such as kubernetes kubernetes the next step is to continue aligning yi's behavior with ni and to san compatibility test coverage the second load map item

is microbased containers with lip kan likan is a BM provided as a shared library. It enables lightweight BM based container execution where containers done inside a guest OS within the BM. This matters because it can provide stronger isolation than the usual host can sharing model. More broadly, this could expand how continents can be run with Yoki. We also already have a reference point here because Shenan supports

this approach experimentally. So the goal is to add liken support to Yoki. And the next step is to explore how this execution model could be integrated with Yoki. The third road map item is making Kubernetes adoption easier. Today adopting Yoki on Kubernetes still requires several other manual steps. You need to install and enable Yoki on Kubernetes no configure contain or kio to use it and use runtime

class for papot runtime selection. So the goal here is simple. Make your key easier to adopt on Kubernetes. The next step is to introduce deployment to similar to cutter deploy for cut containers so that this setup becomes much easier and more repeatable. Thank you.