GCP Istio and the service mesh - ghdrako/doc_snipets GitHub Wiki
A service mesh is an infrastructure layer in a microservices architecture that controls the communication between services. It is possible to create a mesh of services within a microservices architecture that not only runs in a Kubernetes cluster, but it is also possible to create a single service mesh that spans multiple clusters, or even non-microservice services running on virtual machines. A service mesh manages all the ingress, or inbound traffic, and egress, or outbound traffic for each microservice.
There are three approaches to create a service mesh:
- Sidecar Proxy: in a microservices architecture where a proxy is connected to each microservice, with the same life cycle as the microservice itself, but executes as a separate process.
- Proxyless: in a microservices architecture where the microservice can send the telemetry directly to the control plane by using gRPC, a remote procedure call (RPC) system developed by Google.
- Proxy inside a VM: an L7 proxy runs inside VMs as a process or an agent which can be added to the service mesh as if it were a sidecar proxy.
ASM - Anthos Service Mesh To monitor in real time the telemetry of all inbound and outbound communications between the microservices of the various service mesh networks, ASM uses two approaches:
- Anthos Service Mesh can use the sidecar proxy approach, using Envoy3 proxies, an open source service proxy attached on each pod to get the real time telemetry;
- Anthos Service Mesh can use a proxyless approach using Google Cloud Traffic Director4 that is able to use gRPC, with xDS API5, the same technology used by Envoy to communicate with the control plane.
A single service mesh can have services that both use the standard Istio sidecar and the proxyless approach. This allows you to use the correct approach for different applications, including gRPC using a proxyless approach, sidecars for services that do not use gRPC and sidecars for services that use gRPC.
One of the most well-known and adopted solutions for microservice networking is Istio. Istio lets you easily interconnect microservices within a Kubernetes cluster in a sort of overlay network called a service mesh.
Istio has the following features
- Traffic management: You can decide how traffic and API calls can be routed across your service mesh. You can easily implement important fault-handling properties in your service mesh, such as circuit breakers, timeouts, and retries. Additionally, you can implement several application deployment testing strategies, such as A/B testing, canary, and so on.
- Security: Microservice applications can run anywhere. It is fundamental to implement a zero-trust security approach to ensure safe communication. Therefore, Istio manages all aspects of security, from traffic encryption to mutual microservice authentications via digital certificates and auditing
- Observability: Monitoring and logging activities are crucial in modern applications, especially those built as microservices. Istio generates service metrics such as latency, error, traffic, and saturation (the golden signals) to monitor application performance. It also generates distributed traces to monitor call flows within a service mesh. Istio generates access logs as well for auditing purposes.
To achieve all this, Istio relies on the Envoy proxies that are deployed along with your application microservices. Indeed, all traffic leaving and entering your mesh is proxied by the Envoys that are actually implementing your application data plane networking. On the other hand, the control plane of your service mesh is implemented by istiod, a daemon running in your Kubernetes cluster that is responsible for the service mesh governance. istiod is composed of three elements, Pilot, Citadel, and Galley.
More specifically, these functions are implemented by the Pilot, Citadel, and Galley respectively components, which have been consolidated in istiod in the latest versions.
The data plane is implemented by the Envoy proxies that are running as sidecar containers inside the pods where the services live. Envoys handle all the traffic coming from outside the mesh, from the service itself or another proxy within the service mesh. All traffic within a service mesh is encrypted and authenticated using mutual Transport Layer Security (mTLS) technology, which guarantees strong security. Istiod provides certificates to Envoys as they appear in the service mesh and acts as a certification authority for certificate validation. Moreover, istiod injects authorization policies to Envoys in order to authorize services to make calls to other services, thus securing the service mesh further.
Istio Traffic Management
Istio provides powerful traffic management that allows users to control ingress and egress traffic. This control is not limited to simply routing traffic to a specific service, it also provides the ability to split traffic between different versions and simulate failures and timeouts in applications.
| Feature | Description |
|---|---|
| Ingress | Controls the ingress traffic for the service mesh, to expose a service outside the service mesh over TLS or mTLS using the Istio gateway. In the chapter, Hybrid Applications in Anthos: The Edge and Beyond, we will deep dive into Ingress for Anthos. |
| Egress | Controls the egress traffic from the service mesh, route traffic to an external system, perform TLS for outbound traffic, configure the outbound gateway to use an HTTPS proxy. |
| Request routing and traffic splitting: | Dynamically route the traffic to multiple versions of the microservice or migrate traffic from one version to another version gradually and in a controlled way. |
| Fault Injection | Provides configurable HTTP delays and fault injection, allowing developers to discover problems before they would occur in production. |
Istio Security
The first component that Istio provides to increase your application security is the handling of certificate management, including an Istio's certificate authority (CA) with an existing root certificate. In cryptography, a certificate authority9 or certification authority is an entity that issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key - proving the identity of the certificate owner. A CA acts as a trusted third party—trusted both by the owner of the certificate and by the party relying upon the certificate.