What Are Namespace, Annotation, and Label?(En)
Today, we will explain the three fundamental resource object types.
- Namespace
- Annotation
- Label
1. Namespace
Primarily responsible for isolating resource groups within the cluster.It’s important to note that object names within the same namespace must be unique.
Furthermore, cluster-level objects, such as storage classes, nodes, and PVs, do not possess isolation capabilities.
After Kubernetes is set up, it will have the following four default namespaces:
- default: The default namespace for objects that do not have a namespace specified.
- kube-system: Namespace for Kubernetes system components.
- kube-public: All clients can read the contents of this namespace. It primarily stores objects that are used at the cluster level.
- kube-node-lease: It contains objects that interact with each node, allowing kubelet to send heartbeats to ensure the control plane can detect node failures..
These default namespaces help organize and manage resources within the Kubernetes cluster.
we can modify the default namespace using the following method:
[master]# kubectl create ns test-ns
[master]# kubectl config set-context --current --namespace=test-ns
Context "kubernetes-admin@kubernetes" modified.
[master]# kubectl config view --minify | grep namespace:
namespace: test-nsBasically, the composition of a namespace includes:
- A collection of resources for a particular application or software.
- Resources specific to a particular user. After creating their own namespace, users can create various resources (e.g., PVCs) within the namespace that they will use.
- A group of resources required for a specific environment, such as separate namespaces for Development (Dev) and Testing (Test). However, the resource types used internally within these namespaces may be the same.
Note: If you want to create additional sub-namespaces within a namespace, you will need the Hierarchical Namespaces Controller (HNC), which will be explained separately later on.
2. Annotation
In simple terms, it’s comment.
User defined additional information used for external tooling and querying. It can be used to describe the resource.
(1) Attaching metadata to an object
Both labels and annotations can be used to attach metadata to Kubernetes objects. However, annotations are not intended for identifying and selecting objects for use. Annotation can be either structured or unstructured, allow the use of characters that are not allowed in labels.
"metadata": {
"annotations": {
"key1" : "value1",
"key2" : "value2"
}
}(2) The difference between labels and annotations in Kubernetes is as follows:
3. Label & Selector
Labels are indeed based on the concept of key/value pairs and are used to specify specific attributes of objects. They are typically assigned to objects when those objects are created.
Every object can define labels, but each key name must be unique within that specific object.
apiVersion: v1
kind: Pod
metadata:
name: label-demo
labels:
environment: production
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80(1) Labels can be used in various places within Kubernetes, including:
- Identifying objects in a way that is understandable to users
- Objects can be grouped together by defining labels
- This makes it easier to perform actions on a group of objects
- Tracking, configuring, and managing costs in Kubernetes.
(2) Label selector
Currently, there are two types of selectors supported: equality-based and set-based. A label selector can be composed of multiple requirements separated by commas.
- equality-based
※ Syntax:
environment = production
tier != frontend
※ Example:
# kubectl get pods -l environment=production,tier=frontend- set-based
※ Syntax:
environment in (production, qa)
tier notin (frontend, backend)
partition
!partition
※ Example:
# kubectl get pods -l 'environment in (production),tier in (frontend)'
# kubectl get pods -l 'environment in (production, qa)'
# kubectl get pods -l 'environment,environment notin (frontend)'Here is an example illustrating how to write a label selector in a YAML file：
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: label-test
spec:
replicas: 2
selector:
matchLabels:
app: labelapp <<< selector
template:
metadata:
labels:
app: labelapp <<< label
spec:
containers:
- name: label-app
image: github/labelapp
imagePullPolicy: Always
ports:
- containerPort: 8080
resources:
limits:
cpu: "0.2"
memory: 20Mi
---
apiVersion: apps/v1
kind: Service
metadata:
name: label-svc
spec:
ports:
- protocol: TCP
port: 8080
targetPort: 8080
type: LoadBalancer
selector:
app: labelapp <<< selector
The official recommendation is to create relevant labels for application services:
# This is an excerpt
apiVersion: apps/v1
kind: StatefulSet
metadata:
labels:
app.kubernetes.io/name: mysql
app.kubernetes.io/instance: mysql-abcxzy
app.kubernetes.io/version: "5.7.21"
app.kubernetes.io/component: database
app.kubernetes.io/part-of: wordpress
app.kubernetes.io/managed-by: helm4. Here are some recommended usage practices
- Optimizing the visibility of Kubernetes objects by adding labels and annotations.
- Maintaining a consistent labeling convention helps prevent confusion, duplication, and unnecessary rework.
- Keeping labels and annotations concise can reduce complexity, especially for labels since Kubernetes uses them in its internal operations.
- It’s advisable to start using the officially recommended conventions for labels and annotations as early as possible.
- Building consensus by adhering to the correct character set and syntax for each type.
- Avoid writing confidential information in labels or annotations.
- When designing backups, remember to utilize labels and annotations to plan your strategies effectively.
- Organizing resources in a meaningful way allows teams to more easily detect and troubleshoot issues in bulk.
