My understanding of containers is that they should be considered to be short-lived. In addition, we can scale containers (and if using a container orchestrator like k8s, via pods) by creating additional instances on one or more machines.
In order to allow for the ephemeral nature of containers, as well as to allow users to access an application from only one address (say, www.myapp.com), we must abstract away the container. From now on, I'm going to assume we're using k8s as the container orchestrator and speak only of pods. In k8s, we do this by using
Services to expose pods (either to other pods which comprise the application, or directly to users).
Services allow us to load balance and allow for deployment scenarios such as blue/green and zero-downtime deployments while providing a consistent and abstract interface from which to access the underlying pods.
With this in mind, I have a question about the
NetworkPolicy resource in k8s. When creating a
podSelector is used to determine to which pod(s) a network policy applies. However, since a
Service must be created in order to expose a pod, why is it, then, that a
NetworkPolicy uses a
podSelector instead of a "
serviceSelector"? Wouldn't the concept of a "
serviceSelector" be more general/abstract, and better reflect to what the policy is really allowing access? Is there a reason I'm unaware of for why network policies are "applied" to pods versus services? (Not to say that you would never want a
NetworkPolicy to apply directly to a pod, but, generally speaking, most times we apply them to pods which are exposed by a
Service—or maybe I'm totally off base here?)