Labels for organizing objects.
Different teams can deploy their objects in separate namespaces. Each team gets access to one or more namespaces. Objects in different namespaces can use the sama names.
Not all object types are namespaced. E.g, Nodes, PersistentVolumes, StorageClasses, Namespaces are not namespaced. They are cluster-scoped.
Deleting a namespace automatically deletes all objects in it.
Each K8s cluster contains a few predefined namespaces. Those prefixed with
kube- are K8s system namespaces.
Other than allowing names of objects to be the same in different namespaces, there is no isolation:
- pods from different namespaces can run on the same node
- by default there is no network isolation - a pod from one ns can talk to pods
from another ns. Isolation can be configured using a
Namespaces should not be used to separate production workloads from development environments. It’s better to use separate clusters.
Labels are key-value pairs that can be added to any object to decorate it with
some meta data. Labels are placed in
metadata.labels section of YAML.
K8s uses labels on its own. For example Node objects have
labels indicating the CPU architecture of a node. K8s does not usually add
labels to objects that users create.
Labels have various limitations in length, and accepted characters of keys and values.
Objects can be queried by the values of their labels. Operators:
k get pods -l app=webapp
k get pods -l app=webapp,rel=canary
k get pods -l 'app in (quiz, quote)'
k delete pod -l rel=canary
Some objects accept label selections. For example in the YAML of a pod, under
spec.nodeSelector we can specify labels and their values that we required on a
node for the pod to run on it. It supports only the
= operator. Other objects
do support other operators.
Similarly, a PersistentVolumeClaim may define required labels of the
PersistentVolume that it will attach to. The YAML path is
Similarly there are also field selectors. They can be used with kubectl (or K8s API) to filter objects based on some object properties. Not all properties are supported with selectors. For example:
k get pods --field-selector spec.nodeName=kind-worker-2
kubectl get po --field-selector status.phase!=Running --all-namespaces
They are similar to labels. They have less limitations regarding length and
content (e.g. annotation can have 256KB and it can contain any character). They
can’t be used to filter objects. They are placed in
Various controllers add annotations to objects if the information can’t be stored in other fields.
Sometimes, before changing structure of objects, annotations are used as a testing ground for K8s. After some time, annotation gets deprecated, and a new field is introduced in an object. After another few releases annotation support is removed entirely.
Annotations are a good place to store various information about the object: description, author, git hash, build timestamp, etc. For example, Azure pipeline adds various information to the annotations of the objects it deploys.