1

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 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?)

Improve this question

1 Answer 1

Reset to default
1

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 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.

Improve this answer
3
  • 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
    Commented Mar 11, 2021 at 0:53
  • 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).
    – Jonas
    Commented Mar 11, 2021 at 6:10
  • 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
    Commented Mar 13, 2021 at 2:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.