Creating custom namespaces in Kubernetes - Mechanics & Internals

Overview - Creating custom namespaces

What is it?

A namespace in Kubernetes is like a separate room inside a big house where you can keep your resources organized and isolated. Creating custom namespaces means making your own rooms to group related applications or teams. This helps avoid confusion and keeps things tidy when many projects run on the same cluster. Each namespace acts like a mini environment inside the cluster.

Why it matters

Without namespaces, all resources would live together in one big space, making it hard to manage, secure, and find things. Custom namespaces solve this by separating resources logically, so teams don’t accidentally interfere with each other. This improves security, resource management, and clarity, especially in shared environments or large projects.

Where it fits

Before learning namespaces, you should understand basic Kubernetes concepts like pods, deployments, and clusters. After mastering namespaces, you can learn about resource quotas, network policies, and role-based access control (RBAC) that often use namespaces to apply rules and limits.

Mental Model

Core Idea

Namespaces are isolated compartments inside a Kubernetes cluster that organize and separate resources for better management and security.

Think of it like...

Imagine a large office building where each team has its own room to work in. Each room keeps that team's files, desks, and equipment separate from others, preventing mix-ups and confusion.

┌───────────────────────────────┐
│        Kubernetes Cluster      │
│ ┌───────────────┐ ┌───────────┐ │
│ │ Namespace A   │ │ Namespace B│ │
│ │ ┌───────────┐ │ │ ┌───────┐ │ │
│ │ │ Pod 1     │ │ │ │ Pod 3 │ │ │
│ │ │ Deployment│ │ │ │       │ │ │
│ │ └───────────┘ │ │ └───────┘ │ │
│ └───────────────┘ └───────────┘ │
└───────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Kubernetes namespaces basics

Concept: Namespaces divide cluster resources into separate groups to avoid conflicts and organize workloads.

Kubernetes clusters can have many resources like pods and services. Namespaces let you create separate spaces inside the cluster so resources with the same name can exist without clashing. By default, Kubernetes has a 'default' namespace where resources go if you don't specify one.

Result

You learn that namespaces help keep resources organized and prevent name conflicts in a cluster.

Understanding namespaces as separate spaces inside a cluster is key to managing multiple projects or teams safely.

2

Foundation

How to create a custom namespace

Concept: You can create your own namespace using a simple YAML file or a command-line instruction.

To create a namespace, you write a YAML file like this: apiVersion: v1 kind: Namespace metadata: name: my-namespace Then apply it with: kubectl apply -f namespace.yaml Or create it directly with: kubectl create namespace my-namespace

Result

A new namespace named 'my-namespace' is created and ready to use.

Knowing how to create namespaces manually or via command line lets you organize your cluster resources from the start.

3

Intermediate

Using namespaces with kubectl commands

🤔Before reading on: Do you think kubectl commands automatically use your custom namespace or the default one? Commit to your answer.

Concept: kubectl commands target the default namespace unless you specify otherwise with a flag or context setting.

When you run commands like 'kubectl get pods', Kubernetes looks in the 'default' namespace unless you add '-n my-namespace'. For example: kubectl get pods -n my-namespace You can also set your current context to use a namespace by default: kubectl config set-context --current --namespace=my-namespace

Result

You can list, create, or delete resources specifically inside your custom namespace.

Understanding that kubectl defaults to the 'default' namespace prevents confusion and mistakes when managing resources.

4

Intermediate

Why namespaces improve security and resource control

🤔Before reading on: Do you think namespaces alone prevent users from accessing other namespaces? Commit to your answer.

Concept: Namespaces help separate resources but need additional tools like RBAC to enforce security boundaries.

Namespaces group resources, but by themselves, they don't block access. To restrict who can do what in each namespace, Kubernetes uses Role-Based Access Control (RBAC). For example, you can give a team permission to only manage resources in their namespace, keeping others safe.

Result

Namespaces combined with RBAC create secure, isolated environments for teams.

Knowing namespaces are part of a bigger security system helps you design safer Kubernetes clusters.

5

Advanced

Managing resource quotas per namespace

