Istioctl Installation
Istioctl can be installed on Windows, but since the original document works with Linux scripts, we follow the Linux installation. To install the final release of Istioctl, it is sufficient to run the following command:
curl -L https://istio.io/downloadIstio | sh -
Alternatively, you can install the version you want with a command like the following:
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.4.0 sh -
After the installation is complete, you can add istioctl to the Path of the operating system and run it anywhere:
export PATH=$PWD/bin:$PATH
Istio Installation
After installing Istioctl, the following command is run to install Istio with the recommended demo profile:
istioctl manifest apply --set profile=demo
This command will install all the components in the demo profile to the Kubernetes cluster (istio-system namespace). You can examine the installed components with the following command:
kubectl get all -n istio-system
Use of Istio
Istio bypasses default network configuration of Kubernetes to manage the traffic of applications running on Istio Kubernetes. It adds its own sidecar proxy containers to the pods of the application and runs the network and security rules it defines through these proxies.
Therefore, if an application traffic needs to be managed with Istio, the deployment / statefulset definitions of that application should be changed to include Istio's sidecar proxies.
But there is no need to do this manually. Istio manages this easily.
There are two ways to manage Deployment and StatefulSets:
- Label the namespace where the application will be installed. With the kubectl label namespace playground istio-injection=enabled command, the namespace is labelled, and Istio automatically places its sidecar proxy containers inside all pods deployed to this namespace.
- Inject to StatefulSet or Deployment yaml files with istioctl. With kubectl apply -f <(istioctl kube-inject -f dpeloyment.yaml)> , the sidecar proxy is added only to the deployment / statefulset to be deployed.
Ingress Gateway
Ingress Gateway is the application through which all the outside traffic to the services using Istio passes.
It reaches the IngressGateway service via the external request hostname or nodePort and is directed from there to the IngressGateway pod.
VirtualService and Gateways are the resources that determine how the IngressGateway will behave, which requests it will route to where, whether it will use tls, and which requests will be allowed to pass.
Gateway
Gateways are the gates of Istio services. The Gateway rules decide which requests will pass through which ports of these gates and which rules will be applied during passing. These rules apply to requests passing through the IngressGateway.
Sample Gateway:
Virtual Service
The requests that satisfy the gateway rules and pass through the gate are directed to real services according to Virtual Service rules. VitrualServices have the routing features such as the request with specified header will access to, and how the incoming load will be distributed among different versions.
Sample VirtualService:
Destination Rule
DestinationRule is a rule definition that determines which pole the subset from VirtualService will correspond to. The subsets specified in VirtualServices are mapped with the labels specified in pods, and the pods to which requests are routed to Kubernetes service will go to are determined by these rules. In addition, the LoadBalancing rules that apply on the request to be routed from destinationRule in the destination service are determined. These rules can be given according to subset or ports.
Sample DestinationRule:
Kiali
Kiali is a tool which is installed with the Istio demo profile. It includes a useful dashboard where you can visually see your microservice architecture, identify problems, and create charts.
Jaeger
Jaeger is also a tool which is installed with Istio's demo profile. This tool allows you to trace your microservices. Using this tool, you can measure how much time the requests lose in any service and address the performance problems better:
BookInfo Example
Traffic management tests can be performed after installing BookInfo, one of the default examples in Istio installation, on Kubernetes cluster.
The sample setup is based on routing with different rules the request which has come to the ProductPage microservice to the Reviews microservice whose three different versions have been installed and on the three different versions bringing three different reviews to the frontend.
The following command is run for installation:
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml -n <namespace>
Installed pods:
Services:
Istio's IngressGateway Pod and Service installed by default:
Note: For convenience, I opened the service of my IngressGateway pod with NodePort. You can proceed with DNS definition if you wish or with external IP if you have a LoadBalancer.
There are three different versions of the Reviews microservice in the default installation of the BookInfo instance. No VirtualService, Gateway or DestinationRule is defined.
Therefore, any request to IngressGateway Ip and NodePort is not routed to BookInfo pods. In order to open the application to outside, we need to define Gateway and VirtualService in the namespace where we installed the application.
kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml -n playground
We have created a new Gateway called bookinfo-gateway, whose selector section is Istio: ingressgateway. This gateway will directly talk to the IngressGateway pod that comes in the default installation and allow the requests which come to that pod to pass through port 80 without filtering in the playground namespace.
We have also created a VirtualService that talks to the bookinfo-gateway. When arrived at the IngressGateway through / productpage, / static /, / login, / logout uri, this VirtualService tells that it should be directed to the Kubernetes service named productpage.
Now, we can access our application through the browser, via the NodePort where we access the Ingress Gateway.
In our current installation, we were able to route the requests from the IngressGateway to the ProductPage microservice in the playground namespace. However, since we do not define any other rules, the requests from ProductPage to the Reviews service are called with the default LoadBalancing rule (Random), and depending on the version of the Reviews to which each request is routed, the output with No Star, Black Star or Red Star returns to the screen.
Now let us write a new VirtualService to Access to the Review versions that show a red star when coming Reviews only with a specific user, and 75% starless and 25% black star in other cases.
If the requests that come to the review service include end-user: barcode in the header, the request review will go to v3. otherwise, in the default case, 75% of requests will go to v1 and 25% will go to v2.
Let us re-enter our application:
We will have the above error. We would like to go to Reviews microservice from the ProductPage microservice. While doing this, VirtualService, which we have just described, wants to send us to various subsets. But Istio does not know what these subsets are. We write DestinationRule to specify which microservice version the subset will be mapped to:
Now, when we access our application, we will see a no star screen with a 75% probability or a black star screen with a 25% probability. When we sign-in with the bartu user, we will always see a red star.
The example I showed above contains very useful features for release strategies such as A / B testing or Canary release. But Istio's capabilities are far beyond this article. With Istio, you can perform LoadBalancing, tracing, circuit breaking, fault injection and many more features.
References
