Building Multi-Cloud Service Meshes at Snowflake
summary
Snowflake runs ~170 Kubernetes clusters plus millions of VMs and needs a cloud-agnostic service mesh. Built solutions include running ingress gateways as daemonsets with preserve source IP via node-local externalTrafficPolicy, a blue‑green control‑plane upgrade that avoids DNS by using a common load balancer with manual Endpoints and a controller to shift backends, and autoscaling workarounds because the 30s admission webhook timeout prevents safe pod‑delete gating; alternatives evaluated: eBPF data plane, node‑level autoscaler, and a Kubernetes enhancement proposal.
AI-written summary · about
chapters (7)
- 0:00Start
- 2:22Container Platform Overview
- 7:05Preserving Source IP Makes Autoscaling Hard
- 9:13Setup Before We Support Autoscale
- 11:59Three Possible Solutions
- 20:17Common LB Animation
- 21:38Open Questions with Multi-cloud
related talks
37mBuilding a Multi-Cloud Service Mesh from the Ground Up with Kilo
24mSelf-Service Multi-Cloud K8s Platform at a Regulated Financial Enterprise
20mNetwork Service Mesh
19mMulti-region Service Mesh: How Koyeb Built and Operates One Using Kuma and Envoy
31mSimplifying multi-clusters in Kubernetes using KubeSlice
26mBuilding a Scalable Cloud Native Platform: The Key to Success
21mI Deployed my Snowflake and it Didn't Melt! Now What?
32mBreaking Boundaries: Multi-cluster with Cilium cluster mesh