Japan Community Day Schedule

This session will be held entirely in Japanese.

Please pre-register at the site below.
https://ocgroups.dev/cncf/group/bqd97by/event/rhvmu2v

Widely used open-source traffic generators like TRex come with dependencies such as DPDK and legacy Python libraries, which make them cumbersome to set up and use. Could we solve this by rebuilding such a tool on a modern, cloud-native technology stack? XDPerf is our attempt at exactly that.

XDPerf is a traffic generator that combines packet transmission via eBPF/XDP's Live Frames mode with user-defined packet generation logic written in WebAssembly. It runs as a single binary, and unlike DPDK, it doesn't take over the NIC, so it can coexist with the Linux network stack.

In this session, we'll walk through XDPerf's architecture and implementation. We'll dig into the concrete details, including how we transmit packets using XDP and how we made it possible to generate arbitrary traffic through WASM plugins.

Recently, Agentic AI has become widespread and collaborates with various external tools to perform tasks. Therefore, governance, such as authentication and authorization, becomes crucial, and MCP, which includes authentication and authorization specifications, has been created. There are authorization servers that claim to be compliant with MCP, but there is no way to verify whether they correctly comply. If implemented incorrectly, this could lead to information leakage through CSRF or replay attacks, making conformance tests to verify compliance with MCP essential.
In this session, Michito Okai will introduce conformance tests he developed to verify whether an authorization server complies with the Authorization Code Grant in OAuth 2.1 on which MCP is based. He will also demonstrate how to verify that Keycloak is compliant as an MCP authorization server using these tests. These tests are contributed to the MCP community to help increase trust in MCP within Agentic AI systems.

As AI Agents gain access to files, tools, APIs, and operational systems, ensuring their security becomes increasingly important.

While GuardRails and policy controls help reduce risks, they cannot completely prevent unintended actions or unexpected behavior.

In this session, we discuss AI Agent Security through three layers:

GuardRails
Risk Management
Runtime Security

We then explore how CNCF technologies such as eBPF and Falco can provide runtime visibility and protection as the final line of defense for AI Agents.

The kernel has no concept of a "container." eBPF, on the other hand, runs inside the kernel. So how does Tetragon — which is built on eBPF — determine, at the very instant an event fires, "which container does this process belong to"?
Starting from a puzzling behavior — "I scoped my policy to nginx, but the host's runc keeps getting flagged" — we'll unravel how container boundaries are actually drawn at the kernel layer. No prior eBPF experience required.

[This talk will be delivered in English]

Cilium has become one of the most widely adopted CNI implementations in Kubernetes.
Yet many engineers use Cilium without understanding how it differs from other CNIs, how eBPF is used inside it, or what new capabilities it enables.

In this session, we will explore the following topics using real eBPF code from Cilium:
– Core responsibilities of a Kubernetes CNI
– How other CNIs, such as Flannel and Calico, implement those responsibilities
– How Cilium implements those responsibilities with eBPF
– Features and optimizations enabled by eBPF, including kube-proxy replacement and netkit

Through a deep dive into Cilium's internals and comparisons with other CNIs, we'll explore what eBPF made possible in Kubernetes networking.

The OpenTelemetry project is graduating from the CNCF! As part of celebrating, let's look back on the challenges and successes early in the project, lay out our roadmap to the future, and discuss ways that we can collaborate more deeply with the OpenTelemetry community in Japan.

Platform engineers need to deal with new agentic workloads that use protocols like MCP, A2A, and Skills, which pose new challenges and promote a culture of shadow AI.

How can we enable developers, platform engineers and SREs to understand and react to non-deterministic behaviors with all these new protocols and tools?

By relying on cloud-native techniques, we can learn from the new data that these workloads are generating to enable development teams to go faster, measure their performance and modify behaviours when needed as part of our platform initiatives.

Join me in this presentation to go over the tools and practices that we learnt from the cloud native ecosystem to power the next iteration of your existing platforms.

When operating AI Agents in a production environment, many behaviors emerge that were not fully anticipated during development. With the introduction of AI Agents, more parts of the system tend to become "black boxes"—including unintended tool calls, hallucinations, failures in external APIs or workflows, and the challenges of pinpointing the causes of latency.

