ExamFinch.com My Study

Study guide

3.3 Namespaces, Labels, Selectors & Annotations

Practice this exam

Kubernetes and Cloud Native Associate KCNA

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & Exam Overview

1.1 About the KCNA Exam & Certification Path 1.2 How to Use This Study Guide

2 Chapter 2: Kubernetes Fundamentals - Cluster Architecture & the API

2.1 Kubernetes Architecture & Control Plane Components 2.2 Worker Node Architecture & Node Components 2.3 Kubernetes API, Declarative Management & kubectl 2.4 Kubernetes Releases, API Versioning & Deprecation Policy

3 Chapter 3: Kubernetes Fundamentals - Workloads & Configuration

3.1 Core Workload Objects (Pods, Deployments & ReplicaSets) 3.2 Advanced Controllers (StatefulSets, DaemonSets, Jobs & CronJobs) 3.3 Namespaces, Labels, Selectors & Annotations 3.4 ConfigMaps, Secrets & Application Configuration 3.5 Pod & Container Lifecycle, Restart Policies & Graceful Termination

4 Chapter 4: Kubernetes Fundamentals - Scheduling & Autoscaling

4.1 Scheduling, Resource Management & Node Selection 4.2 Advanced Scheduling: Affinity, Topology Spread, Priority & Disruption Budgets 4.3 Autoscaling Workloads & Clusters (HPA, VPA, Cluster Autoscaler, KEDA)

5 Chapter 5: Kubernetes Fundamentals - Cluster Administration & Extensibility

5.1 Kubernetes Distributions, Installation Tools & Managed Services 5.2 Cluster Administration: Node Maintenance, Upgrades & etcd Backup 5.3 Extending Kubernetes: CRDs, Operators & the Controller Pattern

6 Chapter 6: Kubernetes Fundamentals - Containerization

6.1 Container Fundamentals, Runtimes & Registries 6.2 Container Image Anatomy: Layers, Tags, Digests & Pull Policy

7 Chapter 7: Container Orchestration - Networking & Service Discovery

7.1 Kubernetes Networking, Services & Ingress 7.2 Cluster DNS & Service Discovery with CoreDNS 7.3 NetworkPolicies, Zero-Trust Segmentation & the Gateway API

8 Chapter 8: Container Orchestration - Storage

8.1 Storage Concepts (PVs, PVCs, StorageClasses & CSI) 8.2 Volume Types, Snapshots & Stateful Storage Operations

9 Chapter 9: Container Orchestration - Security

9.1 Kubernetes Security & Access Control (RBAC & ServiceAccounts) 9.2 The 4C's of Cloud Native Security & Supply-Chain Trust 9.3 Service Mesh, mTLS & Zero-Trust Service Identity

10 Chapter 10: Container Orchestration - Troubleshooting

10.1 Container Troubleshooting & Health Probes 10.2 Cluster & Node-Level Troubleshooting

11 Chapter 11: Cloud Native Application Delivery

11.1 Cloud Native CI/CD Pipelines & Build Tooling 11.2 GitOps & Package Management (Helm, Kustomize, Argo CD & Flux) 11.3 Deployment Strategies & Release Management 11.4 Progressive Delivery Automation: Argo Rollouts, Flagger & Feature Flags 11.5 Application Debugging & Developer Workflows in Kubernetes 11.6 Platform Engineering & Developer Self-Service

12 Chapter 12: Cloud Native Architecture - Observability & Principles

12.1 Cloud Native Observability (Logging, Metrics & Tracing) 12.2 Cloud Native Principles & Architecture Patterns 12.3 Serverless, FaaS & Event-Driven Architecture

13 Chapter 13: Cloud Native Architecture - CNCF Ecosystem & Community

13.1 The CNCF Landscape, Governance & Project Lifecycle 13.2 Cloud Native Community, Collaboration & Contribution

3.3 Namespaces, Labels, Selectors & Annotations

Key Takeaways Explain This Topic AI

Namespaces provide virtual cluster isolation within a single physical cluster, isolating resources, names, and access control boundaries across multi-tenant environments.

Kubernetes initializes four standard default namespaces: default, kube-system, kube-public, and kube-node-lease.

ResourceQuota objects enforce aggregate resource consumption limits per namespace, while LimitRange objects set container-level minimum, maximum, and default request/limit constraints.

Labels are identifying key-value pairs attached to objects, enabling loose coupling and dynamic grouping via equality-based and set-based label selectors.

Annotations store non-identifying metadata (such as build information, commit hashes, or ingress controller configuration) that cannot be queried via label selectors.

Last updated: August 2026

3.3 Namespaces, Labels, Selectors & Annotations

As Kubernetes clusters expand to accommodate dozens of applications and multi-tenant engineering teams, managing resource organization, isolation, and metadata becomes vital. Kubernetes satisfies these management challenges using Namespaces , ResourceQuotas , LimitRanges , Labels , Selectors , and Annotations .

1. Virtual Isolation with Namespaces

A Namespace is a logical abstraction that divides a single physical Kubernetes cluster into multiple virtual clusters. Namespaces provide scoped naming boundaries, resource quota boundaries, and access control scopes (via Role-Based Access Control / RBAC).

