In this lesson, you will learn how to restrict specific namespaces to dedicated hardware using node selectors and affinity rules to enhance performance and isolation for sensitive workloads.
In a shared Kubernetes cluster, pods are usually free to land on any available node. However, sometimes you need to ensure that a specific application—perhaps a high-performance database or a security-sensitive service—runs only on specialized, high-capacity, or isolated hardware. While we use Namespaces to logically isolate resources, they do not inherently restrict where a pod lives. We bridge this gap by combining node labeling with scheduling constraints.
Step 1: Labeling your Nodes
First, we mark specific nodes in our cluster to identify their purpose. For example, you might label a high-performance node for your "Production" namespace:
kubectl label nodes node-01 disk-type=ssd
Step 2: Constraining Pods
To ensure pods within your sensitive namespace stay on these nodes, you can use a nodeSelector in your pod template. This acts as a hard filter:
spec:
nodeSelector:
disk-type: ssd
If you need more complex logic, such as "preferring" a node but allowing a fallback, you can use Node Affinity. Unlike a simple selector, affinity rules allow for "soft" requirements (preferred during scheduling) or "hard" requirements (required during scheduling).
Why use this for Namespaces?
By applying these rules to all deployments within a specific Namespace, you create a "logical boundary" that extends into your physical infrastructure. This is particularly useful for:
- Performance: Keeping resource-hungry workloads off general-purpose nodes.
- Compliance: Ensuring data-sensitive pods only run on nodes that meet specific security hardening or encryption standards.
- Cost Management: Directing batch processing jobs to cheaper, preemptible nodes while keeping critical services on reliable, high-uptime instances.
By combining Namespaces for organizational access control with node-level scheduling constraints, you ensure that your cluster’s hardware is utilized efficiently while guaranteeing that your most important applications receive the exact environment they require to thrive.
Key Takeaway: Use node labels combined with node selectors or affinity rules to enforce physical hardware boundaries for your logical Kubernetes namespaces, ensuring critical workloads run only on the infrastructure they require.