Skip to content

Commit

Permalink
[zh] Fix links in concepts section (1)
Browse files Browse the repository at this point in the history
  • Loading branch information
@tengqm
tengqm committed Jul 29, 2020
1 parent f2ff9c0 commit 8d7fd3f
Show file tree
Hide file tree
Showing 10 changed files with 211 additions and 429 deletions.
133 changes: 0 additions & 133 deletions content/zh/docs/concepts/_index.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -19,136 +19,3 @@ The Concepts section helps you learn about the parts of the Kubernetes system an
-->

概念部分可以帮助你了解 Kubernetes 的各个组成部分以及 Kubernetes 用来表示集群的一些抽象概念，并帮助你更加深入的理解 Kubernetes 是如何工作的。



<!-- body -->

<!--
## Overview
-->

## 概述

<!--
To work with Kubernetes, you use *Kubernetes API objects* to describe your cluster's *desired state*: what applications or other workloads you want to run, what container images they use, the number of replicas, what network and disk resources you want to make available, and more. You set your desired state by creating objects using the Kubernetes API, typically via the command-line interface, `kubectl`. You can also use the Kubernetes API directly to interact with the cluster and set or modify your desired state.
-->

要使用 Kubernetes，你需要用 *Kubernetes API 对象* 来描述集群的 *预期状态（desired state）* ：包括你需要运行的应用或者负载，它们使用的镜像、副本数，以及所需网络和磁盘资源等等。你可以使用命令行工具 `kubectl` 来调用 Kubernetes API 创建对象，通过所创建的这些对象来配置预期状态。你也可以直接调用 Kubernetes API 和集群进行交互，设置或者修改预期状态。

<!--
Once you've set your desired state, the *Kubernetes Control Plane* makes the cluster's current state match the desired state via the Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md)). To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster:
-->

一旦你设置了你所需的目标状态，*Kubernetes 控制面（control plane）* 会通过 Pod 生命周期事件生成器([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))，促成集群的当前状态符合其预期状态。为此，Kubernetes 会自动执行各类任务，比如运行或者重启容器、调整给定应用的副本数等等。Kubernetes 控制面由一组运行在集群上的进程组成：

<!--
* The **Kubernetes Master** is a collection of three processes that run on a single node in your cluster, which is designated as the master node. Those processes are: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) and [kube-scheduler](/docs/admin/kube-scheduler/).
* Each individual non-master node in your cluster runs two processes:
* **[kubelet](/docs/admin/kubelet/)**, which communicates with the Kubernetes Master.
* **[kube-proxy](/docs/admin/kube-proxy/)**, a network proxy which reflects Kubernetes networking services on each node.
-->

* **Kubernetes 主控组件（Master）** 包含三个进程，都运行在集群中的某个节点上，主控组件通常这个节点被称为 master 节点。这些进程包括：[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/) 和 [kube-scheduler](/docs/admin/kube-scheduler/)。
* 集群中的每个非 master 节点都运行两个进程：
* **[kubelet](/docs/admin/kubelet/)**，和 master 节点进行通信。
* **[kube-proxy](/docs/admin/kube-proxy/)**，一种网络代理，将 Kubernetes 的网络服务代理到每个节点上。

<!--
## Kubernetes Objects
-->

## Kubernetes 对象

<!--
Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API. See [Understanding Kubernetes Objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/) for more details.
-->

Kubernetes 包含若干用来表示系统状态的抽象层，包括：已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。这些抽象使用 Kubernetes API 对象来表示。有关更多详细信息，请参阅[了解 Kubernetes 对象](/docs/concepts/overview/working-with-objects/kubernetes-objects/)。

<!--
The basic Kubernetes objects include:
-->

基本的 Kubernetes 对象包括：

* [Pod](/docs/concepts/workloads/pods/pod-overview/)
* [Service](/docs/concepts/services-networking/service/)
* [Volume](/docs/concepts/storage/volumes/)
* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)

<!--
Kubernetes also contains higher-level abstractions that rely on [Controllers](/docs/concepts/architecture/controller/) to build upon the basic objects, and provide additional functionality and convenience features. These include:
-->

