<p>Pods is the deployment unit in Kubernetes and it is also the unit that gets a single unique IP address within the cluster.</p>
<p>You can access Pods without going via a Service. A Service is mostly there to get a &quot;stable&quot; address for an application, where the traffic is then load balanced to any Pod representing the Service. Both Pods and Services gets a <a href="https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pods" rel="nofollow noreferrer">DNS name</a> in the cluster.</p>
<p>A Service has a selector to identify what Pods belong to the Service, but a Pod can receive traffic from multiple Services. In the same way a NetworkPolicy has a selector to select the Pods where it is applied.</p>
<p>Since a Pod is the smallest unit in Kubernetes, that gets its own unique network address it also makes sense to add the network security (e.g. Network Policies) at this level.</p>

CC BY-SA 4.0
2021-03-11T00:53:29.187Z
Yes, I know all of this, but Services also get an IP address (NodePort, ClusterIP, LoadBalancer, etc.). So, while pods could be ephemeral, services are typically "long-lasting" and "stable", and so would potentially be a better abstraction to which to apply network policies. Not saying you wouldn't _ever_ want a Network Policy to apply to one or more pods, just that generally, we abstract the application traffic to the level of services. Thanks for your answer.
fourpastmidnight
CC BY-SA 4.0
2021-03-11T06:10:11.047Z
but it is access to the pods that you want to protect. A Service is just a virtualIP for easier abstraction, but traffic goes to Pod and Pod can be accessed directly anyways (unless protected by NetworkPolicy).
Jonas
CC BY-SA 4.0
2021-03-13T02:54:55.540Z
I see your point. Thank you for answering the question and helping me better understand why Network Policies are applied to pods as opposed to services.
fourpastmidnight
CC BY-SA 4.0
2021-03-10T18:54:46.803Z
2021-03-10T18:54:46.803Z
Jonas
<p>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.</p>
<p>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, <a href="http://www.myapp.com" rel="nofollow noreferrer">www.myapp.com</a>), 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 <code>Service</code>s to expose pods (either to other pods which comprise the application, or directly to users). <code>Service</code>s 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.</p>
<p>With this in mind, I have a question about the <code>NetworkPolicy</code> resource in k8s. When creating a <code>NetworkPolicy</code>, a <code>podSelector</code> is used to determine to which pod(s) a network policy applies. However, since a <code>Service</code> must be created in order to expose a pod, why is it, then, that a <code>NetworkPolicy</code> uses a <code>podSelector</code> instead of a &quot;<code>serviceSelector</code>&quot;? Wouldn't the concept of a &quot;<code>serviceSelector</code>&quot; 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 &quot;applied&quot; to pods versus services? (Not to say that you would <em>never</em> want a <code>NetworkPolicy</code> to apply directly to a pod, but, generally speaking, most times we apply them to pods which are exposed by a <code>Service</code>—or maybe I'm totally off base here?)</p>

<kubernetes>
NetworkPolicy: Why are pod selectors used over "service selectors"?
fourpastmidnight
# NetworkPolicy: Why are pod selectors used over "service selectors"?

(Asked by: username_0 on 2021-03-07)

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](http://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 `Service`s to expose pods (either to other pods which comprise the application, or directly to users). `Service`s 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 `NetworkPolicy`, 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?)

**Tags:** kubernetes


---

## 1 answers

### Answer by username_1 on 2021-03-10. Score: 1 | Accepted answer

Pods is the deployment unit in Kubernetes and it is also the unit that gets a single unique IP address within the cluster.

You can access Pods without going via a Service. A Service is mostly there to get a "stable" address for an application, where the traffic is then load balanced to any Pod representing the Service. Both Pods and Services gets a [DNS name](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pods) in the cluster.

A Service has a selector to identify what Pods belong to the Service, but a Pod can receive traffic from multiple Services. In the same way a NetworkPolicy has a selector to select the Pods where it is applied.

Since a Pod is the smallest unit in Kubernetes, that gets its own unique network address it also makes sense to add the network security (e.g. Network Policies) at this level.

> **Comments:**
> **username_0**: Yes, I know all of this, but Services also get an IP address (NodePort, ClusterIP, LoadBalancer, etc.). So, while pods could be ephemeral, services are typically "long-lasting" and "stable", and so would potentially be a better abstraction to which to apply network policies. Not saying you wouldn't _ever_ want a Network Policy to apply to one or more pods, just that generally, we abstract the application traffic to the level of services. Thanks for your answer.  
> **username_1**: but it is access to the pods that you want to protect. A Service is just a virtualIP for easier abstraction, but traffic goes to Pod and Pod can be accessed directly anyways (unless protected by NetworkPolicy).  
> **username_0**: I see your point. Thank you for answering the question and helping me better understand why Network Policies are applied to pods as opposed to services.  

---

