From 0b15eccf6d9f40d28cb0283ab86f73b29ccb1d23 Mon Sep 17 00:00:00 2001 From: Aldo Culquicondor Date: Tue, 26 Mar 2024 15:26:01 +0000 Subject: [PATCH] Upgrade note about nodeName to warning --- .../docs/concepts/scheduling-eviction/assign-pod-node.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md index bb6ce8d416112..374f044b5fee6 100644 --- a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -586,11 +586,12 @@ Some of the limitations of using `nodeName` to select nodes are: for example OutOfmemory or OutOfcpu. - Node names in cloud environments are not always predictable or stable. -{{< note >}} +{{< warning >}} `nodeName` is intended for use by custom schedulers or advanced use cases where you need to bypass any configured schedulers. Bypassing the schedulers might lead to -failed Pods if the assigned Nodes get oversubscribed. You can use the [node affinity](#node-affinity) or the [`nodeselector` field](#nodeselector) to assign a Pod to a specific Node without bypassing the schedulers. -{{}} +failed Pods if the assigned Nodes get oversubscribed. You can use [node affinity](#node-affinity) +or the [`nodeSelector` field](#nodeselector) to assign a Pod to a specific Node without bypassing the schedulers. +{{}} Here is an example of a Pod spec using the `nodeName` field: