Service Mesh Extensibility Explained
Have you ever wondered how to extend your service mesh for your specific business needs? Perhaps you need to add external authorization or advanced rate-limiting? Or maybe you want to add custom logic in the data path to perform dynamic routing and policy enforcement? In this blog, I want to explain service mesh extensibility patterns to help you further progress with service mesh.
What is a Service Mesh?
As part of the journey to cloud-native, organizations face many challenges when managing microservices, such as connecting, securing and observing services. You could solve these challenges directly in the service code, but it can quickly become unmanageable when you have many services in different languages. Service mesh is designed to solve this problem in a language-agnostic way. A service mesh is a programmable framework that allows you to observe, secure and connect microservices. It doesn’t establish connectivity between microservices; instead, it allows you to apply policies and controls on top of existing networks to govern how microservices interact. This means you can declare your intentions, and the mesh will ensure that your declared intentions are applied to the services and network. A service mesh ultimately shifts the implementation responsibilities out of the application and moves them to the network. There are many open source service mesh implementations out there, including Istio, Consul Connect, Kuma and Linkerd.
Service Mesh Data Plane Extension
Listed below are a few common patterns to extend the service mesh data plane based on your use cases:
1. Customize the init Container
Those of you who have implemented a service mesh project commonly use iptables to capture incoming and outgoing traffic. The traffic redirection essentially enables proxies to perform interesting tasks such as intelligent routing, retry, timeout, circuit breaking, etc. In Istio, for example, there are two ways to set up the iptables rules. The default method is via the init container, which requires `NET_ADMIN` privileges for deploying any pods to the mesh. This elevated privilege could be problematic for some organizations. The more secure approach uses the Istio CNI (container network interface) plugin, which runs as a Kubernetes DaemonSet on each node to configure the iptable rules as soon as pods are deployed to the mesh. When Istio CNI is enabled, the init container validates that the Istio CNI DaemonSet correctly applies the iptable rules.
2. Customize the Proxy Image or Configuration
A simple method for extending the data plane is to use your own proxy image. For example, some service mesh projects may want to provide a non-Envoy-based proxy or add additional libraries to the default proxy image. Proxy injection configuration is commonly customizable in the service mesh. For example, in Istio service mesh, you can modify the `istio-sidecar-injection` config map in the `istio-system` namespace to customize the proxy image, iptable rules, security context and many others.
3. Extend your Sidecar Proxy Using Envoy Filters
Envoy, the most popular sidecar proxy, is highly extensible with multiple extension points. You can write an extension for Envoy using either C++ or Lua. Envoy filter APIs may change from release to release, and you may need to adjust your filter accordingly for each release. In Istio, you can use the EnvoyFilter custom resource definition (CRD) to customize the Envoy configuration generated by the Istio control plane. You can modify certain fields or add specific filters or entire new listeners with Istio’s EnvoyFilter resource. The high extensibility comes with a cost! There is currently no plan to graduate Istio’s EnvoyFilter CRD out of alpha status because your Envoy filter may stop working after upgrading Istio, due to Envoy filter API incompatibility.
4. Web Assembly
Web assembly (Wasm) plugins are rising to become the de facto standard to extend the sidecar proxy. There are multiple advantages of Wasm over Envoy filters:
- Wasm expands to any language.
- Wasm runs in an isolated VM and can dynamically update without Envoy restarts.
- Near-native performance.
- Eliminate the need to recompile and maintain a build of Envoy.
- Easy to store and consume via the web assembly hub.
Service owners can use Wasm filters to help manage Wasm plugins’ life cycle; however, that is just one piece of the puzzle. Wasm is a fast-evolving area where service owners likely need help to get started, whether to deploy or debug their wasm plugins into their service mesh or reuse other developers’ wasm plugins.
5. Extend the Gateway
Gateways mediate north-south traffic at the edge of the mesh. You may have similar requirements for gateways and sidecar proxies, such as connecting to an external authorization system or rate-limiting a service. Or, you may need specific features such as a web application firewall, or data loss prevention at the gateways for north-south traffic only. The above data plane extensibility patterns can also be applied to the gateways, although the difference is that you don’t need iptable configuration or automatic sidecar injection at the gateways. Gloo Edge 2.0 , for instance, extends Istio’s ingress gateway using some of these patterns to provide extra functions requested by our users.
Service Mesh Control Plane Extension
Abstraction Over Service Mesh APIs
Suppose service mesh-provided APIs (commonly known as Kubernetes CRDs) don’t align with your organization’s roles and responsibilities; you might be interested in providing a higher-level abstraction that matches your organization’s business needs. Another common scenario is that you may want the same API for your users regardless of what service mesh projects your organization chooses, or if your organization chooses more than one service mesh project across different clouds. Some of our users have spoken publicly about building such an abstraction over the Istio service mesh. For example, Salesforce uses Helm and eBay uses its homegrown custom resource to provide the abstraction. Providing the right abstraction over different service mesh projects is also why we built the Gloo Mesh role-based API as an abstraction on top of Istio and other service mesh projects.
Plug in Your own Certificate Authority (CA)
The service mesh control plane commonly serves as a certificate authority for issuing keys and certificates for sidecars and gateways within the mesh. However, your organization may have an existing certificate authority that you prefer to use. The ability to plug in your own CA is a work-in-progress item for Istio. For example, you can disable the Istio control plane’s CA functionality and leverage the istio-csr project and your cert-manager issuer, such as Vault, as an example, to sign your workload’s keys and certificates within the service mesh. Alternatively, you can add an init container to the Istio control plane pod to connect to your Vault server to request the intermediate certificates for the Istio control plane, as Christian Posta demonstrated in his talk at IstioCon.
I hope these extension points provide a good overview for folks looking to extend service mesh beyond simple use cases. I invite you to connect me on Twitter or Linkedin to discuss more service mesh, Istio, Wasm, and other cloud-native topics.
