<p>Istio's deployment requirements state that a <a href="https://istio.io/docs/ops/deployment/requirements/" rel="nofollow noreferrer">Pod must belong to at least one Kubernetes Service</a> in order to form part of an Istio mesh. One of the reasons for this as I understand it is to create an entry to refer to the Pod (or group of Pods) in configuration rules (e.g. <code>&lt;serviceName&gt;.&lt;namespace&gt;.svc.cluster.local</code>).</p>

<p>Are there any other reasons? </p>

<p>Many of Istio's features (policy enforcement, distributed tracing, cross-service metrics) depend on knowing what service a request is coming <em>from</em>.  Ordinarily you only need to create Kubernetes services to route inbound requests to specific pods, but Istio uses them more generally to associate pods with abstract "services".</p>

<p>Say pod A is calling pod B.  Even in plain Kubernetes you need a service for B, and the request from A would target the service rather than the pod directly.  If you set up, for example, <a href="https://istio.io/docs/concepts/observability/#metrics" rel="nofollow noreferrer">metrics</a> in Istio (maybe using its built-in Prometheus), then Istio also tries to look up a service for A.  If it finds it then you'll see metrics like <code>istio_requests_total(source_service="A", destination_service="B")</code>.  If it doesn't the source will just show up as "unknown".</p>
