Menu
I am looking for some good examples about structuring namespaces in Kubernetes clusters, and an appropriate way to label my pods for long term maintainability.
Can you recommend some resources, or examples from real world applications that follow some solid practices?
650
Namespaces are a way to organize clusters into virtual sub-clusters — they can be helpful when different teams or projects share a Kubernetes cluster. Any number of namespaces are supported within a cluster, each logically separated from others but with the ability to communicate with each other.
Labels can be used to select objects and to find collections of objects that satisfy certain conditions. In contrast, annotations are not used to identify and select objects. The metadata in an annotation can be small or large, structured or unstructured, and can include characters not permitted by labels.
Kubernetes labels are key-value pairs that can connect identifying metadata with Kubernetes objects. Kubernetes offers integrated support for using these labels to query objects and perform bulk operations on selected subsets.
To see which Kubernetes resources are and aren't in a namespace: The Kubernetes control plane sets an immutable label kubernetes.io/metadata.name on all namespaces, provided that the NamespaceDefaultLabelName feature gate is enabled. The value of the label is the namespace name.
You can visualize and manage Kubernetes objects with more tools than kubectl and the dashboard. A common set of labels allows tools to work interoperably, describing objects in a common manner that all tools can understand. In addition to supporting tooling, the recommended labels describe applications in a way that can be queried.
In addition to supporting tooling, the recommended labels describe applications in a way that can be queried. The metadata is organized around the concept of an application. Kubernetes is not a platform as a service (PaaS) and doesn't have or enforce a formal notion of an application. Instead, applications are informal and described with metadata.
The shared prefix ensures that shared labels do not interfere with custom user labels. In order to take full advantage of using these labels, they should be applied on every resource object. An application can be installed one or more times into a Kubernetes cluster and, in some cases, the same namespace.
Namespaces:
I recommend grouping resources by namespaces for "resources you can just delete altogether".
Most notably, Kubernetes Policy objects (like RBAC, PodSecurityPolicy, NetworkPolicy, ResourceQuota) are per-namespace. So "namespaces" are often for organizational/team boundary.
Labels:
app=paymentservice label for everything that empowers this app (Pods, Service, Secret)gitcommit=235ab3f
purpose=testing
team=payments
75
A good starting point is Ahmet Alp Balkan's resource "kubernetes-network-policy-recipes".
You can see examples of labels like one allowing traffic only to a port of an application:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: api-allow-5000
spec:
podSelector:
matchLabels:
app: apiserver
ingress:
- ports:
- port: 5000
from:
- podSelector:
matchLabels:
role: monitoring
That helps illustrating a good label policy, ie one which helps your use case (that is: what you are trying to do as a network policy)
43
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
