Envoy comes packaged as a Docker container. If you need to run it without a container, you will need to build it from the source. Envoy is like an engine, and being familiar with it is required if you wish to configure it for serious use without using a control plane for automation. A service mesh provider such as Istio, which is in an open source space, or AWS App Mesh, which is in a closed space, takes care of the right configuration with the proper plumbing through a control plane so that it can be used out of the box.

Its ease of use is evident from the fact that once Istio has been deployed, we only have to label a namespace with istio-injection=enabled and the rest is taken care of automatically. If a particular pod in this namespace doesn't get its sidecar, the pod can be annotated (for example, sidecar.istio.io/inject: False) and that pod won't get the sidecar.

For example, let's assume that Istio has already been installed and that we label the namespace default with an annotation of istio-injection=enabled and then deploy the application. The Envoy sidecar proxy will be injected automatically. The following code shows this:

# Label the default name space to enable auto injection of the Envoy proxy
$ kubectl label namespace default istio-injection=enabled

# Install busybox pod
$ kubectl create -f https://k8s.io/examples/admin/dns/busybox.yaml

# Check the pod and you should see sidecar injected automatically
# With 2/2 under the READY column
$ kubectl get pods
NAME      READY   STATUS    RESTARTS   AGE
busybox   2/2     Running   0          3m55s

If you describe the busybox pod, you will be able to see details about the Envoy sidecar proxy.

Notice that the busybox pod has one init container, istio-init, that initializes the proxy. The busybox container is created and the istio-proxy sidecar proxy is also created with the proper command-line parameters:

$ kubectl describe pod busybox
Name:         busybox
Namespace:    default
...
Init Containers:
  istio-init:
    Image:         docker.io/istio/proxy_init:1.2.2
    Args:
      -p
      15001
      -u
      1337
      -m
      REDIRECT
      -i
      *
      -x
      -b
      -d
      15020
Containers:
  busybox:
    Image:         busybox:1.28
...

The following code block shows the sidecar implementation of istio-proxy:

  istio-proxy:
    Image:         docker.io/istio/proxyv2:1.2.2
    Port:          15090/TCP
    Host Port:     0/TCP
    Args:
      proxy
      sidecar
      --domain
      $(POD_NAMESPACE).svc.cluster.local
      --configPath
      /etc/istio/proxy
      --binaryPath
...

Injecting an Envoy sidecar proxy into a deployment happens through Kubernetes mutating the admission webhook controller. The mutating controller modifies the object before it's sent to Kubernetes. In this case, the busybox deployment YAML file does not contain any information regarding deploying the sidecar proxy. However, when the deployment begins in the default namespace, which is labeled with istio-injection=enabled, the webhook admission controller is called, which modifies the busybox deployment so that it includes the sidecar proxy.

It is important to note that the deployment of the sidecar proxy is a feature of the Istio control plane, which automates the process. For example, configmap's istio-sidecar-injector contains the templates that can be used manually using istioctl or through a webhook admission controller to modify the application's deployment.

Fortunately, we don't have to worry about how a sidecar proxy deployment happens. It's part of the control plane, which makes the process easy since all we have to do is label a namespace. Everything else is taken care of automatically. 

Now that we've looked at the data plane and how it's implemented, we can move on. The most essential feature of Istio is the tools it uses for its observability features, without which it is next to impossible to figure out what is going on in a distributed application. In contrast to monolithic applications, distributed microservices applications come with complex test capabilities, log collections, and knowledge of what's happening in the service mesh. Istio bundles the necessary tools to provide such capabilities. We'll explain this in more detail in the next section.