KCD Kuala Lumpur 2026

As Organisation grow, DevOps models often struggle to scale. Expecting every product team to deeply understand reliability, security, and cloud infrastructure can slow delivery and increase operational risk. At Electrolux Group, we faced this challenge as our engineering footprint expanded across teams and regions. Rather than pushing more operational responsibility onto developers, we encoded these concerns into a shared Internal Developer Platform (IDP), enabling faster delivery without sacrificing reliability or control. This session explores the design and evolution of our Internal Developer Platform, built using Backstage and infrastructure-as-code. We’ll show how self-service provisioning, opinionated defaults, and standardized workflows reduce cognitive load while maintaining consistent operational standards. We’ll also share lessons from open-sourcing the platform, including removing internal assumptions, improving extensibility, and preparing it for community adoption.

Kubernetes is notoriously difficult to learn because "Day 2" operations require breaking things - something you can’t easily do in a production environment. To solve this, we built a platform at KodeKloud that spins up thousands of fully isolated, short-lived Kubernetes clusters every hour for students to experiment with. In this technical deep dive, I will share how we leverage the CNCF ecosystem to build an automated learning engine: 1. The Orchestrator: How we use K3s and custom controllers to manage the lifecycle of hyper-ephemeral clusters with sub-30-second cold starts. 2. Networking and Isolation: Using Cilium or Calico to ensure that thousands of students can run "root" workloads in isolated sandboxes without cross-contamination. 3. How we monitor the health of thousands of clusters that only exist for 60 minutes using Prometheus and Grafana. 4. How we implemented automated reconciliation to ensure a student can "reset" their environment to a known good state instantly. This session is for anyone interested in Platform Engineering, Education Technology, or those looking for advanced patterns in ephemeral infrastructure and resource multi-tenancy.

The Kubernetes Gateway API is rapidly becoming the standard for traffic management, but its power and flexibility introduce new risks. A simple misconfiguration in an HTTPRoute could expose an internal service to the internet, while inconsistent Gateway configurations can lead to security vulnerabilities. How do we empower platform and application teams to use this new standard without compromising on security and best practices? This session introduces Kyverno as the essential policy engine for the Gateway API ecosystem. We will demonstrate how to write Kubernetes-native policies to validate, mutate, and generate Gateway API resources. Learn how to enforce critical guardrails, such as mandating corporate TLS certificates on all Gateways, preventing developers from using risky wildcard hostnames, and ensuring all routes have a default timeout policy. We'll also look ahead at how these same principles apply to service mesh with the GAMMA initiative, providing a unified policy approach for both north-south and east-west traffic

AI agents like OpenClaw can execute arbitrary code - install packages, run shell commands, modify files. Today, most platforms sandbox these workloads in Docker containers. But containers share the host kernel. A single container escape gives an agent access to every other workload on the node. This talk shows a different approach: running agentic workloads inside Kata Containers with Cloud Hypervisor on Kubernetes. Each agent session gets its own lightweight VM with a dedicated kernel, memory, and filesystem - real hardware isolation, not just namespace separation - while Kubernetes handles scheduling, scaling, and lifecycle as usual. I'll walk through a working setup where OpenClaw (an open source AI assistant with 189k GitHub stars) runs its sandbox inside a Kata microVM on bare metal Kubernetes nodes. You'll see: - Why containers aren't enough for untrusted code execution, and what microVMs actually isolate - How Kata Containers + Cloud Hypervisor work under the hood - Running Autonomous Agents inside a microVM - Observability: monitoring microVM boot times, hypervisor metrics, and per-sandbox resource usage with Prometheus and Grafana - Performance tradeoffs: boot latency, memory overhead, and when microVMs make sense vs. when containers are fine Attendees will leave understanding when and how to use Kata microVMs on Kubernetes to safely run agentic AI workloads, with a reusable architecture they can adapt. Key takeaways: 1. The container isolation gap for agentic workloads and why it matters now 2. A working Kubernetes + Kata + Cloud Hypervisor architecture for microVM sandboxing 3. Practical lessons from running MicroVM with Kubernetes

Agentic AI systems do more than generate text. They invoke tools, maintain state across interactions, retry failed actions, and emit large volumes of telemetry tied to users, models, prompts, and downstream services. When deployed on Kubernetes, these agents behave like any other distributed workload: they autoscale, experience partial failures, and generate high-cardinality data that traditional monitoring stacks struggle to handle. This talk explores how to run agentic AI systems as first-class cloud-native services. We’ll walk through a practical architecture for capturing agent decisions and tool calls as structured events, storing and querying that telemetry in real time, and building feedback loops that help teams understand latency, cost, and outcome quality. Using a high-performance analytical database such as ClickHouse as the event backbone, we’ll examine how to move beyond dashboards toward query-driven debugging and evaluation. Rather than focusing on model internals, this session concentrates on infrastructure and reliability. Attendees will leave with a concrete blueprint for making agentic AI systems observable, debuggable, and production-ready in Kubernetes environments.