🤔Before reading on: Do you think resource quotas apply cluster-wide or can be set per namespace? Commit to your answer.

Concept: Resource quotas limit how much CPU, memory, or objects a namespace can use to prevent one team from overloading the cluster.

You can create a ResourceQuota object in a namespace to limit resources. For example: apiVersion: v1 kind: ResourceQuota metadata: name: compute-quota namespace: my-namespace spec: hard: pods: "10" requests.cpu: "4" requests.memory: 8Gi This ensures the namespace can't create more than 10 pods or use more than 4 CPUs and 8Gi memory.

Result

The namespace 'my-namespace' is limited in resource usage, protecting cluster stability.

Understanding resource quotas prevents resource hogging and keeps multi-tenant clusters healthy.

6

Advanced

Namespace lifecycle and cleanup best practices

Concept: Namespaces can be deleted to remove all resources inside them, but this must be done carefully to avoid data loss.

Deleting a namespace removes all resources inside it. Use: kubectl delete namespace my-namespace This can take time if many resources exist. It's best to clean up resources inside first or use labels to manage them. Also, some resources like PersistentVolumes may persist beyond namespace deletion.

Result

The namespace and its contained resources are removed, freeing cluster space.

Knowing how namespace deletion works helps avoid accidental data loss and cluster issues.

7

Expert

Namespace design patterns for large clusters

🤔Before reading on: Do you think one namespace per team is always best, or are there other patterns? Commit to your answer.

Concept: Experts design namespaces based on team size, project needs, and security, sometimes using multiple namespaces per team or shared namespaces with strict policies.

In large organizations, namespaces might be: - One per team for isolation - One per environment (dev, test, prod) to separate stages - Shared namespaces with labels and RBAC for microservices Choosing the right pattern balances isolation, management overhead, and collaboration. Also, namespaces integrate with network policies and quotas for fine control.

Result

A scalable, secure namespace structure tailored to organizational needs.

Understanding namespace design patterns helps build maintainable and secure Kubernetes environments at scale.

Under the Hood

Namespaces are implemented as a metadata field on Kubernetes resources. The API server uses the namespace to scope resource queries and operations. Internally, namespaces partition the etcd database keys, so resources with the same name can coexist in different namespaces. Controllers and schedulers respect namespaces when managing resources. However, namespaces do not isolate network traffic or storage by themselves; these require additional configurations.

Why designed this way?

Namespaces were introduced to solve the problem of resource name collisions and to enable multi-tenancy in a single cluster. Instead of creating multiple clusters, namespaces allow logical separation with low overhead. This design balances isolation with resource sharing and operational simplicity. Alternatives like separate clusters were more costly and complex to manage.

┌───────────────────────────────┐
│        Kubernetes API Server   │
│ ┌───────────────┐ ┌───────────┐ │
│ │ Namespace A   │ │ Namespace B│ │
│ │ ┌───────────┐ │ │ ┌───────┐ │ │
│ │ │ Resource  │ │ │ │Resource│ │ │
│ │ │ keys in  │ │ │ │ keys  │ │ │
│ │ │ etcd     │ │ │ │ in etcd│ │ │
│ │ └───────────┘ │ │ └───────┘ │ │
│ └───────────────┘ └───────────┘ │
└───────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does creating a namespace automatically restrict user access to it? Commit yes or no.

Common Belief: Creating a namespace automatically prevents users from accessing resources outside it.

Reality: Namespaces alone do not enforce access control; RBAC policies are needed to restrict user permissions.

Why it matters: Assuming namespaces secure access can lead to unauthorized users modifying or viewing resources they shouldn't.

Quick: Can resources in different namespaces communicate without restrictions? Commit yes or no.

Common Belief: Namespaces isolate network traffic by default, so pods in different namespaces cannot talk to each other.

Reality: Namespaces do not isolate network traffic by default; network policies must be configured to restrict communication.

Why it matters: Believing namespaces isolate network can cause security gaps if network policies are not applied.

Quick: Does deleting a namespace immediately remove all its resources? Commit yes or no.

Common Belief: Deleting a namespace instantly deletes all resources inside it without delay.

