Kubernetes / Basic: objects and execution boundaries / Lesson 2

Objects, labels, and namespaces

Read object identity and desired-state fields, use selectors deliberately, and understand the limits of namespace separation.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain the model, assumptions, and boundaries of objects, labels, and namespaces.
Interpret both examples and distinguish declared intent from established evidence.
Diagnose the listed failures and justify the worked recovery decisions without executing cluster operations.

Read the object envelope

A Kubernetes object identifies its API version and kind, metadata, and kind-specific fields. Many resources use spec for desired configuration and status for observed information, but fields and semantics belong to the resource schema. Name and namespace form part of an object’s address; UID distinguishes a particular lifetime even if the name is reused. resourceVersion supports concurrency semantics and is not a business revision number. The first example is a complete illustrative ConfigMap object using v1. It is never submitted to a server and does not establish that a target namespace exists.

yaml Illustrative v1 ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: booking-display
  namespace: training
  labels:
    app: booking
data:
  DISPLAY_MODE: compact

metadata identifies a namespaced object; data holds nonsecret strings. Successful YAML parsing does not create the namespace or authorize access.

Treat names and scopes deliberately

Namespaced resources belong to a namespace; cluster-scoped resources do not. A Namespace, Node, or ClusterRole cannot be made local merely by adding metadata.namespace. Choose the correct scope for each API and identify owner references where relevant. Deleting and recreating an object under the same name changes its lifetime and can affect dependents. Keep a stable application identity in labels while using the real UID for lifetime-sensitive evidence. Avoid assuming a filename or repository folder controls which namespace a manifest will affect; the submitted object and request context determine scope.

Use labels as selection contracts

Labels are structured identifying metadata used by selectors, not secret storage. A Service selecting app=booking can include every matching Pod in its namespace, regardless of which file created it. The second simulation shows exact matching against synthetic labels. Real selector syntax also supports set-based expressions where the relevant API permits them. An annotation stores nonidentifying metadata and is not interchangeable with a selector label. Review label changes like routing changes: an innocent rename can remove endpoints or include a different workload. Controllers may also restrict selector changes after creation.

python Harmless exact-label selection

selector = {"app": "booking", "tier": "api"}
pods = [{"name": "a", "labels": {"app": "booking", "tier": "api"}},
        {"name": "b", "labels": {"app": "booking", "tier": "worker"}}]
print([pod["name"] for pod in pods if all(pod["labels"].get(k) == v for k, v in selector.items())])

Expected output

['a']

Only synthetic Pod a matches both required labels. The calculation does not resolve real endpoints or model all Kubernetes selector operators.

Namespace is a scope, not complete isolation

Namespaces organize names, access rules, quotas, and policy attachment, but do not alone isolate network traffic, node kernels, credentials, or cluster-wide administrators. Multi-tenancy needs an explicit threat model plus authorization, admission, network, resource, and runtime controls. Some workloads require stronger separation than a shared cluster can provide. Do not place secrets in annotations simply because the namespace is called private. Decide who can read, mutate, and create workloads there, since workload creation can provide indirect access to mounted credentials or service identities. Verify the chosen isolation model rather than inferring it from naming.

Validate syntax and ownership separately

A YAML parser checks text structure, while API validation checks schema and admission applies policy. None alone proves that the object targets the intended environment or will behave correctly. Compare desired fields with their documented ownership and avoid multiple tools continuously overwriting the same field. Server-side apply tracks field managers, but conflicts still require a decision rather than a blind force. Keep illustrative records separate from deployable manifests, and review exact namespace, resource kind, labels, and references before any authorized change. No apply, delete, or discovery command is run by this lesson.

Common errors and fixes

A Service selects unintended Pods

Why it happens: A broad or reused label matches another workload.
How to fix it: Review the selector and intended label contract together.
Prevent it next time: Test inclusion and exclusion before label changes.

A namespace is treated as a security boundary

Why it happens: Organization was confused with enforced isolation.
How to fix it: Define and verify RBAC, policy, runtime, and tenant controls.
Prevent it next time: Review tenant threats and cluster-scoped authority.

Tools overwrite each other’s fields

Why it happens: Desired-state ownership was not assigned.
How to fix it: Resolve field ownership and review conflicts explicitly.
Prevent it next time: Keep one accountable owner per managed concern.

Check your understanding

1. Can adding namespace: training make a ClusterRole local to training?

Show worked solution

No. Resource scope belongs to its API kind. A Role is namespaced while a ClusterRole is cluster-scoped; a binding determines how its permissions are granted. Read both the role and binding before drawing an authorization conclusion.

2. A Pod is recreated under the same name. Which identity distinguishes the new lifetime?