From a21359a765d1d451524d92b23b48c65e74430fab 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 --- .../en/docs/concepts/scheduling-eviction/assign-pod-node.md | 4 ++-- 1 file changed, 2 insertions(+), 2 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..377e28498a59c 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,11 @@ 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. -{{}} +{{}} Here is an example of a Pod spec using the `nodeName` field: