the formal definition of
istio is - it allows to connect, secure, control & observe microservices.
microservices are 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 understanding ISTIO, first we need to understand what is a service mesh and how it functions
Service mesh comprises generic functions where each function serves a meaningful purpose
Service registry - every time you deploy a microservice it gets register 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 a 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 service registry to serve its purpose.
Automated testing - these tools ensure 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, increase, possibly gradually in increments fashion.
Istio is a dedicated infrastructure layer for handling service to
service communication, which is responsible for reliable delivery of the request
thru 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 case.
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 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 a 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 interaction.
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.
Istio Architecture
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 - 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.
# Download Istio$ curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.7.3 sh -# 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$ sudo cp -rp istioctl /usr/bin# on successful completion you will seeIstio 1.7.3 Download Complete! Istio has been successfully downloaded into the istio-1.7.3 folder on your system. To configure the istioctl client tool for your workstation, add the /software/istio-1.7.3/bin directory to your environment path variable with: $ export PATH="$PATH:/software/istio-1.7.3/bin" # Run Istio pre-installation check $ istioctl x precheck You will get details aboutkubernetes( api, version, setup)Istio(namespace, sideCar-Injector etc)# Install Istio and its service/components into the istio-system namespace$ kubectl get svc -n istio-system$ kubectl apply -f istio.yaml# You 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.# Deploying ISTIO operator to manage your mesh$ istioctl operator init --watchedNamespaces=istio-namespace1,istio-namespace2to be continued...