A service mesh is an infrastructure layer for secure, reliable, observable communication between microservices. It configures proxies that handle traffic on an application's behalf, so teams can add communication policies without changing application code. In Kubernetes, those proxies operate on top of the container network rather than replacing it. section 8.4.2
A proxy can take responsibility for several recurring communication needs:
- Validate a web token before forwarding an API request. section 8.4.2
- Retry a failed connection to another service before returning an error. section 8.4.2
- Encrypt traffic between proxies and provide service-specific traffic control and metrics. section 8.4.2
Proxy placement is a design choice. A dedicated proxy for each pod supports finer-grained policies, isolation, and observability. Sharing one proxy across a node or cluster reduces that granularity. A mesh control plane provides a standardized way to deploy and configure the proxies. section 8.4.2
Start with the networking requirement rather than the mesh. Kubernetes service-to-service networking can provide routing and load balancing; a service mesh is an option when routing requirements become more complex or circuit breaking is needed. This distinction matters when building a platform capability that development teams can use without taking ownership of every networking decision. section 2.3.5
Self-service application ingress
One platform pattern installs Istio, enables proxy injection for a namespace, and configures a platform-managed domain and gateway. An application's VirtualService then names its public host, selects that gateway, and routes requests to its Kubernetes Service. A functional check calls the HTTPS endpoint and examines the response. The routing configuration gives a team an application-facing entry point without requiring routing logic in the application. section 8.4.2
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: httpbin
namespace: default-mtls
spec:
hosts:
- "httpbin.$cluster_name.epetech.io" #1
gateways:
- istio-system/$cluster_name-epetech-io-gateway #2
http:
- route:
- destination:
host: httpbin.default-mtls.svc.cluster.local
port:
number: 80
The VirtualService listing makes the routing boundary concrete: a public host and gateway point to a Kubernetes Service destination. section 8.4.2
For an incremental rollout, choose the traffic behavior to standardize, decide whether its policy needs per-pod granularity, then test the configured route end to end. Keep installation, upgrades, and integration tests in the platform deployment pipeline so the capability remains operable as cluster configuration changes. section 8.4.2
