Open Source Summit Korea 2026

As cloud native systems evolve, WebAssembly(WASM) is emerging as a runtime that complements and sometimes challenges container based approaches. With fast startup, strong isolation, and portability, WASM enables efficient and secure event driven workloads.

In this session, we explore how to build and run the systems using WebAssembly on Kubernetes, focusing on SpinKube, an open source project that brings WASM workloads into Kubernetes.

Through a live demonstration, we will deploy and run WASM workloads using SpinKube, highlighting real workflows. We will also compare cold start and execution performance, showing millisecond startup and lower latency than traditional containers. Plus to demonstrate observability using eBPF based telemetry, we enable visibility into runtime behavior without overhead. Attendees will learn how to trace execution, monitor performance, and troubleshoot distributed WASM systems.

Finally, we will talk how WebAssembly improves security and operational efficiency by reducing the attack surface and enabling consistent execution across environments, providing a practical guide for production adoption.

Standard load balancers route LLM requests without awareness of KV-cache state or GPU queue depth — causing inflated Time-To-First-Token and wasted accelerator capacity.

loxilb closes this gap with an eBPF-native AI gateway. The L4 layer uses XDP/TC and kernel sockmap for zero-copy forwarding. The L7 layer adds API-key validation, token-quota enforcement, and accelerator-aware routing via Consistent Hashing with Bounded Loads (CHWBL).

This talk focuses on KV-exact routing for P/D disaggregated deployments. When requests share a prompt prefix, prefill GPUs recompute identical KV tensors repeatedly — wasting up to 80% of GPU cycles. Tier 1.5 eliminates this: loxilb tokenizes the prompt in-process (HuggingFace Rust tokenizer via CGO), computes block hashes matching vLLM's internal format, and routes to the exact GPU already holding those KV blocks — via a live inventory fed by vLLM's native ZMQ event stream.

Unlike serving-layer schedulers (llm-d, Dynamo), this runs in the eBPF data-plane hot path with no Kubernetes dependency — works on bare metal, VMs, and BlueField DPUs.

We'll trace a live request through the P/D testbed and share lessons from building GPU-state-aware routing

One controller at 846m CPU. The other at 6m. Both running. Both supposedly doing the same job.

We had two ArgoCD application controllers. Scaling looked solved on paper. Except -- one was doing all the work and the other was just... sitting there.

The thing nobody tells you when you first set up ArgoCD HA is that sharding works at the cluster level, not the application level (sadly). So when you only have one cluster -- it doesn't matter how many controller replicas you spin up. The work doesn't split. It all piles onto one pod.

We were running 300+ apps across 11 EKS clusters in a banking environment. Dropping availability was not an option. So we went digging.

What we found was not in the official docs. It was a trick - something so counterintuitive that the first time I thought of it, I laughed. Then I tried it. Then it worked.

This talk is the story of that fix -- how we found it, why it works, and how we shipped it safely to production using Terraform without touching a single app config.

Explore advanced Linux perf techniques for sophisticated performance analysis. This session delves into specialized areas beyond typical CPU profiling:

* Data Type Profiling: Learn how to associate memory access hotspots with specific data structures and fields, gaining insights into data layout efficiency.
* Latency Profiling: Discover methods to identify and analyze serial execution segments within parallel programs that act as scalability bottlenecks.
* Kernel Lock Contention profiling: Understand how to use perf to detect and analyze kernel-level lock contention issues.
* And more..

This talk will cover the concepts and perf tool methodologies to diagnose these critical performance aspects in both user-space and kernel contexts, empowering you to pinpoint elusive performance problems.

"Let’s be real: My AI has dementia."
"Vibe-coding in real: Me and My AI is stupid"
Welcome to the "Vibe Coding" era, where anyone can prompt their way to complex code. But as a 17-year-old developer who "bullied" LLMs to build a custom Linux Based OS (MaruxOS) from scratch, I’ve seen the ugly truth: AI is a brilliant assistant, but a chronic liar with a 5-minute memory.
In this session, I expose the messy reality of AI-native development. I’ll share how I battled "Contextual Dementia"—where AI forgets my ARM64 architecture mid-patch—and survived "Mindless Yes-Clicking Syndrome," where a single trusted prompt almost nuked my entire glibc.
Key Takeaways:
The Hallucination Hunter: Sniffing out AI’s "confident bullshit."
The Dementia Doctor: Managing AI’s memory loss to maintain architectural integrity.
The Final Decider: Moving beyond the "Yes-Clicking" trap to take true technical ownership.
AI might be writing the code, but only a real engineer can stop it from burning the house down.

Tech blogs usually talk about huge Ceph clusters with thousands of disks. But in reality, many of us run smaller on-prem setups. I will share my real experience of debugging a small Ceph cluster (10 nodes, 10 NVMe, 15 normal SSDs) and how tracking a slow app led me to write an upstream C++ patch.

