whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

zh-trans: update content/zh/docs/admin/cluster-large.md (#13771)

Browse Source
This commit is contained in:
SataQiu
2019-04-11 22:06:14 +08:00
committed by Kubernetes Prow Robot
parent 58f99cb2ef
commit f7f6d4125e
1 changed files with 32 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/admin/cluster-large.md
+11 -11
View File
@@ -21,9 +21,9 @@ title: 创建大规模集群
## 创建 ## 创建
集群是一组运行Kubernetes代理组件的节点(物理或虚拟机)，它们被 "master" (集群管理平面)所管理。 集群是一组运行 Kubernetes 代理组件的节点（物理或虚拟机），它们被 `master`（集群管理平面）所管理。
一般来说，集群的节点数量通过平台相关的 `config-default.sh` 文件中的 `NUM_NODES` 值来控制，(例如，详见 [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh))。 一般来说，集群的节点数量通过平台相关的 `config-default.sh` 文件中的 `NUM_NODES` 值来控制，（例如，详见 [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)）。
对很多云提供商来说，单纯地修改 `NUM_NODES` 为一个非常大的值，可能会导致集群的创建脚本失败。 例如，在 GCE 中部署时，会因配额不足，导致集群启动失败。 对很多云提供商来说，单纯地修改 `NUM_NODES` 为一个非常大的值，可能会导致集群的创建脚本失败。 例如，在 GCE 中部署时，会因配额不足，导致集群启动失败。
@@ -74,11 +74,11 @@ AWS使用的规格为：
* 251-500 节点： c4.4xlarge * 251-500 节点： c4.4xlarge
* 500 节点以上： c4.8xlarge * 500 节点以上： c4.8xlarge
注意，管理节点的规格只会在集群创建时进行设置，后续集群规模发生变化 (如 手动增删节点或集群自动扩缩容)后不会再调整。 注意，管理节点的规格只会在集群创建时进行设置，后续集群规模发生变化（如手动增删节点或集群自动扩缩容）后不会再调整。
### 插件的资源占用 ### 插件的资源占用
为防止 [集群插件](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) 耗尽节点资源引起内存泄漏或其他资源问题， Kubernetes 设置了插件容器资源的上限，来限制其对CPU和内存资源的占用 (参考 PR [#10653](http://pr.k8s.io/10653/files) 和 [#10778](http://pr.k8s.io/10778/files))。 为防止[集群插件](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons)耗尽节点资源引起内存泄漏或其他资源问题， Kubernetes 设置了插件容器资源的上限，来限制其对 CPU 和内存资源的占用（参考 PR [#10653](http://pr.k8s.io/10653/files) 和 [#10778](http://pr.k8s.io/10778/files)）。
例如： 例如：
@@ -92,22 +92,22 @@ AWS使用的规格为：
memory: 200Mi memory: 200Mi
``` ```
除 Heapster 外，这些限制是静态的，基于4个节点规模的集群上运行的插件所采集的数据 (详见 [#10335](http://issue.k8s.io/10335#issuecomment-117861225))。 而实际大规模集群中插件所消耗的资源要多得多 (详见 [#5880](http://issue.k8s.io/5880#issuecomment-113984085))。 所以如果部署大规模集群时不对这些值进行调整，插件可能会因为资源占用达到上限而不断被杀死。 除 Heapster 外，这些限制是静态的，基于 4 个节点规模的集群上运行的插件所采集的数据（详见 [#10335](http://issue.k8s.io/10335#issuecomment-117861225)）。 而实际大规模集群中插件所消耗的资源要多得多（详见 [#5880](http://issue.k8s.io/5880#issuecomment-113984085)）。 所以如果部署大规模集群时不对这些值进行调整，插件可能会因为资源占用达到上限而不断被杀死。
为了避免集群插件的资源问题，创建多节点的集群时，考虑以下几点： 为了避免集群插件的资源问题，创建多节点的集群时，考虑以下几点：
* 当扩大集群规模时，如果涉及，相应扩大以下插件的内存和CPU限制 (通过一个实例处理整个集群，因此其内存和CPU使用量往往与集群的大小/负载成比例增长)： * 当扩大集群规模时，如果涉及，相应扩大以下插件的内存和 CPU 限制（通过一个实例处理整个集群，因此其内存和 CPU 使用量往往与集群的大小/负载成比例增长）：
* [InfluxDB 和 Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml) * [InfluxDB 和 Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
* [kubedns, dnsmasq, 和 sidecar](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kubedns-controller.yaml.in) * [kubedns, dnsmasq, 和 sidecar](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kubedns-controller.yaml.in)
* [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-controller.yaml) * [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-controller.yaml)
* 当扩大集群规模时，如果涉及，相应扩大以下插件副本数 (每个组件有多个副本，因此增加副本将有助于处理增加的负载，但是，由于每个副本的负载也略有增加，也应考虑提高CPU /内存上限)： * 当扩大集群规模时，如果涉及，相应扩大以下插件副本数（每个组件有多个副本，因此增加副本将有助于处理增加的负载，但是，由于每个副本的负载也略有增加，也应考虑提高 CPU / 内存上限）：
* [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-controller.yaml) * [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-controller.yaml)
* 当扩大集群规模时，如果涉及，略微扩大以下插件的内存和CPU限制 (每个节点一个副本， 但是CPU/内存使用随集群的大小/负载增长变化不明显)： * 当扩大集群规模时，如果涉及，略微扩大以下插件的内存和 CPU 限制（每个节点一个副本， 但是 CPU / 内存使用随集群的大小/负载增长变化不明显）：
* [FluentD with ElasticSearch Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml) * [FluentD with ElasticSearch Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
* [FluentD with GCP Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml) * [FluentD with GCP Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
Heapster 的资源限制是基于集群的初始规模动态设置的 ( 参考 [#16185](http://issue.k8s.io/16185) Heapster 的资源限制是基于集群的初始规模动态设置的 ( 参考 [#16185](http://issue.k8s.io/16185)
和 [#22940](http://issue.k8s.io/22940))。 当发现Heapster资源耗尽，应考虑调整计算Heapster内存请求的公式 (参考上述PR)。 和 [#22940](http://issue.k8s.io/22940))。 当发现 Heapster 资源耗尽，应考虑调整计算 Heapster 内存请求的公式（参考上述 PR）。
关于如何检测插件是否达到资源上限 参考 [计算资源的故障排除章节](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting)。 关于如何检测插件是否达到资源上限 参考 [计算资源的故障排除章节](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting)。
@@ -116,7 +116,7 @@ Heapster的资源限制是基于集群的初始规模动态设置的 (参考 [#1
### 启动时允许部分失败 ### 启动时允许部分失败
因为种种原因 (详见 [#18969](https://github.com/kubernetes/kubernetes/issues/18969))，在 `NUM_NODES` 值很大的情况下执行 因为种种原因（详见 [#18969](https://github.com/kubernetes/kubernetes/issues/18969)），在 `NUM_NODES` 值很大的情况下执行
`kube-up.sh`， 可能因为其中一小部分节点没有正常启动而失败。 `kube-up.sh`， 可能因为其中一小部分节点没有正常启动而失败。
这时我们有两种选择：重启集群 (`kube-down.sh` 然后再 `kube-up.sh`），或者在执行 `kube-up.sh`之前， 这时我们有两种选择：重启集群（`kube-down.sh` 然后再 `kube-up.sh`），或者在执行 `kube-up.sh` 之前，
将环境变量 `ALLOWED_NOTREADY_NODES` 设置为合适的值。 这将允许 `kube-up.sh` 以少于 `NUM_NODES` 的节点数量启动集群。 依据失败的具体原因，另外的节点可能在后面加入集群，或者集群节点数量将保持在 `NUM_NODES - ALLOWED_NOTREADY_NODES`。 将环境变量 `ALLOWED_NOTREADY_NODES` 设置为合适的值。 这将允许 `kube-up.sh` 以少于 `NUM_NODES` 的节点数量启动集群。 依据失败的具体原因，另外的节点可能在后面加入集群，或者集群节点数量将保持在 `NUM_NODES - ALLOWED_NOTREADY_NODES`。