Background
As organizations embrace micro-services based architecture, they run into challenges in terms of authentication and authorization, traffic routing between various services or versions, load balancing and encryption.
Kubernetes Security Hardening Guide published by CISA recommends encryption of service-to-service communication and weaving this into each and every service become nigh impossible at the scale.
Introduction To Service Mesh¶
A service mesh typically implements a sidecar design pattern (layer 7 proxies) through which it controls all traffic movements, both east-west and north-south. It solves a host of problems faced by cloud-native applications using micro-services and containers in the areas of network visibility and observability, security, traffic routing and load balancing, deployment strategies, fault tolerance and testing.
Typical Requirements¶
Platform Teams¶
Service mesh provide a good way to scale and manage organization's security controls and traffic management requirements for applications. Some of the typical requirements of platform teams that service mesh addresses are :
- Visibility into network traffic across clusters, namespaces and ability to implement circuit breakers in case of faulty instances
- Ensure secure communication by encrypting inter-service traffic via mTLS
- Ability to maintain high QoS during deployments and system upgrades
- Authenticate and authorize service communication via CA
Application teams¶
Service mesh also addresses requirements of application teams, some of them being:
- Ability to quickly debug applications with real-time visibility into traffic flows, latency and errors
- Ability to throttle traffic to and from service, allow/deny access to specific micro-services
- Ability to manage deployments via blue-green/canary strategies
- Data retention of traffic flows for monitoring state of application and forensic purposes