Default Kubernetes Namespaces

Every fresh Kubernetes cluster starts with four standard system namespaces:

default : The fallback namespace for any object created without an explicit .metadata.namespace specification.

kube-system : The system namespace reserved for Kubernetes control plane components, system add-ons, CoreDNS, and ingress controllers.

kube-public : A readable namespace created automatically for resources that should be publicly discoverable across the whole cluster (e.g., cluster-info ConfigMap).

kube-node-lease : A specialized namespace holding Lease objects for worker nodes. Node heartbeats are updated here to reduce control plane traffic overhead.

Note

Namespaces scope cluster names (you cannot have two Pods named frontend in the default namespace, but you can have one frontend Pod in development and another frontend Pod in production ). However, Namespaces do not provide network isolation by default; NetworkPolicies must be configured to block cross-namespace traffic.

2. Namespace Resource Management: ResourceQuota & LimitRange

To prevent one tenant or buggy microservice from exhausting all cluster resources in a shared cluster, administrators apply resource controls at the namespace level.

ResourceQuota

A ResourceQuota enforces aggregate resource consumption caps across an entire namespace. If a namespace reaches its quota, the API server rejects any further creation of objects that would exceed the defined caps.

ResourceQuotas can restrict:

Compute Resources : Total CPU requests/limits (e.g., requests.cpu: "10" , limits.cpu: "20" ) and total memory requests/limits.

Storage Resources : Total PersistentVolumeClaim storage requests (e.g., requests.storage: 500Gi ).

Object Count Limits : Maximum total count of Pods, Services, ConfigMaps, Secrets, or Deployments.

LimitRange

While a ResourceQuota sets namespace-wide aggregate limits, a LimitRange enforces resource constraints at the individual Pod or container level within a namespace.

A LimitRange can:

Enforce minimum and maximum CPU and memory requests/limits for individual containers.

Define default resource requests and limits automatically injected into any container submitted without resource specifications. apiVersion: v1

kind: ResourceQuota

metadata:

  • name: dev-quota
  • namespace: development

spec:

hard:

  • requests.cpu: "4"
  • requests.memory: 8Gi
  • limits.cpu: "8"
  • limits.memory: 16Gi
  • pods: "10"
  • --
  • apiVersion: v1
  • kind: LimitRange

metadata:

  • name: dev-limit-range
  • namespace: development

spec:

limits:

- default:

  • cpu: 500m
  • memory: 512Mi

defaultRequest:

  • cpu: 250m
  • memory: 256Mi
  • type: Container
  • 3. Metadata Identification: Labels vs. Annotations

Kubernetes objects can be tagged with key-value metadata pairs. However, Kubernetes makes a fundamental architectural distinction between Labels and Annotations .

Labels and Label Selectors

Labels are identifying key-value pairs attached to API objects (such as Pods, Nodes, and Services). They are intended to specify identifying attributes of objects that are meaningful and relevant to users, without implying semantic changes to the core system.

Labels are queried using Label Selectors to group and bind resources dynamically. There are two types of selectors:

Equality-Based Selectors : Filter resources using = , == , or != operators.

Example: environment = production , tier != frontend

Set-Based Selectors : Filter resources using set operations ( in , notin , exists ).

Example: environment in (production, staging) , tier notin (legacy)

Labels power core Kubernetes operations:

Services use label selectors to route network traffic to matching Pod endpoints.

Deployments use label selectors to discover and manage ReplicaSet Pods.

kubectl CLI commands use selectors to target specific resources ( kubectl get pods -l env=prod ).

Annotations

Annotations are key-value pairs used to attach non-identifying, arbitrary metadata to objects. Unlike Labels, Annotations cannot be queried by label selectors and are not used by Kubernetes to identify or group objects.

Common annotation use cases include:

Storing build info, git commit hashes, or release timestamps.

Ingress controller configuration directives (e.g., nginx.ingress.kubernetes.io/rewrite-target: / ).

Storage provisioner options or container runtime parameters.

Pointer fields for external management and orchestration tools.

4. Metadata Feature Comparison Matrix

Attribute Labels Annotations Namespaces

Primary Purpose Resource identification & grouping Non-identifying metadata storage Virtual cluster resource isolation

Queryable via Selectors? Yes (Equality & Set selectors) No N/A (Scoped target)

Used by Kubernetes Core? Yes (Service routing, Deployments) Yes (Ingress, tool plugins) Yes (RBAC, Quotas, Object scope)

  • Example Key-Value app: payment-api build.info/commit: 8f3a12b namespace: staging apiVersion: v1
  • kind: Pod

metadata:

  • name: order-service
  • namespace: production

labels:

  • app.kubernetes.io/name: order-service
  • app.kubernetes.io/tier: backend
  • environment: production

annotations:

  • build.info/commit: "a1b2c3d4e5f6"
  • prometheus.io/scrape: "true"
  • prometheus.io/port: "8080"

spec:

containers:

  • name: app
  • image: order-service:v2.1.0