[zh] Resync cluster-administration concepts

Author: tengqm

content/zh-cn/docs/concepts/cluster-administration/_index.md

@@ -5,6 +5,12 @@ content_type: concept
 description: >
   关于创建和管理 Kubernetes 集群的底层细节。
 no_list: true
+card:
+  name: setup
+  weight: 60
+  anchors:
+  - anchor: "#securing-a-cluster"
+    title: 保护集群
 ---
 <!--
 title: Cluster Administration
@@ -16,6 +22,12 @@ content_type: concept
 description: >
   Lower-level detail relevant to creating or administering a Kubernetes cluster.
 no_list: true
+card:
+  name: setup
+  weight: 60
+  anchors:
+  - anchor: "#securing-a-cluster"
+    title: Securing a cluster
 -->
 
 <!-- overview -->

content/zh-cn/docs/concepts/cluster-administration/networking.md

@@ -57,29 +57,40 @@ Kubernetes 的宗旨就是在应用之间共享机器。
 与其去解决这些问题，Kubernetes 选择了其他不同的方法。
 
 要了解 Kubernetes 网络模型，请参阅[此处](/zh-cn/docs/concepts/services-networking/)。
+
 <!--
 ## How to implement the Kubernetes network model
 
-The network model is implemented by the container runtime on each node. The most common container runtimes use [Container Network Interface](https://github.com/containernetworking/cni) (CNI) plugins to manage their network and security capabilities. Many different CNI plugins exist from many different vendors. Some of these provide only basic features of adding and removing network interfaces, while others provide more sophisticated solutions, such as integration with other container orchestration systems, running multiple CNI plugins, advanced IPAM features etc.
-
-See [this page](/docs/concepts/cluster-administration/addons/#networking-and-network-policy) for a non-exhaustive list of networking addons supported by Kubernetes.
+The network model is implemented by the container runtime on each node. The most common container
+runtimes use [Container Network Interface](https://github.com/containernetworking/cni) (CNI)
+plugins to manage their network and security capabilities. Many different CNI plugins exist from
+many different vendors. Some of these provide only basic features of adding and removing network
+interfaces, while others provide more sophisticated solutions, such as integration with other
+container orchestration systems, running multiple CNI plugins, advanced IPAM features etc.
 -->
 ## 如何实现 Kubernetes 的网络模型    {#how-to-implement-the-kubernetes-network-model}
 
-网络模型由每个节点上的容器运行时实现。最常见的容器运行时使用
-[Container Network Interface](https://github.com/containernetworking/cni) (CNI) 插件来管理其网络和安全功能。
-许多不同的 CNI 插件来自于许多不同的供应商。其中一些仅提供添加和删除网络接口的基本功能，
+网络模型由各节点上的容器运行时来实现。最常见的容器运行时使用
+[Container Network Interface](https://github.com/containernetworking/cni) (CNI) 插件来管理其网络和安全能力。
+来自不同供应商 CNI 插件有很多。其中一些仅提供添加和删除网络接口的基本功能，
 而另一些则提供更复杂的解决方案，例如与其他容器编排系统集成、运行多个 CNI 插件、高级 IPAM 功能等。
 
+<!--
+See [this page](/docs/concepts/cluster-administration/addons/#networking-and-network-policy)
+for a non-exhaustive list of networking addons supported by Kubernetes.
+-->
 请参阅[此页面](/zh-cn/docs/concepts/cluster-administration/addons/#networking-and-network-policy)了解
 Kubernetes 支持的网络插件的非详尽列表。
 
 ## {{% heading "whatsnext" %}}
 
 <!--
-The early design of the networking model and its rationale, and some future
-plans are described in more detail in the
+The early design of the networking model and its rationale are described in more detail in the
 [networking design document](https://git.k8s.io/design-proposals-archive/network/networking.md).
+For future plans and some on-going efforts that aim to improve Kubernetes networking, please
+refer to the SIG-Network
+[KEPs](https://github.com/kubernetes/enhancements/tree/master/keps/sig-network).
 -->
-网络模型的早期设计、运行原理以及未来的一些计划，
-都在[联网设计文档](https://git.k8s.io/design-proposals-archive/network/networking.md)里有更详细的描述。
+网络模型的早期设计、运行原理都在[联网设计文档](https://git.k8s.io/design-proposals-archive/network/networking.md)里有详细描述。
+关于未来的计划，以及旨在改进 Kubernetes 联网能力的一些正在进行的工作，可以参考 SIG Network
+的 [KEPs](https://github.com/kubernetes/enhancements/tree/master/keps/sig-network)。

content/zh-cn/docs/concepts/cluster-administration/system-traces.md

@@ -215,12 +215,19 @@ span will be sent to the exporter.
 <!--
 The kubelet in Kubernetes v{{< skew currentVersion >}} collects spans from
 the garbage collection, pod synchronization routine as well as every gRPC
-method. Connected container runtimes like CRI-O and containerd can link the
-traces to their exported spans to provide additional context of information.
+method. The kubelet propagates trace context with gRPC requests so that
+container runtimes with trace instrumentation, such as CRI-O and containerd,
+can associate their exported spans with the trace context from the kubelet.
+The resulting traces will have parent-child links between kubelet and
+container runtime spans, providing helpful context when debugging node
+issues.
 -->
-Kubernetes v{{< skew currentVersion >}} 中的 kubelet 从垃圾回收、Pod
-同步例程以及每个 gRPC 方法中收集 span。CRI-O 和 containerd
-这类关联的容器运行时可以将链路链接到其导出的 span，以提供更多上下文信息。
+Kubernetes v{{< skew currentVersion >}} 中的 kubelet 收集与垃圾回收、Pod
+同步例程以及每个 gRPC 方法相关的 Span。
+kubelet 借助 gRPC 来传播跟踪上下文，以便 CRI-O 和 containerd
+这类带有跟踪插桩的容器运行时可以在其导出的 Span 与 kubelet
+所提供的跟踪上下文之间建立关联。所得到的跟踪数据会包含 kubelet
+与容器运行时 Span 之间的父子链接关系，从而为调试节点问题提供有用的上下文信息。
 
 <!--
 Please note that exporting spans always comes with a small performance overhead