[zh] Sync concepts pages for service-networking

* [zh] Umbrella issue: pages out of sync in concepts section(#26177 Misc
Batch 2)

```
[x] content/zh/docs/concepts/services-networking/network-policies.md
[x] content/zh/docs/concepts/services-networking/service.md
[x] content/zh/docs/concepts/services-networking/dns-pod-service.md
```

Signed-off-by: ydFu ader.ydfu@gmail.com

content/zh/docs/concepts/services-networking/dns-pod-service.md

@@ -271,17 +271,14 @@ record unless `publishNotReadyAddresses=True` is set on the Service.
 
 <!--
 ### Pod's setHostnameAsFQDN field {#pod-sethostnameasfqdn-field}
+
+{{< feature-state for_k8s_version="v1.20" state="beta" >}}
 -->
 ### Pod 的 setHostnameAsFQDN 字段  {#pod-sethostnameasfqdn-field}
 
-{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.20" state="beta" >}}
 
 <!--
-**Prerequisites**: The `SetHostnameAsFQDN` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
- The `SetHostnameAsFQDN` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
-must be enabled for the
-{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}
-
 When a Pod is configured to have fully qualified domain name (FQDN), its hostname is the short hostname. For example, if you have a Pod with the fully qualified domain name `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`, then by default the `hostname` command inside that Pod returns `busybox-1` and  the `hostname -fqdn` command returns the FQDN.
 -->
 **前置条件**：`SetHostnameAsFQDN`

content/zh/docs/concepts/services-networking/network-policies.md

@@ -69,6 +69,8 @@ By default, pods are non-isolated; they accept traffic from any source.
 Pods become isolated by having a NetworkPolicy that selects them. Once there is any NetworkPolicy in a namespace selecting a particular pod, that pod will reject any connections that are not allowed by any NetworkPolicy. (Other pods in the namespace that are not selected by any NetworkPolicy will continue to accept all traffic.)
 
 Network policies do not conflict; they are additive. If any policy or policies select a pod, the pod is restricted to what is allowed by the union of those policies' ingress/egress rules. Thus, order of evaluation does not affect the policy result.
+
+For a network flow between two pods to be allowed, both the egress policy on the source pod and the ingress policy on the destination pod need to allow the traffic. If either the egress policy on the source, or the ingress policy on the destination denies the traffic, the traffic will be denied.
 -->
 ## 隔离和非隔离的 Pod   {#isolated-and-non-isolated-pods}
 
@@ -83,6 +85,11 @@ Pod 在被某 NetworkPolicy 选中时进入被隔离状态。
 如果任何一个或多个策略选择了一个 Pod, 则该 Pod 受限于这些策略的
 入站（Ingress）/出站（Egress）规则的并集。因此评估的顺序并不会影响策略的结果。
 
+为了允许两个 Pods 之间的网络数据流，源端 Pod 上的出站（Egress）规则和
+目标端 Pod 上的入站（Ingress）规则都需要允许该流量。
+如果源端的出站（Egress）规则或目标端的入站（Ingress）规则拒绝该流量，
+则流量将被拒绝。
+
 <!--
 ## The NetworkPolicy resource {#networkpolicy-resource}
 

content/zh/docs/concepts/services-networking/service.md

@@ -225,7 +225,7 @@ For example:
   * You want to point your Service to a Service in a different
     {{< glossary_tooltip term_id="namespace" >}} or on another cluster.
 * You are migrating a workload to Kubernetes. While evaluating the approach,
-    you run only a proportion of your backends in Kubernetes.
+    you run only a portion of your backends in Kubernetes.
 
 In any of these scenarios you can define a Service _without_ a Pod selector.
 For example:
@@ -406,7 +406,7 @@ There are a few reasons for using proxying for Services:
 <!--
 ### User space proxy mode {#proxy-mode-userspace}
 
-In this mode, kube-proxy watches the Kubernetes master for the addition and
+In this mode, kube-proxy watches the Kubernetes control plane for the addition and
 removal of Service and Endpoint objects. For each Service it opens a
 port (randomly chosen) on the local node.  Any connections to this "proxy port"
 are proxied to one of the Service's backend Pods (as reported via
@@ -423,7 +423,7 @@ By default, kube-proxy in userspace mode chooses a backend via a round-robin alg
 -->
 ### userspace 代理模式 {#proxy-mode-userspace}
 
-这种模式，kube-proxy 会监视 Kubernetes 主控节点对 Service 对象和 Endpoints 对象的添加和移除操作。
+这种模式，kube-proxy 会监视 Kubernetes 控制平面对 Service 对象和 Endpoints 对象的添加和移除操作。
 对每个 Service，它会在本地 Node 上打开一个端口（随机选择）。
 任何连接到“代理端口”的请求，都会被代理到 Service 的后端 `Pods` 中的某个上面（如 `Endpoints` 所报告的一样）。
 使用哪个后端 Pod，是 kube-proxy 基于 `SessionAffinity` 来确定的。