Skip to main content

Namespaces

What You Will Learn

  • What namespaces are and why they matter
  • The Junovy naming pattern for client namespaces
  • How namespaces provide isolation

What Is a Namespace?

A namespace is a way to divide a Kubernetes cluster into separate areas. Each area has its own Pods, Services, Secrets, and other resources. Resources in one namespace cannot see resources in another namespace (by default).

Think of it like rooms in a building. The building is the cluster. Each room is a namespace. Each client gets their own room with their own stuff inside. They cannot walk into another client's room.

The Junovy Naming Pattern

At Junovy, every client namespace starts with hst- followed by the client name:

Client Namespace
Bizdom hst-bizdom
Drake Design Studio hst-dds
Riverland Faeries hst-riverland-faeries-netherlands
Tom of Amsterdam hst-tomofamsterdam

The hst- prefix stands for "hosted." It makes client namespaces easy to identify when you list all namespaces in the cluster.

What Lives in a Client Namespace

Each hst- namespace contains everything that client needs:

Resource Type Example Purpose
Deployments / HelmReleases BookStack, Rallly The client's applications
Services bookstack-svc Internal routing to Pods
Ingress bookstack-ingress Public domain + TLS
Secrets bookstack-db-credentials Passwords and API keys
ConfigMaps app-settings Non-sensitive configuration
PersistentVolumeClaims data-volume Storage for databases or files

Creating a Namespace

A namespace is defined in YAML. At Junovy, it is always the 010-namespace.yaml file (the 010 prefix means it is applied first):

apiVersion: v1
kind: Namespace
metadata:
  name: hst-my-client    # the namespace name
  labels:
    app.kubernetes.io/managed-by: flux   # tells us Flux manages this
    tenant: my-client                     # identifies the client

System Namespaces

Not all namespaces are for clients. The cluster has system namespaces too:

Namespace Purpose
kube-system Core Kubernetes components
flux-system Flux CD controllers
cert-manager TLS certificate automation
monitoring Prometheus, Grafana
traefik Ingress controller (routes external traffic)
linkerd Service mesh (mTLS between services)
vault Secrets management server
external-secrets Syncs secrets from Vault into K8s
longhorn-system Persistent storage orchestration

You will mostly work in hst- namespaces. You rarely need to touch system namespaces.

Using Namespaces with kubectl

When running kubectl commands, you specify the namespace with -n:

# List Pods in the bizdom namespace
kubectl get pods -n hst-bizdom

# List all Pods across all namespaces
kubectl get pods -A

If you forget -n, kubectl uses the default namespace, which is usually empty. Always specify the namespace.

Key Takeaways

  • Namespaces isolate resources within the cluster, like separate rooms in a building
  • Client namespaces always start with hst- followed by the client name
  • Always specify -n <namespace> when using kubectl

What Is Next

Next up: Secrets and ConfigMaps where you will learn how applications get their passwords and settings.

Back to top