Why would I hand-write a Namespace manifest instead of just running kubectl create namespace?

`kubectl create namespace` creates a bare namespace with no labels or annotations. A manifest lets you set both up front, for example labels that a Pod Security Admission policy or a NetworkPolicy selector depends on, and it's the version-controllable, GitOps-friendly way to manage namespaces alongside everything else.

What are namespace labels typically used for?

Beyond simple organization, namespace labels are commonly used as selector targets for NetworkPolicies (namespaceSelector) and to configure Pod Security Admission enforcement levels via the well-known pod-security.kubernetes.io/enforce label.

Can I generate a manifest for a reserved namespace like kube-system?

The tool allows it but adds a comment noting that reserved namespaces (default, kube-system, kube-public, kube-node-lease) already exist in every cluster; applying this manifest against one of those only updates its labels/annotations, it won't create a duplicate.

Do labels and annotations behave differently once applied?

Yes: labels are meant to be selected on (by NetworkPolicies, admission controllers, tooling) and should stay short and structured, while annotations are for arbitrary metadata (an owning team, a contact link, a change ticket) that nothing in Kubernetes itself selects against.

Kubernetes Namespace Generator - Build Namespace YAML

Overview

Introduction

A Namespace manifest is about as simple as Kubernetes YAML gets, but it's still worth generating rather than typing by hand once you start attaching labels that Pod Security Admission or NetworkPolicies depend on.

This tool generates a Namespace manifest with a name and any number of labels and annotations, entirely client-side.

What Is Kubernetes Namespace YAML Generator?

A Kubernetes Namespace YAML generator that produces a v1 Namespace object with an arbitrary number of metadata labels and annotations.

It's a small, focused tool: no spec fields beyond metadata, since a Namespace object itself carries no spec configuration.

How Kubernetes Namespace YAML Generator Works

The name field populates metadata.name directly, validated against the same DNS-label rules Kubernetes enforces for namespace names.

Each label row becomes an entry under metadata.labels, and each annotation row becomes an entry under metadata.annotations; both sections are only included in the output when at least one row has been added.

If the name matches one of the four cluster-reserved namespaces (default, kube-system, kube-public, kube-node-lease), a leading YAML comment notes that the namespace already exists.

When To Use Kubernetes Namespace YAML Generator

Use it when setting up a new namespace as part of a GitOps repository, so its labels/annotations are declared alongside the rest of your cluster configuration instead of applied ad hoc with kubectl.

Use it specifically when you need labels a NetworkPolicy or Pod Security Admission policy will select against, since those need to exist on the Namespace object itself, not just on the Pods inside it.

Often used alongside Kubernetes ResourceQuota YAML Generator, Kubernetes ConfigMap YAML Generator and Kubernetes Secret YAML Generator.

Features

Advantages

Produces a minimal, correct Namespace manifest without any unnecessary boilerplate.
Supports an arbitrary number of both labels and annotations, covering everything from Pod Security Admission labels to team-ownership annotations.
Flags reserved namespace names so you don't mistakenly think you're creating a new namespace when you're actually just updating one of the four Kubernetes creates by default.

Limitations

Doesn't create any accompanying ResourceQuota, LimitRange, RBAC RoleBinding, or NetworkPolicy objects; those need to be generated or written separately.
Doesn't validate that label values conform to any policy-specific expected values (for example, valid pod-security.kubernetes.io/enforce levels are restricted to privileged, baseline, or restricted, but this tool won't check that for you).

Examples

A namespace labeled for restricted Pod Security Admission

Input

name: team-a, labels: [pod-security.kubernetes.io/enforce=restricted]

Output

apiVersion: v1
kind: Namespace
metadata:
  name: team-a
  labels:
    pod-security.kubernetes.io/enforce: restricted

Kubernetes' built-in Pod Security Admission controller reads this label directly off the Namespace object to decide what Pod specs it will admit.

Best Practices & Notes

Best Practices

Set a pod-security.kubernetes.io/enforce label on every namespace explicitly, rather than relying on cluster-wide defaults, so security posture is visible in the manifest itself.
Use annotations, not labels, for free-form information like an owning team's contact channel; reserve labels for anything you expect a selector to match against.
Follow this manifest immediately with a ResourceQuota (see the Kubernetes ResourceQuota Generator) for any namespace shared across teams.

Developer Notes

Namespace name validation reuses the RFC 1123 DNS label subset applied across this category's other generators. The reserved-namespace check is a simple set membership test against the four namespaces every Kubernetes cluster provisions automatically (default, kube-system, kube-public, kube-node-lease); it only changes the output by prepending an informational YAML comment, it doesn't block generation, since applying a manifest against one of those namespaces to update its labels/annotations is a legitimate, common operation.

Kubernetes Namespace YAML Generator Use Cases

Declaring a new team or environment namespace as part of a version-controlled cluster configuration repository
Adding Pod Security Admission enforcement labels to an existing namespace
Tagging a namespace with ownership or cost-center annotations for internal tracking

Common Mistakes

Expecting namespace labels to automatically propagate down to Pods inside it; labels on a Namespace and labels on the Pods within it are entirely separate.
Using a label where an annotation was appropriate (or vice versa), for example putting a long free-form description under labels, where Kubernetes' label value length and character restrictions are far stricter than annotation values.
Assuming a Namespace manifest alone provides resource isolation; without a paired ResourceQuota and appropriate RBAC, a namespace is an organizational boundary, not a hard resource or security boundary.

Tips

Follow up with the Kubernetes ResourceQuota Generator to actually cap what this namespace's workloads can consume.

Kubernetes Namespace YAML Generator