Deployment Considerations of Service Mesh
Kubernetes, a de-facto software and toolset for orchestration and management at the Edge [1] has the ability to customize its functionality similar to Lego blocks and has enabled application developers to develop and deploy edge services using microservices approach with various Container Network Interfaces (CNI) like Calico, OVS-DPDK, etc and cloud native deployment models such as Continuous Integration/Continuous Deployment (CI/CD). Rich set of service mesh types have evolved to be able to integrate with Kubernetes, such as Isito/Envoy, LinkerD, Consul, etc.
Microservice deployments could use wide variety of deployment scenarios within a Kubernetes environment. Few of the service mesh based microservice interaction patterns that heavily impact the performance of the services communication while utilizing Kubernetes pod and Kubernetes services constructs, as indicated in Figure 1:
- Pod to pod communication
- Pod to service communication
- Ingress controller to pod and vice-versa.
- Load balancer to pod and vice-versa.
- Pod to Egress controller
- API gateway to service and vice-versa
