Overcoming Kubernetes Namespace Limitations

What Are Namespaces?

Namespaces provide logical partitioning for managing Kubernetes resource allocation, access control, and configuration management. They allow developers to manage multiple applications and environments within the same Kubernetes cluster.

This proves beneficial when running unrelated applications in different namespaces or deploying different versions (dev, test, production) of the same application in a single cluster.

Example Setup

Consider two applications maintained by separate teams:

• App1: E-commerce website (Team1)
• App2: Order and customer management backend (Team2)

Both need deployment in the same cluster for cost optimization.

Creating Namespaces

The first step involves creating separate namespaces for each application using kubectl commands to isolate resources.

Configuring Access Control

Role-Based Access Control (RBAC) policies limit user and service account access to resources within each namespace. Resource quotas restrict CPU usage -- for example, allocating 80% cluster CPU to App1 and 10% to App2.

Managing Permissions

Roles define what actions teams can perform (such as managing deployments). RoleBindings associate these roles with specific teams, granting appropriate deployment rights.

Namespace Limitations

Despite their utility, namespaces have notable constraints:

Lack of Ownership Concept: Teams managing multiple microservices with distinct secrets and quotas face challenges. Kubernetes lacks common ownership across multiple namespaces, making uniform policy application difficult.

Administrative Overhead: Creating namespaces requires high-level cluster privileges. Developers must request new namespaces from administrators, creating unnecessary administrative work in larger organizations.

Hierarchical Namespaces Solution

The Kubernetes Hierarchical Namespace Controller (HNC) addresses these issues by introducing parent-child namespace relationships, extending ownership beyond individual namespaces.

HNC enables two key behaviors:

Policy Inheritance: Policy objects like RBAC RoleBindings copy automatically from parent namespaces to child namespaces.

Delegated Creation: Subnamespaces can be created with limited permissions, eliminating cluster-level privilege requirements for developers.

This approach allows cluster administrators to establish a "root" namespace with necessary policies, then delegate subnamespace creation to team members.

Cloud Foundry Korifi Alternative

Open source Korifi provides cloud-native application delivery for Kubernetes while addressing multi-tenancy concerns. It replicates Cloud Foundry's RBAC syntax, enabling organizations familiar with Cloud Foundry Orgs, Spaces, Roles, and Permissions to apply that knowledge directly to Kubernetes clusters.

Like Hierarchical Namespaces, Korifi grants users permissions across entire organizational units and all contained spaces.

Critical Consideration

A common misconception: while namespaces provide logical isolation at the API level, they do not inherently provide network isolation. Achieving network isolation between namespaces requires Network Policies, a separate Kubernetes feature.