KubeCon + CloudNative North America 2022

In this talk, Kevin and Doug will trace a packet through its journey between a meshed client and server. They'll explore how the path of a packet changes after installing a service mesh, the additional hops it introduces, and which networking changes ensure the application's behavior isn't affected.  First they'll observe the networking rule changes that allow for a proxy to intercept traffic. Once we understand what changes about how a packet travels through the kernel, we'll better understand how to observe it in the following steps. Next, in order to observe this packet on its journey they'll take a dive into the Kubernetes networking debugging space. How do you properly use debug containers to observe traffic between other containers? Once you have debugging capabilities, what tools can we use to observe the traffic? Using these tools, attendees will understand what is happening behind the scenes of a service mesh and how a packet travels within it.

The explosion of the service mesh ecosystem over the past 5 years is well-documented; cloud-native users are consistently reaching for common mesh features like advanced traffic routing and policy enforcement(authn/z, timeouts, retries, etc). Unfortunately, the innovation of various service mesh implementations has led to a sprawl in APIs and features that can make life difficult for end-users and tooling providers. In this session, you’ll learn about historical efforts to unify the service mesh space and how the new Kubernetes Gateway API may hold the key to achieving that vision.

Intuit has a few monolithic applications that are scaled horizontally by sharding. It is common practice to use a dedicated frontend layer to route requests to a specific application shard based on request attributes. The attributes used for shard determination are non static and include tens of millions of users and thousands of services. Hence maintaining a static mapping of these attributes to shards is not feasible. For maintainability and separation of concerns, a dedicated look up service could be used to store and retrieve this shard information. Currently at Intuit, the sharded routing is performed in a central API Gateway using this lookup service. However, as we move our monolithic applications to service mesh, our next step was to decentralize the sharded routing to happen on a client’s service mesh proxy. A service mesh that utilizes a client side proxy like Envoy does not have an out of the box support for lookup based dynamic routing to the destination shards. This session discusses and demos how Intuit uses WASM to extend Envoy in a service mesh to provide decentralized routing for a sharded application.

A lot of us test new versions of services in our Production environment, since it's the best way to get representative, reliable results. If the new service is "on the edge" of the topology then hitting it is easy, as the test clients can directly call it. But if it's in the middle of a chain of services, then calling the current versions of all of them, except one beta version in the middle of the chain, is the dream. This kind of advanced traffic control is possible with a Service Mesh like Istio. But the configuration needed to enable this for all versions of all services is complex and error-prone. In this session Matt will show you how to use an Operator which auto-generates the necessary config. We'll see how just deploying a new version results in all the necessary config for sophisticated "override-based testing". Matt will walk through the technique, the underlying config, and the operator that generates it from Deployments.

AWS App Runner is using Envoy underhood for its multi-tenant request-routing, load balancing and auto scaling. In this session, the AWS App Runner service team will share Envoy user experience. Journey of building an Envoy-based scalable request-router from developer point of view. Reason to choose Envoy and benefits it brings to the product. Lessons learnt and best practices for maintaining and operating Envoy-based systems in day-to-day work life.