changed 4 years ago  
Linked with GitHub

About Kata Containers releases

2.1.0: try it while it's still warm

During the past few months the Kata Containers community has been working on new features and bugfixes that are now materialized as
the 2.1.0 release, which went out on Friday, May 14th.

The 2.1.0 release includes several bug fixes and improvements, such as:

  • Improving kata-deploy so it becomes the de-facto way of deploying
    kata-containers in a k8s / k3s cluster.
  • Improving tracing support, most notably migrating from opentracing to
    opentelemetry.
  • Improving how PCI devices are handled, making VFIO & SR-IOV more future proof.
  • Improving the agent performance, by making it asynchronous;
  • Improving the project documentation (always on ongoing process!) to ensure users have the latest up-to-date information on how to utilize the project.

Apart from the improvements, a few features that are worth a highlight include:

  • virtio-mem has been enabled as part of the kernel distributed via
    kata-deploy.
  • IPv6 support has been implemented in the agent.
  • kata-runtime metrics command has been introduced for gathering status on a running Kata Containers sandbox.

The release has kept us busy, this is not the only activity we've been working on.

1.x is no longer being maintained

Kata Containers 1.x has reached EOL (End of Life) and is no longer being maintained.

All users should switch to the latest Kata Containers 2.x release to ensure they are using a maintained release that contains the latest security fixes, performance improvements and new features.

This decision was discussed by the @kata-containers/architecture-committee and has been announced via the Kata Containers mailing list:

Changes in the maintained branches

With the release of 2.1.0, the community decided to reevaluate the stable branch maintenance window for the project.

This has been discussed during community meetings, as well as within the following issue and pull requests:

We plan to maintain a single stable branch per active major release, while maitaining the minor release cadence as it's, happening every 12 weeks.

We believe maintaining a single stable branch will free some resources, allowing the community to focus better on improvements to be done down the
road and to better maintain the project as it is.

If you have any questions or concerns on this change, please reach out in the issue or pull request mentioned above.

Select a repo