Exchange

Is the Complexity Worth It?

If you look at Istio in detail, you will face some complexity, at first. The question is whether the Istio feature set genuinely justifies this complexity. Couldn't comparable results also be achieved with on-board resources? Which functions does Istio provide in detail? A simple example illustrates why Istio is particularly valuable in the context of container fleets.

Imagine a simple web application for a business that is buzzing and generating revenue, but Firefox users are constantly complaining about problems in the presentation of the web store. In the meantime, the DevOps team has found the root of this evil but would like to test a special version of the application with Firefox users before rolling it out for everyone (i.e., a canary release).

How would this work in the example? Clearly the load balancer belonging to the application has to take care of the corresponding distribution when the canary version of the application is rolled out to Firefox users. Without Istio, however, this would be very complex from the developer's point of view. First, it is not so easy to set up a load balancer in Kubernetes out of the box. In the worst case scenario, it runs as part of the container fleet itself.

Additionally, the load balancer would have to be reconfigured so that it uses a set of rules for the HTTP header on which the load balancer is ultimately based; otherwise, it cannot distinguish between the various browser types. If you build all of this, you end up with a complex construct of rules and services that is absolutely specific to just one software solution.

Traffic Management

If you look at the same example with Istio, the advantages are immediately self-evident. The central motivation for admins using Istio is that it usually more or less autonomously handles all the traffic within the service mesh of an application on the basis of the microarchitecture, wherein the scalability of the virtual container environment is strictly separated from the scalability of the traffic in it.

In the load balancer example, this means that for certain browser variants, the admin does not define in detail which instances of a certain pod will receive which calls but only specifies the desired call behavior of the load balancer as a whole (e.g., all requests with the user agent Google Chrome end up with version 1.0 pods of application X, and all requests with Firefox land on version 1.1 pods of application X). That version 1.0 runs on pods 1 through 5 of the application and version 1.1 on pods 6 and 7 does not matter from Istio's point of view.

If you were to launch additional 1.0 or 1.1 pods, the Envoy proxies would automatically integrate them into the existing balancing rules. Istio simply relies on the version number you have specified in the corresponding label when starting the pod, resulting in no additional overhead on your end.

Not much is necessary to implement the example described above. A YAML file that contains the corresponding rules and can be imported into Istio with the istio command is all it takes. Examples can be found in the Istio documentation.

Even More Possibilities

In this article, I can only hope to provide a brief overview of the Istio feature set. The principle of stability, which permeates all functions, is clearly in the foreground with Istio. Functional load balancing is only the most obvious example, but by far not the only one.

For example, Istio has built-in health checks for all pods successfully identified by Pilot. Istio monitors these back ends regularly. If a back end fails, Envoy proxies usually react immediately and remove the defective back end from the distribution. If something unexpected goes wrong and a connection is lost, Istio detects this, too, and the responsible Envoy proxy instantly rewires the connection. Of course, this only applies if you have not set Retry as the default tactic in the Istio configuration, thus forcing a different behavior.

If you want to test whether your container application reacts to errors as desired, Istio offers a fault injection mode. The solution then adopts the role of a Chaos Monkey and provides the adjacent pods with nonsensical input data. This capability is enormously helpful, because an application can be tested in a staging environment without risking problems in real operation.

If everything goes haywire, Istio also offers a circuit breaker function, which is a kind of throttle that takes effect when specific parameters (e.g., the number of incoming connections) exceeds values you can set yourself.

Because every Pod is involved in the dynamic routing of traffic as part of the mesh network, Istio-based meshes are well protected against bad guys by the circuit breaker feature. Such a setup might not survive a massive traffic bomb without damage, but the script kiddies will definitely have more difficulty finding attack vectors.

Finally, don't forget policy-based options in Istio. A central API can filter out or direct certain traffic in an orderly manner.