Repository: kubernetes-sigs/kueue

Issue:
Document KueueViz installation in a production suitable documentation
<!-- Please only use this template for submitting clean up requests -->

**What would you like to be cleaned**:

Document KueueViz installation in a production suitable documentation

**Why is this needed**:

KueueViz is getting promoted form experimental to non-experimental and aims to reach production release.
For this to happen, users need a properly documentation installation process available on kueue website.


Hints from issue comments:
@akram: /kind dashboard
@akram: /kind documentation

@kafonek: @akram if it helps, here's my experience deploying KueueViz:

Local (docker-desktop) deployment: 
  - `kubectl port-forward svc/kueue-kueue-viz-frontend -n kueue-system 8080`
  - `kubectl port-forward svc/kueue-kueue-viz-backend  -n kueue-system 8081:8080`
  - Edit the `kueue-viz-frontend` Deployment to set env `REACT_APP_WEBSOCKET_URL=ws://localhost:8081`


For a multi-user cluster that controls ingress through Twingate-style software defined perimeter, the setup was roughly the same just switch out `kubectl port-forward` with defined uris. One small quality of life change would be defining the backend uri in the helm chart. 

@akram: @kafonek thank you for the feedback. This is also what I use for local testing. And I want to document the different cases like:
- vanilla kubernetes with ingress controller installed
- kubernetes without ingress controller
- optionally OpenShift

all these 3 scenarios works but requires a bit of guidance


@tenzen-y: /remove-kind cleanup@mimowo: /help wanted
I think this could be a subpage under https://kueue.sigs.k8s.io/docs/tasks/manage/, say "Enable KueueViz". 

cc @kannon92 @akram do you know some folks with cycles to prepare such a doc?@mimowo: /help-wanted@mimowo: /good-first-issue@k8s-ci-robot: @mimowo: 
	This request has been marked as suitable for new contributors.

### Guidelines
Please ensure that the issue body includes answers to the following questions:
- Why are we solving this issue?
- To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
- How can the assignee reach out to you for help?


