We have found a number of ways to secure our pods, but our network connections are still open. Any pod in the cluster can talk to any other pod in the same cluster. As a site reliability engineer, you will want to enforce both ingress and egress rules. As a developer, you don't want to be bothered by it as you won't have information on where your application will be deployed, as well as what is allowed and what is not. If only there was a way that we could run the applications as is, while still specifying network policies.

Enter service mesh—this is defined as the layer that controls service-to-service communication. Just as with microservices, service mesh implementation is not a free lunch. If you don't have hundreds of microservices running, you probably don't need a service mesh. If you decide that you really do need one, you will need to choose one first. There are four popular options, each with its own advantages:

• Linkerd (https://linkerd.io/)
• Envoy (https://www.envoyproxy.io/)
• Istio (https://istio.io/)
• Linkerd2, formerly Conduit (https://conduit.io/)

You should choose one service mesh based on your needs, and feel comfortable in the knowledge that, until you hit really high volumes, any one of these solutions will work for you.

We are going to try istio for no reason other than its high star rating, at the time of writing, on GitHub (over 15,000). This rating is far higher than any other project.