Services meshes solves some of the common issues occurs during the scalability and operations of highly scalable distributed systems often involves hundred or thousand of micro services. There are numerous patterns used by service mesh solutions, mostly Sidecar, Controller, Fail Fast, Canary and Blue Greens. Isto is popular open source service mesh solution for Kubernetes which is robust and used in many production environments. Let’s discuss briefly some major functions a service mesh addresses.
- Security
- Connection
- Observability
- Controlling
- Authentication & Authroization
Security is utmost important as micro services natively communicate each other to achieve a specific task. For example as shown in the blog feature image, micro services are communication to each other which can be secure let’s say using Mutual TLS (mTLS), which is a standard security solution in service meshes. mTLS provides tight security where both ends need to authentication each other preventing man in the middle attack. Please refer to our mTLS blog to understand more on Mutual TLS.
Meshes provide connection configuration between the micro services to enforce policies and rules on traffic management between micro service. For example defining connection retries in case for connection failure and configuring circuit breakers to stop cascading effects in case of failure in the network.
Observability provides end to end information on the network in order to monitor and trace what’s going on in the network and to mitigate and failure as well as to optimise specific micro services.
Service Meshes also provides the controllability to control which service can communicate to which other services in the network. It also provides us with the policies and rules enforcement which needed to apply at different level. For example for new feature deployment, the policy would enforce to route 20% traffic to new featured micro service and 80% traffic would go to the existing production micro service.
Istio and Configuration Components
Istio implements the Sidecar pattern to inject a sidecar proxy container in the same service pod. Proxy intercept every request it receive in the service, apply any policies and rules and communicate with the destination service proxy which in turn serve the request to destination service.
For configuration, you can configure YAML file which can be added to gallery components. Galleries then pass these configuration to Pilot component which validate and convert the configurations and apply it to proxies. Additional policies are handled by Policy component which is used to enforce policies at different level of network. Policy component then applies these policies to proxies. Istio provides telemetry components to collect information about what is going on in the proxies and network. This information is crucial to optimise micro services as well as for fault fixations. Citadel provides the strong identity to each micro service via proxies and also responsible for providing CA certificates to the proxies.
We need to configure three main resource in order Istio to work. In order to communicate with services and providing input output HTTP and TCP connections, it needs Gateway service which also act as a load balancer to direct traffic to different services within the cluster. In order to direct this service we need a virtual service which can be bound either to Gateway service which direct the traffic to different services or it can be bound to service to control the traffic direction from this service to other services in the network based on some policies and rules to provide granular level control. In order to apply rules on top of policies such as TLS settings and circuit breakers which is done with destination rules in Istio.