For more details on the requirements of such an issue, please see [here](https://www.kubernetes.dev/docs/guide/help-wanted/#good-first-issue) and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the `/remove-good-first-issue` command.


<details>

In response to [this](https://github.com/kubernetes-sigs/kueue/issues/4755):

>/good-first-issue


Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md).  If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
</details>@samzong: /assign samzong

This may take some time. I need to set up the local environment for kueue, and I also hope to make more types of contributions.@samzong: - #5988

I have completed the initial the doc. help review it pls.

thanks.


Solution patch:
diff --git a/pkg/cache/clusterqueue.go b/pkg/cache/clusterqueue.go
index 98879d509..e0378decc 100644
--- a/pkg/cache/clusterqueue.go
+++ b/pkg/cache/clusterqueue.go
@@ -120,8 +120,7 @@ var defaultFlavorFungibility = kueue.FlavorFungibility{WhenCanBorrow: kueue.Borr
 func (c *clusterQueue) updateClusterQueue(log logr.Logger, in *kueue.ClusterQueue, resourceFlavors map[kueue.ResourceFlavorReference]*kueue.ResourceFlavor, admissionChecks map[kueue.AdmissionCheckReference]AdmissionCheck, oldParent *cohort) error {
 	if c.updateQuotasAndResourceGroups(in.Spec.ResourceGroups) || oldParent != c.Parent() {
 		if oldParent != nil && oldParent != c.Parent() {
-			// ignore error when old Cohort has cycle.
-			_ = updateCohortTreeResources(oldParent)
+			updateCohortTreeResourcesIfNoCycle(oldParent)
 		}
 		if c.HasParent() {
 			// clusterQueue will be updated as part of tree update.
diff --git a/pkg/cache/cohort.go b/pkg/cache/cohort.go
index edd557207..2f842b2bf 100644
--- a/pkg/cache/cohort.go
+++ b/pkg/cache/cohort.go
@@ -48,8 +48,7 @@ func (c *cohort) updateCohort(apiCohort *kueue.Cohort, oldParent *cohort) error
 
 	c.resourceNode.Quotas = createResourceQuotas(apiCohort.Spec.ResourceGroups)
 	if oldParent != nil && oldParent != c.Parent() {
-		// ignore error when old Cohort has cycle.
-		_ = updateCohortTreeResources(oldParent)
+		updateCohortTreeResourcesIfNoCycle(oldParent)
 	}
 	return updateCohortTreeResources(c)
 }
diff --git a/pkg/controller/jobframework/reconciler.go b/pkg/controller/jobframework/reconciler.go
index a48944fc7..b5cda36a4 100644
--- a/pkg/controller/jobframework/reconciler.go
+++ b/pkg/controller/jobframework/reconciler.go
@@ -310,6 +310,18 @@ func (r *JobReconciler) ReconcileGenericJob(ctx context.Context, req ctrl.Reques
 		return ctrl.Result{}, client.IgnoreNotFound(err)
 	}
 
+	if features.Enabled(features.ManagedJobsNamespaceSelectorAlwaysRespected) {
+		ns := corev1.Namespace{}
+		if err := r.client.Get(ctx, client.ObjectKey{Name: req.Namespace}, &ns); err != nil {
+			log.Error(err, "failed to get namespace for selector check")
+			return ctrl.Result{}, err
+		}
+		if !r.managedJobsNamespaceSelector.Matches(labels.Set(ns.GetLabels())) {
+			log.V(2).Info("Namespace not opted in for Kueue management", "namespace", ns.Name)
+			return ctrl.Result{}, nil
+		}
+	}
+
 	var (
 		ancestorJob   client.Object
 		isTopLevelJob bool
diff --git a/pkg/controller/jobs/pod/pod_controller.go b/pkg/controller/jobs/pod/pod_controller.go
index 4cea3e67c..e67b9bad9 100644
--- a/pkg/controller/jobs/pod/pod_controller.go
+++ b/pkg/controller/jobs/pod/pod_controller.go
@@ -164,39 +164,37 @@ var (
 	_ jobframework.TopLevelJob                     = (*Pod)(nil)
 )
 
-type options struct {
-	excessPodExpectations *expectations.Store
-	clock                 clock.Clock
-}
-
-type PodOption func(*options)
+// PodOption is a function type that modifies a Pod. It allows customization of a Pod's
+// properties during its creation.
+type PodOption func(pod *Pod)
 
+// WithExcessPodExpectations sets the excessPodExpectations field of the Pod to the given expectations store.
+// This allows customizing the expectations for excess pods that are tracked by the Pod.
 func WithExcessPodExpectations(store *expectations.Store) PodOption {
-	return func(o *options) {
-		o.excessPodExpectations = store
+	return func(pod *Pod) {
+		pod.excessPodExpectations = store
 	}
 }
 
-func WithClock(c clock.Clock) PodOption {
-	return func(o *options) {
-		o.clock = c
+// WithClock sets the clock field of the Pod to the given clock. This allows the Pod to
+// use a custom clock instead of the default one.
+func WithClock(clock clock.Clock) PodOption {
+	return func(pod *Pod) {
+		pod.clock = clock
 	}
 }
 
-var defaultOptions = options{
-	clock: realClock,
-}
-
+// NewPod creates a new Pod with the provided options. It applies all the given PodOptions
+// to customize the Pod's fields. By default, the Pod is created with a real clock, unless
+// overridden by a WithClock option.
 func NewPod(opts ...PodOption) *Pod {
-	options := defaultOptions
-	for _, opt := range opts {
-		opt(&options)
+	pod := &Pod{
+		clock: realClock, // Default clock is set to realClock.
 	}
-
-	return &Pod{
-		excessPodExpectations: options.excessPodExpectations,
-		clock:                 options.clock,
+	for _, opt := range opts {
+		opt(pod) // Apply each option to the pod.
 	}
+	return pod
 }
 
 func FromObject(o runtime.Object) *Pod {
diff --git a/pkg/features/kube_features.go b/pkg/features/kube_features.go
index b15a73818..80da7e707 100644
--- a/pkg/features/kube_features.go
+++ b/pkg/features/kube_features.go
@@ -167,6 +167,13 @@ const (
 	//
 	// In TAS, treat node as failed if the node is not ready and the pods assigned to this node terminate.
 	TASReplaceNodeOnPodTermination featuregate.Feature = "TASReplaceNodeOnPodTermination"
+
+	// owner: @PannagaRao
+	// kep: https://github.com/kubernetes-sigs/kueue/tree/main/keps/3589-manage-jobs-selectively
+	//
+	// Enforces that even Jobs with a queue-name label are only reconciled if their namespace
+	// matches managedJobsNamespaceSelector.
+	ManagedJobsNamespaceSelectorAlwaysRespected featuregate.Feature = "ManagedJobsNamespaceSelectorAlwaysRespected"
 )
 
 func init() {
@@ -259,6 +266,9 @@ var defaultVersionedFeatureGates = map[featuregate.Feature]featuregate.Versioned
 	TASReplaceNodeOnPodTermination: {
 		{Version: version.MustParse("0.13"), Default: false, PreRelease: featuregate.Alpha},
 	},
+	ManagedJobsNamespaceSelectorAlwaysRespected: {
+		{Version: version.MustParse("0.13"), Default: false, PreRelease: featuregate.Alpha},
+	},
 }
 
 func SetFeatureGateDuringTest(tb testing.TB, f featuregate.Feature, value bool) {
diff --git a/site/content/en/docs/tasks/manage/enable_kubeviz.md b/site/content/en/docs/tasks/manage/enable_kubeviz.md
new file mode 100644
index 000000000..5b3643d3c
--- /dev/null
+++ b/site/content/en/docs/tasks/manage/enable_kubeviz.md
@@ -0,0 +1,177 @@
+---
+title: "Enable KueueViz"
+date: 2025-07-18
+weight: 12
+description: >
+  Installing and configuring KueueViz, a web-based visualization tool for Kueue workload monitoring.
+---
+
+{{% alert title="Note" color="primary" %}}
+For a streamlined installation and simplified upgrades, we recommend deploying Kueue using Helm.  
+You can customize the deployment with a local `values.yaml` file to fit your environment.  
+See the [Helm chart installation guide](/docs/installation/#install-by-helm) for full instructions.
+{{% /alert %}}
+
+KueueViz is a web-based visualization tool that provides real-time monitoring of Kueue workloads, queues, and resource allocation. It offers an intuitive dashboard for observing job queue status, resource utilization, and workload progression.
+
+This page shows how to install and configure KueueViz in your cluster.
+
+The page is intended for [batch administrators](/docs/tasks#batch-administrator).
+
+## Before you begin
+
+Make sure the following conditions are met:
+
+- A Kubernetes cluster is running
+- The kubectl command-line tool has communication with your cluster
+- The Helm command-line tool is installed
+- Kueue is installed in your cluster
+- (Optional) An ingress controller for external access (e.g. Nginx Ingress Controller)
+
+KueueViz can be installed using Helm (recommended), or kubectl. Choose the method that best fits your workflow.
+
+## Installation with Kueue
+
+To install KueueViz as part of a new Kueue installation:
+
+```bash
+helm install kueue oci://registry.k8s.io/kueue/charts/kueue \
+  --version={{< param "chart_version" >}} \
+  --namespace kueue-system \
+  --create-namespace \
+  --set enableKueueViz=true \ # enable KueueViz
+  --wait --timeout 300s
+```
+
+For more information on installing Kueue, please refer to [Installation](/docs/installation).
+
+## Enable KueueViz (Kueue is already installed)
+
+If Kueue is already installed, you can enable KueueViz by Helm or kubectl.
+
+### Enable KueueViz by Helm
+
+To enable KueueViz on an existing Kueue installation by Helm:
+
+```bash
+helm upgrade kueue oci://registry.k8s.io/kueue/charts/kueue \
+  --version={{< param "chart_version" >}} \
+  --namespace kueue-system \
+  --set enableKueueViz=true # enable KueueViz
+```
+
+### Enable KueueViz by YAML
+
+To enable KueueViz on an existing Kueue installation by YAML:
+
+```bash
+kubectl apply --server-side -f https://github.com/kubernetes-sigs/kueue/releases/download/{{< param "chart_version" >}}/kueueviz.yaml
+```
+
+## Accessing the Dashboard
+
+### Port Forwarding (Only for development)
+
+For quick access during development or testing(had tested by Docker Desktop):
+
+```bash
+kubectl port-forward svc/kueue-kueue-viz-frontend -n kueue-system 8080
+kubectl port-forward svc/kueue-kueue-viz-backend  -n kueue-system 8081:8080
+```
+
+Edit the kueue-viz-frontend Deployment to set env `REACT_APP_WEBSOCKET_URL=ws://localhost:8081`.
+
+Then access the dashboard at [http://localhost:8080](http://localhost:8080).
+
+### Ingress
+
+For production deployments, configure an Ingress resource:
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: kueueviz-ingress
+  namespace: kueue-system
+spec:
+  rules:
+    - host: kueueviz.example.com
+      http:
+        paths:
+          - path: /api(/|$)(.*)
+            pathType: Prefix
+            backend:
+              service:
+                name: kueue-kueueviz-backend
+                port:
+                  number: 8080
+          - path: /
+            pathType: Prefix
+            backend:
+              service:
+                name: kueue-kueueviz-frontend
+                port:
+                  number: 8080
+  tls:
+    - hosts:
+        - kueueviz.example.com # replace with your domain
+      secretName: kueueviz-tls # you need to create a TLS secret at first
+```
+
+### LoadBalancer
+
+For cloud environments with LoadBalancer support:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: kueueviz-loadbalancer
+  namespace: kueue-system
+spec:
+  type: LoadBalancer
+  ports:
+    - name: http
+      port: 80
+      targetPort: 8080
+      protocol: TCP
+  selector:
+    app.kubernetes.io/name: kueue
+    app.kubernetes.io/component: kueueviz-frontend
+```
+
+## Upgrade
+
+### Upgrade by Helm
+
+To upgrade KueueViz by Helm:
+
+```bash
+helm upgrade kueue oci://registry.k8s.io/kueue/charts/kueue \
+  --version={{< param "chart_version" >}} \
+  --namespace kueue-system \
+  --set enableKueueViz=true
+```
+
+### Upgrade by YAML
+
+To upgrade KueueViz by YAML:
+
+```bash
+kubectl apply --server-side -f https://github.com/kubernetes-sigs/kueue/releases/download/{{< param "chart_version" >}}/kueueviz.yaml
+```
+
+## Uninstall
+
+**Note:** Be sure to uninstall KueueViz, and not to accidentally uninstall Kueue instead.
+
+To uninstall KueueViz components:
+
+```bash
+kubectl delete -f https://github.com/kubernetes-sigs/kueue/releases/download/{{< param "chart_version" >}}/kueueviz.yaml
+```
+
+## What's next
+
+- Explore more [Tasks](/docs/tasks)
+- Learn about [Concepts](/docs/concepts)
diff --git a/site/content/zh-CN/docs/concepts/topology_aware_scheduling.md b/site/content/zh-CN/docs/concepts/topology_aware_scheduling.md
index 7943b210f..7d4aebdfc 100644
--- a/site/content/zh-CN/docs/concepts/topology_aware_scheduling.md
+++ b/site/content/zh-CN/docs/concepts/topology_aware_scheduling.md
@@ -1,163 +1,116 @@
 ---
-title: "Topology Aware Scheduling"
+title: "拓扑感知调度"
 date: 2024-04-11
 weight: 6
 description: >
-  Allows scheduling of Pods based on the topology of nodes in a data center.
+  允许基于数据中心节点拓扑结构调度 Pod。
 ---
 
 {{< feature-state state="alpha" for_version="v0.9" >}}
 
-It is common that AI/ML workloads require a significant amount of pod-to-pod
-communication. Therefore the network bandwidth between the running Pods
-translates into the workload execution time, and the cost of running
-such workloads. The available bandwidth between the Pods depends on the placement
-of the Nodes, running the Pods, in the data center.
+AI/ML 工作负载通常需要大量的 Pod 间通信。因此，运行 Pod
+之间的网络带宽会直接影响工作负载的执行时间和运行成本。
+Pod 之间的可用带宽取决于运行这些 Pod 的节点在数据中心中的分布。
 
-We observe that the data centers have a hierarchical structure of their
-organizational units, like racks and blocks, where there are multiple nodes
-within a rack, and there are multiple racks within a block. Pods running within
-the same organizational unit have better network bandwidth than Pods on
-different units. We say that nodes placed in different racks are more distant
-than nodes placed within the same rack. Similarly, nodes placed in different
-blocks are more distant than two nodes within the same block.
+我们观察到，数据中心的组织单元具有层次结构，如机架（rack）和区块（block），一个机架内有多个节点，
+一个区块内有多个机架。运行在同一组织单元内的 Pod 之间的网络带宽优于运行在不同单元的 Pod。
+我们认为，不同机架上的节点比同一机架内的节点距离更远。同理，不同区块的节点比同一区块内的节点距离更远。
 
-In this feature (called Topology Aware Scheduling, or TAS for short) we
-introduce a convention to represent the
-[hierarchical node topology information](#node-topology-information), and a set
-of APIs for Kueue administrators and users to utilize the information
-to optimize the Pod placement.
+本特性（称为拓扑感知调度，简称 TAS）引入了一种约定，用于表示[分层节点拓扑信息](#node-topology-information)，
+并为 Kueue 管理员和用户提供一组 API，以利用这些信息优化 Pod 的放置。
 
-### Node topology information
+### 节点拓扑信息 {#node-topology-information}
 
-We propose a lightweight model for representing the hierarchy of nodes within a
-data center by using node labels. In this model the node labels are set up by a
-cloud provider, or set up manually by administrators of on-premise clusters.
+我们提出了一种轻量级模型，通过节点标签来表示数据中心内节点的层次结构。在该模型中，节点标签由云服务商设置，或由本地集群管理员手动设置。
 
-Additionally, we assume that every node used for TAS has a set of the labels
-which identifies uniquely its location in the tree structure. We do not assume
-global uniqueness of labels on each level, i.e. there could be two nodes with
-the same "rack" label, but in different "blocks".
+此外，我们假设用于 TAS 的每个节点都带有一组标签，这些标签能唯一标识其在树状结构中的位置。
+我们不要求每一层标签全局唯一，即可能存在两个节点具有相同的 "rack" 标签，但位于不同的 "block"。
 
-For example, this is a representation of the data center hierarchy;
+例如，数据中心层次结构的表示如下：
 
-|  node  |  cloud.provider.com/topology-block | cloud.provider.com/topology-rack |
+|  节点  |  cloud.provider.com/topology-block | cloud.provider.com/topology-rack |
 |:------:|:----------------------------------:|:--------------------------------:|
 | node-1 |               block-1              |              rack-1              |
 | node-2 |               block-1              |              rack-2              |
 | node-3 |               block-2              |              rack-1              |
 | node-4 |               block-2              |              rack-3              |
 
-Note that, there is a pair of nodes, node-1 and node-3, with the same value of
-the "cloud.provider.com/topology-rack" label, but in different blocks.
+注意，node-1 和 node-3 虽然 "cloud.provider.com/topology-rack" 标签值相同，但位于不同的 block。
 
-### Capacity calculation
+### 容量计算
 
-For each PodSet TAS determines the current free capacity per each topology
-domain (like a given rack) by:
-- including Node allocatable capacity (based on the `.status.allocatable` field)
-  of only ready (with `Ready=True` condition) and schedulable (with `.spec.unschedulable=false`) Nodes,
-- subtracting the usage coming from all other admitted TAS workloads,
-- subtracting the usage coming from all other non-TAS Pods (owned mainly by
-  DaemonSets, but also including static Pods, Deployments, etc.).
+对于每个 PodSet，TAS 通过以下方式确定每个拓扑域（如某个机架）的当前可用容量：
+- 仅包括已就绪（`Ready=True` 条件）且可调度（`.spec.unschedulable=false`）节点的 Node 可分配容量（基于 `.status.allocatable` 字段），
+- 减去所有其他已准入 TAS 工作负载的用量，
+- 减去所有其他非 TAS Pod（主要由 DaemonSet 拥有，也包括静态 Pod、Deployment 等）的用量。
 
-### Admin-facing APIs
+### 管理员 API
 
-As an admin, in order to enable the feature you need to:
-1. ensure the `TopologyAwareScheduling` feature gate is enabled
-2. create at least one instance of the `Topology` API
-3. reference the `Topology` API from a dedicated ResourceFlavor by the
-   `.spec.topologyName` field
+作为管理员，启用该特性需：
+1. 确保已启用 `TopologyAwareScheduling` 特性门控（feature gate）
+2. 至少创建一个 `Topology` API 实例
+3. 通过 `.spec.topologyName` 字段在专用 ResourceFlavor 中引用 `Topology` API
 
-#### Example
+#### 示例
 
 {{< include "examples/tas/sample-queues.yaml" "yaml" >}}
 
-### User-facing APIs
-
-Once TAS is configured and ready to be used, you can create Jobs with the
-following annotations set at the PodTemplate level:
-- `kueue.x-k8s.io/podset-preferred-topology` - indicates that a PodSet requires
-	Topology Aware Scheduling, but scheduling all pods within pods on nodes
-	within the same topology domain is a preference rather than requirement.
-	The levels are evaluated one-by-one going up from the level indicated by
-	the annotation. If the PodSet cannot fit within a given topology domain
-	then the next topology level up is considered. If the PodSet cannot fit
-	at the highest topology level, then it gets admitted as distributed
-	among multiple topology domains.
-- `kueue.x-k8s.io/podset-required-topology` - indicates indicates that a PodSet
-  requires Topology Aware Scheduling, and requires scheduling all pods on nodes
-	within the same topology domain corresponding to the topology level
-	indicated by the annotation value (e.g. within a rack or within a block).
-
-#### Example
-
-Here is an example Job a user might submit to use TAS. It assumes there exists
-a LocalQueue named `tas-user-queue` which refernces the ClusterQueue pointing
-to a TAS ResourceFlavor.
+### 用户 API
+
+TAS 配置好并可用后，用户可在 PodTemplate 层级设置如下注解来创建 Job：
+- `kueue.x-k8s.io/podset-preferred-topology` —— 表示 PodSet 需要拓扑感知调度，
+  但所有 Pod 调度到同一拓扑域节点只是偏好而非强制。系统会自下而上逐级评估注解指定的层级。
+  如果 PodSet 无法适配某一拓扑域，则考虑上一级拓扑。如果在最高层级仍无法适配，
+  则会分布在多个拓扑域。
+- `kueue.x-k8s.io/podset-required-topology` —— 表示 PodSet 需要拓扑感知调度，
+  且要求所有 Pod 必须调度到注解值指定的拓扑层级（如同一机架或同一区块）内的节点。
+
+#### 示例
+
+以下是用户提交以使用 TAS 的 Job 示例。假设存在名为 `tas-user-queue` 的 LocalQueue，且其引用的 ClusterQueue 指向 TAS ResourceFlavor。
 
 {{< include "examples/tas/sample-job-preferred.yaml" "yaml" >}}
 
-### ClusterAutoscaler support
-
-TAS integrates with the [Kubernetes ClusterAutoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)
-through the [Provisioning AdmissionCheck](/docs/admission-check-controllers/provisioning/).
-
-When a workload is assigned to the TAS ResourceFlavor with Provisioning
-AdmissionCheck, then its admission flow has the following stages:
-1. **Quota reservation**: quota is reserved, and the Workload obtains the
-  `QuotaReserved` condition. Preemptions are evaluated if configured.
-2. **Admission checks**: Kueue waits for all AdmissionChecks, including the
-  Provisioning one, to report `Ready` inside the Workload's
-  `status.admissionChecks` field.
-3. **Topology assignment**: Kueue sets topology assignment, on the Workload
-  object, calculated taking into account any newly provisioned nodes.
-
-Check also [PodSet updates in ProvisioningRequestConfig](site/content/en/docs/admission-check-controllers/provisioning.md)
-to see how you can configure Kueue if you want to restrict scheduling to the
-newly provisioned nodes (assuming the provisioning class supports it).
-
-### Hot swap support
-{{% alert title="Note" color="primary" %}}
-To enable the feature, you have to set the [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/)
-`TASFailedNodeReplacement` to `true` and the lowest topological label has to be
-`kubernetes.io/hostname`. This feature was introduced to Kueue in version 0.12.
+### ClusterAutoscaler 支持
+
+TAS 通过 [Provisioning AdmissionCheck](/docs/admission-check-controllers/provisioning/)
+集成 [Kubernetes ClusterAutoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)。
+
+当工作负载分配到带有 Provisioning AdmissionCheck 的 TAS ResourceFlavor 时，其准入流程如下：
+1. **配额预留**：预留配额，Workload 获得 `QuotaReserved` 条件。如配置了抢占，则会评估抢占。
+2. **准入检查**：Kueue 等待所有 AdmissionCheck（包括 Provisioning）在 Workload 的 `status.admissionChecks` 字段中报告 `Ready`。
+3. **拓扑分配**：Kueue 在 Workload 对象上设置拓扑分配，计算时会考虑新扩容的节点。
+
+另请参阅 [ProvisioningRequestConfig 中的 PodSet 更新](site/content/en/docs/admission-check-controllers/provisioning.md)，了解如何配置 Kueue 以限制调度到新扩容节点（前提是扩容类支持）。
+
+### 热插拔（Hot swap）支持
+{{% alert title="注意" color="primary" %}}
+要启用此特性，需将 `TASFailedNodeReplacement`  [特性门控](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)设置为 `true`，
+且最低拓扑标签必须为 `kubernetes.io/hostname`。此特性自 Kueue 0.12 版本引入。
 {{% /alert %}}
 
-When the lowest level of Topology is set to node, TAS finds a fixed assignment
-of pods to nodes and injects a NodeSelector to make sure the pods get scheduled
-on the selected nodes. But this means that in case
-of any node failures or deletions, which occur during the runtime of a workload,
-the workload cannot run on any other nodes. In order to avoid costly re-scheduling
-of the entire TAS workload we introduce the node hot swap feature.
-
-With this feature, TAS tries to find a replacement of the failed or deleted node for
-all the affected workloads, without changing the rest of the topology assignment.
-Currently this works only for a single node failure at the time and in case of multiple failures,
-the workload gets evicted. The node is assumed to have failed if its `conditions.Status.Ready`
-is not `True` for at least 30 seconds or if the node is missing (removed from the cluster).
-
-Note that finding a replacement node within the old domain (like rack) may not always
-be possible. Hence, we recommend using [WaitForPodsReady](/docs/tasks/manage/setup_wait_for_pods_ready/)
-and configuring `waitForPodsReady.recoveryTimeout`, to prevent the workloads from
-waiting for the replacement indefinetly.
-
-### Limitations
-
-Currently, there are limitations for the compatibility of TAS with other
-features, including:
-- some scheduling directives (e.g. pod affinities and anti-affinities) are ignored,
-- the "podset-required-topology" annotation may fail if the underlying
-  ClusterAutoscaler cannot provision nodes that satisfy the domain constraint,
-- a ClusterQueue for [MultiKueue](multikueue.md) referencing a ResourceFlavor
-with Topology name (`.spec.topologyName`) is marked as inactive.
-
-These usage scenarios are considered to be supported in the future releases
-of Kueue.
-
-## Drawbacks
-
-When enabling the feature Kueue starts to keep track of all Pods and all nodes
-in the system, which results in larger memory requirements for Kueue.
-Additionally, Kueue will take longer to schedule the workloads as it needs to
-take the topology information into account.
+当拓扑最低层级为节点时，TAS 会为 Pod 到节点做固定分配，并注入 NodeSelector，
+确保 Pod 调度到选定节点。但这意味着如果运行期间节点发生故障或被删除，
+工作负载无法迁移到其他节点。为避免整个 TAS 工作负载的高成本重调度，引入了节点热插拔特性。
+
+启用后，TAS 会尝试为所有受影响的工作负载找到故障或被删除节点的替代节点，
+同时保持其他拓扑分配不变。目前仅支持单节点故障，多节点故障时工作负载会被驱逐。
+若节点的 `conditions.Status.Ready` 至少 30 秒不为 `True`，
+或节点被移除（从集群中消失），则视为节点故障。
+
+注意，在原有域（如机架）内找到替代节点并非总是可行。因此，建议使用
+[WaitForPodsReady](/docs/tasks/manage/setup_wait_for_pods_ready/) 并配置 `waitForPodsReady.recoveryTimeout`，
+以防止工作负载无限等待替换节点。
+
+### 限制
+
+目前，TAS 与其他特性兼容性存在如下限制：
+- 某些调度指令（如 Pod 亲和性和反亲和性）会被忽略，
+- 若底层 ClusterAutoscaler 无法扩容满足域约束的节点，则 "podset-required-topology" 注解可能失效，
+- [MultiKueue](multikueue.md) 的 ClusterQueue 若引用带拓扑名（`.spec.topologyName`）的 ResourceFlavor，则会被标记为非活跃。
+
+这些场景计划在 Kueue 后续版本中支持。
+
+## 缺点
+
+启用该特性后，Kueue 会开始跟踪系统中所有 Pod 和节点，这会导致 Kueue 占用更多内存。此外，Kueue 调度工作负载时需考虑拓扑信息，调度耗时也会增加。
diff --git a/site/content/zh-CN/docs/tasks/manage/monitor_pending_workloads/pending_workloads_in_grafana.md b/site/content/zh-CN/docs/tasks/manage/monitor_pending_workloads/pending_workloads_in_grafana.md
index 2ac4180c8..791cb8d71 100644
--- a/site/content/zh-CN/docs/tasks/manage/monitor_pending_workloads/pending_workloads_in_grafana.md
+++ b/site/content/zh-CN/docs/tasks/manage/monitor_pending_workloads/pending_workloads_in_grafana.md
@@ -1,138 +1,138 @@
 ---
-title: "Pending Workloads in Grafana"
+title: "Grafana 中监控待处理的工作负载"
 date: 2025-06-12
 weight: 20
 description: >
-  Monitoring Pending Workloads using the VisibilityOnDemand feature in Grafana.
+  使用 Grafana 中的 **VisibilityOnDemand** 特性监控待处理的工作负载。
 ---
 
-This guide explains how to monitor pending workloads in Grafana using the `VisibilityOnDemand` feature.
+本指南解释了如何使用 `VisibilityOnDemand` 特性在 Grafana 中监控待处理的工作负载。
 
-The intended audience for this page are [batch administrators](/docs/tasks#batch-administrator)
-for ClusterQueue visibility, and [batch users](/docs/tasks#batch-user) for LocalQueue visibility.
+本文的受众是[批处理管理员](/zh-CN/docs/tasks#batch-administrator)，
+用于 ClusterQueue 可见性，以及[批处理用户](/zh-cn/docs/tasks#batch-user)用于 LocalQueue 可见性。
 
-## Before you begin
+## 开始之前
 
-Make sure the following conditions are met:
+确保满足以下条件：
 
-- A Kubernetes cluster is running.
-- [Kueue](/docs/installation) is installed
-- [Kube-prometheus operator](https://github.com/prometheus-operator/kube-prometheus/blob/main/README.md#quickstart) is installed in version v0.15.0 or later.
-- The [VisibilityOnDemand](/docs/tasks/manage/monitor_pending_workloads/pending_workloads_on_demand/#monitor-pending-workloads-on-demand) feature is enabled.
+- 正在运行一个 Kubernetes 集群。
+- 已安装 [Kueue](/zh-CN/docs/installation)
+- 已安装 [Kube-prometheus operator](https://github.com/prometheus-operator/kube-prometheus/blob/main/README.md#quickstart)
+  版本 v0.15.0 或更新版本。
+- 已启用 [VisibilityOnDemand](/zh-CN/docs/tasks/manage/monitor_pending_workloads/pending_workloads_on_demand/#monitor-pending-workloads-on-demand) 特性。
 
-## Setting Up Grafana for Pending Workloads
+## 配置 Grafana 监控待处理工作负载   {#setting-up-grafana-for-pending-workloads}
 
-### Step 1: Configure Cluster Permissions
+### 步骤 1：配置集群权限
 
-To enable visibility, create a `ClusterRole` and `ClusterRoleBinding` for either `ClusterQueue` or `LocalQueue`:
+为了启用可见性，为 `ClusterQueue` 或 `LocalQueue` 创建 `ClusterRole` 和 `ClusterRoleBinding`：
 
-- For `ClusterQueue` visibility:
+- 对于 `ClusterQueue` 可见性：
 
 {{< include "examples/visibility/grafana-cluster-queue-reader.yaml" "yaml" >}}
 
-- For `LocalQueue` visibility:
+- 对于 `LocalQueue` 可见性：
 
 {{< include "examples/visibility/grafana-local-queue-reader.yaml" "yaml" >}}
 
-Apply the appropriate configuration:
+应用适当的配置：
 
 ```shell
 kubectl apply -f <filename>.yaml
 ```
 
-### Step 2: Generate a Service Account Token
+### 步骤 2：生成服务账号令牌
 
-Create a token for Grafana authentication:
+为 Grafana 创建身份验证令牌：
 
 ```shell
 TOKEN=$(kubectl create token default -n default)
 echo $TOKEN
 ```
 
-Save the token for use in Step 5.
+保存令牌，以便在步骤 5 中使用。
 
-### Step 3: Set up port forwarding for Grafana
+### 步骤 3：为 Grafana 设置端口转发
 
-Access Grafana locally:
+本地访问 Grafana ：
 
 ```shell
 kubectl port-forward -n monitoring service/grafana 3000:3000
 ```
 
-Grafana is now available at [http://localhost:3000](http://localhost:3000).
+Grafana 现已在 [http://localhost:3000](http://localhost:3000) 可用。
 
-### Step 4: Install the Infinity Plugin
+### 步骤 4：安装 Infinity 插件
 
-1. Open Grafana at [http://localhost:3000](http://localhost:3000).
-2. Log in (default credentials: admin/admin).
-3. Go to `Connections` > `Add new connection`. 
-4. Search for `Infinity` and click `Install`.
+1. 打开 Grafana，访问 [http://localhost:3000](http://localhost:3000)。
+2. 登录（默认凭据：admin/admin）。
+3. 转到 `Connections` > `Add new connection`。
+4. 搜索 `Infinity` 并点击 `Install`。
 
-### Step 5: Configure the Infinity Data Source
+### 步骤 5：配置 Infinity 数据源
 
-1. Go to `Connections` >` Data sources` and click `+ Add new data source`.
-2. Select `Infinity`.
-3. Configure the data source:
-    - Authentication: Set the `Bearer Token` to the token generated in Step 2.
-    - Network: Enable `Skip TLS Verify`.
-    - Security: Add `https://kubernetes.default.svc` to allowed hosts and set `Query security` to `Allowed`.
-4. Click `Save & test` to verify the configuration.
+1. 转到 `Connections` > `Data sources` 并点击 `+ Add new data source`。
+2. 选择 `Infinity`。
+3. 配置数据源：
+    - 认证：设置 `Bearer Token` 为步骤 2 中生成的令牌。
+    - 网络：启用 `Skip TLS Verify`。
+    - 安全性：添加 `https://kubernetes.default.svc` 到允许的主机，并将 `Query security` 设置为 `Allowed`。
+4. 点击 `Save & test` 以验证配置。
 
+### 步骤 6：导入待处理工作负载仪表板
 
-### Step 6: Import the Pending Workloads Dashboard
+1. 下载适当的仪表板 JSON：
+    - [ClusterQueue 可视化](examples/visibility/pending-workloads-for-cluster-queue-visibility-dashboard.json)。
+    - [LocalQueue 可视化](examples/visibility/pending-workloads-for-local-queue-visibility-dashboard.json)。
+2. 在 Grafana 中，转到 `Dashboards` > `New` > `Import`。
+3. 选择 `Upload dashboard JSON` 文件并选择下载的文件。
+4. 选择在步骤 5 中配置的 Infinity 数据源。
+5. 点击 `Import`。
 
-1. Download the appropriate dashboard JSON:
-   - [ClusterQueue Visibility](examples/visibility/pending-workloads-for-cluster-queue-visibility-dashboard.json).
-   - [LocalQueue Visibility](examples/visibility/pending-workloads-for-local-queue-visibility-dashboard.json).
-2. In Grafana, go to `Dashboards` > `New` > `Import`.
-3. Select `Upload dashboard JSON` file and choose the downloaded file.
-4. Select the Infinity data source configured in Step 5.
-5. Click `Import`.
+### 步骤 7：设置 ClusterQueue
 
-### Step 7: Set Up ClusterQueue
-
-To configure a basic `ClusterQueue`, apply the following:
+要配置一个基本的 `ClusterQueue`，应用以下内容：
 
 {{< include "examples/admin/single-clusterqueue-setup.yaml" "yaml" >}}
 
-Apply the configuration:
+应用配置：
 
 ```shell
 kubectl apply -f https://kueue.sigs.k8s.io/examples/admin/single-clusterqueue-setup.yaml
 ```
 
-### Step 8: Create Sample Workloads
+### 步骤 8：创建示例工作负载
 
-To populate the dashboard with data, create sample jobs:
+要向仪表板填充数据，创建示例作业：
 
 {{< include "examples/jobs/sample-job.yaml" "yaml" >}}
 
-Apply the job multiple times:
+多次应用该作业：
 
 ```shell
 for i in {1..6}; do kubectl create -f https://kueue.sigs.k8s.io/examples/jobs/sample-job.yaml; done
 ```
 
-### Step 9: View the Dashboard
+### 步骤 9：查看仪表板
 
-1. In Grafana, navigate to `Dashboards`.
-2. Select the imported dashboard (e.g., "Pending Workloads for ClusterQueue visibility").
-3. Verify that pending workloads are displayed.
+1. 在 Grafana 中，导航到 `Dashboards`。
+2. 选择导入的仪表板（例如，“ClusterQueue 可见性的待处理工作负载”）。
+3. 确认显示了待处理的工作负载。
 
 ![ClusterQueue Visibility Dashboard](/images/pending-workloads-for-cluster-queue-visibility-dashboard.png)
 
 ![LocalQueue Visibility Dashboard](/images/pending-workloads-for-local-queue-visibility-dashboard.png)
 
-## Troubleshooting
+## 故障排查
 
-### No data in dashboard
+### 仪表板中无数据
 
-Ensure jobs are created and the `Infinity` data source is correctly configured.
+确保已创建作业并且正确配置了 `Infinity` 数据源。
 
-### Permission errors
+### 权限错误
 
-Verify the `ClusterRole` and `ClusterRoleBinding` are applied correctly.
+验证是否正确应用了 `ClusterRole` 和 `ClusterRoleBinding`。
 
-### Grafana inaccessible
+### 无法访问 Grafana
 
-Check port forwarding and ensure the Grafana service is running in the monitoring namespace.
+检查端口转发并确保 Grafana 服务在 monitoring 命名空间中运行。
diff --git a/site/content/zh-CN/docs/tasks/manage/rbac.md b/site/content/zh-CN/docs/tasks/manage/rbac.md
index 9b22e467f..f871300f9 100644
--- a/site/content/zh-CN/docs/tasks/manage/rbac.md
+++ b/site/content/zh-CN/docs/tasks/manage/rbac.md
@@ -1,9 +1,9 @@
 ---
-title: "Setup RBAC"
+title: "设置 RBAC"
 date: 2022-02-14
 weight: 1
 description: >
-  Setup role-based access control (RBAC) in your cluster to control the types of users that can view and create Kueue objects.
+  在集群中设置基于角色的访问控制（RBAC），以控制可以查看和创建 Kueue 对象的用户类型。
 ---
 
 This page shows you how to setup role-based access control (RBAC) in your cluster
@@ -11,34 +11,34 @@ to control the types of users that can view and create Kueue objects.
 
 The page is intended for a [batch administrator](/docs/tasks#batch-administrator).
 
-## Before you begin
+本页面介绍了如何在集群中设置基于角色的访问控制（RBAC），以控制可以查看和创建 Kueue 对象的用户类型。
 
-Make sure the following conditions are met:
+本页面适用于[批处理管理员](/zh-cn/docs/tasks#batch-administrator)。
 
-- A Kubernetes cluster is running.
-- The kubectl command-line tool has communication with your cluster.
-- [Kueue is installed](/docs/installation).
+## 开始之前
 
-This page assumes you are already familiar with [RBAC in kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/).
+确保满足以下条件：
 
-## ClusterRoles included in the installation
+- Kubernetes 集群正在运行。
+- kubectl 命令行工具与你的集群通信。
+- [Kueue 已安装](/zh-CN/docs/installation)。
 
-When you install Kueue, the following set of ClusterRoles are created for the
-two main personas that we assume will interact with Kueue:
+本页面假设你已经熟悉 [Kubernetes 中的 RBAC](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/)。
 
-- `kueue-batch-admin-role` includes the permissions to manage ClusterQueues,
-  Queues, Workloads, and ResourceFlavors.
-- `kueue-batch-user-role` includes the permissions to manage [Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/job/)
-  and to view Queues and Workloads.
+## 安装步骤中包含的 ClusterRole  {#clusterroles-included-in-the-installation}
 
-## Giving permissions to a batch administrator
+当你安装 Kueue 时，会为预计将与 Kueue 交互的两个主要角色创建以下 ClusterRole：
 
-A batch administrator typically requires the `kueue-batch-admin-role` ClusterRole
-for all the namespaces.
+- `kueue-batch-admin-role` 包含管理 ClusterQueues、Queues、Workloads 和 ResourceFlavors 的权限。
+- `kueue-batch-user-role` 包含管理 [Job](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/job/)
+  并查看 Queues 和 Workloads 的权限。
 
-To bind the `kueue-batch-admin-role` role to a batch administrator, represented
-by the user `admin@example.com`, create a ClusterRoleBinding with a manifest
-similar to the following:
+## 向批处理管理员授予权限  {#giving-permissions-to-a-batch-administrator}
+
+批处理管理员通常需要 `kueue-batch-admin-role` ClusterRole 对所有命名空间进行操作。
+
+要将 `kueue-batch-admin-role` 角色绑定到由用户 `admin@example.com`
+表示的批处理管理员，需创建一个类似的 ClusterRoleBinding 清单：
 
 ```yaml
 # batch-admin-role-binding.yaml
@@ -56,24 +56,22 @@ roleRef:
   apiGroup: rbac.authorization.k8s.io
 ```
 
-To create the ClusterRoleBinding, save the preceding manifest and run the
-following command:
+要创建 ClusterRoleBinding，保存上述清单并运行以下命令：
 
 ```shell
 kubectl apply -f batch-admin-role-binding.yaml
 ```
 
-## Giving permissions to a batch user
+## 给批处理用户授予权限  {#giving-permissions-to-a-batch-user}
 
-A batch user typically requires permissions to:
+批处理用户通常需要以下权限：
 
-- Create and view Jobs in their namespace.
-- View the queues available in their namespace.
-- View the status of their [Workloads](/docs/concepts/workload) in their namespace.
+- 在其命名空间中创建和查看 Job。
+- 查看其命名空间中可用的队列。
+- 查看其命名空间中**工作负载**的状态。
 
-To give these permissions to a group of users `team-a@example.com` for the
-namespace `team-a`, create a RoleBinding with a manifest similar to the
-following:
+要为 `team-a@example.com` 用户组在命名空间 `team-a` 中授予这些权限，
+可以创建一个 RoleBinding，并使用类似于下面的清单：
 
 ```yaml
 # team-a-batch-user-role-binding.yaml
@@ -92,8 +90,7 @@ roleRef:
   apiGroup: rbac.authorization.k8s.io
 ```
 
-To create the RoleBinding, save the preceding manifest and run the
-following command:
+要创建 RoleBinding，请保存上述清单并运行以下命令：
 
 ```shell
 kubectl apply -f team-a-batch-user-role-binding.yaml
diff --git a/site/content/zh-CN/docs/tasks/run/external_workloads/argo_workflow.md b/site/content/zh-CN/docs/tasks/run/external_workloads/argo_workflow.md
index a9008234b..32c8ae0c1 100644
--- a/site/content/zh-CN/docs/tasks/run/external_workloads/argo_workflow.md
+++ b/site/content/zh-CN/docs/tasks/run/external_workloads/argo_workflow.md
@@ -1,52 +1,54 @@
 ---
-title: "Run An Argo Workflow"
+title: "运行 Argo Workflow"
 linkTitle: "Argo Workflow"
 date: 2025-01-23
 weight: 3
 description: >
-  Integrate Kueue with Argo Workflows.
+  将 Kueue 与 Argo Workflow 集成。
 ---
 
-This page shows how to leverage Kueue's scheduling and resource management capabilities when running [Argo Workflows](https://argo-workflows.readthedocs.io/en/latest/).
+此页面展示了在运行 [Argo Workflow](https://argo-workflows.readthedocs.io/en/latest/)
+时，如何利用 Kueue 的调度和资源管理能力。
 
-This guide is for [batch users](/docs/tasks#batch-user) that have a basic understanding of Kueue. For more information, see [Kueue's overview](/docs/overview).
+本指南适用于对 Kueue 有基本了解的[批处理用户](/zh-cn/docs/tasks#batch-user)。
+欲了解更多信息，请参见 [Kueue 概述](/zh-CN/docs/overview)。
 
-Currently Kueue doesn't support Argo Workflows [Workflow](https://argo-workflows.readthedocs.io/en/latest/workflow-concepts/) resources directly,
-but you can take advantage of the ability for Kueue to [manage plain pods](/docs/tasks/run_plain_pods) to integrate them.
+目前，Kueue 不直接支持 Argo Workflow 的 [Workflow](https://argo-workflows.readthedocs.io/en/latest/workflow-concepts/) 资源，
+但你可以利用 Kueue [管理普通 Pod](/zh-CN/docs/tasks/run_plain_pods) 的能力来集成它们。
 
-## Before you begin
+## 开始之前
 
-1. Learn how to [install Kueue with a custom manager configuration](/docs/installation/#install-a-custom-configured-released-version).
+1. 学习如何[使用自定义管理器配置安装 Kueue](/zh-CN/docs/installation/#install-a-custom-configured-released-version)。
 
-2. Follow steps in [Run Plain Pods](/docs/tasks/run/plain_pods/#before-you-begin)
-to learn how to enable and configure the `pod` integration.
+2. 遵循[运行普通 Pod](/zh-CN/docs/tasks/run/plain_pods/#before-you-begin)
+   中的步骤来学习如何启用和配置 `pod` 集成。
 
-3. Install [Argo Workflows](https://argo-workflows.readthedocs.io/en/latest/installation/#installation)
+3. 安装 [Argo Workflow](https://argo-workflows.readthedocs.io/en/latest/installation/#installation)
 
-## Workflow definition
+## Workflow 定义  {#workflow-definition}
 
-### a. Targeting a single LocalQueue
+### a. 针对单个本地队列
 
-If you want the entire workflow to target a single [local queue](/docs/concepts/local_queue),
-it should be specified in the `spec.podMetadata` section of the Workflow configuration.
+如果你希望整个工作流针对单个[本地队列](/zh-CN/docs/concepts/local_queue)，
+应在 Workflow 配置的 `spec.podMetadata` 部分指定它。
 
 {{< include "examples/pod-based-workloads/workflow-single-queue.yaml" "yaml" >}}
 
-### b. Targeting a different LocalQueue per template
+### b. 针对每个模板的不同本地队列
 
-If you prefer to target a different [local queue](/docs/concepts/local_queue) for each step of your Workflow,
-you can define the queue in the `spec.templates[].metadata` section of the Workflow configuration.
+如果你希望针对工作流的每一步使用不同的[本地队列](/zh-CN/docs/concepts/local_queue)，
+可以在 Workflow 配置的 `spec.templates[].metadata` 部分定义队列。
 
-In this example `hello1` and `hello2a` will target `user-queue` and `hello2b` will
-target `user-queue-2`.
+在这个例子中，`hello1` 和 `hello2a` 将针对 `user-queue`，
+而 `hello2b` 将针对 `user-queue-2`。
 
 {{< include "examples/pod-based-workloads/workflow-queue-per-template.yaml" "yaml" >}}
 
-### c. Limitations
+### c. 限制
 
-- Kueue will only manage pods created by Argo Workflows. It does not manage the Argo Workflows resources in any way.
-- Each pod in a Workflow will create a new Workload resource and must wait for admission by Kueue.
-- There is no way to ensure that a Workflow will complete before it is started. If one step of a multi-step Workflow does not have
-available quota, Argo Workflows will run all previous steps and then wait for quota to become available.
-- Kueue does not understand Argo Workflows `suspend` flag and will not manage it.
-- Kueue does not manage `suspend`, `http`, or `resource` template types since they do not create pods.
+- Kueue 仅管理由 Argo Workflow 创建的 Pod。它不会以任何方式管理 Argo Workflow 资源。
+- Workflow 中的每个 Pod 都将创建一个新的 Workload 资源，并且必须等待 Kueue 的准入。
+- 没有办法确保 Workflow 在开始前完成。如果多步骤工作流中的某一步没有可用配额，
+  Argo Workflow 将运行所有之前的步骤并等待配额变为可用。
+- Kueue 不理解 Argo Workflow 的 `suspend` 标志，也不会管理它。
+- Kueue 不管理 `suspend`、`http` 或 `resource` 模板类型，因为它们不创建 Pod。
diff --git a/site/content/zh-CN/docs/tasks/run/jobs.md b/site/content/zh-CN/docs/tasks/run/jobs.md
index 3be198ef6..15fafdf40 100644
--- a/site/content/zh-CN/docs/tasks/run/jobs.md
+++ b/site/content/zh-CN/docs/tasks/run/jobs.md
@@ -1,96 +1,94 @@
 ---
-title: "Run A Kubernetes Job"
-linkTitle: "Kubernetes Jobs"
+title: "运行 Kubernetes Job"
+linkTitle: "Kubernetes Job"
 date: 2022-02-14
 weight: 4
 description: >
-  Run a Job in a Kubernetes cluster with Kueue enabled.
+  在启用了 Kueue 的 Kubernetes 集群中运行 Job。
 ---
 
-This page shows you how to run a Job in a Kubernetes cluster with Kueue enabled.
+本页面向您展示如何在启用了 Kueue 的 Kubernetes 集群中运行 Job。
 
-The intended audience for this page are [batch users](/docs/tasks#batch-user).
+本页面的目标受众是[批量用户](/docs/tasks#batch-user)。
 
-## Before you begin
+## 开始之前 {#before-you-begin}
 
-Make sure the following conditions are met:
+确保满足以下条件：
 
-- A Kubernetes cluster is running.
-- The kubectl command-line tool has communication with your cluster.
-- [Kueue is installed](/docs/installation).
-- The cluster has [quotas configured](/docs/tasks/manage/administer_cluster_quotas).
+- Kubernetes 集群正在运行。
+- kubectl 命令行工具能够与您的集群通信。
+- [已安装 Kueue](/zh-CN/docs/installation)。
+- 集群已[配置配额](/zh-CN/docs/tasks/manage/administer_cluster_quotas)。
 
-The following picture shows all the concepts you will interact with in this tutorial:
+下图显示了您在本教程中将要学习的所有概念：
 
 ![Kueue Components](/images/queueing-components.svg)
 
-## 0. Identify the queues available in your namespace
+## 0. 识别命名空间中可用的队列 {#0-identify-the-queues-available-in-your-namespace}
 
-Run the following command to list the `LocalQueues` available in your namespace.
+运行以下命令列出您命名空间中可用的 `LocalQueues`。
 
 ```shell
 kubectl -n default get localqueues
-# Or use the 'queues' alias.
+# 或使用 'queues' 别名。
 kubectl -n default get queues
 ```
 
-The output is similar to the following:
+输出类似于以下内容：
 
 ```bash
 NAME         CLUSTERQUEUE    PENDING WORKLOADS
 user-queue   cluster-queue   3
 ```
 
-The [ClusterQueue](/docs/concepts/cluster_queue) defines the quotas for the
-Queue.
+[ClusterQueue](/zh-CN/docs/concepts/cluster_queue) 定义了队列的配额。
 
-## 1. Define the Job
+## 1. 定义 Job {#1-define-the-job}
 
-Running a Job in Kueue is similar to [running a Job in a Kubernetes cluster](https://kubernetes.io/docs/tasks/job/)
-without Kueue. However, you must consider the following differences:
+在 Kueue 中运行 Job 类似于[在 Kubernetes 集群中运行 Job](https://kubernetes.io/docs/tasks/job/)，
+只是没有使用 Kueue。但是，您必须考虑以下差异：
 
-- You should create the Job in a [suspended state](https://kubernetes.io/docs/concepts/workloads/controllers/job/#suspending-a-job),
-  as Kueue will decide when it's the best time to start the Job.
-- You have to set the Queue you want to submit the Job to. Use the
- `kueue.x-k8s.io/queue-name` label.
-- You should include the resource requests for each Job Pod.
+- 您应该在[挂起状态](https://kubernetes.io/docs/concepts/workloads/controllers/job/#suspending-a-job)下创建 Job，
+  因为 Kueue 将决定何时是启动 Job 的最佳时间。
+- 您必须设置要提交 Job 的队列。使用
+ `kueue.x-k8s.io/queue-name` 标签。
+- 您应该为每个 Job Pod 包含资源请求。
 
-Here is a sample Job with three Pods that just sleep for a few seconds.
+这是一个包含三个 Pod 的示例 Job，它们只是休眠几秒钟。
 
 {{< include "examples/jobs/sample-job.yaml" "yaml" >}}
 
-## 2. Run the Job
+## 2. 运行 Job {#2-run-the-job}
 
-You can run the Job with the following command:
+您可以使用以下命令运行 Job：
 
 ```shell
 kubectl create -f sample-job.yaml
 ```
 
-Internally, Kueue will create a corresponding [Workload](/docs/concepts/workload)
-for this Job with a matching name.
+在内部，Kueue 将为此 Job 创建一个与名称匹配的相应[Workload](/zh-CN/docs/concepts/workload)。
 
 ```shell
 kubectl -n default get workloads
 ```
 
-The output will be similar to the following:
+输出将类似于以下内容：
 
 ```shell
 NAME               QUEUE         RESERVED IN   ADMITTED   AGE
 sample-job-sl4bm   user-queue                             1s
 ```
 
-## 3. (Optional) Monitor the status of the workload
+## 3. （可选）监控 Workload 的状态 {#3-optional-monitor-the-status-of-the-workload}
 
-You can see the Workload status with the following command:
+您可以使用以下命令查看 Workload 状态：
 
 ```shell
 kubectl -n default describe workload sample-job-sl4bm
 ```
 
-If the ClusterQueue doesn't have enough quota to run the Workload, the output
-will be similar to the following:
+如果 ClusterQueue 没有足够的配额来运行 Workload，
+输出将类似于以下内容：
 
 ```shell
 Name:         sample-job-sl4bm
@@ -114,27 +112,27 @@ Status:
 Events:               <none>
 ```
 
-When the ClusterQueue has enough quota to run the Workload, it will admit
-the Workload. To see if the Workload was admitted, run the following command:
+当 ClusterQueue 有足够的配额来运行 Workload 时，它将让此 Workload 准入。
+要查看 Workload 是否被准入，运行以下命令：
 
 ```shell
 kubectl -n default get workloads
 ```
 
-The output is similar to the following:
+输出类似于以下内容：
 
 ```shell
 NAME               QUEUE         RESERVED IN   ADMITTED   AGE
 sample-job-sl4bm   user-queue    cluster-queue True       1s
 ```
 
-To view the event for the Workload admission, run the following command:
+要查看 Workload 准入的事件，运行以下命令：
 
 ```shell
 kubectl -n default describe workload sample-job-sl4bm
 ```
 
-The output is similar to the following:
+输出类似于以下内容：
 
 ```shell
 ...
@@ -144,13 +142,13 @@ Events:
   Normal  Admitted  50s   kueue-manager  Admitted by ClusterQueue cluster-queue
 ```
 
-To continue monitoring the Workload progress, you can run the following command:
+要继续监控 Workload 进度，您可以运行以下命令：
 
 ```shell
 kubectl -n default describe workload sample-job-sl4bm
 ```
 
-Once the Workload has finished running, the output is similar to the following:
+一旦 Workload 完成运行，输出类似于以下内容：
 
 ```shell
 ...
@@ -166,13 +164,13 @@ Status:
 ...
 ```
 
-To review more details about the Job status, run the following command:
+要查看 Job 状态的更多详细信息，运行以下命令：
 
 ```shell
 kubectl -n default describe job sample-job-sl4bm
 ```
 
-The output is similar to the following:
+输出类似于以下内容：
 
 ```shell
 Name:             sample-job-sl4bm
@@ -197,21 +195,26 @@ Events:
   Normal  Completed         18m   job-controller        Job completed
 ```
 
-Since events have a timestamp with a resolution of seconds, the events might
-be listed in a slightly different order from which they actually occurred.
+由于事件的时间戳精度为秒，事件可能与实际发生的顺序略有不同。
 
-## Partial admission
+## 部分准入 {#partial-admission}
 
 {{< feature-state state="beta" for_version="v0.5" >}}
 
-Kueue provides the ability for a batch user to create Jobs that ideally will run with a parallelism `P0` but can accept a smaller parallelism, `Pn`, if the Job dose not fit within the available quota.
+Kueue 提供了批量用户创建 Job 的能力，这些 Job 理想情况下将以并行度 `P0` 运行，
+但如果 Job 不适合可用配额，可以接受较小的并行度 `Pn`。
 
-Kueue will only attempt to decrease the parallelism after both _borrowing_ and _preemption_ was taken into account in the admission process, and none of them are feasible.
+Kueue 只有在准入过程中同时考虑了_借用_和_抢占_，
+并且两者都不可行的情况下，才会尝试减少并行度。
 
-To allow partial admission you can provide the minimum acceptable parallelism `Pmin` in `kueue.x-k8s.io/job-min-parallelism` annotation of the Job, `Pn` should be grater that 0 and less that `P0`. When a Job is partially admitted its parallelism will be set to `Pn`, `Pn` will be set to the maximum acceptable value between `Pmin` and `P0`. The Job's completions count will not be changed.
+要允许部分准入，您可以在 Job 的 `kueue.x-k8s.io/job-min-parallelism`
+注解中提供最小可接受并行度 `Pmin`，`Pn` 应该大于 0 且小于 `P0`。
+当 Job 被部分准入时，其并行度将设置为 `Pn`，`Pn` 将设置为 `Pmin` 和 `P0`
+之间的最大可接受值。Job 的完成计数不会改变。
 
-For example, a Job defined by the following manifest:
+例如，由以下清单定义的 Job：
 
 {{< include "examples/jobs/sample-job-partial-admission.yaml" "yaml" >}}
 
-When queued in a ClusterQueue with only 9 CPUs available, it will be admitted with `parallelism=9`. Note that the number of completions doesn't change.
+当在只有 9 个 CPU 可用的 ClusterQueue 中排队时，它将以 `parallelism=9`
+被准入。请注意，完成次数不会改变。



Test patch:
diff --git a/pkg/controller/jobs/job/job_controller_test.go b/pkg/controller/jobs/job/job_controller_test.go
index e81cb65da..7d8a63093 100644
--- a/pkg/controller/jobs/job/job_controller_test.go
+++ b/pkg/controller/jobs/job/job_controller_test.go
@@ -507,8 +507,9 @@ func TestReconciler(t *testing.T) {
 	baseWaitForPodsReadyConf := &configapi.WaitForPodsReady{Enable: true}
 
 	cases := map[string]struct {
-		enableObjectRetentionPolicies bool
-		enableTopologyAwareScheduling bool
+		enableObjectRetentionPolicies                     bool
+		enableTopologyAwareScheduling                     bool
+		enableManagedJobsNamespaceSelectorAlwaysRespected bool
 
 		reconcilerOptions []jobframework.Option
 		job               batchv1.Job
@@ -3709,18 +3710,89 @@ func TestReconciler(t *testing.T) {
 				},
 			},
 		},
+		"job with queue name is not reconciled in unlabelled namespace when AlwaysRespected is enabled": {
+			enableManagedJobsNamespaceSelectorAlwaysRespected: true,
+			reconcilerOptions: []jobframework.Option{
+				jobframework.WithManagedJobsNamespaceSelector(labels.SelectorFromSet(map[string]string{
+					"managed-by-kueue": "true",
+				})),
+			},
+			job: *baseJobWrapper.
+				Clone().
+				Queue("test-queue").
+				Suspend(false).
+				Obj(),
+			wantJob: *baseJobWrapper.
+				Clone().
+				Queue("test-queue").
+				Suspend(false).
+				Obj(),
+			wantWorkloads: nil,
+		},
+		"job with queue name is reconciled in labelled namespace when AlwaysRespected is enabled": {
+			enableManagedJobsNamespaceSelectorAlwaysRespected: true,
+			reconcilerOptions: []jobframework.Option{
+				jobframework.WithManagedJobsNamespaceSelector(labels.SelectorFromSet(map[string]string{
+					"managed-by-kueue": "true",
+				})),
+				jobframework.WithManageJobsWithoutQueueName(true),
+			},
+			job: *utiltestingjob.MakeJob("job", "labelled-ns").
+				Queue("test-queue").
+				Suspend(true).
+				UID("test-uid").
+				Parallelism(10).
+				Request(corev1.ResourceCPU, "1").
+				Image("", nil).
+				Obj(),
+			wantJob: *utiltestingjob.MakeJob("job", "labelled-ns").
+				Queue("test-queue").
+				UID("test-uid").
+				Suspend(true).
+				Parallelism(10).
+				Request(corev1.ResourceCPU, "1").
+				Image("", nil).
+				Obj(),
+			wantWorkloads: []kueue.Workload{
+				*utiltesting.MakeWorkload("job", "labelled-ns").
+					Finalizers(kueue.ResourceInUseFinalizerName).
+					Queue("test-queue").
+					Priority(0).
+					Labels(map[string]string{
+						controllerconsts.JobUIDLabel: "test-uid",
+					}).
+					PodSets(*utiltesting.MakePodSet(kueue.DefaultPodSetName, 10).
+						Request(corev1.ResourceCPU, "1").
+						Obj()).
+					Obj(),
+			},
+			wantEvents: []utiltesting.EventRecord{
+				{
+					Key:       types.NamespacedName{Name: "job", Namespace: "labelled-ns"},
+					EventType: "Normal",
+					Reason:    "CreatedWorkload",
+					Message:   "Created Workload: labelled-ns/" + GetWorkloadNameForJob("job", "test-uid"),
+				},
+			},
+		},
 	}
 	for name, tc := range cases {
 		t.Run(name, func(t *testing.T) {
 			features.SetFeatureGateDuringTest(t, features.TopologyAwareScheduling, tc.enableTopologyAwareScheduling)
 			features.SetFeatureGateDuringTest(t, features.ObjectRetentionPolicies, tc.enableObjectRetentionPolicies)
+			features.SetFeatureGateDuringTest(t, features.ManagedJobsNamespaceSelectorAlwaysRespected, tc.enableManagedJobsNamespaceSelectorAlwaysRespected)
 
 			ctx, _ := utiltesting.ContextWithLog(t)
 			clientBuilder := utiltesting.NewClientBuilder().WithInterceptorFuncs(interceptor.Funcs{SubResourcePatch: utiltesting.TreatSSAAsStrategicMerge})
 			if err := SetupIndexes(ctx, utiltesting.AsIndexer(clientBuilder)); err != nil {
 				t.Fatalf("Could not setup indexes: %v", err)
 			}
-			objs := append(tc.priorityClasses, &tc.job, utiltesting.MakeResourceFlavor("default").Obj(), testNamespace)
+
+			labelledNamespace := utiltesting.MakeNamespaceWrapper("labelled-ns").
+				Label("managed-by-kueue", "true").
+				Obj()
+
+			objs := append(tc.priorityClasses, &tc.job, utiltesting.MakeResourceFlavor("default").Obj(), testNamespace, labelledNamespace)
 			kcBuilder := clientBuilder.
 				WithObjects(objs...)
 
diff --git a/test/e2e/customconfigs/reconcile_test.go b/test/e2e/customconfigs/reconcile_test.go
new file mode 100644
index 000000000..588bd1325
--- /dev/null
+++ b/test/e2e/customconfigs/reconcile_test.go
@@ -0,0 +1,134 @@
+/*
+Copyright The Kubernetes Authors.
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+*/
+
+package customconfigse2e
+
+import (
+	"github.com/onsi/ginkgo/v2"
+	"github.com/onsi/gomega"
+	corev1 "k8s.io/api/core/v1"
+	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
+	"sigs.k8s.io/controller-runtime/pkg/client"
+
+	config "sigs.k8s.io/kueue/apis/config/v1beta1"
+	kueue "sigs.k8s.io/kueue/apis/kueue/v1beta1"
+	"sigs.k8s.io/kueue/pkg/features"
+	"sigs.k8s.io/kueue/pkg/util/testing"
+	testingjob "sigs.k8s.io/kueue/pkg/util/testingjobs/job"
+	testingpod "sigs.k8s.io/kueue/pkg/util/testingjobs/pod"
+	"sigs.k8s.io/kueue/test/util"
+)
+
+var _ = ginkgo.Describe("Job reconciliation with ManagedJobsNamespaceSelectorAlwaysRespected", ginkgo.Ordered, func() {
+	const (
+		cqName = "cluster-queue"
+		rfName = "default"
+		lqName = "user-queue"
+	)
+
+	var (
+		rf *kueue.ResourceFlavor
+		lq *kueue.LocalQueue
+		cq *kueue.ClusterQueue
+		ns *corev1.Namespace
+	)
+
+	ginkgo.BeforeAll(func() {
+		updateKueueConfiguration(func(cfg *config.Configuration) {
+			cfg.FeatureGates = map[string]bool{string(features.ManagedJobsNamespaceSelectorAlwaysRespected): true}
+			cfg.ManagedJobsNamespaceSelector = &metav1.LabelSelector{
+				MatchExpressions: []metav1.LabelSelectorRequirement{
+					{
+						Key:      "managed-by-kueue",
+						Operator: metav1.LabelSelectorOpIn,
+						Values:   []string{"true"},
+					},
+				},
+			}
+		})
+
+		ns = &corev1.Namespace{
+			ObjectMeta: metav1.ObjectMeta{
+				GenerateName: "managed-ns-",
+				Labels: map[string]string{
+					"managed-by-kueue": "true",
+				},
+			},
+		}
+		gomega.Expect(k8sClient.Create(ctx, ns)).To(gomega.Succeed())
+
+		rf = testing.MakeResourceFlavor(rfName).Obj()
+		gomega.Expect(k8sClient.Create(ctx, rf)).To(gomega.Succeed())
+
+		cq = testing.MakeClusterQueue(cqName).
+			ResourceGroup(*testing.MakeFlavorQuotas(rfName).Resource(corev1.ResourceCPU, "5").Obj()).
+			Obj()
+		gomega.Expect(k8sClient.Create(ctx, cq)).To(gomega.Succeed())
+
+		lq = testing.MakeLocalQueue(lqName, ns.Name).ClusterQueue(cqName).Obj()
+		gomega.Expect(k8sClient.Create(ctx, lq)).To(gomega.Succeed())
+	})
+
+	ginkgo.AfterAll(func() {
+		gomega.Expect(util.DeleteNamespace(ctx, k8sClient, ns)).To(gomega.Succeed())
+		util.ExpectObjectToBeDeletedWithTimeout(ctx, k8sClient, cq, true, util.LongTimeout)
+		util.ExpectObjectToBeDeletedWithTimeout(ctx, k8sClient, rf, true, util.LongTimeout)
+	})
+
+	ginkgo.It("should not reconcile a job in the default (unmanaged) namespace", func() {
+		job := testingjob.MakeJob("unmanaged-job", metav1.NamespaceDefault).
+			Queue(kueue.LocalQueueName(lq.Name)).
+			Suspend(true).
+			Image(util.GetAgnHostImage(), util.BehaviorExitFast).
+			Obj()
+
+		gomega.Expect(k8sClient.Create(ctx, job)).To(gomega.Succeed())
+
+		wls := &kueue.WorkloadList{}
+		gomega.Expect(k8sClient.List(ctx, wls, client.InNamespace(metav1.NamespaceDefault))).To(gomega.Succeed())
+		gomega.Expect(wls.Items).To(gomega.BeEmpty(), "Expected no workload in unmanaged namespace")
+	})
+
+	ginkgo.It("should reconcile a job in managed namespace and create a workload", func() {
+		job := testingjob.MakeJob("managed-job", ns.Name).
+			Queue(kueue.LocalQueueName(lq.Name)).
+			Suspend(true).
+			Image(util.GetAgnHostImage(), util.BehaviorExitFast).
+			Obj()
+
+		gomega.Expect(k8sClient.Create(ctx, job)).To(gomega.Succeed())
+
+		ginkgo.By("check that only one workload is created", func() {
+			createdWorkloads := &kueue.WorkloadList{}
+			gomega.Eventually(func(g gomega.Gomega) {
+				g.Expect(k8sClient.List(ctx, createdWorkloads, client.InNamespace(ns.Name))).To(gomega.Succeed())
+				g.Expect(createdWorkloads.Items).To(gomega.HaveLen(1))
+			}, util.Timeout, util.Interval).Should(gomega.Succeed())
+		})
+	})
+
+	ginkgo.It("Verify existing behavior - should not reconcile a pod in the default (unmanaged) namespace", func() {
+		testPod := testingpod.MakePod("test-pod", metav1.NamespaceDefault).
+			Queue(lq.Name).
+			Image(util.GetAgnHostImage(), util.BehaviorWaitForDeletion).
+			Obj()
+		gomega.Expect(k8sClient.Create(ctx, testPod)).To(gomega.Succeed())
+
+		wls := &kueue.WorkloadList{}
+		gomega.Expect(k8sClient.List(ctx, wls, client.InNamespace(metav1.NamespaceDefault))).To(gomega.Succeed())
+		gomega.Expect(wls.Items).To(gomega.BeEmpty(), "Expected no workload for pod in unmanaged namespace")
+	})
+})