add zh pages

2020-06-01 09:23:39 -04:00
parent 21fd0a12f9
commit 4b35d4d401
303 changed files with 2764 additions and 2439 deletions
@@ -1,6 +1,6 @@
 ---
 title: 将 Pod 分配给节点
-content_template: templates/concept
+content_type: concept
 weight: 50
 ---

@@ -11,13 +11,13 @@ reviewers:
 - kevin-wangzefeng
 - bsalamat
 title: Assigning Pods to Nodes
-content_template: templates/concept
+content_type: concept
 weight: 50
 ---
 -->


-{{% capture overview %}}
+<!-- overview -->

 <!--
 You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} to only be able to run on particular
@@ -33,9 +33,9 @@ services that communicate a lot into the same availability zone.

 你可以约束一个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 只能在特定的 {{< glossary_tooltip text="Node(s)" term_id="node" >}} 上运行，或者优先运行在特定的节点上。有几种方法可以实现这点，推荐的方法都是用[标签选择器](/docs/concepts/overview/working-with-objects/labels/)来进行选择。通常这样的约束不是必须的，因为调度器将自动进行合理的放置（比如，将 pod 分散到节点上，而不是将 pod 放置在可用资源不足的节点上等等），但在某些情况下，你可以需要更多控制 pod 停靠的节点，例如，确保 pod 最终落在连接了 SSD 的机器上，或者将来自两个不同的服务且有大量通信的 pod 放置在同一个可用区。

-{{% /capture %}}

-{{% capture body %}}
+
+<!-- body -->

 ## nodeSelector

@@ -664,9 +664,10 @@ The above pod will run on the node kube-01.

 上面的 pod 将运行在 kube-01 节点上。

-{{% /capture %}}

-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+

 <!--
 [Taints](/docs/concepts/configuration/taint-and-toleration/) allow a Node to *repel* a set of Pods.
@@ -690,4 +691,4 @@ resource allocation decisions.

 一旦 pod 分配给 节点，kubelet 应用将运行该 pod 并且分配节点本地资源。[拓扑管理](/docs/tasks/administer-cluster/topology-manager/)

-{{% /capture %}}
+
@@ -1,10 +1,10 @@
 ---
 title: ConfigMap
-content_template: templates/concept
+content_type: concept
 weight: 20
 ---

-{{% capture overview %}}
+<!-- overview -->

 {{< glossary_definition term_id="configmap" prepend="ConfigMap 是" length="all" >}}

@@ -18,9 +18,9 @@ or use additional (third party) tools to keep your data private.
 ConfigMap 并不提供保密或者加密功能。如果你想存储的数据是机密的，请使用 {{< glossary_tooltip text="Secret" term_id="secret" >}} ，或者使用其他第三方工具来保证你的数据的私密性，而不是用 ConfigMap。
 {{< /caution >}}

-{{% /capture %}}

-{{% capture body %}}
+
+<!-- body -->
 <!--
 ## Motivation

@@ -213,8 +213,9 @@ ConfigMap 最常见的用法是为同一命名空间里某 Pod 中运行的容
 {{< /note >}}


-{{% /capture %}}
-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+

 <!--
 * Read about [Secrets](/docs/concepts/configuration/secret/).
