From b02b593f00d8ead55ad22f57b3c82a9d871c36bf Mon Sep 17 00:00:00 2001
From: "xin.li" <xin.li@daocloud.io>
Date: Sun, 10 Nov 2024 20:00:30 +0800
Subject: [PATCH] [zh-cn]sync manage-resources-containers.md

Signed-off-by: xin.li <xin.li@daocloud.io>
---
 .../manage-resources-containers.md             | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md b/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md
index 3055b271b3..7a638efe30 100644
--- a/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md
@@ -350,7 +350,7 @@ limits you defined.
 {{< glossary_tooltip text="CGroups" term_id="cgroup" >}}，负责应用并实施所定义的请求。
 
 <!--
-- The CPU limit defines a hard ceiling on how much CPU time that the container can use.
+- The CPU limit defines a hard ceiling on how much CPU time the container can use.
   During each scheduling interval (time slice), the Linux kernel checks to see if this
   limit is exceeded; if so, the kernel waits before allowing that cgroup to resume execution.
 -->
@@ -443,11 +443,11 @@ kubelet 会将 Pod 的资源使用情况作为 Pod
 If you do not specify a `sizeLimit` for an `emptyDir` volume, that volume may
 consume up to that pod's memory limit (`Pod.spec.containers[].resources.limits.memory`).
 If you do not set a memory limit, the pod has no upper bound on memory consumption,
-and can consume all available memory on the node.  Kubernetes schedules pods based
+and can consume all available memory on the node. Kubernetes schedules pods based
 on resource requests (`Pod.spec.containers[].resources.requests`) and will not
 consider memory usage above the request when deciding if another pod can fit on
-a given node.  This can result in a denial of service and cause the OS to do
-out-of-memory (OOM) handling.  It is possible to create any number of `emptyDir`s
+a given node. This can result in a denial of service and cause the OS to do
+out-of-memory (OOM) handling. It is possible to create any number of `emptyDir`s
 that could potentially consume all available memory on the node, making OOM
 more likely.
 -->
@@ -463,23 +463,23 @@ Kubernetes 基于资源请求（`Pod.spec.containers[].resources.requests`）调
 <!--
 From the perspective of memory management, there are some similarities between
 when a process uses memory as a work area and when using memory-backed
-`emptyDir`. But when using memory as a volume like memory-backed `emptyDir`,
-there are additional points below that you should be careful of.
+`emptyDir`. But when using memory as a volume, like memory-backed `emptyDir`,
+there are additional points below that you should be careful of:
 -->
 从内存管理的角度来看，进程使用内存作为工作区与使用内存作为 `emptyDir` 的介质有一些相似之处。
 但当将内存用作存储卷（例如内存为介质的 `emptyDir` 卷）时，你需要额外注意以下几点：
 
 <!--
 * Files stored on a memory-backed volume are almost entirely managed by the
-  user application.  Unlike when used as a work area for a process, you can not
+  user application. Unlike when used as a work area for a process, you can not
   rely on things like language-level garbage collection.
 * The purpose of writing files to a volume is to save data or pass it between
-  applications.  Neither Kubernetes nor the OS may automatically delete files
+  applications. Neither Kubernetes nor the OS may automatically delete files
   from a volume, so memory used by those files can not be reclaimed when the
   system or the pod are under memory pressure.
 * A memory-backed `emptyDir` is useful because of its performance, but memory
   is generally much smaller in size and much higher in cost than other storage
-  media, such as disks or SSDs.  Using large amounts of memory for `emptyDir`
+  media, such as disks or SSDs. Using large amounts of memory for `emptyDir`
   volumes may affect the normal operation of your pod or of the whole node,
   so should be used carefully.
 -->