Introducing A New Architecture for Simplified Service Mesh Deployments
summary
Consul replaces node agents with a lightweight sidecar called the Consul data plane that wraps and manages Envoy, letting workloads register directly with Consul servers and removing gossip dependence. The demo severs VPC peering, upgrades to Consul 1.14 beta and Consul Kubernetes 1.0 beta, and restores cross-cluster traffic without node-level agents, eliminating duplicated health checks and the need for flat networks. Feature ships in HCP in November and is initially supported on Kubernetes only.
AI-written summary · about
chapters (15)
- 0:00Start
- 1:09What Is the Current Service Mesh Architecture for Console
- 1:47Current Service Mesh Architecture
- 2:56Console Service Mesh
- 4:11Service Discovery
- 4:55Control Plane
- 9:20Why Do We Use Gossip
- 10:15What Do Console Clients Do
- 11:50The Challenges
- 17:06Duplication of Health Checking
- 21:39Demo
- 22:55Hashicorp Cloud
- 28:05New Architecture Console Data Planes
- 29:20Console Data Plane
- 35:03Upgrade My Services
related talks
19mService Mesh and Your Legacy Apps: Connecting to Kubernetes with Consul
32mService Mesh - Beyond the Hype
27mConsul Mesh Federation Deep Dive
22mConsul Use Cases At Stripe: Service Mesh and More
24mDeployment Patterns for Consul in Kubernetes
26mNavigating the Service Mesh Landscape - Paul Bouwer, Microsoft
05mService Mesh Architectures Explained - Sidecar and Beyond
30mA Developer’s Introduction to Service Mesh