@@ -226,4 +227,4 @@ ConfigMap 最常见的用法是为同一命名空间里某 Pod 中运行的容
 * 阅读 [配置 Pod 来使用 ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)。
 * 阅读 [Twelve-Factor 应用](https://12factor.net/) 来了解将代码和配置分开的动机。

-{{% /capture %}}
+
@@ -1,6 +1,6 @@
 ---
 title: 为容器管理计算资源
-content_template: templates/concept
+content_type: concept
 weight: 20
 feature:
  title: 自动装箱
@@ -11,7 +11,7 @@ feature:
 <!--
 ---
 title: Managing Compute Resources for Containers
-content_template: templates/concept
+content_type: concept
 weight: 20
 feature:
  title: Automatic binpacking
@@ -20,7 +20,7 @@ feature:
 ---
 -->

-{{% capture overview %}}
+<!-- overview -->

 <!--
 When you specify a [Pod](/docs/concepts/workloads/pods/pod/), you can optionally specify how
@@ -33,10 +33,10 @@ the difference between requests and limits, see
 -->
 当您定义 [Pod](/docs/user-guide/pods) 的时候可以选择为每个容器指定需要的 CPU 和内存（RAM）大小。当为容器指定了资源请求后，调度器就能够更好的判断出将容器调度到哪个节点上。如果您还为容器指定了资源限制，Kubernetes 就可以按照指定的方式来处理节点上的资源竞争。关于资源请求和限制的不同点和更多资料请参考 [Resource QoS](https://git.k8s.io/community/contributors/design-proposals/resource-qos.md)。

-{{% /capture %}}


-{{% capture body %}}
+
+<!-- body -->

 <!--
 ## Resource types
@@ -945,10 +945,11 @@ spec:
        example.com/foo: 1
 ```

-{{% /capture %}}


-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+

 <!--
 * Get hands-on experience [assigning Memory resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/).
@@ -968,4 +969,4 @@ spec:

 * [资源需求](/docs/resources-reference/{{< param "version" >}}/#resourcerequirements-v1-core)

-{{% /capture %}}
+
@@ -1,17 +1,17 @@
 ---
 title: 使用 kubeconfig 文件组织集群访问
-content_template: templates/concept
+content_type: concept
 weight: 60
 ---
 <!--
 ---
 title: Organizing Cluster Access Using kubeconfig Files
-content_template: templates/concept
+content_type: concept
 weight: 60
 ---
 --->

-{{% capture overview %}}
+<!-- overview -->

 <!--
 Use kubeconfig files to organize information about clusters, users, namespaces, and
@@ -46,10 +46,10 @@ For step-by-step instructions on creating and specifying kubeconfig files, see
 --->
 有关创建和指定 kubeconfig 文件的分步说明，请参阅[配置对多集群的访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。

-{{% /capture %}}


-{{% capture body %}}
+
+<!-- body -->

 <!--
 ## Supporting multiple clusters, users, and authentication mechanisms
@@ -264,10 +264,11 @@ are stored absolutely.
 --->
 kubeconfig 文件中的文件和路径引用是相对于 kubeconfig 文件的位置。命令行上的文件引用是相当对于当前工作目录的。在 `$HOME/.kube/config` 中，相对路径按相对路径存储，绝对路径按绝对路径存储。

-{{% /capture %}}


-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+

 <!--
 * [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
@@ -275,6 +276,6 @@ kubeconfig 文件中的文件和路径引用是相对于 kubeconfig 文件的位
 --->
 * [配置对多集群的访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
 * [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
-{{% /capture %}}
+


@@ -2,7 +2,7 @@
 reviewers:
 - mikedanese
 title: 配置最佳实践
-content_template: templates/concept
+content_type: concept
 weight: 10
 ---
 <!--
@@ -10,12 +10,12 @@ weight: 10
 reviewers:
 - mikedanese
 title: Configuration Best Practices
-content_template: templates/concept
+content_type: concept
 weight: 10
 ---
 -->

-{{% capture overview %}}
+<!-- overview -->
 <!--
 This document highlights and consolidates configuration best practices that are introduced throughout the user guide, Getting Started documentation, and examples.
 -->
@@ -26,9 +26,9 @@ This is a living document. If you think of something that is not on this list bu
 -->
 这是一份活文件。
 如果您认为某些内容不在此列表中但可能对其他人有用，请不要犹豫，提交问题或提交 PR。
-{{% /capture %}}

-{{% capture body %}}
+
+<!-- body -->
 <!--
 ## General Configuration Tips
 -->
@@ -264,4 +264,4 @@ The caching semantics of the underlying image provider make even `imagePullPolic
 - 使用`kubectl run`和`kubectl expose`来快速创建单容器部署和服务。
  有关示例，请参阅[使用服务访问集群中的应用程序](/docs/tasks/access-application-cluster/service-access-application-cluster/)。

-{{% /capture %}}
+
@@ -1,10 +1,10 @@
 ---
 title: Pod 开销
-content_template: templates/concept
+content_type: concept
 weight: 20
 ---

-{{% capture overview %}}
+<!-- overview -->

 {{< feature-state for_k8s_version="v1.18" state="beta" >}}

@@ -18,10 +18,10 @@ on top of the container requests & limits.
 在节点上运行 Pod 时，Pod 本身占用大量系统资源。这些资源是运行 Pod 内容器所需资源的附加资源。
 _POD 开销_ 是一个特性，用于计算 Pod 基础设施在容器请求和限制之上消耗的资源。

-{{% /capture %}}


-{{% capture body %}}
+
+<!-- body -->

 <!--
 ## Pod Overhead
@@ -298,11 +298,12 @@ from source in the meantime.
 在 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 中可以通过 `kube_pod_overhead` 指标来协助确定何时使用 PodOverhead 以及协助观察以一个既定开销运行的工作负载的稳定性。
 该特性在 kube-state-metrics 的 1.9 发行版本中不可用，不过预计将在后续版本中发布。在此之前，用户需要从源代码构建 kube-state-metrics. 

-{{% /capture %}}

-{{% capture whatsnext %}}
+
+## {{% heading "whatsnext" %}}
+

 * [RuntimeClass](/docs/concepts/containers/runtime-class/)
 * [PodOverhead 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)

-{{% /capture %}}
+
@@ -4,7 +4,7 @@ reviewers:
 - k82cn
 - ahg-g
 title: 扩展资源的资源箱打包
-content_template: templates/concept
+content_type: concept
 weight: 10
 ---
 <!--
@@ -14,12 +14,12 @@ reviewers:
 - k82cn
 - ahg-g
 title: Resource Bin Packing for Extended Resources
-content_template: templates/concept
+content_type: concept
 weight: 10
 ---
 -->

-{{% capture overview %}}
+<!-- overview -->

 {{< feature-state for_k8s_version="1.16" state="alpha" >}}

@@ -29,9 +29,9 @@ The kube-scheduler can be configured to enable bin packing of resources along wi
 可以将 kube-scheduler 配置为使用 `RequestedToCapacityRatioResourceAllocation` 优先级函数启用资源箱打包以及扩展资源。
 优先级函数可用于根据自定义需求微调 kube-scheduler 。

-{{% /capture %}}

-{{% capture body %}}
+
+<!-- body -->

 <!--
 ## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation
@@ -254,5 +254,5 @@ NodeScore   =  (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3)

 ```

-{{% /capture %}}
+

@@ -1,11 +1,11 @@
 ---
 title: Secret
-content_template: templates/concept
+content_type: concept
 weight: 50
 ---


-{{% capture overview %}}
+<!-- overview -->

 <!--
 Kubernetes `secret` objects let you store and manage sensitive information, such
@@ -18,9 +18,9 @@ is safer and more flexible than putting it verbatim in a
 将这些信息放在 `secret` 中比放在 {{< glossary_tooltip term_id="pod" >}} 的定义或者 {{< glossary_tooltip text="容器镜像" term_id="image" >}} 中来说更加安全和灵活。
 参阅 [Secret 设计文档](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) 获取更多详细信息。

-{{% /capture %}}

-{{% capture body %}}
+
+<!-- body -->

 <!--
 ## Overview of Secrets
@@ -1561,6 +1561,7 @@ for secret data, so that the secrets are not stored in the clear into {{< glossa
 - 可以创建和使用 secret 的 pod 的用户也可以看到该 secret 的值。即使 API server 策略不允许用户读取 secret 对象，用户也可以运行暴露 secret 的 pod。
 - 目前，任何节点的 root 用户都可以通过模拟 kubelet 来读取 API server 中的任何 secret。只有向实际需要它们的节点发送 secret 才能限制单个节点的根漏洞的影响，该功能还在计划中。

-{{% capture whatsnext %}}
+## {{% heading "whatsnext" %}}
+
+

-{{% /capture %}}
@@ -1,11 +1,11 @@
 ---
 title: Taint 和 Toleration
-content_template: templates/concept
+content_type: concept
 weight: 40
 ---


-{{% capture overview %}}
+<!-- overview -->
 <!--
 Node affinity, described [here](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature),
 is a property of *pods* that *attracts* them to a set of nodes (either as a
@@ -23,9 +23,9 @@ onto nodes with matching taints.
 -->
 Taint 和 toleration 相互配合，可以用来避免 pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ，这表示对于那些不能容忍这些 taint 的 pod，是不会被该节点接受的。如果将 toleration 应用于 pod 上，则表示这些 pod 可以（但不要求）被调度到具有匹配 taint 的节点上。

-{{% /capture %}}

-{{% capture body %}}
+
+<!-- body -->

 <!--