COSCUP 2026 - Golang TW x Cloud Native

在雲端開發盛行的時代，為每位開發者配置獨立 VM 既昂貴又浪費資源。Containarium 是一個基於 Go 語言與 LXC 技術的開源專案，旨在解決這個痛點。它能在單一 VM 上快速佈署數百個具備完整 OS 體驗、支援 SSH 存取、且能執行 Docker 的隔離開發環境。

本場次將分享我們如何利用 LXC 系統容器取代傳統 VM，並透過 SSH Jump Host 與雲端原生自動化技術，在不犧牲安全性的前提下，將基礎設施成本降低 90% 以上。我們也將介紹 Containarium 如何在 Spot Instance（競價實例）上實現自動恢復，打造穩定的開發環境。

Bare-metal provisioning tools speak a language that virtual machines simply don't understand: IPMI and Redfish, the protocols of physical Baseboard Management Controllers (BMCs). Yet in today's cloud-native landscape, there's a very real need to run those same provisioning workflows against virtualized infrastructure: for development, testing, CI pipelines, and beyond.

In this talk, we'll introduce KubeVirtBMC, an open-source, cloud-native project that gives KubeVirt VMs virtual BMCs, exposing IPMI and Redfish endpoints so that existing bare-metal provisioning stacks, whether cloud-native or not (Metal3, Tinkerbell, Foreman, and others), can interact with virtual infrastructure without any modification. Think of it as the Kubernetes-native counterpart to VirtualBMC, but built from the ground up around the Kubernetes controller pattern.

We'll walk through the architecture, demonstrate a live integration with Metal3/Tinkerbell, and discuss project governance, including lessons learned from navigating the migration into the KubeVirt organization.

GPUs are expensive. Kubernetes doesn't share them well yet, DRA is still work in progress.

HAMi: Heterogeneous GPU sharing for Kubernetes.

What I'll Tell You:

How it hijacks CUDA calls without touching your app code Why memory isolation matters Some real production use cases Real Results: Teams cut GPU costs 40-60%

Who Should Show Up: K8s operators, platform engineers, anyone watching GPUs sit idle

github.com/Project-HAMi/HAMi

當你的 Go 服務開始出現 latency Spike，第一個懷疑對象往往是 channel。 Channel 內部的 mutex、GC 壓力、false sharing，這些問題在高吞吐場景下會被放大。 LMAX Disruptor 是金融交易系統中解決這類問題的經典方案，但它真的適合 Go 嗎？ 本議題帶你從源碼出發，一起讀懂 smarty/go-disruptor 的設計，理解 Disruptor 為什麼快，以及在 Go 的生態下它的邊界在哪裡。

1. Channel 的成本從哪裡來？ 用 benchmark 展示 channel 在多核環境下的瓶頸，從 CPU cache line、false sharing 與 mutex contention 建立直覺，讓後續的源碼解析有具體的問題背景。
2. 讀源碼：Ring Buffer 的核心設計 逐段解析 smarty/go-disruptor 的關鍵檔案， sequence.go 的 cache line padding 如何消滅 false sharing、sequencer.go 的 atomic 操作如何取代 mutex、producer/consumer gating 機制如何在不加鎖的情況下保證順序。
3. Go Memory Model 的關鍵轉折 Go 1.19 正式明確了 atomic 操作的 happens-before 語義，這讓 smarty/go-disruptor 從 pre-release 進入穩定狀態。我們會從源碼理解這個語義保證在實作上意味著什麼，以及為什麼在這之前 lock-free 的 Go 程式碼其實站在不穩固的地基上。
4. 邊界在哪裡：什麼時候 Channel 就夠了 以 exchange matching engine 的設計評估為例，說明在真實系統中如何判斷是否需要 Disruptor:吞吐量需求、團隊維護成本、系統複雜度的三角取捨。
5. 從 Disruptor 借回 Go 的設計概念 即使不用 Disruptor，它的設計思想仍然可以改善你的 Go 系統：預分配 slice 減少 GC 壓力、struct padding 避免 false sharing、ring buffer 作為固定大小的 event queue。

• 目標受眾： 對 Go 並發有基礎認識、對系統效能調優或底層設計感興趣的工程師。不需要有 Disruptor 或金融系統背景。
• 帶走什麼： 讀源碼的方法、對 Go memory model atomic 語義的具體理解、一個判斷是否需要 Disruptor 的決策框架。 所有參考內容皆為公開開源專案，技術方法不依賴任何特定雲端平台或商業工具。

隨著 Kubernetes 環境邁向超大規模與多雲複雜化，傳統的 SRE 自動化腳本與預定義規則已難以應對「未知之未知」的系統風險。2026 年的維運思維正在發生移轉——我們不再僅是追求「自動化 (Automation)」，而是致力於實現「自主化 (Autonomy)」。

本議程將分享如何運用 kagent——CNCF Sandbox 的 Kubernetes 原生 Agentic AI 框架，搭配 A2A (Agent-to-Agent) 協議，讓不同專長的 Agent 能像人類專家一樣相互協商、委派任務並達成共識，在 K8s 上打造一組真正會協作的 SRE Agent。我們會從三個面向切入：

1. 自主協作架構：A2A 協議如何定義 Agent 間的發現機制、通訊邊界與衝突仲裁，讓異質框架的代理也能無縫協作
2. 從觀測到行動的閉環：kagent 如何讓 Agent 不只「看見」異常，更能協助工程師推理、決策，並在 Kubernetes 與雲端服務上執行修復，與人類團隊共同完成從感知到行動的完整閉環
3. 從意圖到安全執行：將使用者的目標 (Intent) 轉化為可稽核的 Kubernetes 操作，並透過 Human-in-the-Loop 機制守住自動化的邊界