Namespaces: Virtual Clusters for AI Workloads

You've deployed services to Kubernetes and exposed them for traffic. But what happens when your dev team's experimental agent consumes all the cluster's GPU memory? Or when a prod bug causes one team's deployment to spiral out of control, bringing down everyone else's workloads? In shared clusters, resource contention becomes inevitable without boundaries.

Namespaces solve this. They're virtual clusters within a single Kubernetes cluster—isolated spaces where you can enforce quotas, set default limits, and partition workloads by environment, team, or project. When you deploy the same agent to dev, staging, and production, namespaces keep each environment separate and constrained.

What Are Namespaces?

A namespace is a logical partition of a Kubernetes cluster. Think of it like having separate apartments in a building—they share the same foundation and utilities, but each has its own door, locks, and boundaries.

Three key properties of namespaces:

Kubernetes provides three built-in namespaces:

The problem without namespaces: All deployments share one resource pool. A runaway pod in development can consume cluster memory, causing prod services to crash. The solution: Use namespaces to partition the cluster by environment and enforce quotas.

---

Creating and Managing Namespaces

Let's create namespaces for dev, staging, and production environments. The simplest approach is using kubectl:

Output:

Verify the namespaces exist:

Output:

Now let's deploy a simple agent deployment to the dev namespace:

Output:

Verify the deployment exists in the dev namespace:

Output:

Notice the --namespace=dev flag. Without it, kubectl defaults to the default namespace. You can also use the shorthand -n dev.

---

ResourceQuotas: Limiting Namespace Resource Usage

Namespaces become powerful when you enforce quotas. A ResourceQuota limits the total CPU, memory, and other resources a namespace can consume. This prevents one team's workloads from starving others.

Create a ResourceQuota for the dev namespace:

Output:

Verify the quota was created:

Output:

The output shows current usage (200m CPU, 256Mi memory) from the two agent-api pods we created earlier. The quota allows up to 2 CPUs and 2GB memory in requests.

Why this matters for AI workloads: GPU-intensive agents require reserved resources. A ResourceQuota prevents experimental agents in dev from consuming the GPU memory that staging needs for final testing.

---

LimitRanges: Default Limits for Containers

ResourceQuotas set namespace-wide limits. LimitRanges set per-container defaults and boundaries. When developers deploy containers without specifying requests/limits, LimitRange provides sensible defaults.

Create a LimitRange for the dev namespace:

Output:

Verify the LimitRange:

Output:

Describe the LimitRange to see the full configuration:

Output:

Now, if a developer deploys a pod without specifying requests/limits, Kubernetes automatically applies the defaultRequest and default values from the LimitRange. This ensures every pod in the namespace has reasonable resource boundaries.

Example: Deploy a pod without explicit limits—the LimitRange provides defaults:

Output:

Check the pod's actual requests/limits:

Output:

The LimitRange automatically injected the default values even though we didn't specify them in the pod definition.

---

Multi-Environment Strategy: Deploying to Dev, Staging, Prod

The real power of namespaces emerges when you deploy the same application across environments with identical configuration but different resource quotas. Here's how to structure a multi-environment setup:

1. Create staging and prod namespaces with their own quotas:

Output:

2. Production: Highest quotas and strictest limits:

Output:

3. Deploy your agent to all three environments:

Save this as agent-deployment.yaml:

Deploy to all three namespaces:

Output:

Verify deployments in each namespace:

Output:

Now each environment has the same agent running with resource isolation. A memory leak in dev won't affect prod.

---

Cross-Namespace Communication

By default, services in one namespace cannot directly reference services in another namespace. But if you need cross-namespace communication, use the fully qualified DNS name: <service-name>.<namespace-name>.svc.cluster.local

For example, if the logging service in the observability namespace needs to reach the agent-api service in prod:

The DNS name breaks down as:

• agent-api - service name
• prod - namespace
• svc.cluster.local - cluster DNS suffix (always this)

This pattern is useful when you have shared services (logging, monitoring, authentication) in a central namespace that other namespaces need to access.

---

Try With AI

You now understand how namespaces provide virtual cluster partitions with resource quotas and per-container limits. The AI collaboration begins when you need to design namespace strategies for complex multi-team scenarios.

Exercise 1: Design Namespace Strategy for Multi-Team Setup

Scenario: Your organization has 3 teams deploying AI agents to the same cluster:

• Data Pipeline Team: Runs long-running training jobs (GPU-intensive, high memory)
• Model Serving Team: Runs inference APIs (low latency requirements, moderate CPU)
• Experimentation Team: Runs short-lived development agents (highly variable, experimental)

Your task: Design a namespace strategy that isolates these teams while allowing shared observability services (Prometheus, Loki) to monitor all of them.

Parts to consider:

1. How many namespaces would you create?
2. What ResourceQuota would you set for each team's namespace?
3. How would you expose monitoring/logging endpoints so all teams can reach shared services?
4. What LimitRange defaults would prevent runaway pods in each environment?

Ask AI to evaluate your strategy: Describe your namespace design, ResourceQuotas, and cross-namespace access patterns. AI can review whether your quotas are realistic for the workload types and suggest adjustments based on team requirements.

---

Reflect on Your Skill

You built a kubernetes-deployment skill in Chapter 0. Test and improve it based on what you learned.

Test Your Skill

Identify Gaps

Ask yourself:

• Did my skill include ResourceQuota configuration for limiting namespace resource consumption?
• Did it explain LimitRanges for setting default container requests and limits?
• Did it cover cross-namespace communication using fully qualified DNS names?
• Did it include multi-environment strategies (dev, staging, prod namespaces)?

Improve Your Skill

If you found gaps: