Open Source Summit Korea 2026

Agentic AI is all the hype right now, but how do you actually implement such a system for real enterprise, cloud based use cases?

The challenge for developers, architects and platform engineers alike lies in custom building agents, and even more so, orchestrating these agents to collaborate effectively towards a common goal. Unfortunately though, despite all the promises from vendors, a "one-size-fits-all" or “off-the-shelf” approach just doesn't work due to the complex nature of software. In addition, just like traditional apps, these agentic systems will likely need to be deployed, managed and observed in cloud environments.

In this session we'll explore:
* The spectrum of Agentic AI patterns
* A real world-ish implementation of a highly performant - open source - agentic system (with Java!)
* Deploying this agentic system to Kubernetes
* Other considerations such as observability and fault tolerance to get it all running smoothly in production.

As organizations scale their Kubernetes footprint, the "Day 2" reality of GitOps becomes clear: static thresholds are brittle. Standard Canary rollouts rely on fixed Prometheus queries (e.g., Error Rate < 1%), but these rules lack the context to distinguish between a minor transient blip and a systemic failure. For Platform Engineers, this results in "Alert Fatigue" and manual "promotion" gates that slow down the delivery pipeline.
In 2026, we are moving from Static Automation to Reasoning Platforms.
This session explores how to evolve your delivery infrastructure into an intelligent system that doesn't just follow rules, but reasons through data. We will demonstrate how to wrap ArgoCD Rollouts with an Agentic Reasoning Layer capable of cross-referencing metrics, logs, and distributed traces to make autonomous "Go/No-Go" decisions.

We will trigger a Canary deployment that passes basic health checks but introduces a "silent failure" (e.g., a cache hit-rate drop causing downstream latency). You will see the Reasoning Platform detect the anomaly, pause the rollout, "investigate" the root cause, and present a natural-language justification for the automated rollback.

Deploying OS images to bare metal clusters is painful. Unicast scales linearly with node count. Multicast stalls if one node is slow. Past BitTorrent approaches either transfer entire raw partitions (wasting bandwidth) or require RAM buffering for image conversion (size limited).

EZIO's provisioning time depends on image size and bandwidth, not node count. It transfers only used filesystem blocks and writes directly to raw disk by calculating offsets on the fly. No RAM buffering, no image conversion, no size limit. Each node works independently. Broken nodes can rejoin after recovery. This enables deploying large HPC environments with pre-installed software and data. Clonezilla has integrated EZIO for production use.

Benchmarks: On HDD (50GB, 32 nodes), 11x faster than unicast, 50% faster than multicast. In the cluster with NVMe SSD and 10G network at Taiwan's National Center for High-performance Computing (NCHC), 500 MB/s across 32 nodes. Lab tests reach 700 MB/s.

This talk covers EZIO's architecture, real-world benchmarks, and integration approach.

Can you build OpenStack and Kubernetes clusters anywhere, across multiple clouds, and still understand how network connectivity works?

This session explores that question through a scenario using Cloud-Barista, an open-source multi-cloud orchestrator.

Instead of separate project overviews, this talk connects Cloud-Barista, OpenStack, and Kubernetes as infrastructure layers. Cloud-Barista provisions VMs on public clouds, then OpenStack is deployed on them. The OpenStack-based cloud is registered back into Cloud-Barista to create VMs and host a web service.

Will that service be reachable from Internet? If not, why? What makes it complex? These questions guide our explanation of network paths and reachability. We will apply the same lens to Kubernetes on multi-cloud VMs.

The focus is not just automation, but how connectivity works: public/private IPs, bastion access, cluster nodes, and how users reach workloads.

Beginners curious about these topics will gain practical insight into open-source infrastructure stacks.

This is not another cluster deployment talk. It is an experimental journey across open-source cloud layers, from multi-cloud IaaS to OpenStack and Kubernetes.

Running Kubernetes in air-gapped environments changes how the software supply chain behaves. Image distribution, signature verification, and dependency updates cannot rely on upstream access and need to be handled explicitly.
This talk examines what breaks when enforcing SBOM and image provenance in restricted networks. It covers artifact promotion across trust boundaries, signature verification without external services, base image drift, and coordinating updates across disconnected environments.
The focus is on concrete failure patterns and trade-offs: broken trust chains, stale dependencies, inconsistent SBOM data, and operational overhead introduced by manual controls. Several common supply chain practices do not translate directly to air-gapped setups.

The session shows which parts of the supply chain need to be redesigned to keep provenance and integrity intact without relying on continuous connectivity to upstream ecosystems.

There is this moment every platform team hits where an alert fires at 1am, everyone stares at it, and nobody is quite sure what it means or whose job it is to fix it.

That was us. 11 EKS clusters. 6 AWS accounts. Alerts routing to a channel. No runbooks. No context. Just noise.

Here is what made it worse --- we were the team responsible for the observability stack itself. VictoriaMetrics, vmagent, vmselect, Grafana, CloudWatch --- we ran all of it. And most of it was set up just well enough to fire alerts, but not well enough to actually help anyone during an incident.

Most observability talks are about how to instrument your applications. This one is about what happens when the platform itself becomes the thing you need to observe! and you are the one responsible for both the problem and the solution.

We will talk about what we got wrong first, what a P1 at 1am actually teaches you about your own stack, and what we built to make sure the next time something breaks, we know exactly where to look within the first five minutes.

Running the 5G User Plane Function (UPF) as a Kubernetes pod using open-source stacks like free5GC often hits a wall: kernel networking overhead destroys packet throughput. eBPF can bypass this bottleneck, but the concept remains intimidating to network engineers who don’t do kernel programming.

This lightning talk provides a zero-to-understanding educational journey. The speaker will first illustrate, with simple diagrams, the kernel’s slow path versus the eBPF XDP/AF_XDP fast path for GTP-U packets. Then, using a live (or pre-recorded) demo on a Minikube cluster, they will show an open-source UPF accelerated by a small eBPF program—demonstrating how GTP encapsulation/decapsulation is handled in the driver, with line-rate forwarding. The entire code, including a ready-to-run Docker image and Helm chart, will be shared on GitHub. Attendees will leave with a mental model of exactly where eBPF sits, which hooks to use, and how to evaluate eBPF acceleration for their own 5G cloud-native network functions. No prior eBPF or 5G core knowledge is required ,only curiosity about high-performance networking.

Terraform is widely used to manage infrastructure as code, but traditional drift detection relies on periodic scans or manual checks such as terraform plan. This approach often fails to detect real-time changes, manual modifications, or unauthorized actions.

In this technical feature demonstration, we present an open source approach to drift detection using an event-driven model powered by Falco.

We will demonstrate how:

infrastructure is provisioned using Terraform
manual or out-of-band changes introduce drift
Falco detects these changes in real time via event streams
an open source tool analyzes and surfaces these events as actionable drift signals

Unlike traditional drift detection tools, this approach enables near real-time detection, user attribution, and continuous visibility into infrastructure changes.

This session introduces the concept of “event-driven runtime drift” and shows how it complements Terraform-based workflows using open source technologies.

The demo is based on a publicly available open source project, allowing attendees to reproduce the setup and apply it to their own environments.