[zh]Part1:updated the term "群集" to "集群"

2022-05-16 19:03:55 +08:00
parent 76d91f11ec
commit fb1a2cb54a
33 changed files with 46 additions and 46 deletions
@@ -45,7 +45,7 @@ weight: 10
                  </p>

                <!-- <p>Once the application instances are created, a Kubernetes Deployment Controller continuously monitors those instances. If the Node hosting an instance goes down or is deleted, the Deployment controller replaces the instance with an instance on another Node in the cluster. <b>This provides a self-healing mechanism to address machine failure or maintenance.</b></p> -->
-                <p>创建应用程序实例后，Kubernetes Deployment 控制器会持续监视这些实例。 如果托管实例的节点关闭或被删除，则 Deployment 控制器会将该实例替换为群集中另一个节点上的实例。 <b>这提供了一种自我修复机制来解决机器故障维护问题。</b></p>
+                <p>创建应用程序实例后，Kubernetes Deployment 控制器会持续监视这些实例。 如果托管实例的节点关闭或被删除，则 Deployment 控制器会将该实例替换为集群中另一个节点上的实例。 <b>这提供了一种自我修复机制来解决机器故障维护问题。</b></p>

                <!-- <p>In a pre-orchestration world, installation scripts would often be used to start applications, but they did not allow recovery from machine failure.  By both creating your application instances and keeping them running across Nodes, Kubernetes Deployments provide a fundamentally different approach to application management. </p> -->
                <p>在没有 Kubernetes 这种编排系统之前，安装脚本通常用于启动应用程序，但它们不允许从机器故障中恢复。通过创建应用程序实例并使它们在节点之间运行， Kubernetes Deployments 提供了一种与众不同的应用程序管理方法。</p>
@@ -63,7 +63,7 @@ weight: 10
 <!--
        <p>Pods are the atomic unit on the Kubernetes platform. When we create a Deployment on Kubernetes, that Deployment creates Pods with containers inside them (as opposed to creating containers directly). Each Pod is tied to the Node where it is scheduled, and remains there until termination (according to restart policy) or deletion. In case of a Node failure, identical Pods are scheduled on other available Nodes in the cluster.</p>
 -->
-        <p>Pod是 Kubernetes 平台上的原子单元。 当我们在 Kubernetes 上创建 Deployment 时，该 Deployment 会在其中创建包含容器的 Pod （而不是直接创建容器）。每个 Pod 都与调度它的工作节点绑定，并保持在那里直到终止（根据重启策略）或删除。 如果工作节点发生故障，则会在群集中的其他可用工作节点上调度相同的 Pod。</p>
+        <p>Pod是 Kubernetes 平台上的原子单元。 当我们在 Kubernetes 上创建 Deployment 时，该 Deployment 会在其中创建包含容器的 Pod （而不是直接创建容器）。每个 Pod 都与调度它的工作节点绑定，并保持在那里直到终止（根据重启策略）或删除。 如果工作节点发生故障，则会在集群中的其他可用工作节点上调度相同的 Pod。</p>

      </div>
      <div class="col-md-4">
@@ -124,7 +124,7 @@ weight: 10
        </ul>
 -->
        <h2>工作节点</h2>
-        <p>一个 pod 总是运行在 <b>工作节点</b>。工作节点是 Kubernetes 中的参与计算的机器，可以是虚拟机或物理计算机，具体取决于集群。每个工作节点由主节点管理。工作节点可以有多个 pod ，Kubernetes 主节点会自动处理在群集中的工作节点上调度 pod 。 主节点的自动调度考量了每个工作节点上的可用资源。</p>
+        <p>一个 pod 总是运行在 <b>工作节点</b>。工作节点是 Kubernetes 中的参与计算的机器，可以是虚拟机或物理计算机，具体取决于集群。每个工作节点由主节点管理。工作节点可以有多个 pod ，Kubernetes 主节点会自动处理在集群中的工作节点上调度 pod 。 主节点的自动调度考量了每个工作节点上的可用资源。</p>

        <p>每个 Kubernetes 工作节点至少运行:</p>
        <ul>
@@ -199,7 +199,7 @@ weight: 10
 <!--
          <p><i> A node is a worker machine in Kubernetes and may be a VM or physical machine, depending on the cluster. Multiple Pods can run on one Node. </i></p>
 -->
-          <p><i>工作节点是 Kubernetes 中的负责计算的机器，可能是VM或物理计算机，具体取决于群集。多个 Pod 可以在一个工作节点上运行。 </i></p>
+          <p><i>工作节点是 Kubernetes 中的负责计算的机器，可能是VM或物理计算机，具体取决于集群。多个 Pod 可以在一个工作节点上运行。 </i></p>
        </div>
      </div>
    </div>
@@ -520,7 +520,7 @@ PodSecurityPolicy 在 Kubernetes v1.21 版本中已被废弃，将在 v1.25 版
 If the PodSecurityPolicy extension is enabled, cluster-wide AppArmor restrictions can be applied. To
 enable the PodSecurityPolicy, the following flag must be set on the `apiserver`: 
 -->
-如果启用了 PodSecurityPolicy 扩展，则可以应用群集范围的 AppArmor 限制。
+如果启用了 PodSecurityPolicy 扩展，则可以应用集群范围的 AppArmor 限制。
 要启用 PodSecurityPolicy，必须在 `apiserver` 上设置以下标志：

 ```
@@ -117,7 +117,7 @@ When a PersistentVolumeClaim is created, a PersistentVolume is dynamically provi

 MySQL 和 Wordpress 都需要一个 PersistentVolume 来存储数据。他们的 PersistentVolumeClaims 将在部署步骤中创建。

-许多群集环境都安装了默认的 StorageClass。如果在 PersistentVolumeClaim 中未指定 StorageClass，则使用群集的默认 StorageClass。
+许多集群环境都安装了默认的 StorageClass。如果在 PersistentVolumeClaim 中未指定 StorageClass，则使用集群的默认 StorageClass。

 创建 PersistentVolumeClaim 时，将根据 StorageClass 配置动态设置 PersistentVolume。

@@ -126,7 +126,7 @@ MySQL 和 Wordpress 都需要一个 PersistentVolume 来存储数据。他们的
 In local clusters, the default StorageClass uses the `hostPath` provisioner.  `hostPath` volumes are only suitable for development and testing. With `hostPath` volumes, your data lives in `/tmp` on the node the Pod is scheduled onto and does not move between nodes. If a Pod dies and gets scheduled to another node in the cluster, or the node is rebooted, the data is lost.
 -->

-在本地群集中，默认的 StorageClass 使用`hostPath`供应器。 `hostPath`卷仅适用于开发和测试。使用 `hostPath` 卷，你的数据位于 Pod 调度到的节点上的`/tmp`中，并且不会在节点之间移动。如果 Pod 死亡并被调度到群集中的另一个节点，或者该节点重新启动，则数据将丢失。
+在本地集群中，默认的 StorageClass 使用`hostPath`供应器。 `hostPath`卷仅适用于开发和测试。使用 `hostPath` 卷，你的数据位于 Pod 调度到的节点上的`/tmp`中，并且不会在节点之间移动。如果 Pod 死亡并被调度到群集中的另一个节点，或者该节点重新启动，则数据将丢失。
 {{< /warning >}}

 {{< note >}}