Recap Namespaces

Welcome to this detailed overview of Kubernetes namespaces. In this lesson, we'll explore how namespaces help organize resources within your cluster using a simple analogy and practical examples. This guide is designed to improve your understanding and management of namespaces in various environments.

Imagine two boys named Mark. To differentiate between them, their last names—Smith and Williams—are used. Within their respective houses, family members refer to them by their first names. However, when addressing someone from a different house, the full name is used. Similarly, in Kubernetes, namespaces act like houses, each with its own set of rules and resources.

Up until now, objects such as Pods, Deployments, and Services have been created in a single namespace—the default namespace—which is automatically generated when the cluster is set up. Kubernetes also creates several internal namespaces:

• The kube-system namespace contains system components (e.g., networking and DNS services) and keeps them isolated from user modifications.
• The kube-public namespace is designed for resources that should be accessible to all users.

For small environments, learning purposes, or experimental setups, you might work exclusively in the default namespace. However, in enterprise or production settings, creating additional namespaces helps isolate resources. For instance, you can use separate namespaces for development and production to prevent accidental modifications and enforce specific policies and resource quotas.

Each namespace can enforce its own set of policies and quotas. This ensures that every namespace receives a guaranteed portion of resources and remains within its limits.

Within a namespace, resources can simply refer to one another by name—just as family members within a house use only first names. For example, a web application pod in the default namespace can access a database service using the service's hostname.

When a pod needs to access a service in another namespace, append the namespace to the service name using the following format:

python
mysql.connect("db-service.namespace.svc.cluster.local")

For example, if a pod in the default namespace needs to connect to a database in the "dev" namespace:

python
mysql.connect("db-service.dev.svc.cluster.local")

This works because Kubernetes automatically creates a DNS entry for each service using the format: service-name.namespace.svc.cluster.local
Here, "cluster.local" is the default domain name of the cluster, and "svc" is the subdomain for services.

Operational Aspects with kubectl Commands

Below are some examples of how to work with namespaces using kubectl commands:

bash
> kubectl get pods
> kubectl get pods --namespace=kube-system
> kubectl get pods --namespace=prod

Creating and Managing Pods

Consider a pod definition file that creates a pod in the default namespace:

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
    type: front-end
spec:
  containers:
    - name: nginx-container
      image: nginx

To create the pod in a different namespace (e.g., "dev"), run:

bash
> kubectl create -f pod-definition.yml --namespace=dev

If you want to ensure the pod is always created in the "dev" namespace, add the namespace within the pod definition file under the metadata section.

Creating Namespaces

Creating a new namespace is as straightforward as creating other Kubernetes objects. Below is an example YAML file for a namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: dev

Once prepared, create the namespace using:

bash
> kubectl create -f namespace-definition.yml

Alternatively, you can create a namespace via the command line:

bash
> kubectl create namespace dev

Setting the Default Namespace

If you work with multiple namespaces, setting a default namespace in your current context can streamline your workflow:

bash
kubectl config set-context $(kubectl config current-context) --namespace=dev

After running this, simple commands like kubectl get pods will operate within the "dev" namespace. To list pods across all namespaces, use:

bash
> kubectl get pods --all-namespaces

Managing Resource Quotas

Resource quotas help control resource usage within a namespace. Use a ResourceQuota definition file to limit resources. For example, the following YAML sets resource limits for the "dev" namespace:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: dev
spec:
  hard:
    pods: "10"
    requests.cpu: "4"
    requests.memory: 5Gi
    limits.cpu: "10"
    limits.memory: 10Gi

Deploy this resource quota with:

bash
> kubectl create -f compute-quota.yaml

Practice these namespace techniques to efficiently manage your Kubernetes clusters. For more details on Kubernetes concepts and best practices, visit the Kubernetes Documentation.