As introduced above, Istio comprises a control plane and a data plane. The data plane is a set of proxies. These proxies intercept and control the network communication in your mesh.
In an Istio service mesh, several proxies are used to gate traffic into your cluster (ingress), between services (service proxy), and out of your cluster (egress). The service proxies are typically deployed as sidecar containers next to each service. Together, they are bundled into a single pod. Service-to-Service communication is technically proxy-to-proxy communication.
Istio uses an ingress gateway for gating traffic into your cluster. The ingress gateway is a dedicated proxy that is deployed in the istio-system
namespace.
For gating traffic out of your service mesh, you can either do it directly from the sidecar proxy or use an egress gateway. The egress gateway can also be used to apply policies to the traffic leaving your service mesh. Istio uses the Envoy proxy as a service proxy.
One crucial point is that Istio installs its API in Kubernetes as CRDs (Custom Resource Definitions). You can use Kubernetes native tools like kubectl
to manage Istio resources.