Reality: Namespace deletion can take time as Kubernetes cleans up resources; some resources may persist if not properly handled.

Why it matters: Expecting instant deletion can cause confusion and delays in cluster cleanup or redeployment.

Quick: Can you create unlimited namespaces without affecting cluster performance? Commit yes or no.

Common Belief: Namespaces have no impact on cluster performance, so you can create as many as you want.

Reality: Too many namespaces can increase API server load and complicate management, affecting performance.

Why it matters: Ignoring namespace limits can degrade cluster responsiveness and increase operational complexity.

Expert Zone

1

Namespaces do not isolate storage by default; PersistentVolumes are cluster-wide and require careful management.

2

Label selectors and annotations within namespaces enable fine-grained resource grouping beyond namespace boundaries.

3

Namespace lifecycle events can trigger automation workflows, but improper handling may cause resource leaks or downtime.

When NOT to use

Namespaces are not suitable for complete isolation of workloads requiring separate network stacks or hardware. In such cases, separate Kubernetes clusters or virtual clusters are better alternatives.

Production Patterns

In production, namespaces are combined with RBAC, network policies, and resource quotas to enforce multi-tenant security and resource fairness. Teams often use namespaces per environment (dev, staging, prod) and per application to organize deployments and apply policies consistently.

Connections

Role-Based Access Control (RBAC)

Namespaces provide the scope for RBAC policies to restrict user permissions.

Understanding namespaces helps grasp how RBAC limits user actions within specific parts of a cluster.

Network Policies

Namespaces group resources that network policies can target to control traffic flow.

Knowing namespaces clarifies how network policies isolate or allow communication between workloads.

Operating System User Accounts

Namespaces are like user accounts that separate files and processes to prevent interference.

Seeing namespaces as OS user accounts helps understand resource isolation and access control in Kubernetes.

Common Pitfalls

#1 Assuming kubectl commands affect the intended namespace without specifying it.

Wrong approach:

kubectl get pods
# This lists pods only in the default namespace, not the custom one.

Correct approach:

kubectl get pods -n my-namespace
# This lists pods in the 'my-namespace' namespace.

Root cause:

Not specifying the namespace causes kubectl to default to 'default', leading to confusion about resource visibility.

#2 Deleting a namespace without cleaning up persistent resources.

Wrong approach:

kubectl delete namespace my-namespace
# PersistentVolumes may remain and cause resource leaks.

Correct approach:

kubectl delete pvc --all -n my-namespace
kubectl delete namespace my-namespace
# Clean persistent volume claims before deleting namespace.

Root cause:

Misunderstanding that namespace deletion does not automatically remove cluster-wide resources like PersistentVolumes.

#3 Relying on namespaces alone for security isolation.

Wrong approach:

Creating namespaces and assuming users cannot access other namespaces without RBAC.

Correct approach:

Implement RBAC policies to restrict user permissions per namespace explicitly.

Root cause:

Confusing logical grouping with security enforcement leads to unauthorized access risks.

Key Takeaways

Namespaces are essential for organizing and isolating resources within a Kubernetes cluster.

Creating custom namespaces helps manage multi-team or multi-project environments safely and clearly.

kubectl commands default to the 'default' namespace unless you specify otherwise, so always be explicit when working with custom namespaces.

Namespaces alone do not enforce security or network isolation; they must be combined with RBAC and network policies.

Proper namespace design and management prevent resource conflicts, improve security, and maintain cluster health in production.

Practice

1. What is the main purpose of creating a custom namespace in Kubernetes?

easy

A. To increase the number of nodes in the cluster

B. To group and isolate resources for better organization

C. To speed up container image downloads

D. To automatically update all pods

Solution

1. Step 1: Understand Kubernetes namespaces

   Namespaces help organize and isolate resources within the same cluster.

2. Step 2: Identify the purpose of custom namespaces

   Custom namespaces separate projects, teams, or environments for clarity and management.

3. Final Answer:

   To group and isolate resources for better organization -> Option B

4. Quick Check:

   Namespaces = Organize resources [OK]

Hint: Namespaces isolate resources logically, not physically [OK]

Common Mistakes:

