diff --git a/content/zh/docs/concepts/workloads/controllers/statefulset.md b/content/zh/docs/concepts/workloads/controllers/statefulset.md
index cdc0383316..4cd6606a38 100644
--- a/content/zh/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/zh/docs/concepts/workloads/controllers/statefulset.md
@@ -1,7 +1,7 @@
 ---
 title: StatefulSets
 content_type: concept
-weight: 40
+weight: 30
 ---
 
 <!--
@@ -146,15 +146,25 @@ spec:
 ```
 
 <!--
+In the above example:
+
 * A Headless Service, named `nginx`, is used to control the network domain.
 * The StatefulSet, named `web`, has a Spec that indicates that 3 replicas of the nginx container will be launched in unique Pods.
 * The `volumeClaimTemplates` will provide stable storage using [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) provisioned by a PersistentVolume Provisioner.
+
+The name of a StatefulSet object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
 -->
+上述例子中：
+
 * 名为 `nginx` 的 Headless Service 用来控制网络域名。
 * 名为 `web` 的 StatefulSet 有一个 Spec，它表明将在独立的 3 个 Pod 副本中启动 nginx 容器。
 * `volumeClaimTemplates` 将通过 PersistentVolumes 驱动提供的
   [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
 
+StatefulSet 的命名需要遵循[DNS 子域名](zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)规范。
+
 <!--
 ## Pod Selector
 -->
@@ -217,9 +227,48 @@ StatefulSet 可以使用 [无头服务](/zh/docs/concepts/services-networking/se
 一旦每个 Pod 创建成功，就会得到一个匹配的 DNS 子域，格式为：
 `$(pod 名称).$(所属服务的 DNS 域名)`，其中所属服务由 StatefulSet 的 `serviceName` 域来设定。
 
+<!--
+Depending on how DNS is configured in your cluster, you may not be able to look up the DNS
+name for a newly-run Pod immediately. This behavior can occur when other clients in the
+cluster have already sent queries for the hostname of the Pod before it was created.
+Negative caching (normal in DNS) means that the results of previous failed lookups are
+remembered and reused, even after the Pod is running, for at least a few seconds.
+
+If you need to discover Pods promptly after they are created, you have a few options:
+
+- Query the Kubernetes API directly (for example, using a watch) rather than relying on DNS lookups.
+- Decrease the time of caching in your Kubernetes DNS provider (typically this means editing the config map for CoreDNS, which currently caches for 30 seconds).
+
+
+As mentioned in the [limitations](#limitations) section, you are responsible for
+creating the [Headless Service](/docs/concepts/services-networking/service/#headless-services)
+responsible for the network identity of the pods.
+
+-->
+取决于集群域内部 DNS 的配置，有可能无法查询一个刚刚启动的 Pod 的 DNS 命名。
+当集群内其他客户端在 Pod 创建完成前发出 Pod 主机名查询时，就会发生这种情况。
+负缓存 (在 DNS 中较为常见) 意味着之前失败的查询结果会被记录和重用至少若干秒钟，
+即使 Pod 已经正常运行了也是如此。
+
+如果需要在 Pod 被创建之后及时发现它们，有以下选项：
+
+- 直接查询 Kubernetes API（比如，利用 watch 机制）而不是依赖于 DNS 查询
+- 缩短 Kubernetes DNS 驱动的缓存时长（通常这意味着修改 CoreDNS 的 ConfigMap，目前缓存时长为 30 秒）
+
+正如[限制](#limitations)中所述，你需要负责创建[无头服务](/zh/docs/concepts/services-networking/service/#headless-services)
+以便为 Pod 提供网络标识。
+
 <!--
 Here are some examples of choices for Cluster Domain, Service name,
 StatefulSet name, and how that affects the DNS names for the StatefulSet's Pods.
+
+
+Cluster Domain | Service (ns/name) | StatefulSet (ns/name)  | StatefulSet Domain  | Pod DNS | Pod Hostname |
+-------------- | ----------------- | ----------------- | -------------- | ------- | ------------ |
+ cluster.local | default/nginx     | default/web       | nginx.default.svc.cluster.local | web-{0..N-1}.nginx.default.svc.cluster.local | web-{0..N-1} |
+ cluster.local | foo/nginx         | foo/web           | nginx.foo.svc.cluster.local     | web-{0..N-1}.nginx.foo.svc.cluster.local     | web-{0..N-1} |
+ kube.local    | foo/nginx         | foo/web           | nginx.foo.svc.kube.local        | web-{0..N-1}.nginx.foo.svc.kube.local        | web-{0..N-1} |
+
 -->
 下面给出一些选择集群域、服务名、StatefulSet 名、及其怎样影响 StatefulSet 的 Pod 上的 DNS 名称的示例：
 
@@ -350,12 +399,14 @@ described [above](#deployment-and-scaling-guarantees).
 `Parallel` pod management tells the StatefulSet controller to launch or
 terminate all Pods in parallel, and to not wait for Pods to become Running
 and Ready or completely terminated prior to launching or terminating another
-Pod.
+Pod. This option only affects the behavior for scaling operations. Updates are not affected.
+
 -->
 #### 并行 Pod 管理   {#parallel-pod-management}
 
 `Parallel` Pod 管理让 StatefulSet 控制器并行的启动或终止所有的 Pod，
 启动或者终止其他 Pod 前，无需等待 Pod 进入 Running 和 ready 或者完全停止状态。
+这个选项只会影响伸缩操作的行为，更新则不会被影响。
 
 <!--
 ## Update Strategies
@@ -476,4 +527,3 @@ StatefulSet 才会开始使用被还原的模板来重新创建 Pod。
 * 示例一：[部署有状态应用](/zh/docs/tutorials/stateful-application/basic-stateful-set/)。
 * 示例二：[使用 StatefulSet 部署 Cassandra](/zh/docs/tutorials/stateful-application/cassandra/)。
 * 示例三：[运行多副本的有状态应用程序](/zh/docs/tasks/run-application/run-replicated-stateful-application/)。
-