Kubernetes 也包含大量的被称作 [Controller](/docs/concepts/architecture/controller/) 的高级抽象。控制器基于基本对象构建并提供额外的功能和方便使用的特性。具体包括：

* [Deployment](/docs/concepts/workloads/controllers/deployment/)
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)

<!--
## Kubernetes Control Plane
-->

## Kubernetes 控制面

<!--
The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects' state. At any given time, the Control Plane's control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system match the desired state that you provided.
-->

关于 Kubernetes 控制平面的各个部分，（如 Kubernetes 主控组件和 kubelet 进程），管理着 Kubernetes 如何与你的集群进行通信。控制平面维护着系统中所有的 Kubernetes 对象的状态记录，并且通过连续的控制循环来管理这些对象的状态。在任意的给定时间点，控制面的控制环都能响应集群中的变化，并且让系统中所有对象的实际状态与你提供的预期状态相匹配。

<!--
For example, when you use the Kubernetes API to create a Deployment, you provide a new desired state for the system. The Kubernetes Control Plane records that object creation, and carries out your instructions by starting the required applications and scheduling them to cluster nodes--thus making the cluster's actual state match the desired state.
-->

比如， 当你通过 Kubernetes API 创建一个 Deployment 对象，你就为系统增加了一个新的目标状态。Kubernetes 控制平面记录着对象的创建，并启动必要的应用然后将它们调度至集群某个节点上来执行你的指令，以此来保持集群的实际状态和目标状态的匹配。

<!--
### Kubernetes Master
-->

### Kubernetes Master 节点

<!--
The Kubernetes master is responsible for maintaining the desired state for your cluster. When you interact with Kubernetes, such as by using the `kubectl` command-line interface, you're communicating with your cluster's Kubernetes master.
-->

Kubernetes master 节点负责维护集群的目标状态。当你要与 Kubernetes 通信时，使用如 `kubectl` 的命令行工具，就可以直接与 Kubernetes master 节点进行通信。

<!--
> The "master" refers to a collection of processes managing the cluster state. Typically all these processes run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundancy.
-->

> "master" 是指管理集群状态的一组进程的集合。通常这些进程都跑在集群中一个单独的节点上，并且这个节点被称为 master 节点。master 节点也可以扩展副本数，来获取更好的可用性及冗余。
<!--
### Kubernetes Nodes
-->

### Kubernetes Node 节点

<!--
The nodes in a cluster are the machines (VMs, physical servers, etc) that run your applications and cloud workflows. The Kubernetes master controls each node; you'll rarely interact with nodes directly.
-->

集群中的 node 节点（虚拟机、物理机等等）都是用来运行你的应用和云工作流的机器。Kubernetes master 节点控制所有 node 节点；你很少需要和 node 节点进行直接通信。




## {{% heading "whatsnext" %}}


<!--
If you would like to write a concept page, see
[Using Page Templates](/docs/home/contribute/page-templates/)
for information about the concept page type and the concept template.
-->

如果你想编写一个概念页面，请参阅[使用页面模板](/docs/home/contribute/page-templates/)获取更多有关概念页面类型和概念模板的信息。


12 changes: 6 additions & 6 deletions content/zh/docs/concepts/configuration/configmap.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,6 @@ ConfigMap 并不提供保密或者加密功能。如果你想存储的数据是
{{< /caution >}}



<!-- body -->
<!--
## Motivation
Expand Down Expand Up @@ -59,9 +58,11 @@ The name of a ConfigMap must be a valid
-->
## ConfigMap 对象

ConfigMap 是一个 API [对象](/docs/concepts/overview/working-with-objects/kubernetes-objects/)，让你可以存储其他对象所需要使用的配置。和其他 Kubernetes 对象都有一个 `spec` 不同的是，ConfigMap 使用 `data` 块来存储元素（键名）和它们的值。
ConfigMap 是一个 API [对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)，
让你可以存储其他对象所需要使用的配置。
和其他 Kubernetes 对象都有一个 `spec` 不同的是，ConfigMap 使用 `data` 块来存储元素（键名）和它们的值。

