the formal definition of
istio is - it allows one to connect, secure, control & observe microservices.
A microservice application has more moving parts as compared to a monolithic application. Each service is simpler but the entire system as a whole is more complex.
Microservices is an app architectural style that divides an app into components where each component is a full but diminutive app that’s focused on producing a single business task according to the Single Responsibility Principle.
Before we understand ISTIO first we need to see the -
Basic Challenge in MicroService Architecture -Usually, communications in microservice clusters are insecure, request comes via a proxy to clusters, MS talks to each other freely without any security that increases the risk of being attacked. Every service can talk to others without any restrictions.
Rather than working on applications' actual service logic, developers have to work on securing their applications, integrating them with monitoring tools, or adding some new non-business-logics to MS to address these challenges, which also add complexity to services, instead of keeping them simple and lightweight. The below diagram depicts the same.
Service registry - every time you deploy a microservice it gets registered to the service registry that will keep a track of all the services you have deployed in your architecture. It uses register() heartbeat() & unregister() functions to maintain an updated instances list.
Service discovery - whenever a service needs another service, it uses the service discovery function to find an instance of that service, service discovery works closed with the service registry to serve its purpose.
Automated testing - these tools ensures the resiliency of your application deployed as a microservice.
canary deployment (or rollout) is the tool in ISTIO, when you introduce a new version of a service by first it tests it using a small percentage of user traffic, and then if all goes well, increases, possibly gradually in increments fashion.
Istio is a dedicated infrastructure layer for handling service-to-service communication, which is responsible for the reliable delivery of the request
thru a complex topology of services that comprise a modern cloud-native
application.
It is a configurable, open-source service-mesh layer that
connects, monitors, and secures the containers in a Kubernetes cluster.
At this writing, Istio works natively with Kubernetes only,
but its open-source nature makes it possible for anyone to write extensions
enabling istio to run on any clustering software. Today, we'll focus on using
Istio with generic Kubernetes-cluster, one of its most popular use cases.
Before we start we should know the core features of ISTIO
Traffic management: Istio’s traffic
routing rules let you easily control the flow of traffic and API calls between
services.
The pilot uses three types of configuration resources to manage traffic in its service mesh:
a. Virtual services b. Destination rules c. Service entries
- Virtual services - A virtual service defines a set of traffic routing rules to apply when a host is addressed. Each routing rule defines matching criteria for the traffic of a specific protocol. If the traffic is matched, it is sent to a named destination service (or subset or version of it) defined in the service registry.
- Destination rules - A DestinationRule defines policies that apply to traffic that is intended for service after routing has occurred. These rules specify configuration for load balancing, connection pool size from the sidecar, and outlier detection settings to detect and evict unhealthy hosts from the load balancing pool. Any destination host and subset referenced in a VirtualService rule must be defined in a corresponding DestinationRule.
- Service entries - A ServiceEntry configuration enables services in the mesh to access a service that is not necessarily managed by Istio. The rule describes the endpoints, ports, and protocols of a white-listed set of mesh-external domains and IP blocks that services in the mesh are allowed to access.
Observability: with its custom the dashboard provides visibility of the performance of all of its services & provides visibility in your microservice operations.
Policy enforcement - you can apply custom policies between service interactions.
Connect: In the context of k8s, a
service provides a simple OSI layer 4 DNS-based load balancing for the pods
belonging to the service. Service mesh addresses OSI layer 7 load balancing
needs.
Secure: It ensures the
communication between two services is safely and securely using encryption and
mutual TLS also includes auditing capabilities of who does what and at what time
in result provides authorization and secure communication channel b/w services.
Reliability: It ensures
provisions for health checks, timeouts, deadlines, socket breakers &
retrace.
Integration &
Customization: works with any services registered at GCP, AWS, k8s, or
custom console or on-prem.
Detailed diagram of Istio Architecture which is logically split into control & data plane
Underlying orchestrator such as Kubernetes or hashicorp nomad.
Pilot - ( equivalent to service discovery) Responsible for configuring the Envoy and Mixer at runtime.
Mixer - Create a portability layer on top of infrastructure backends. Enforce policies such as ACLs, rate limits, quotas, authentication, request tracing and telemetry collection at an infrastructure level.
Citadel / Istio CA - ( certificate generation) Secures service to service communication over TLS. Providing identity & key management system to automate key and certificate generation, distribution, rotation, and revocation.
Galley - is responsible for interpreting the YAML files in Kubernetes and transforming them into a format that Istio understands. The galley makes it possible for Istio to work with other environments than Kubernetes since it translates different configuration data into the common format that Istio understands.
Data Plane
composed of a set of intelligent proxies deployed as a sidecar container that mediates and control all n/w communication between services.
Proxy / Envoy - The proxy can communicate with another proxy without connecting to Istiod in the control plane since they have all the logic in the configs we have supplied that was converted by Istiod.
Sidecar proxies per microservice to handle ingress/egress traffic between services in the cluster and from a service to external services. The Proxy manages connections to services, handling health checking, retry, failover, and flow control. The Proxy can report client-side metrics and logs (
For Istio to work, Envoy proxies must be deployed as sidecars to each pod of the deployment. You can inject the Istio sidecar into a pod in two ways:
Manually by using the istioctl CLI tool
Automatically by using the Istio Initializer
Ingress/Egress - Configure path-based routing for inbound and outbound external traffic.
How to setup Istio for a Kubernetes-cluster
Install istioctl$ curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.7.3 sh - $ sudo cp -rp istio-1.7.3/bin/istioctl /usr/local/bin/if fails use monolithic approach$ wget https://github.com/istio/istio/releases/download/1.7.3/istioctl-1.7.3-linux-amd64.tar.gz \--no-check-certificate(Optional) Run Istio pre-installation check $ istioctl x precheck You will get details aboutkubernetes( api, version, setup)Istio(namespace, sideCar-Injector etc)Install Istio-core & Istiod in k8s and its components into the istio-system namespace$ istioctl installthis will add istio-system namespace into your cluster and run ingress & istiod podsYou might end up getting one of the usual error, while initiallizing istiod pod possibly because of less resources available to host your mesh Warning FailedScheduling 39s (x11 over 13m) default-scheduler 0/2 nodes are available:1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate,1 node(s) had taint {node.kubernetes.io/disk-pressure: }, that the pod didn't tolerate.Now deploy some MS so that we can test how istio injects envoy proxy into pods [https://github.com/GoogleCloudPlatform/microservices-demo]Injecting Envoy Proxy for microservices it wont be happend automatically, so you have to do that, label the namespace which you want to observe, so that ISTIO will understand where to inject proxy $ kubectl get ns default --show-labelsNAME STATUS AGE LABELS default Active 61m <none> $ kubectl label ns default istio-injection=enabledNAME STATUS AGE LABELS default Active 61m istio-injection=enablednow redeploy the microservices you will see an additional container(2/2) added into pod,which was injected by ISTIOData Visualization by installing Addons (Grafana,Prometheus,kiali,tracing etc)[https://istio.io/latest/docs/ops/integrations/][https://github.com/istio/istio/releases/download/1.7.3/istioctl-1.7.3-linux-amd64.tar.gz][istio-1.7.3/sample/addons/*.yamls]$ kubectl -f apply istio-1.7.3/sample/addons/for ex - checking Kiali service to visualize data$ kubectl get svc -n istio-system$ kubectl port-forward svc/kiali -n istio-system 20001open GUI - http://localhost:20001/ to visualize MS flowKiali - we use for MS overview in graph form