EnvoyCon North America 2021

Running multitenant Kubernetes clusters is challenging, particularly when different tenants require their own dedicated infrastructure. At Adobe Experience Manager Cloud Service we built solutions to provide customers with their own dedicated infrastructure, such as ips, DNS, VPN connectivity,... while running most services in multitenant Kubernetes clusters. We make extensive use of Envoy to run networking tunnels between Kubernetes pods and customer dedicated infrastructure, enforcing encryption and mutual authentication using certificates. This allows, for example, different pods to have their own dedicated egress ip instead of the cluster's, or connections from pods to multiple customer on-premise services using VPN. The solution is provisioned automatically using Terraform, Kubernetes operators and other services. We have previously shown the architecture we built to run this service, and we will provide updates on what worked well, what didn't and the lessons we learned running it in production.

With HTTP/3 support going alpha in the Envoy 1.19.0 release, the team that launched HTTP/3 is excited to explain what HTTP/3 is, and talk about Envoy’s HTTP/3 integration: what is supported today, what is upcoming, and what best practices there are for testing and deploying HTTP/3 for your own Envoy instances, client side or server side.

Envoy has a number of different load shedding mechanisms available out-of-the-box. Circuit breaking, rate limiting, admission control, adaptive concurrency-- how do they work? When should you use them? How can they fail spectacularly? Let's find out!

This one's a deep-dive into the different load shedding mechanisms available in Envoy. Come watch Tony gush about how each one is implemented, the queuing/scheduling concepts behind them, and how they can fail to protect us from noisy-neighbor problems. He'll conclude with some experimental results based on his previous work on FBThrift and how we (as a community) can apply those ideas to improve Envoy.

Tinder adopted an Envoy based service mesh for their Kubernetes based infrastructure a few years ago. Our implementation is custom to Tinder's architecture but the lessons we picked up along the way are universal. Whether it's how we store and represent our routing configuration, building out a robust monitoring pipeline for all our Envoy metrics, utilizing Envoy's global rate limiting capabilities to protect our infrastructure, meshing our database and microservice requests, retry and timeout do’s and don’ts, and more, there is plenty of knowledge to share. We will explore our bespoke features like deadline propagation, multi-cluster Envoy metric monitoring, and how we implemented our own xDS control plane. From the early struggles of our service mesh migration, to cautionary tales and best practices, we're excited to walk through the process of building out an Envoy topology that powers Tinder's infrastructure worldwide.

Each day, Twitter responds to hundreds of billions of requests from users around the world. Today, Envoy is the point of entry for 100% of these requests. This hasn't always been the case. Not long ago, requests to Twitter passed through an ancient and highly bespoke edge proxy that was created internally and predated the open-source Envoy. In this talk, Ryland will describe how Twitter runs Envoy at the edge at scale, some of the unique benefits that Envoy provides in Twitter's edge architecture, and highlight features that Twitter has contributed to Envoy to support the edge use-case. He will outline how Twitter's edge architecture has evolved over time as the number of users and services has grown, what the next steps are for Twitter's edge, and the role Envoy will play in the future.