ConfigMap 的名字必须是一个合法的 [DNS 子域名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
ConfigMap 的名字必须是一个合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。

<!--
## ConfigMaps and Pods
Expand Down Expand Up @@ -216,15 +217,14 @@ ConfigMap 最常见的用法是为同一命名空间里某 Pod 中运行的容

## {{% heading "whatsnext" %}}


<!--
* Read about [Secrets](/docs/concepts/configuration/secret/).
* Read [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/).
* Read [The Twelve-Factor App](https://12factor.net/) to understand the motivation for
separating code from configuration.
-->
* 阅读 [Secret](/docs/concepts/configuration/secret/)。
* 阅读 [配置 Pod 来使用 ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)。
* 阅读 [Secret](/zh/docs/concepts/configuration/secret/)。
* 阅读 [配置 Pod 来使用 ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)。
* 阅读 [Twelve-Factor 应用](https://12factor.net/) 来了解将代码和配置分开的动机。


39 changes: 19 additions & 20 deletions content/zh/docs/concepts/configuration/manage-resources-containers.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -9,15 +9,13 @@ feature:
---

<!--
---
title: Managing Resources for Containers
content_type: concept
weight: 40
feature:
title: Automatic binpacking
description: >
Automatically places containers based on their resource requirements and other constraints, while not sacrificing availability. Mix critical and best-effort workloads in order to drive up utilization and save even more resources.
---
-->

<!-- overview -->
Expand All @@ -35,7 +33,7 @@ at least the _request_ amount of that system resource specifically for that cont
to use.
-->

当你定义 {{< glossary_tooltip term_id="pod" >}} 时可以选择性地为每个
当你定义 {{< glossary_tooltip text="Pod" term_id="pod" >}} 时可以选择性地为每个
{{< glossary_tooltip text="容器" term_id="container" >}}设定所需要的资源数量。
最常见的可设定资源是 CPU 和内存（RAM）大小；此外还有其他类型的资源。

Expand Down Expand Up @@ -138,8 +136,8 @@ through the Kubernetes API server.

CPU 和内存统称为*计算资源*，或简称为*资源*。
计算资源的数量是可测量的，可以被请求、被分配、被消耗。
它们与 [API 资源](/docs/concepts/overview/kubernetes-api/) 不同。
API 资源（如 Pod 和 [Service](/docs/concepts/services-networking/service/)）是可通过
它们与 [API 资源](/zh/docs/concepts/overview/kubernetes-api/) 不同。
API 资源（如 Pod 和 [Service](/zh/docs/concepts/services-networking/service/)）是可通过
Kubernetes API 服务器读取和修改的对象。

<!--
Expand Down Expand Up @@ -388,9 +386,9 @@ directly or from your monitoring tools.
Pod 的资源使用情况是作为 Pod 状态的一部分来报告的。

如果为集群配置了可选的
[监控工具](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)，
[监控工具](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/)，
则可以直接从
[指标 API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api)
[指标 API](/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api)
或者监控工具获得 Pod 的资源使用情况。

<!--
Expand All @@ -417,7 +415,7 @@ mount [`emptyDir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir

Pods 通常可以使用临时性本地存储来实现缓冲区、保存日志等功能。
kubelet 可以为使用本地临时存储的 Pods 提供这种存储空间，允许后者使用
[`emptyDir`](/docs/concepts/storage/volumes/#emptydir) 类型的
[`emptyDir`](/zh/docs/concepts/storage/volumes/#emptydir) 类型的
{{< glossary_tooltip term_id="volume" text="卷" >}}将其挂载到容器中。

<!--
Expand All @@ -436,7 +434,7 @@ of ephemeral local storage a Pod can consume.
-->

kubelet 也使用此类存储来保存
[节点层面的容器日志](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)，
[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)，
容器镜像文件、以及运行中容器的可写入层。

{{< caution >}}
Expand Down Expand Up @@ -474,7 +472,7 @@ Kubernetes 有两种方式支持节点上配置本地临时性存储：
（kubelet）来保存数据的。

kubelet 也会生成
[节点层面的容器日志](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)，
[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)，
并按临时性本地存储的方式对待之。

<!--
Expand Down Expand Up @@ -525,7 +523,7 @@ as you like.
无关的其他系统日志）；这个文件系统还可以是根文件系统。

kubelet 也将
[节点层面的容器日志](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)
[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)
写入到第一个文件系统中，并按临时性本地存储的方式对待之。

同时你使用另一个由不同逻辑存储设备支持的文件系统。在这种配置下，你会告诉
Expand Down Expand Up @@ -558,7 +556,7 @@ than as local ephemeral storage.

kubelet 能够度量其本地存储的用量。实现度量机制的前提是：

- `LocalStorageCapacityIsolation` [特性门控](/docs/reference/command-line-tools-reference/feature-gates/)被启用（默认状态），并且
- `LocalStorageCapacityIsolation` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)被启用（默认状态），并且
- 你已经对节点进行了配置，使之使用所支持的本地临时性储存配置方式之一

如果你的节点配置不同于以上预期，kubelet 就无法对临时性本地存储的资源约束实施限制。
Expand Down Expand Up @@ -650,7 +648,7 @@ The scheduler ensures that the sum of the resource requests of the scheduled Con
当你创建一个 Pod 时，Kubernetes 调度器会为 Pod 选择一个节点来运行之。
每个节点都有一个本地临时性存储的上限，是其可提供给 Pods 使用的总量。
欲了解更多信息，可参考
[节点可分配资源](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
[节点可分配资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
节。

调度器会确保所调度的 Containers 的资源请求总和不会超出节点的资源容量。
Expand Down Expand Up @@ -838,7 +836,7 @@ If you want to use project quotas, you should:
如果你希望使用项目配额，你需要：

* 在 kubelet 配置中启用 `LocalStorageCapacityIsolationFSQuotaMonitoring=true`
[特性门控](/docs/reference/command-line-tools-reference/feature-gates/)。
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。

* 确保根文件系统（或者可选的运行时文件系统）启用了项目配额。所有 XFS
文件系统都支持项目配额。
Expand Down Expand Up @@ -896,7 +894,8 @@ for how to advertise device plugin managed resources on each node.

##### 设备插件管理的资源

有关如何颁布在各节点上由设备插件所管理的资源，请参阅[设备插件](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。
有关如何颁布在各节点上由设备插件所管理的资源，请参阅
[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。

<!--
##### Other resources
Expand Down Expand Up @@ -1198,11 +1197,11 @@ with namespaces, it can prevent one team from hogging all the resources.
通过查看 `Pods` 部分，您将看到哪些 Pod 占用了节点上的资源。

可供 Pod 使用的资源量小于节点容量，因为系统守护程序也会使用一部分可用资源。
[NodeStatus](/docs/resources-reference/{{< param "version" >}}/#nodestatus-v1-core)
[NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core)
的 `allocatable` 字段给出了可用于 Pod 的资源量。
有关更多信息，请参阅 [节点可分配资源](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md)。

可以配置 [资源配额](/docs/concepts/policy/resource-quotas/) 功能特性以限制可以使用的资源总量。
可以配置 [资源配额](/zh/docs/concepts/policy/resource-quotas/) 功能特性以限制可以使用的资源总量。
如果与名字空间配合一起使用，就可以防止一个团队占用所有资源。

<!--
Expand Down Expand Up @@ -1301,10 +1300,10 @@ You can see that the Container was terminated because of `reason:OOM Killed`, wh
* Read about [project quotas](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS
-->

* 获取将 [分配内存资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验
* 获取将 [分配 CPU 资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验
* 获取将 [分配内存资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验
* 获取将 [分配 CPU 资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验
* 关于请求和约束之间的区别，细节信息可参见[资源服务质量](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md)
* 阅读 API 参考文档中 [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 部分。
* 阅读 API 参考文档中 [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) 部分。
* 阅读 XFS 中关于 [项目配额](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) 的文档。
* 阅读 XFS 中关于 [项目配额](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) 的文档。

Loading

0 comments on commit 8d7fd3f

Please sign in to comment.