Service mesh essentially "appends" or adds a set of cross-cutting features to all your microservices in one go, without requiring you to modify the code of each service.
Sidecar Proxies: A service mesh typically uses "sidecar" proxies. These are small processes that run alongside each of your microservice instances. All network traffic to and from the service goes through this proxy.
Centralized Control Plane: The service mesh has a central control plane that manages these proxies. This control plane is responsible for configuring the proxies with the desired policies and features.
Features are applied consistently across all services, ensuring uniform behavior and simplifying management.
Developers don't have to implement these cross-cutting concerns in their service code, reducing complexity and allowing them to focus on business logic.
*****
A) This describes Container Network Interface (CNI) plugins, not a service mesh. CNIs handle basic pod networking.
C) This describes something like a global load balancer or a cloud provider's multi-cluster ingress controller. While related to networking, it's not the core function of a service mesh.
D) While some CNIs do implement network policies, the description is still about the CNI itself, not a service mesh. Network policies control pod-to-pod communication at the network layer (layers 3/4), whereas a service mesh operates at the application layer (layer 7).