It started when our Valkey (Redis) pods suffered from severe write latency. We checked CephFS metadata and Istio network metrics, but they were fine. So we dug into the storage layer using ceph osd perf. We saw huge latency on one specific node. Looking at the kernel logs (dmesg -k), we found a failing NVMe disk. I will explain the "Slow OSD" issue—how one broken disk can freeze a 3-replication cluster.

During this outage, reading ceph osd perf was very frustrating because the OSD IDs were completely unordered. Since it made debugging harder, I decided to fix it. I looked into Ceph's C++ code, changed the unordered hash map to a sorted vector (std::sort), and opened PR #67915 (https://github.com/ceph/ceph/pull/67915). I will share my experience discussing the fix with Ceph maintainers and why I believe engineers should fix the open-source tools they use.

AI agents are quickly moving from prototypes to production systems that manage APIs, tools, and complex reasoning tasks.

Once these systems are deployed, they often act like black boxes, hiding failures, slowdowns, and unexpected behavior.

This session will show you how to add observability to agentic systems with open-source tools and cloud-native tech.

​Brandon and Mostafa will break down the lifecycle of an AI agent, covering prompt execution, tool invocation, memory access, and multi-agent coordination, and demonstrate how to make each stage observable.

Using a practical, architecture-focused approach, they will show how to:

- Trace agent workflows across distributed systems
- Monitor latency and token usage
- Detect anomalies such as hallucinations, tool misuse, and runaway behavior.
- Connect LLM behavior with infrastructure metrics like GPU, container, and network data.

They will also present a complete reference architecture that uses open-source projects including OpenTelemetry (OTel), Prometheus, Grafana, and some new tools for LLM observability.

Attendees will learn practical ways to build transparent and reliable production AI agent systems.

As cloud service providers evolve their infrastructure, Multi-AZ architecture becomes essential for service continuity, failure isolation, and operational resilience. However, building a Multi-AZ cloud with open source technologies is not simply about spreading components across data centers. It requires design decisions across compute, networking, storage, observability, automation, and failure validation.

This session shares a CSP’s journey from a region-centric architecture toward a Multi-AZ cloud model using open source technologies such as OpenStack, Kubernetes, OVN, Kube-OVN, OpenStack-Helm, Cluster API, Ceph, and cloud native observability tools.

The talk will cover regional versus AZ-local service design, OpenStack control plane deployment on Kubernetes, zone-aware networking, storage replication, image availability, observability, and DR validation. It will also discuss trade-offs in traffic locality, failover behavior, data consistency, and complexity.

Rather than presenting a vendor-specific platform, this session focuses on reusable architecture patterns and lessons for cloud operators who want to build resilient open cloud infrastructure with open source software.

The advent of heterogeneous memory like CXL allows systems to secure additional bandwidth, but effectively utilizing it remains challenging. While widely adopted memory tiering optimizes latency by migrating hot pages to fast memory, bandwidth-intensive workloads require utilizing multiple memory tiers simultaneously.

To address this, Weighted Interleaving was introduced to distribute pages proportionally based on each node's bandwidth. However, it has a critical limitation: it ignores the physical topology of multi-socket systems, often leading to inefficient cross-socket memory accesses.

To resolve this, we introduce Socket-aware Weighted Interleave, an advanced memory policy currently being upstreamed to the mainline Linux kernel. It recognizes multi-socket boundaries, preventing performance degradation from unintended remote accesses and maximizing total throughput via localized allocation.

This advanced policy is a newly integrated feature of HMSDK, an open-source toolkit introduced last year. This session will focus primarily on this new capability, exploring how HMSDK efficiently manages large-scale CXL and heterogeneous memory systems.

In April 2026, x402 joined the Linux Foundation with over 20 founding members. It is the first payment protocol under open source governance at the Linux Foundation.

x402 activates HTTP 402 "Payment Required," reserved in 1997 but never used. A server responds with 402 and payment terms, the client settles on-chain, the resource is delivered. Apache 2.0, zero protocol fees, chain-agnostic, no single-organization dependency.

Part 1: Why now. Every internet layer runs on open protocols except payments. That breaks when AI agents must pay at machine speed. We map the agentic payment stack and ask: is it open, who governs it?

Part 2: How x402 works. HTTP 402 challenge-response, stateless architecture, one middleware line to gate any API, production deployments today.

Part 3: Bottom-up to foundation. x402 was open-sourced, developers adopted it, major infrastructure providers shipped native support, competing protocols chose to integrate x402 rather than build a rival. Then it moved to the Linux Foundation.

Part 4: What comes next. The protocol is early. Foundation governance changes the signal. We examine what sustained adoption requires.