Kubernetes allows nodes to be annotated with arbitrary key–value labels. These labels can then be referenced by pods using nodeSelector or the more expressive nodeAffinity rules.

For example, nodes might be labeled to reflect:

• CPU architecture or microarchitecture
• NUMA topology
• Kernel configuration
• Kernel page size (4K vs 64K)
• Performance profile applied using tuned to the host

A simple example label might look like:

Copy
kubectl label nodes node1 disktype=ssd

Pods can then express a preference or requirement for nodes with that capability:

Copy
affinity: 
  nodeAffinity: 
    requiredDuringSchedulingIgnoredDuringExecution: 
      nodeSelectorTerms: 
        - matchExpressions: 
            - key: disktype 
              operator: In 
              values: 
                - "ssd"

This allows Kubernetes to place workloads on nodes that are known to be configured in a way that benefits them, without embedding node names or relying on manual scheduling.

One concrete example where node-level configuration can matter is kernel page size. On Arm64 systems, for base kernel page size, Linux supports page sizes of 4K (the default page size), 16K, and 64K. On x86 systems, the base kernel page size is fixed at 4K.

Larger page sizes can reduce TLB pressure and improve performance for applications with large heaps or memory footprints — including many JVM-based workloads. When adding new compute nodes to your Kubernetes cluster, it is possible to provision nodes with different kernel page sizes and label them accordingly, allowing you to steer suitable workloads to those nodes.

However, this is an area where managed Kubernetes services impose real constraints. On hosted Kubernetes platforms such as OKE, the changes that you can make to kernel configuration on managed node pools are limited. In those environments, workload placement must focus on higher-level characteristics such as instance type, CPU count, or memory capacity.

Workload placement in Kubernetes can happen both during initial scheduling and during the regular operation of an application – for example, when a compute node is put into maintenance mode or experiences CPU or memory pressure, workloads can be moved from one node to another. Kubernetes uses node affinity rules to determine on which nodes workloads may be scheduled during these events.

Kubernetes lets you choose between:

• Hard requirements (requiredDuringSchedulingIgnoredDuringExecution)
• Soft preferences (preferredDuringSchedulingIgnoredDuringExecution)

For characteristics that are essential to correct behavior, hard requirements make sense. For performance optimizations—such as preferring nodes with larger page sizes or specific tuning profiles, it’s often better to express a preference, allowing the scheduler to fall back gracefully if ideal nodes are temporarily unavailable.

This distinction is particularly important for Java services in elastic environments, where strict placement rules can reduce scheduling flexibility and impact availability. From a practical standpoint:

• Use node labels to describe capabilities, not roles
• Prefer affinity rules over hard-coded node names
• Treat advanced host characteristics (like page size) as opt-in optimizations
• Accept that managed Kubernetes services limit how far down the stack you can tune

Workload placement won’t magically fix an under-provisioned or poorly tuned JVM, but when combined with explicit resource allocation, it ensures your application is running on infrastructure that can actually deliver the performance you expect.

CPU pinning is enabled through the combination of:

• Guaranteed quality of service
• Static CPU Manager policy

The CPU Manager capability allows administrators to support the exclusive reservation of CPU cores for a container. To be eligible for CPU pinning, a pod must request and limit an integer number of CPUs, and these amounts must be identical. Fractional CPU requests (for example, 1500 millicores) are not eligible for pinning. In the resource requests for a pod (or ReplicaSet/Deployment), the CPU request and limit must match. For example:

Copy
resources: 
  requests: 
    cpu: "2" 
    memory: "4Gi" 
  limits: 
    cpu: "2" 
    memory: "4Gi" 

On the node, the kubelet must be configured with:

Copy
--cpu-manager-policy=static 

With this policy enabled, Kubernetes assigns exclusive cores to eligible pods and removes those cores from the shared scheduling pool. These cores are then exposed to the container via a CPU set.

Inside the container, this is visible as:

Copy
cat /sys/fs/cgroup/cpuset.cpus 

The container and all processes inside it may execute only on those cores.

Pinned containers still respect CPU limits, but the enforcement model changes. For pinned workloads, CPU throttling largely disappears. The container can use 100% of its assigned cores, and CPU usage is bounded by which cores it owns, not by time slices. This distinction matters for performance-sensitive workloads. When CPU time is delivered consistently on the same cores, applications benefit from:

