LinkedIn’s Kubernetes-based compute platform spans more than 500k bare-metal machines, 5M pods, with thousands of developers doing more than 110k deploys a week. We don’t expose raw Kubernetes to developers and instead, provide a curated set of platform offerings.

We extend Kubernetes with APIs for stateless and stateful applications. Deployment and self-service debugging are first-class platform capabilities, so developers can run and troubleshoot their applications without needing to understand the underlying Kubernetes details.

We built the compute platform as a layered system that connects machine lifecycle, Kubernetes cluster management, and workload platforms. These layers coordinate infrastructure maintenance with application needs, allowing us to operate the fleet and its workloads together.

This talk explains how we designed these layers and the contracts between them, and how this architecture supported a centrally run migration of over 25M CPU cores. Existing applications could run on the old and the new platforms simultaneously, allowing gradual migration without application changes. We’ll share the tradeoffs behind what we expose, what we extend, and what we deliberately leave out of Kubernetes, and how these choices help us operate at scale while keeping deployment and debugging simple for developers.