Homework: Namespaces & Labels

Three tasks that reinforce namespace isolation, labelling strategy, and quota enforcement

Instructions

Complete each task independently. Use the self-check criteria to verify your work before moving on. You may reference the theory reading and lab guide, but try to work from memory first.

Task 1: Multi-Namespace Deployment

Create a Helm chart called hw04-multi. Deploy the same chart into three namespaces: hw04-dev, hw04-staging, and hw04-prod. Each installation should use a different release name (e.g., app-dev, app-staging, app-prod).

After deploying, run a single kubectl command that lists pods across all three namespaces filtered by the label app.kubernetes.io/name=hw04-multi.

Self-Check

✓ Three namespaces exist: hw04-dev, hw04-staging, hw04-prod.
✓ helm list -A | grep hw04 shows three releases, each in a different namespace.
✓ kubectl get pods -A -l app.kubernetes.io/name=hw04-multi returns exactly three pods (one per namespace).
✓ Each pod has a distinct app.kubernetes.io/instance label value.

Task 2: Custom Label Strategy with Annotations

Extend the chart from Task 1 (or create a new one) to include the following metadata on every resource:

All six recommended app.kubernetes.io/* labels (name, instance, version, component, part-of, managed-by).
A custom label cost-center whose value comes from .Values.costCenter (default: "engineering").
An annotation owner whose value comes from .Values.owner (default: "platform-team").

All labels and annotations must be defined in _helpers.tpl using named templates. The cost-center label must not be included in matchLabels.

Self-Check

✓ helm template . | grep "cost-center" shows the label on Deployment, Service, and ServiceAccount metadata.
✓ helm template . | grep "owner:" appears under annotations:, not labels:.
✓ helm template . --set costCenter=marketing | grep "cost-center" shows marketing.
✓ The Deployment's spec.selector.matchLabels contains only app.kubernetes.io/name and app.kubernetes.io/instance.

Task 3: ResourceQuota & LimitRange Guard Rails

Add both a ResourceQuota and a LimitRange template to your chart. They should be toggled via .Values.resourceQuota.enabled and .Values.limitRange.enabled respectively. Configure the following defaults:

ResourceQuota: 4 CPU requests, 4Gi memory requests, 20 pods max.
LimitRange: default container limit of 500m CPU / 512Mi memory; default request of 100m CPU / 128Mi memory.

Deploy with both enabled, then attempt to create a pod that exceeds the LimitRange default limit by adding resources.limits.memory: 2Gi to a second deployment.

Self-Check

✓ kubectl describe resourcequota -n <ns> shows the correct hard limits.
✓ kubectl describe limitrange -n <ns> shows the correct default and defaultRequest values.
✓ A pod deployed without explicit resource requests automatically receives 100m CPU and 128Mi memory (set by LimitRange).
✓ A pod requesting 2Gi memory is allowed (LimitRange sets defaults, not maximums, unless max is specified).

Grading Rubric

Criterion	Points	Description
Task 1: Multi-namespace deployment	30	Three releases across three namespaces; cross-namespace label query returns all pods.
Task 2: Label strategy	35	All six standard labels present; custom label and annotation from values; selector labels remain minimal.
Task 3: Quota & LimitRange	25	Both resources correctly templated and gated behind values; defaults are applied to new pods.
Code quality	10	Labels centralised in `_helpers.tpl`; values have sensible defaults; templates pass `helm lint`.

Cleanup

When finished, uninstall all releases and delete the homework namespaces:

helm uninstall app-dev -n hw04-dev
helm uninstall app-staging -n hw04-staging
helm uninstall app-prod -n hw04-prod
kubectl delete ns hw04-dev hw04-staging hw04-prod