Istio service mesh

#devops #kubernets #istio #servicemesh

What is a service mesh?

?Developers and operators face chanllenges with a distributed or microservices architecture in cloud-based applications,?containers?and?microservices ,that triggered the need for a service mesh.

One chanllenge is that each MS has business logic , communication configuration.Another challenge is inside the cluster the MS communicate with each other insecurely with no additional security. if security is needed it has to added to MS logic. More challenges like retry logic and metrics and monitoring , it has to be add their logic to MS itself.

What service mesh offers for service-to-service communication ?

1. Observability & Metrics
2. Traffic management ( canary deployments)
3. Traffic spliting
4. Security like access control , end-to-end authentication & Encryption
5. Serevice discovery & Load balancing
6. Failure recovery
7. Rate limiting

How a service mesh works ?

A service mesh is a dedicated infrastructure layer that controls service-to-service communication over a network. This method enables separate parts of an application to communicate with each other.

A service mesh architecture uses a proxy instance called a?sidecar?attaches to each service. In a container, the sidecar attaches to each application container,?VM?or container orchestration unit, such as a Kubernetes pod.

What is Istio?

Istio is an open source service mesh that layers transparently onto existing distributed applications. Service mesh is a paradaism and istio is one of its implementations.

Istio Architecture :

• The data plane is simply a group of envoy proxies . An Envoy proxy is deployed along with each service in the cluster.
• The control plane manages and configures the proxies to route traffic. it is simply an istiod components that combines other component : Pilot , Discovery , Citadel , and Galley

Envoy

• Envoy is a high-performance proxy developed in C++ to mediate all inbound and outbound traffic for all services in the service mesh. They are the only Istio components that interact with data plane traffic.
• Envoy proxies are deployed as sidecars to services, The sidecar proxy model allows you to add Istio capabilities to an existing deployment without requiring you to rearchitect or rewrite code.
• Some of the Istio features and tasks enabled by Envoy proxies include:Traffic control features , Network resiliency features , Security and authentication , rate limiting ,and over all this , a pluggable extensions model based on WebAssembly that allows for custom policy enforcement and telemetry generation for mesh traffic.

Istiod

Istiod provides:

• Pilot : Service discovery by : internal regiestery for services and their end points. when new MS is added automatically to the registery
• Galley: Configuration : of envoy proxies
• Citadel : Certificate management : as Istiod acts as a certificate authority generate certificates for MS allowing secure TLS Communication between MS
• Gathering Telemetry data

Istio Ingress Gateway

The entry point to you cluster . it asn alternative to ngnix ingress controller and it runs as apod in the cluster and acts as a Load balancer.

it accepts traffic in cluster then redirect traffice to MS. It can be configured using CRDs as well.

Putting it all Together

• Istio is configured with K8 yaml files using Cutome resource definition (CRD) . CRDs extend K8 APIs.For example tarffice routing rules can be configured by using Istio CRDs see https://istio.io/latest/docs/concepts/traffic-management/
• Istiod Converts those routing rules configuration into envoy specific configurations that is propagated into proxy sidecars. we don't configure proxies we configure Istiod.
• Envoy proxies can now communicate with each other without connecting to Istiod.

Traffic flow

• For external request to the cluster , Istio gateway receives the request then route it using virtual service rules and send it to envoy proxy of intended MS envoy proxy that Forward it to the service container in the same pod.
• For inter process communication between MS , A convey proxy communicate with the other convey proxy using mutaul TLS
• During the request flow the proxies will gather all the metrics about the request and send it back to the control plane

Hand on experience : Istio on local K8 cluster overview

• Install Docker & minikube . Please see related documentation
• Install Istio core and Istiod on K8
• Configure automatic envoy proxy configuration
• Optional : install Istio addons for monitoring & tracing & visulalization

Useful commands

• start mininkube with extra resources

minikube start --cpus 6 --memory 8192        

• download istio for OS

https://istio.io/latest/docs/setup/getting-started/#download        

• install istio core to K8 cluster.Check istio ns , pods , svc are added to cluster.

cd <<istio_installation_folder>>
istioctl install
kubectl get ns 
kubectl get pod -n istio-system
Kubectl get svc -n istio-system        

• Inject Envoy proxies to running MS in cluster , an Check it is labeled

kubectl label namespace default istio-injection=enabled
kubectl get ns default --show-labels        

• Cluster is now ready to install MS . you will notice each pod you create for a MS will have 2 containers . the second one is the envoy proxy.
• Install Istio addons for monitoring like Grafana . Documantation available at : https://istio.io/latest/docs/ops/integrations/

References:

[1] https://istio.io/latest/about/service-mesh/

[2] https://www.techtarget.com/searchitoperations/definition/service-mesh

[3] https://konghq.com/learning-center/service-mesh/what-is-a-service-mesh

[4] https://www.youtube.com/watch?v=voAyroDb6xk&t=1317s