People want to run Java workloads in Linux containers and they want that to work well. Historically, Java has tended to prefer to manage things itself, and without tuning, there have been challenges getting OpenJDK payloads to excel alongside other workloads in container workloads. But that has been changing.
This talk will give a high-level overview of the journey that OpenJDK has taken to play nicely with others in a container context (Kubernetes or otherwise), the current state-of-play, and where we might be going in the future.
No deep Java knowledge necessary.
The author works on OpenJDK and containers, both in the upstream OpenJDK project and downstream, initially at Red Hat, and now at IBM.
https://openjdk.org https://rh-openjdk.github.io/redhat-openjdk-containers/
In early 2025 we started the process to create the Kubernetes Checkpoint Restore Working Group. In December the working group had its first meeting and in this short presentation I want give an overview why we think it is important to continue the checkpoint restore related work from the last five years in this working group. In addition I want to present the topics the working group hopes to solve in the context of Kubernetes.
Reducing container image size improves security, speeds up cold starts, and cuts network transfer costs. Yet in development workflows, it’s easy to inherit bloated base images or copy templates full of unused tools. To build minimal, production-ready OCI images, we need visibility into what a container actually uses at runtime
This talk presents a lightweight method for profiling file access inside containers using eBPF, Podman, and OCI lifecycle hooks. By leveraging the prestart hook, we can gain access to the container’s initial PID, allowing an eBPF program to trace all file opens. Tracepoint and LSM (Linux Security Module) eBPF programs are combined to capture the absolute path of each opened file.
In this presentation, we will show how this approach can allow us to distinguish required files from bloat, validate dependencies, and reduce container image size, resulting in smaller, faster, and more secure OCI images.
We usually think about successful open source in terms of user adoption, level of community contributions, or even vanity metrics like GitHub stars. But what if the success of many of the most popular open source projects in the cloud native ecosystem lies in the ability of external consumers to extend the project in ways the creators didn’t even envision?
In this talk we’ll look at the containerd project and its intentionally designed extensibility. These extensible capabilities have become key launching points for innovation created and even maintained outside of the core project. We’ll look at the details of our snapshotter and shim interfaces, two popular ways to extend containerd that have many examples after 10 years of project development. New features will be demonstrated that utilize these interfaces such as native macOS support that uses the brand new "nerdbox" shim and the erofs snapshotter.
We'll detail the concrete value provided by extensibility and invite other project creators and maintainers to consider how they are designing for extensibility to enable innovation.
Reproducing a container image would ideally be just a matter of setting SOURCE_DATE_EPOCH in your build commands or containerfiles. Like most reproducible builds though, that’s just one part of the story. And unfortunately, the other part is not the rest of the sources of non-determinism (and yes, there are quite a few). The most critical part of the story is guaranteeing that anyone can reproduce your container image bit-for-bit, regardless of the date, location, device architecture, or container runtime they are using. Who’s doing this though?
In this talk we’ll explain why one should care about reproducible images, why are we reproducibly building sha256:b0088ba0110c2acfe757eaf41967ac09fe16e96a8775b998577f86d90b3dbe53 for about a year now, and how you can easily leverage some of the stuff we learned along the way.
Containers are everywhere, whether you run them locally for testing or on a production server, there is always a need to find its logs, metrics to know how much resources are being consumed and whether it is stable or not.
In this talk, we will demonstrate an example of how to monitor your Docker Containers using Prometheus and cAdvisor and view the metrics in Grafana to get better observability.
It will be an introduction Open Source tools, integration and also an excellent opportunity to learn more about the advanced features, including troubleshooting & debugging.
join us to learn more about Grafana, community contributions and share your feedback and suggestions!
Last year we open sourced a Containerization framework and container CLI tooling to enable developers to create and run Linux container images directly on their Mac in a way that focuses on security and privacy. In this talk, we'll dive into the Containerization framework, describing its foundational role in creating the container CLI which enables users to build, run and deploy Linux containers on Mac. We’ll walk through the architecture, highlight key APIs and discuss why we wrote it in Swift. We’ll then discuss some of our future roadmap for feature development and integration opportunities and challenges in the existing open source ecosystem.
OCI is many things, and soon it's a format systemd is going to understand somewhat natively. In this talk I want to explain the how, the why, and where we are going with this.
Over the past decade (or three) of container runtimes on Linux, the attacks against container runtimes with the most bang-for-your-buck have generally been filesystem related — often in the form of a confused-deputy style attack. This is aided in part by the sheer number of juicy targets accessible through filesystem APIs such as /proc.
In particular, the past few years have seen quite a few security issues of this form in runc and other container runtimes — most recently in a set of CVEs published in November 2025 (CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881). However, this is far from a container-specific issue. Many Unix programs have historically suffered from similar issues, and the various attempts at resolving it have not really measured up.
This talk will go through the myriad of issues necessary to protect user space programs against these kinds of attacks, completed and ongoing kernel work to try to make these problems easier to resolve, and our experience migrating a container runtime's codebase to a design which emphasises path-safety. In addition, this talk will also include an update on libpathrs (a library intended to make mitigating these attacks much easier for most Linux programs).
This talk is aimed to give an overview on a problem of system resource reporting in LXC-based containers.
We will cover: - LXCFS - syscall interception (sysinfo) - what is still missing in kernel API
I run my 3D in Kubernetes, as-code and git versioned, and you can too! Say goodbye to your Raspberry Pets, lost configs, clunky updates, apt upgrade breaking your setup, and always out-of-date backups. Say hi to everything is versioned and tracked in git, one git revert away from mistakes.
In this session I will showcase kubeklipper, a helm chart to run Klipper, Moonraker, a web frontend (Mainsail or Fluidd) and even a slicer all in your Kubernetes cluster.
In 2025 we rebuilt www.epfl.ch from the ground up: a fleet of 650 WordPresses, masquerading as one Web site. By applying Kubernetes and nginx (instead of Apache previously) to the best of their abilities, we achieved a 10-fold reduction of our footprint, from 20 Kubernetes pods to 2. Our contribution consists of two dozen plug-ins for WordPress, and extensive configuration-as-code including an OpenShift (OLM)-compatible WordPress operator. You can use it in whole or in part for your organization today, and we'll show you where to start.