Creating custom namespaces in Kubernetes - Visual Walkthrough

Process Flow - Creating custom namespaces

Write YAML file for Namespace

↓

Run kubectl apply -f namespace.yaml

↓

Kubernetes API Server receives request

↓

Namespace resource created in cluster

↓

kubectl get namespaces shows new namespace

↓

Use namespace in pods/deployments

This flow shows how you create a custom namespace by writing a YAML file, applying it with kubectl, and then using it in your cluster.

Execution Sample

Kubernetes

apiVersion: v1
kind: Namespace
metadata:
  name: my-custom-namespace

This YAML defines a new Kubernetes namespace called 'my-custom-namespace'.

Process Table

Step	Command/Action	System Response	Resulting State
1	Create namespace.yaml file with namespace definition	File created locally	namespace.yaml exists with correct content
2	kubectl apply -f namespace.yaml	Namespace 'my-custom-namespace' created	Namespace resource added to cluster
3	kubectl get namespaces	Lists all namespaces including 'my-custom-namespace'	User sees new namespace in list
4	Use namespace in pod/deployment spec	Pods/deployments created in 'my-custom-namespace'	Resources scoped to custom namespace
5	kubectl delete namespace my-custom-namespace	Namespace and all resources inside deleted	Namespace removed from cluster

💡 Namespace creation completes after kubectl apply; visible in namespace list and usable for resource scoping.

Status Tracker

Variable	Start	After Step 2	After Step 3	Final
namespace.yaml	Not created	Created with namespace definition	Unchanged	Unchanged
Cluster Namespaces	Default namespaces only	Includes 'my-custom-namespace'	Includes 'my-custom-namespace'	Depends on deletion
Resources in 'my-custom-namespace'	None	None	None	Created after deployment

Key Moments - 3 Insights

Why doesn't the namespace appear immediately after creating the YAML file?

Creating the YAML file only saves the definition locally. The namespace appears in the cluster only after running 'kubectl apply -f namespace.yaml' as shown in execution_table step 2.

Can I create pods in a namespace before it exists?

No, pods must be created after the namespace exists in the cluster. The namespace resource must be applied first (step 2), then pods can be created inside it (step 4).

What happens if I delete a namespace?

Deleting a namespace removes it and all resources inside it from the cluster, as shown in step 5 of the execution_table.

Visual Quiz - 3 Questions

Look at the execution table, what command creates the namespace resource in the cluster?

A kubectl get namespaces

B kubectl apply -f namespace.yaml

C kubectl delete namespace my-custom-namespace

D Creating the YAML file

💡 Hint

Check step 2 in the execution_table where the namespace is created.

At which step does the new namespace become visible when listing namespaces?

A Step 3

B Step 2

C Step 1

D Step 4

💡 Hint

Look at the system response in step 3 of the execution_table.

If you delete the namespace, what happens to the resources inside it?

A They remain in the cluster

B They move to the default namespace

C They are deleted along with the namespace

D They become inactive but stay allocated

💡 Hint

Refer to step 5 in the execution_table about namespace deletion.

Concept Snapshot

Creating a custom namespace:
- Write a YAML file with kind: Namespace and metadata.name
- Run 'kubectl apply -f filename.yaml' to create it
- Verify with 'kubectl get namespaces'
- Use the namespace in pod/deployment specs
- Deleting the namespace removes all contained resources

Full Transcript

To create a custom namespace in Kubernetes, first write a YAML file defining the namespace with kind: Namespace and a unique name. Then apply this file using 'kubectl apply -f'. This sends the request to the Kubernetes API server, which creates the namespace resource in the cluster. You can verify the namespace exists by listing namespaces with 'kubectl get namespaces'. After creation, you can create pods or deployments inside this namespace by specifying it in their specs. If you delete the namespace, all resources inside it are also deleted. This process helps organize and isolate resources in your cluster.

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