• Thinking namespaces add nodes
• Confusing namespaces with pods
• Believing namespaces speed up downloads

2. Which YAML snippet correctly defines a custom namespace named dev-team?

easy

A. apiVersion: v1\nkind: Namespace\nmetadata:\n name: dev-team

B. apiVersion: v1\nkind: Pod\nmetadata:\n name: dev-team

C. apiVersion: apps/v1\nkind: Namespace\nmetadata:\n name: dev-team

D. apiVersion: v1\nkind: Service\nmetadata:\n name: dev-team

Solution

1. Step 1: Identify correct apiVersion and kind for namespace

   The correct apiVersion is 'v1' and kind is 'Namespace' for creating namespaces.

2. Step 2: Check metadata name field

   The metadata name must be the desired namespace name, here 'dev-team'.

3. Final Answer:

   apiVersion: v1\nkind: Namespace\nmetadata:\n name: dev-team -> Option A

4. Quick Check:

   Namespace YAML = apiVersion v1 + kind Namespace [OK]

Hint: Namespace kind is always 'Namespace' with apiVersion 'v1' [OK]

Common Mistakes:

• Using wrong kind like Pod or Service
• Using wrong apiVersion like apps/v1
• Missing metadata name field

3. What will be the output of the command kubectl get namespaces after applying this YAML?

apiVersion: v1
kind: Namespace
metadata:
  name: test-env

medium

A. Only default namespaces are shown, 'test-env' is missing

B. Shows an error: namespace 'test-env' already exists

C. No output, command hangs

D. Lists all namespaces including 'test-env'

Solution

1. Step 1: Apply the namespace YAML

   Applying the YAML creates a new namespace named 'test-env' in the cluster.

2. Step 2: Run 'kubectl get namespaces'

   This command lists all namespaces, including the newly created 'test-env'.

3. Final Answer:

   Lists all namespaces including 'test-env' -> Option D

4. Quick Check:

   kubectl get namespaces shows all namespaces [OK]

Hint: New namespaces appear in 'kubectl get namespaces' output [OK]

Common Mistakes:

• Expecting error if namespace exists (it won't if new)
• Thinking command hangs
• Assuming only default namespaces show

4. You tried to create a namespace with this YAML but got an error:

apiVersion: v1
kind: Namespace
metadata:
  name: 123team

What is the likely cause?

medium

A. Namespace names cannot start with a number

B. apiVersion 'v1' is incorrect for namespaces

C. Missing 'labels' field in metadata

D. Namespace kind should be 'Project'

Solution

1. Step 1: Check namespace naming rules

   Namespace names must start with a letter and contain only lowercase letters, numbers, and dashes.

2. Step 2: Identify invalid name

   The name '123team' starts with a number, which is invalid and causes the error.

3. Final Answer:

   Namespace names cannot start with a number -> Option A

4. Quick Check:

   Namespace name rules forbid starting with digits [OK]

Hint: Namespace names must start with a letter, not a number [OK]

Common Mistakes:

• Thinking apiVersion v1 is wrong
• Believing labels are mandatory
• Using wrong kind like 'Project'

5. You want to create two namespaces, dev and prod, and ensure pods in dev cannot access services in prod. Which approach is best?

hard

A. Create namespaces and use different node pools for each

B. Create namespaces and label pods with 'access=restricted' only

C. Create both namespaces and use NetworkPolicies to restrict access

D. Create namespaces and deploy all pods in the default namespace

Solution

1. Step 1: Create separate namespaces

   Namespaces 'dev' and 'prod' isolate resources logically in the cluster.

2. Step 2: Use NetworkPolicies to control traffic

   NetworkPolicies can restrict pod-to-service communication between namespaces effectively.

3. Final Answer:

   Create both namespaces and use NetworkPolicies to restrict access -> Option C

4. Quick Check:

   Namespaces + NetworkPolicies = access control [OK]

Hint: Use NetworkPolicies with namespaces for access control [OK]

Common Mistakes:

• Assuming labels alone restrict network access
• Deploying all pods in default namespace ignores isolation
• Using node pools does not isolate network traffic