Istio is the perfect complement to Kubernetes. An elegant and complete networking solution, that also provides log management and monitoring on several platforms (Prometheus, Grafana, Jaeger, Servicegraph, etc.), which is directly integrated into its “control plane”.
In the first part of the articlewe discussed traffic management and monitoring.
Cluster with Istio
Kubernetes, by default, comes without some controllers. Ingress Controller and NetworkPolicy Controller, are some of them. This is one of the drawbacks of using Kubernetes on bare metal; that you have to adapt it to the control plane in which you run. And, that’s why solutions like GKE or EKS are so popular.
In GKE, Istio can be enabled/installed upon clustr creating. But GKE already has GCLB, which is Google’s Kubernetes Ingress Controller, and Calico can be installed, just like Istio; when creating the cluster, as NetworkPolicy Controller. Let’s see what is the difference between using these controllers and Istio.
With GCLB and an Ingress type object we have a layer 7 Load Balancer. We can redirect traffic to one service or another, depending on the host and the path of the request. This is a one-to-one mapping. The same request will always be redirected to the same service, which will go to the same set of pods (backends).
This is a somewhat rigid way of managing traffic. For example, to redirect 5% of the traffic to a “canary” version of the application, you would have to create 1 “canary” pod for every 19 of the main application, and configure them to be targeted by the same service. Although you do not need 20 pods to support the traffic, to get the desired 95-5, it is the only way.
With Istio, this is quite comfortable. What Istio does is to add another jump between the service and the backend, giving considerable flexibility. You can define as many “sub-services” as necessary, in which case the service would make a homogeneous load balancing between the backends of each “sub-service”, and if we wanted to redirect 5% of the traffic to the backends of a specific “sub-service”, we would define it explicitly, when creating it.
In the figure above, Service 1 has two versions. If not explicitly specified, the traffic will be sent equally to the two versions. Service 2 will send 95% of the requests to version 1, and 5% to version 2. Thus, with 3 backends, you can get a “canary” version, without complication.
It is also possible to configure this behavior with headers. For example, you can force requests from an iPhone to be redirected to one version of the application, while requests from an Android are handled by another one. The concept of “sub-service”, in Istio, is the subset of a host, that is specified in a VirtualService.
NetworkPolicies are cluster internal rules with respect of who can “talk” to who. The NetworkPolicy object allows to group a set of pods by their label and enforce ingress, egress, or both policies. The policy is applied by denying all traffic to the set of selected pods, and allowing alny what has been configured; that can be from three sources:
- Pods de un namespace. Any pod that has been created in a specific namespace, can communicate with the set of pods.
- Pods with certain labels. Any pod, from any namespace, with certain labels, can communicate with the set of pods.
- Traffic from an IP block. Typically they would be internal IPs, not belonging to the cluster. They cloud be IPs internal to the cluster, but in that case it would be more convenient to focus it as the two previous points.
NetworkPolicies are quite robust objects, in Kubernetes, although not quite used. The only drawback is that the driver is third-party, and you have to search and install one.
In Istio, nothing is configured directly for this purpose, but it happens naturally; when configuring the routes. As Envoy proxies, within the mesh, are configured to accept traffic only from specific sources, the result is similar, although with different approach.
The management of logs and the monitoring of Istio, in the way it is done, is new, so it can not really be compared with any other solution. Maybe with Stackdriver (within GCP), but they are of different magnitude, so we will not make that comparison in this article.
I personally find Istio a very comfortable and powerful tool to work with. Like a Swiss army knife. Even for medium and small clusters. The fact that the objects are integrated directly into Kubernetes, the flexibility of routing traffic, the enforcement of compliance policies, the logging and monitoring make Istio definitely to be considered adding to our toolbox.
Training Manager & Cloud Technology Evangelist
Juan Carlos Moreno
CTO & Senior Cloud Engineer