Creating custom namespaces in Kubernetes - Interactive Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the command to create a new namespace named 'dev'.

Kubernetes

kubectl create namespace [1]

Drag options to blanks, or click blank then click option'

Adevelopment

Bprod

Cdev

Ddefault

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'default' which is a pre-existing namespace.

Misspelling the namespace name.

Omitting the namespace name.

The command kubectl create namespace dev creates a new namespace called 'dev'.

2fill in blank

medium

Complete the command to list all namespaces in the cluster.

Kubernetes

kubectl get [1]

Drag options to blanks, or click blank then click option'

Anamespaces

Bpods

Cservices

Dnodes

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'pods' or 'services' instead of 'namespaces'.

Using singular form like 'namespace' which is incorrect.

The command kubectl get namespaces lists all namespaces in the Kubernetes cluster.

3fill in blank

hard

Fix the error in the command to delete the namespace named 'test'.

Kubernetes

kubectl delete [1] test

Drag options to blanks, or click blank then click option'

Anode

Bnamespace

Cservice

Dpod

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'pod' or 'service' instead of 'namespace'.

Omitting the resource type.

To delete a namespace, use kubectl delete namespace test. Using 'namespace' is correct.

4fill in blank

hard

Fill both blanks to create a namespace using a YAML file named 'ns.yaml'.

Kubernetes

kubectl [1] -f [2]

Drag options to blanks, or click blank then click option'

Aapply

Bcreate

Cdelete

Dns.yaml

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'apply' instead of 'create' for initial creation.

Using wrong file name or omitting the file.

The command kubectl create -f ns.yaml creates resources defined in the YAML file, including namespaces.

5fill in blank

hard

Fill all three blanks to define a namespace named 'staging' in a YAML manifest.

Kubernetes

apiVersion: v1
kind: [1]
metadata:
  name: [2]
  labels:
    environment: [3]

Drag options to blanks, or click blank then click option'

ANamespace

Bstaging

Cstaging-env

DPod

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'Pod' instead of 'Namespace' for kind.

Incorrect or missing name and label values.

This YAML defines a namespace resource named 'staging' with a label 'environment: staging-env'.

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