Traffic Control

Configuring Envoy

Rolling out Envoy as the sidecar for a container in Kubernetes is not difficult – in fact, it is even quite easy (Figure 2). Where Envoy gets its configuration is a more difficult question, but without configuration, Envoy doesn't even know which back ends are available for an application component. Because microapps, by definition, work much more dynamically than conventional apps, the classic approach of a static configuration is not useful.

Figure 2: Envoy can be used independently of Istio in Kubernetes, as shown by this service definition.

Envoy takes this aspect of microapps into account and offers several options – almost all based on the principle of determining the configuration as autonomously as possible and almost all because Envoy allows a static configuration. The developers explicitly point out that they do not want to sideline this feature.

In a static Envoy configuration, host discovery is only possible over DNS; otherwise, practically all features are available. According to the developers, even large setups can be built with it, and the hot restart feature certainly has a part to play. If the developers change the Envoy configuration on the fly, the hot restart feature acts as a kind of Envoy variant of SIGHUP, which explicitly does not work here because the restart has to be triggered by internal Envoy functions.

For admins who like things a tad more dynamic, various service discovery APIs are available in Envoy that can be used to modify the Envoy configuration during operation. Endpoints can be configured with a dedicated API just as dynamically as clusters. Further APIs are available for routes and for cryptographic strings (typically passwords). On the Envoy website, the developers explain the various service discovery APIs in detail [3]. In practice, the APIs form the basis for solutions such as Istio or Contour, which use the APIs to store new configuration directives in Envoy during operation.

In the Know

Although advocates of modern microarchitecture applications often spread the myth that such applications no longer need monitoring, admins and developers usually know better – especially in setups in which instances of services are constantly disappearing or being added as a result of dynamic scaling. Envoy comes with several built-in functions that enable efficient and comprehensive monitoring.

The program is able to keep extensive records of its activities. For example, if it forwards an incoming request to a back end or establishes a connection between two services in an application, it always records the action and notes how much traffic is sent over the communication path. Additionally, the individual filters supplied with Envoy by default record many metrics. You can write your own filters for Envoy, as well.

However, the ability to record metrics is only one side of the coin. The other side is to get the data out of Envoy, store it sensibly, and then visualize it. Envoy offers several front ends to transfer data to other services.

The historical standard is exporting to Statsd, from which the metric data can then be further processed. If you want to avoid the detour, you can also export the data from Envoy directly to Prometheus (Figure 3). Grafana now has a number of pre-built dashboards that graphically display metric data from Envoy if stored in Prometheus, which guarantees a useful overview.

Figure 3: If you want to know what is going on in Envoy, you can export the data to Statsd or Prometheus, as shown here. © Envoy

Meaningful Envoy

Once you have discovered the various advantages of Envoy, you might ask yourself how you have lived your life up to now without it. Envoy offers huge advantages: In no other way can a mesh network be spanned so easily between the services of a microservices architecture – which inevitably raises the question of how Envoy can be rolled out and provided with a suitable configuration. As one example, Amazon accomplishes this directly as a resource (Figure 4).

Figure 4: Amazon has documentation and pre-configured designs if you want to use Envoy in AWS. © Amazon

The most common approach is Istio. Istio promises no less than an all-round, no worries package that integrates Envoy as a central component for both incoming data traffic on the client side ("ingress") and for communication between the components of an application ("east-west traffic"). Envoy extends Istio to include various automations and, with a few rules, tries to relieve the developer of most of the work.

However, Istio is by no means the only solution of this kind. For example, VMware's Contour is a proxy designed especially for the ingress traffic in Kubernetes. East-west traffic between the parts of an application is irrelevant to Contour, but the developers at VMware do set great store by the features for incoming traffic from the client side.