• Improved cache locality
• Reduced scheduler migration and context switches
• More stable latency under load

For JVM-based workloads, this also means that the JVM’s view of available processors aligns closely with the physical execution model, making GC and JIT heuristics more predictable.

CPU pinning is not a universal recommendation. It makes the most sense when workloads are latency-sensitive, and CPU usage is sustained and predictable – otherwise you are reserving resources that could be used by other tasks. For highly elastic services that scale up or down based on demand, CPU pinning can reduce scheduling flexibility and make capacity management harder.

So far, we’ve focused on how Kubernetes allocates resources and places workloads. The final lever to consider lives one layer below the scheduler: how the operating system on the compute node itself is configured. Even with identical hardware and identical container resource limits, differences in host tuning can materially affect latency, throughput, and predictability.

On Linux, the easiest way to manage host-level performance tuning is the tuned service, using the tuned-adm tool. A set of predefined profiles for tuned are provided out of the box that adjust kernel and system settings—such as CPU frequency scaling, scheduler behavior, power management, and I/O parameters—to favor different workload characteristics. Some of the profiles that are well suited to Kubernetes compute nodes are:

• Throughput-performance: Optimizes for maximum sustained throughput. This profile typically disables aggressive power-saving features, keeps CPUs at higher frequencies, and favors throughput-oriented scheduler behavior.
• Latency-performance: Prioritizes reduced scheduling latency and jitter. This profile often disables CPU power management features and may adjust scheduler parameters to reduce wake-up latency.
• Balanced: This profile is usually the default on Linux distributions out of the box. This profile is a compromise between power efficiency and performance, and offers the best experience on desktops and laptops. This is often the default profile on cloud images but is not the best match for performance-sensitive workloads.

For most production Kubernetes clusters running performance-sensitive Java services, throughput-performance is a reasonable default. For latency-sensitive workloads, such as RPC-heavy services or event-driven systems, latency-performance may be a better fit, particularly when combined with CPU pinning and explicit resource allocation.

The key point is consistency: all nodes intended to run a given class of workload should use the same tuned profile, and be grouped into a single node pool, with a shared tag for workload placement. Mixing profiles within a node pool can lead to difficult-to-diagnose performance variability.

In self-managed Kubernetes environments, tuned is typically configured directly on the node operating system using automation tooling. A typical workflow looks like this:

• Infrastructure provisioning: Nodes are created as virtual machines or bare metal instances using an infrastructure-as-code tool such as Terraform, choosing the instance type, disk layout, and base operating system image
• Operating system configuration: As part of node initialization, tools like cloud-init, Ansible, or Puppet are used to configure the operating system. At this stage, you can install and activate the tuned service and choose a tuned profile using tuned-adm profile <profile-name>. Note that when using tuned inside a virtual machine or cloud instance, settings apply to the virtualized CPU cores – some settings, such as the CPU governor settings for the CPU core, are controlled at the host operating system level.
• Attach the compute node to Kubernetes: Once the OS is tuned, and the kubelet is installed and started, the node joins the cluster and can be labelled immediately with the tuned profile that has been applied.

Once a tuned profile is applied, it affects all workloads running on that node. Kubernetes itself is unaware of the tuning change, which makes tagging critical when adding new nodes. New compute nodes can be tagged with:

Copy
kubectl label nodes node1 tuned-profile=throughput-performance 

or whichever tuned profile was applied.

Workloads can then express placement preferences using node affinity, with hard requirements for workloads that depend on a specific tuning, or with soft requirements when a certain profile is preferable but not required.

On managed Kubernetes services, your ability to control tuned varies. Some platforms expose limited tuning options via node pools or instance templates; others lock down host configuration entirely. In those environments, tuned-based tuning may not be possible, and workload placement must rely on higher-level characteristics such as instance type or CPU generation.

A warning: tuned will not compensate for undersized resource requests or poorly chosen JVM settings, and it will not turn a general-purpose Kubernetes node into a real-time system. However, when used deliberately, it provides a clean and supportable way to align host behavior with workload intent.