11-16, 14:05–14:35 (UTC), The Gallery
Kubernetes already has many properties of a primitive service mesh. Can we make the system better by leaning into this idea?
There's been a lot of excitement (good & bad) about service meshes, and some people believe that they are the best/only way to tackle the hard problems. There are debates about whether Kubernetes should embrace any particular mesh API or whether we really need a mesh at all. Some users are worried about the complexity of adding service meshes to their Kubernetes clusters, but see few alternatives for multi-cluster environments.
We argue that Kubernetes ALREADY HAS a service mesh, albeit a primitive one, and that we should not shy away from thinking of it as such.
Kubernetes APIs already cover many of the things that people think of when they consider meshes. As more and more users face problems that span kubernetes clusters, these mesh-like properties become more visible, and it may be that the solutions to some of our harder problems will be found by leaning into the idea of a mesh.
Tim is a principal software engineer at Google, where he works on Kubernetes and Google Container Engine (GKE). He has been part of the Kubernetes project since before it was open-sourced, and pays attention to topics like networking, storage, node, multi-cluster, resource isolation, and cluster sharing. Before Kubernetes, he worked on Google's Borg and Omega projects as well as the Linux Kernel, and before that he enjoyed playing at the boundary between hardware and software in Google's production fleet.