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.
In Istio, configure a single service mesh to span any number of clusters, or can configure a single mesh to include multiple clusters
Envoy Proxy:
Processes
the inbound/outbound traffic from inter-service and service-to-external-service
transparently. Istio components that interact with data plane traffic. Envoy proxies are deployed as sidecars to
services. It will have Service entry (fully qualified name)
Some
of the Istio features and tasks enabled by Envoy proxies include:
- Traffic
control features: enforce fine-grained traffic control with rich routing
rules for HTTP, gRPC, WebSocket, and TCP traffic.
- Network
resiliency features: setup retries, failovers, circuit breakers, and fault
injection.
- Security and
authentication features: enforce security policies and enforce access
control and rate limiting defined through the configuration API.
- Pluggable extensions model based on Web-Assembly that allows for custom policy enforcement and telemetry generation for mesh traffic
Istiod:
Istiod
provides service discovery, configuration and certificate management.
Istiod converts high level routing rules that control traffic behavior into
Envoy-specific configurations, and propagates them to the sidecars at runtime
- Pilot: Pilot provides service discovery for the Envoy sidecars, traffic management capabilities for intelligent routing (e.g., A/B tests, canary deployments, etc.), and resiliency (timeouts, retries, circuit breakers, etc.)
- Citadel:
Citadel enables strong service-to-service and end-user authentication
with built-in identity and credential management. It provides encryption
of traffic between Envoy Sidecar Proxies using mutual TLS
- Galley: Galley is Istio’s configuration validation, ingestion, processing and distribution component. It is responsible for insulating the rest of the Istio components from the details of obtaining user configuration from the underlying platform (e.g. Kubernetes).
Virtual
services route
traffic to a given destination and use destination rules to
configure what happens to traffic for that destination.
Ingress gateway configuration lets HTTP traffic from Istio ingress gateway into the mesh on port 80. To specify routing and for the gateway to work as intended, we also bind the gateway to a virtual service.
setup Istio service mesh in AWS EKS
Prerequisites:
·
kubectl
v1.18.0
·
helm v3.2.1
·
Istio 1.8.2
·
terraform
v0.12.30
·
aws-iam-authenticator
· Programming access to AWS account.
Complete view for
Istio:
· Istio Gateway - connect outside to Service Mesh clusters
· Ingress Gateway - request coming in / request connecting to Service mesh
- It is Envoy proxies, running on separate POD as Istio proxy container, it runs only Istio Envoy Proxy nothing else on this container
§ Create Virtual Service§ Create Destination Rule§ Attach routing rules using virtual service and Destination Rule to Envoy proxies
- Egress Gateway - Connecting from Mesh to outside
- It is Envoy proxies, running on separate POD as Istio proxy container, it runs only Istio Envoy Proxy nothing else on this container
§ Create Virtual Service
§ Create Destination Rule
§ Attach routing rules using virtual service and Destination Rule to Envoy proxies
· Deployment for Ingress Gateway:
- Running Envoy Proxies POD
- Service for Ingress Gateway to connect to envoy Proxy
- Service Object (Gateway
Object)
to enable Ingress Gateway to Receive Traffic from outside
- Virtual Service to link routing
services to routing rules to Ingress Gateway (Istio Proxy)
- Gateways object will host details
which will allow host / external world connect to the application and
filters other requests.
- Ingress Gateway Service come with Istio
installation
- There are two types of
virtual service, first one at ingress gateway layer and other one is inside
the service mesh.
- Virtual Service enable further routing
using "gateway",
this "gateway" allow request to enter into Mesh and forward to
Ingress Gateway/Proxy.
- Other Virtual service will allow inter
service communications and will configure on each POD with Istio Service
Mesh
- Launch k8s cluster in AWS EKS using terraform. deploy EKS cluster. prepare namespaces to Istio service mesh. deploy each application to own namespace.
- Kiali is an observability console for Istio with service mesh configuration and validation capabilities
- K8, AWS ALB WITH ISTIO INGRESSGATEWAY:
All traffic through the IngressGateway, we can route traffic differently depending on hostnames, most easily by using prefixes, by using Virtual Services.
