Understanding Namespaces in Kubernetes: Imperative vs Declarative Approaches & Resources Not Specific to Namespaces

In the world of Kubernetes (K8s), namespaces are an essential concept for managing and organizing resources within a cluster. Whether you're managing a small development environment or a large-scale production system, namespaces provide a way to isolate and group related objects for better organization, access control, and resource management.

In this blog, we'll take a deep dive into Kubernetes namespaces, exploring their use cases, comparing imperative vs. declarative approaches for managing resources, and discussing which resources are not bound to a specific namespace.

What Are Namespaces in Kubernetes?

In Kubernetes, a namespace is a logical partition of a cluster that allows you to group resources. Namespaces help you organize objects like pods, services, deployments, and configmaps, providing a way to manage resources effectively in multi-tenant environments. They offer isolation between different applications, teams, or environments within the same cluster.

For example, you can use namespaces to:

• Isolate production and development environments.
• Segment resources by team or project.
• Manage resource quotas and access control on a per-namespace basis.
• Simplify security policies and networking between isolated environments.

By default, Kubernetes includes several built-in namespaces:

• default: The default namespace for resources that are not assigned a specific namespace.
• kube-system: The namespace for Kubernetes system components like controllers, services, and DNS.
• kube-public: A namespace that is readable by all users (including unauthenticated users), commonly used for public resources like cluster information.
• kube-node-lease: For managing node lease data to improve performance and reliability.

Namespace Usage Example

Imagine you have a Kubernetes cluster used by multiple teams. You might have:

• A dev namespace for development workloads.
• A prod namespace for production services.
• A qa namespace for testing.

Each namespace can have its own set of resources (e.g., deployments, pods, services) without interfering with other namespaces.

Imperative vs Declarative Approaches in Kubernetes

When working with Kubernetes resources (including namespaces), you generally have two approaches to managing your resources: imperative and declarative. Each approach has its own benefits and trade-offs, and the choice depends on your operational needs and environment.

Imperative Approach

In the imperative approach, you directly issue commands to Kubernetes to create, update, or delete resources. This approach is often quick and simple for tasks that need immediate effect but can become cumbersome when managing large, complex configurations.

Example of Imperative Commands

# Create a namespace using an imperative command
kubectl create namespace dev

# Create a deployment in the "dev" namespace
kubectl run myapp --image=nginx --namespace=dev

In this approach, you're instructing Kubernetes directly to perform a specific action. While it’s useful for quick tasks or one-off changes, it doesn’t provide an easy way to track or manage configurations over time.

Advantages:

• Quick and easy for single, ad-hoc changes.
• Best suited for one-off tasks or during experimentation.
• Ideal for quick troubleshooting and debugging.

Disadvantages:

• Less reproducible: Hard to track changes or manage configurations in the long run.
• Lacks version control: Difficult to know what exactly was changed over time.

Declarative Approach

The declarative approach involves defining your desired state of the system in configuration files (typically YAML or JSON), and then applying these configurations to Kubernetes using commands like kubectl apply. With declarative management, you describe what you want to happen (desired state), and Kubernetes ensures that the actual state matches that description.

Example of Declarative Commands

# namespace.yaml: Define the desired namespace in a YAML file
apiVersion: v1
kind: Namespace
metadata:
  name: dev
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  namespace: dev
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: nginx
        image: nginx

# Apply the declarative configuration to create resources
kubectl apply -f namespace.yaml

Advantages:

• Declarative configurations are version-controlled and easy to maintain.
• Supports infrastructure-as-code principles, allowing reproducibility and consistency.
• Easier to track changes, roll back, and collaborate with others.
• Kubernetes takes care of managing the resources, ensuring they match the defined state.

Disadvantages:

• May take more time to set up than imperative commands.
• Requires maintaining YAML or JSON files for configurations.

Which Kubernetes Resources Are Not Specific to Namespaces?

While many resources in Kubernetes are namespace-scoped, there are certain resources that exist outside of any namespace. These resources are considered cluster-wide and are not confined to a specific namespace.

Cluster-Wide Resources in Kubernetes

1.Nodes

• Nodes are the physical or virtual machines that run your workloads in Kubernetes. They are part of the overall cluster and are not tied to any specific namespace.

   kubectl get nodes

2.Persistent Volumes (PV)

• Persistent Volumes represent physical storage in the cluster and are managed at the cluster level. While Persistent Volume Claims (PVCs) are namespace-scoped, the Persistent Volume (PV) itself is not.

   kubectl get pv

3.ClusterRole & ClusterRoleBinding

• ClusterRoles define a set of permissions that apply to the whole cluster, regardless of namespaces. Similarly, ClusterRoleBindings grant these permissions to users or service accounts.

   kubectl get clusterrole
   kubectl get clusterrolebinding

4.Namespaces (themselves)

• Interestingly, the Namespace resource is not contained within another namespace. It is a cluster-wide resource that defines a logical partitioning of the cluster.

   kubectl get namespaces

5.Custom Resource Definitions (CRDs)

• CRDs are used to define custom resources in Kubernetes, but the CRD itself is a cluster-wide resource. Instances of custom resources created using CRDs, however, are namespace-scoped.

   kubectl get crd

6.API Aggregator Resources (API Services)

• These are part of the Kubernetes API aggregation layer, which allows external APIs to be exposed to the Kubernetes cluster. They are not tied to a specific namespace.

   kubectl get apiservices

7.Service Accounts

• While Service Accounts are typically namespace-scoped, Cluster-wide Service Accounts are part of the control plane, giving access to cluster-wide services.

Conclusion

Namespaces in Kubernetes provide an essential mechanism for organizing and managing cluster resources, particularly in multi-tenant environments. They offer isolation and effective resource management, allowing you to segment workloads based on teams, applications, or environments.

When managing resources in Kubernetes, you can choose between an imperative approach for quick, ad-hoc changes or a declarative approach for long-term, consistent management. While imperative commands are helpful for troubleshooting or experimenting, the declarative approach provides a more scalable and reproducible method for infrastructure management.

Finally, while most Kubernetes resources are tied to namespaces, certain key resources (like nodes, persistent volumes, and cluster roles) exist at the cluster level, not bound to any namespace.

By understanding how namespaces work and the difference between imperative and declarative management, you can better organize and control your Kubernetes environment to meet your operational needs.