Understanding Istio and its Installation
We know that almost every organisation is working to transform their application to support microservices architecture as it provides many benefits which help in their business. Microservices architectures enhance the ability for modern software teams to deliver applications at scale, but as an application’s footprint grows, the challenge is to maintain a network between services. Service meshes provide service discovery, load balancing, and authentication capabilities for microservices
This is where Istio comes into play. Istio is an open-source service mesh that lets you connect, monitor, and secure microservices deployed on-premise, in the cloud, or with orchestration platforms like Kubernetes.
What is a service mesh?
A microservices architecture isolates software functionality into multiple independent services that are independently deployable, highly maintainable and testable, and organized around specific business capabilities. These services communicate with each other through simple, universally accessible APIs. On a technical level, microservices enable continuous delivery and deployment of large, complex applications. On a higher business level, microservices help deliver speed, scalability, and flexibility to companies trying to achieve agility in rapidly evolving markets.
A service mesh is an infrastructure layer that allows your service instances to communicate with one another. The service mesh also lets you configure how your service instances perform critical actions such as service discovery, load balancing, data encryption, and authentication and authorization.
An Istio service mesh is logically split into a data plane and a control plane.
The data plane is composed of a set of intelligent proxies (Envoy) deployed as sidecars. These proxies mediate and control all network communication between microservices. They also collect and report telemetry on all mesh traffic.
The control plane manages and configures the proxies to route traffic.
The following diagram shows the different components that make up each plane:
Shape The overall architecture of an Istio-based application.
The following sections provide a brief overview of each of Istio’s core components.
Istio uses an extended version of the Envoy proxy. Envoy is a high-performance proxy to mediate all inbound and outbound traffic for all services in the service mesh. Envoy proxies are the only Istio components that interact with data plane traffic.
Envoy proxies are deployed as sidecars to services, logically augmenting the services with Envoy’s many built-in features. This sidecar deployment allows Istio to enforce policy decisions and extract rich telemetry which can be sent to monitoring systems to provide information about the behaviour of the entire mesh.
Istiod provides service discovery, configuration and certificate management.
Istiod converts high level routing rules that control traffic behaviour into Envoy-specific configurations, and propagates them to the sidecars at runtime. Pilot abstracts platform-specific service discovery mechanisms and synthesizes them into a standard format that any sidecar conforming with the Envoy API can consume.
We will see how to install Istio on SUSE CaaSP in this section.
Download Istio from below command. It will download latest Istio version from github.
sles@mgmt:~> curl -L https://istio.io/downloadIstio | sh –
To configure the istioctl client tool for your workstation, add the /home/sles/istio-1.7.2/bin directory to your environment path variable with:
sles@mgmt:~/istio-1.7.2> export PATH=”$PATH:/home/sles/istio-1.7.2/bin”
Begin the Istio pre-installation check by running:
sles@mgmt:~/istio-1.7.2> istioctl x precheck
Checking the cluster to make sure it is ready for Istio installation…
Can initialize the Kubernetes client.
Can query the Kubernetes API Server.
———————– Output truncated——————
Install Pre-Check passed! The cluster is ready for Istio installation.
For this installation, we use the demo configuration profile. It’s selected to have a good set of defaults for testing, but there are other profiles for production or performance testing. Please visit below link to check all configuration profiles
sles@mgmt:~/istio-1.7.2> istioctl install –set profile=demo
Add a namespace label to instruct Istio to automatically inject Envoy sidecar proxies when you deploy your application later:
sles@mgmt:~/istio-1.7.2> kubectl label namespace default istio-injection=enabled
Deploy a sleep deployment which is under samples.
sles@mgmt:~/istio-1.7.2>kubectl apply -f samples/sleep/sleep.yaml
This will create pod, service and service account. We need to assign created service account a role which provides NET_ADMIN and NET_RAW capabilities. We will do it by creating below CLusterRoleBinding.
sles@mgmt:~/istio-1.7.2> cat >> sleep-role.yaml <<EOF
– kind: ServiceAccount
sles@mgmt:~> kubectl get pods
NAME READY STATUS RESTARTS AGE
nfs-storage-nfs-client-provisioner-789494d44c-ptzhz 1/1 Running 0 11d
sleep-8f795f47d-mjl9q 2/2 Running 0 3d23h
sles@mgmt:~> kubectl describe pod sleep-8f795f47d-mjl9q
Start Time: Fri, 25 Sep 2020 19:34:12 +0530
Container ID: cri-o://0097a82b060488c88e638d550f7bddbd37fa63a8900ae13c99f646155ea64f9d
Image ID: docker.io/governmentpaas/curl-
Container ID: cri-o://91005e03fcde4a8c35a7e6b141f7fca48ec085c35d08a0d49f614b97e8dbee28
Image ID: docker.io/istio/
———————– Output truncated——————
As we can see from above output when you deploy an application after Istio is deployed and Istio-Injection is enabled on a namespace, side proxy container is getting created by default.
Istio has lots of features which makes service mesh management easier. It provides Dynamic service discovery, Load balancing, TLS termination, HTTP/2 and gRPC proxies, Circuit breakers, Health checks, Staged rollouts with %-based traffic split, Fault injection, Rich metrics, service discovery, configuration and certificate management.
No comments yet