Cloud Native Days Norway 2026 - Real Real Cases. People.. Cloud Native.

Ticket prices excl. VAT

Speakers

Telecom infrastructure demands the performance of bare metal and the flexibility of virtualized environments—but unifying both under a single operational model is challenging. At Ericsson, we’ve built a cloud-native platform powered by Kubernetes, Cluster API, and Metal3.io to automate the lifecycle of telco-scale infrastructure spanning bare metal, OpenStack (via CAPO), and KubeVirt based virtualization. With nearly tens of thousands of servers in production, this platform delivers fully declarative lifecycle management, zero-downtime upgrades, and consistent observability across heterogeneous environments—all while meeting stringent telecom SLAs. This session shares the architectural principles, automation patterns, and operational lessons that make large-scale hybrid infrastructure practical and reliable. Attendees will learn how open-source collaboration and upstream innovation are enabling truly telco-grade cloud-native operations.

Speakers

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.

Vekst er bra – helt til det ikke lenger er det. I årevis kom ny funksjonalitet først mens teknisk gjeld hopet seg opp i det stille. Avhengigheter, treg CI/CD, tette koblinger og midlertidige løsninger gjorde det vanskelig å holde alt oppdatert, og plattformens omdømme ble dårligere for hver måned som gikk. Dette er historien om hvordan vi havnet her, hvorfor vi bygger om i stedet for å fikse det vi har, og hvordan vi bruker Crossplane til å skape en utvikleropplevelse folk faktisk liker å bruke. Det er også historien om alt som ikke er perfekt, utfordringene vi møtte, og hvorfor det å fortjene utviklernes tillit betyr mer enn noen arkitekturbeslutning. Gode verktøy hjelper. Å være åpen om hva som er ødelagt hjelper mer. Å ikke overselge det du bygger hjelper kanskje aller mest. Du kan velge riktig teknologi og likevel ha ingen som bruker det – hvis du ikke lytter.

As Kubernetes handles more complex batch and distributed ML workloads, the limits of default pod-by-pod scheduling become clear. Running these workloads efficiently often requires complex workarounds to manage resource contention.

Kubernetes policies are often introduced to improve security and consistency, but once enabled they can be difficult to understand and troubleshoot. When a workload is rejected, teams frequently lack visibility into which policy was evaluated, how often it fails. This talk presents a simple, technical workflow for observing Kubernetes policy behavior using Kyverno and VictoriaMetrics. Starting from a single validation policy, we show how policy evaluations and enforcement results are exposed as metrics, ingested into VictoriaMetrics and queried through a standard Prometheus-compatible API. A minimal dashboard is then used to inspect policy failures, affected namespaces and policy execution duration. The talk focuses on making policy enforcement observable using standard Kubernetes primitives and open metrics, without assuming prior experience with policy engines or observability systems.