- Title: [[Istio and Service Mesh Simply Explained]] - Type: #source/video - Author: - Reference: https://www.youtube.com/watch?v=16fgzklcF7Y - Published at: - Reviewed at: [[2021-07-10]] - Links: [[kubernetes]] [[Distributed Systems]] [[Service Mesh]] [[Istio]] [[Kubernetes – Services]] --- ## Why Service Meshes In a [[Service Oriented Architecture]] every service must somehow take part in common baseline activities like [[service discovery]], traffic routing, traffic splitting during gradual service roll-out, [[authentication]], enforcing which services are authorized to talk to each other, request retry logic, [[Distributed Tracing]], [[Metrics]] and [[Monitoring]]. A [[Service Mesh]] is a [[Micro Service]] system paradigm that tries to tackle the common additional challenges of migrating from a single monolith to a [[Service Oriented Architecture]]. ## Istio [[Istio]] is an implementation of a [[Service Mesh]] that provides many of these common service facilities via an [[Envoy proxy]] [[sidecar container]]. Services don't need to do anything special, the [[Istio]] control plain injects and configures an [[Envoy proxy]] container into the relevant service [[kuberenetes - pods|pods]]. ^[While [[Istio]] provides functionality that's not currently part of core [[Kubernetes]], Tim Hockin is on record saying that he believes kubernetes *is* a service mesh and describes possible future directions (and why networking is so hard) in [Kubernetes Networking Intro and Deep-Dive - Bowei Du & Tim Hockin, Google - YouTube](https://www.youtube.com/watch?v=tq9ng_Nz9j8)] Configuration is handled by [[Istiod]] and exposed as [[Kubernetes Custom Resource Definitions | Kubernetes CRDs]] configured as [[YAML]]. ^[[[Istiod]] is now a single component but used to be split up as *Pilot (config discovery)*, *Citadel (certs)*, and *Gallery (configuration)*] - **Virtual Service** how to route traffic to a destination (service) - **Destination Rule** what happens to traffic destined for that destination The [[Istiod]] component makes up the [[Istio]] control plane while the [[Istio]] managed [[Enoy proxy]] containers make up the "data plane", is is not directly managed or configured by the end-user. ![[Istio configuration.png]] ### Dynamic service discovery [[Istiod]] serves as a dynamic service registry that's updated as traffic routing configuration is updated. Service discovery is implemented by pushing the config out to the individual [[Envoy proxy]] [[sidecar container | sidecar containers]]. When a new service is deployed, it's automatically registered in Istio's service registry. ### Certificate authority [[Istiod]] serves as a [[Certificate Authority]] generating [[TLS]] certs for each microservice to allow [[Mutual TLS]] for service-to-service communication. ### Metrics and tracing [[Istiod]] gathers telemetry from each envoy proxy and can be configured to pass it on to an appropriate service (e.g. [[Prometheus]] or [[Grafana]]) ### Ingress Gateway Acts as an entry-point for traffic into you cluster and routes traffic to the appropriate destination. You can think of this as an alternative to the [[Kubernetes Nginx Ingress Controller]]. [[Istio Ingress Gateway]] runs as a [[Kubernetes Pod | Pod]] in your cluster that you define using a `Gateway` [[Kubernetes Custom Resource Definitions|CRD]].