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.

Your software rollouts to production are probably always flawless, right? For the rest of us, once in a while we do run into issues when releasing code to production. Even with robust CI/CD, production rollouts can hit unexpected snags. While in Kubernetes, ArgoCD and Argo Rollouts excels at Progressive Delivery and automated rollbacks to mitigate deployment issues, what if we could go a step further?

This session explores how to elevate your release process by integrating Agentic AI and asynchronous coding agents, with Argo Rollouts canary deployments. We'll demonstrate how an intelligent agent can automatically analyze a rollout failure, pinpointing the root cause. Beyond diagnosis, these agents can take proactive steps on your behalf, suggesting and even implementing code fixes as new pull requests, which can be redeployed automatically after PR review. This approach moves us closer to truly self-healing deployments.

Join us to learn how to combine the power of cloud native projects like Kubernetes, ArgoCD and Argo Rollouts with the autonomous capabilities of Agentic AI, achieving a release experience that is not only seamless but also resilient.

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.

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.

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.

Tom and Jerry has run for over 80 years. Every episode follows the same plot: Tom builds an elaborate trap, Jerry walks straight through it, the house is destroyed, and the owner blames Tom. Sound familiar?

This talk is structured exactly like a Tom and Jerry cartoon except Tom is OPA and Jerry is your AI agent. Jerry is not malicious. He just wants the cheese. He will find every gap in every policy, squeeze through every webhook, and retreat to his mouse hole (MCP) the moment Tom gets close. The audience will root for Jerry. Jerry is still the problem.

We walk through three episodes. Episode one: Jerry discovers he can call kubectl delete and Tom's first policy stops him — but not before he's renamed two deployments. Episode two: Jerry finds a namespace Tom forgot to cover and provisions a GPU node at $8/hour. Episode three: Jerry and Tom finally cooperate — the agent runs a legitimate right-sizing workflow, OPA approves every step, and the cluster is actually better for it.


You'll leave with an OPA policy library for agentic tool-call governance, Argo Workflows, and a threat model built from real agent misbehaviour.

At Giant Swarm we use Cluster API to provision and bootstrap our k8s clusters. With this setup, control plane (CP) and worker nodes must run on the same infrastructure which was never an issue so far...

However, in bare-metal environments, using 128-core servers for CP nodes is luxury. It's far more efficient to host them as virtual machines on a hypervisor while keeping workers on physical hardware. But can we get around CAPI's limitations?

We will walk through how we built Frankenstein's cluster by mixing vSphere for the CP and Proxmox for workers as a testing ground. While technically functional, this required "hacky engineering". We will share the hurdles we hit and the operational risks of this hybrid cluster setup.

Finally, we will demonstrate how we solved this challenge with a cleaner, upstream-friendly alternative. Kamaji lets us run the CP as pods in a management cluster. We achieved even better resource optimisation with full native community support and no custom hacks.