02: Namespaces

02: Namespaces

Overview

Namespaces provide a mechanism for isolating groups of resources within a single Kubernetes cluster. They act as virtual clusters, allowing multiple teams or projects to share the same physical cluster without interfering with each other. In this exercise, you will explore existing namespaces, deploy resources into your pre-created namespace, and learn how to switch between them.

Your first task: Each participant must create their own namespace student-XX (where XX is your assigned number). You will work exclusively within this namespace throughout the training.

Objective

• Understand what namespaces are and why they exist
• List and inspect existing namespaces (including AKS-specific ones)
• Create your own student-XX namespace
• Deploy resources into your namespace and observe namespace isolation
• Switch the default namespace in your kubectl context
• Learn about ResourceQuotas for shared clusters

Theory

Namespaces as Virtual Clusters

A namespace scopes the visibility and naming of resources. Two Pods can have the same name as long as they are in different namespaces. Namespaces provide:

• Name isolation — Resource names must be unique within a namespace, but not across namespaces.
• Access control boundary — RBAC policies can grant permissions per namespace.
• Resource quota boundary — ResourceQuotas and LimitRanges can be applied per namespace.
• Network policy scope — NetworkPolicies can restrict traffic between namespaces.

Important: Not all resources are namespaced. Nodes, PersistentVolumes, ClusterRoles, and Namespaces themselves are cluster-scoped.

Default Namespaces

Every Kubernetes cluster comes with these namespaces:

AKS-Specific Namespaces

In an AKS cluster, you will also find:

Namespace Isolation Diagram

graph TB
    subgraph Cluster["Kubernetes Cluster"]
        subgraph NS1["Namespace: student-01"]
            P1A[Pod: kuard]
            S1A[Service: kuard-svc]
            CM1[ConfigMap: app-config]
        end
        subgraph NS2["Namespace: student-02"]
            P2A[Pod: kuard]
            S2A[Service: kuard-svc]
            CM2[ConfigMap: app-config]
        end
        subgraph NS3["Namespace: kube-system"]
            DNS[CoreDNS]
            METRICS[metrics-server]
            CCM[cloud-controller-manager]
        end
    end

    NS1 -.- |"Same names, different namespaces"| NS2
    NS3 -.- |"System components isolated"| NS1

Each namespace operates independently. Resources with identical names (e.g., kuard, kuard-svc, app-config) can coexist in different namespaces without conflict.

Practical Tasks

Task 1: List Existing Namespaces

# List all namespaces
kubectl get namespaces

You should see at least: default, kube-system, kube-public, kube-node-lease, and possibly app-routing-system.

# Get more details
kubectl get namespaces -o wide

# Describe a specific namespace
kubectl describe namespace kube-system

Task 2: Create Your Namespace

Create your own namespace for the training. Replace XX with your assigned student number (e.g., 01, 02, …, 13):

kubectl create namespace student-XX

Verify it was created:

kubectl get namespace student-XX

Examine your new namespace:

# View details of your namespace
kubectl describe namespace student-XX

# Check if there are any ResourceQuotas in your namespace
kubectl get resourcequota -n student-XX

# Check if there are any LimitRanges in your namespace
kubectl get limitrange -n student-XX

In production, namespace creation is typically managed by platform teams who also configure RBAC policies, ResourceQuotas, and NetworkPolicies for each namespace. In this training, you create it yourself to understand the process.

Task 3: Create Objects in Your Namespace

Deploy a Pod in your student-XX namespace and observe how namespaces provide isolation between participants.

# Create a Pod in your namespace
kubectl run kuard-student \
  --image=<ACR_NAME>.azurecr.io/kuard:1 \
  --namespace=student-XX

Now observe how each namespace has its own set of resources:

# List pods in your namespace
kubectl get pods -n student-XX

# List pods across ALL namespaces — notice other students' pods in their namespaces
kubectl get pods --all-namespaces
# Or use the short form:
kubectl get pods -A

Even though all participants share the same cluster, each namespace provides isolation — your resources do not conflict with resources in other student-XX namespaces, even if they use the same names.

Task 4: Switch Default Namespace Context

Instead of typing -n student-XX every time, set your default namespace:

# Check your current context
kubectl config get-contexts

# Set default namespace to your student namespace
kubectl config set-context --current --namespace=student-XX

# Now commands default to student-XX
kubectl get pods
# This shows pods in student-XX without specifying -n

# Verify
kubectl config get-contexts

The NAMESPACE column in get-contexts output shows your current default namespace.

Task 5: View Objects Across Namespaces

Explore what is running in other namespaces to understand how a shared cluster is organized:

# List all namespaces
kubectl get namespaces

# View system pods (in kube-system)
kubectl get pods -n kube-system

# View app-routing pods (if enabled)
kubectl get pods -n app-routing-system

# View all services across all namespaces
kubectl get svc -A

Note: You can view resources in other namespaces, but you should only create, modify, or delete resources in your own student-XX namespace.

Task 6: ResourceQuota Concept

In a shared cluster, ResourceQuotas prevent a single namespace from consuming all cluster resources. Here is an example for reference:

# Example: resource-quota.yaml (review only — applied by the instructor/admin)
apiVersion: v1
kind: ResourceQuota
metadata:
  name: student-quota
  namespace: student-XX
spec:
  hard:
    pods: "10"
    requests.cpu: "4"
    requests.memory: 4Gi
    limits.cpu: "8"
    limits.memory: 8Gi

This would limit the namespace to a maximum of 10 pods, 4 CPU cores in requests, and 4Gi memory in requests.

# To view quotas in your namespace (if configured by the instructor):
kubectl get resourcequota -n student-XX

# To see current usage vs limits:
kubectl describe resourcequota -n student-XX

Note: ResourceQuota creation is a namespace administration task typically performed by the instructor or platform team, not by individual participants.

Task 7: Clean Up

Remove the resources you created in your namespace:

# Delete pods in your namespace
kubectl delete pod kuard-student -n student-XX

# Make sure your context is set to your namespace
kubectl config set-context --current --namespace=student-XX

Important: Do not delete your namespace during the training. Deleting a namespace removes everything inside it. You will need it for all subsequent exercises.

Common Problems

Best Practices

• One namespace per team or environment — In a shared AKS cluster, give each team its own namespace. This provides isolation without the overhead of separate clusters.
• Always set your default namespace — Avoid working in the default namespace. Set your context namespace immediately after connecting to the cluster.
• Apply ResourceQuotas on shared clusters — Prevent a single namespace from starving others of resources. This is especially important in training and development clusters.
• Use labels on namespaces — Add labels like team, environment, or cost-center to namespaces for organization and policy targeting.
• RBAC per namespace — In production AKS clusters, use Kubernetes RBAC (or Azure RBAC for AKS) to restrict users to their own namespaces. A developer should not be able to modify resources in another team’s namespace.
• Do not use kube-system for application workloads — Reserve system namespaces for infrastructure components only.
• Use --all-namespaces / -A for cluster-wide visibility — When troubleshooting, search across all namespaces to get the full picture.

Summary

Namespaces are a fundamental organizational mechanism in Kubernetes. They provide logical isolation for resources, enable access control via RBAC, and allow resource quota enforcement in shared clusters. In this training, you created your own student-XX namespace, deployed resources into it, switched your default context, viewed resources across namespaces, and learned about ResourceQuotas.

Proceed to Exercise 03 to learn about Pods, the fundamental building block of Kubernetes.