In this session, we will focus on how to observe AI agents using OpenTelemetry. We will explain the current status of the OpenTelemetry GenAI Semantic Conventions that are currently being formulated, how to utilize them in actual operations, and share insights on observability gained from AI coding agents.

For years, the CNCF Platform Engineering Community has provided trusted guidance for platform engineering organizations, and as the practice has matured, so have its artifacts. New challenges are emerging: Platforms are everywhere, and many teams now deal with several platforms instead of one. AI lets users and their agents build and deploy faster than platform teams can safely keep up with. The golden path that once led to a single portal now has to work across many. All while many companies are still trying to form their first practice. So what's next? We'll cover updates to the TCG's artifacts, the state of the cloud-native landscape, and how platform engineering is evolving – plus ways to evolve with it.

Since its initial release, the CNCF Platforms White Paper has been widely utilized as a standard guide to understanding Platform Engineering. In April 2026, the community released v1.1. This minor update focuses on improving the clarity, readability, and overall structure of the document. In this session, I will walk you through the key changes introduced in v1.1.

An internal developer platform cannot be built overnight. It begins with platform engineers deeply understanding and bringing to life the needs of both the developers—the users—and the infrastructure administrators who provide the foundation.
In this session, we will explain how developers, infrastructure administrators, and platform engineers can work together to reach consensus on shared services by leveraging open practices. Please consider this as one technique to draw upon.

Demand for edge AI is growing, driven by the need to improve privacy protection and reduce network costs. One key challenge in edge AI is how to update models after deployment. Distribution methods used in the cloud, such as container and Python packages, are difficult to apply directly to edge environments due to resource constraints and the diversity of execution environments.

In this session, we propose an approach that uses WebAssembly (Wasm) as a distribution format for models and computation. By packaging only the inference model and pre/post-processing logic as Wasm, while placing the inference engine in the runtime, we reduce the size of the deployable artifact. Wasm’s portability across CPU architectures and OS also enables the same binary to be distributed across a wide range of edge devices.

We will introduce an edge AI runtime platform and orchestrator that implement this approach, demonstrating Wasm’s applicability beyond browsers and serverless platforms.

Everyone agrees environmental sustainability matters.

Yet across the CNCF ecosystem, only one project has joined the Green Reviews initiative to evaluate its environmental impact.

Why is adoption still so limited?

In this panel discussion, we bring together leaders from across the ecosystem — including members of the CNCF Technical Oversight Committee (TOC), a CNCF Technical Advisory Group (TAG) Chair, and a core maintainer of the Japan-rooted CNCF Sandbox project CoHDI, who is also leading the IOWN Global Forum community— to discuss the reality behind sustainable cloud native adoption.

Together, we'll explore:
– what the cloud native ecosystem actually needs from environmental sustainability metrics,
– how can we reduce operational friction and increase adoption,
– and how local cross-community collaboration can move environmental sustainability forward together.

Join us to move environmental sustainability beyond "sounds good" — and turn it into actions.

Envoy is released to the world in September 2016. Within months, other companies see themselves in Lyft’s problem and start adopting it. Built on the philosophy that the network should be transparent to applications, it quickly evolved from a targeted solution into a global standard.

After graduating from the CNCF in just two years, Envoy now powers production workloads worldwide from startups to the Fortune 500 as edge proxies, service meshes, and load balancers.

Now, the ecosystem is evolving again. Building on the foundation of Envoy Gateway, the new Envoy AI Gateway addresses the unique demands of AI traffic, introducing intelligent inference routing, multi-provider failover, token-based rate limiting, and MCP support.

This talk traces Envoy through three distinct areas by maintainers:
1. The Origin: The 2016 open-source launch and early adoption.
2. The Ecosystem: Growth into a foundational cloud-native standard.
3. The AI Future: Empowering the next generation of AI-native infrastructure.

Run whoami inside a container and it says root. That root, however, does not hold the same privileges as the root on the host. During container startup, the runtime applies capabilities, AppArmor, seccomp, and other mechanisms in sequence, narrowing the process’s privileges step by step. Get the order wrong and you can find yourself without the privilege required to drop the next privilege. In this session we walk through a low-level container runtime I built from scratch in Java + GraalVM Native Image, following this sequence to see how privilege management works on Linux. We also share the workarounds the unusual choice of Java + GraalVM Native Image required.