zhangqx2010
parent
5b0894a04b
commit
835f81cf9a
|
|
@ -1,32 +0,0 @@
|
|||
{% if overview %}
|
||||
|
||||
{{ overview }}
|
||||
|
||||
{% else %}
|
||||
|
||||
{% include templates/_errorthrower.md missing_block='overview' purpose='provides an overview of this concept.' %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
{% if body %}
|
||||
|
||||
{{ body }}
|
||||
|
||||
{% else %}
|
||||
|
||||
{% include templates/_errorthrower.md missing_block='body' purpose='supplies the body of the page content.' %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
|
||||
{% if whatsnext %}
|
||||
|
||||
## What's next
|
||||
|
||||
{{ whatsnext }}
|
||||
|
||||
{% endif %}
|
||||
|
||||
|
|
@ -2,24 +2,17 @@
|
|||
assignees:
|
||||
- davidopp
|
||||
- lavalamp
|
||||
|
||||
title: 搭建大型集群
|
||||
---
|
||||
|
||||
|
||||
## 支持
|
||||
|
||||
|
||||
在 {{page.version}} 版本中，Kubernetes 支持集群节点（node）数可达1000个。更具体地说，我们配置能够支持*所有*如下条件：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
* 不超过2000个节点
|
||||
* 不超过总共6000个 pod
|
||||
* 不超过总共12000个 container
|
||||
* 单节点不超过100个 pod
|
||||
* 最多2000个节点
|
||||
* 总共最多6000个 pod
|
||||
* 总共最多12000个 container
|
||||
* 单节点最多100个 pod
|
||||
|
||||
<br>
|
||||
|
||||
|
|
@ -29,27 +22,20 @@ title: 搭建大型集群
|
|||
|
||||
## 安装
|
||||
|
||||
|
||||
集群是一组运行着 Kubernetes 代理的节点（物理或者虚机），被 "主服务器" （集群层面的控制台）所管理。
|
||||
|
||||
|
||||
通常来说，集群中的节点数是通过平台特定的 `config-default.sh` 文件（例子参考 [GCE's `config-default.sh`](http://releases.k8s.io/{{page.githubbranch}}/cluster/gce/config-default.sh) ）中的 `NUM_NODES` 值控制的。
|
||||
|
||||
|
||||
然而，单单把这个值更改到很大的数值会导致安装脚本在许多云服务商平台上运行失败。例如 GCE 部署，会有配额问题导致集群启动失败。
|
||||
|
||||
|
||||
当需要建立大规模 Kubernetes 集群时，必须考虑下列问题：
|
||||
|
||||
|
||||
### 配额问题
|
||||
|
||||
|
||||
为了避免在云服务商平台上发生配额问题，当创建一个许多节点的集群时，要考虑：
|
||||
|
||||
|
||||
* 增加这些资源的配额，比如 CPU ，IP 地址等等。
|
||||
* 在 [GCE 中，举个例子](https://cloud.google.com/compute/docs/resource-quotas) 你会需要增加：
|
||||
* 例如，在 [GCE 中，举个例子](https://cloud.google.com/compute/docs/resource-quotas) 中用户需要提升以下资源的配额：
|
||||
* CPU
|
||||
* 虚拟机实例
|
||||
* 永久磁盘的预留总量
|
||||
|
|
@ -60,28 +46,20 @@ title: 搭建大型集群
|
|||
* 目标池
|
||||
* 调整好安装脚本，让它能够在创建虚拟机节点的批处理中有等待时间，因为很多云服务商平台对于虚拟机的创建频率有限制。
|
||||
|
||||
|
||||
### Etcd 存储
|
||||
|
||||
|
||||
为了提高大规模集群的性能，我们将 event 存储在一个独立的 etcd 实例中。
|
||||
|
||||
为了提高大规模集群的性能，我们将事件（event）存储在一个独立并且是专用的 etcd 实例中。
|
||||
|
||||
当创建一个集群时，现有的 salt 脚本会：
|
||||
|
||||
|
||||
|
||||
* 启动并配置额外的 etcd 实例
|
||||
* 配置 api-server 用于储存 event
|
||||
|
||||
* 配置 api-server 用于储存事件
|
||||
|
||||
### 主服务器和主服务器组件的规格
|
||||
|
||||
|
||||
在 GCE/GKE 和 AWS 上，`kube-up` 自动为你的主服务器配置合适的虚拟机规格，规格取决于集群中的节点数量。
|
||||
对于其他云服务商平台，你需要手工配置。作为参考，我们在 GCE 上使用的规格是：
|
||||
|
||||
|
||||
* 1-5 节点: n1-standard-1
|
||||
* 6-10 节点: n1-standard-2
|
||||
* 11-100 节点: n1-standard-4
|
||||
|
|
@ -89,10 +67,8 @@ title: 搭建大型集群
|
|||
* 251-500 节点: n1-standard-16
|
||||
* 超过 500 节点: n1-standard-32
|
||||
|
||||
|
||||
在 AWS 上我们使用的规格：
|
||||
|
||||
|
||||
* 1-5 节点: m3.medium
|
||||
* 6-10 节点: m3.large
|
||||
* 11-100 节点: m3.xlarge
|
||||
|
|
@ -100,16 +76,12 @@ title: 搭建大型集群
|
|||
* 251-500 节点: c4.4xlarge
|
||||
* 超过 500 节点: c4.8xlarge
|
||||
|
||||
|
||||
注意，主服务器节点规格只能在集群启动时设置，如果后续对于集群扩容或者缩容（比如，使用手工或集群自动扩展器进行增加或删除节点），规格是不会调整的。
|
||||
|
||||
|
||||
### 插件（Addon）资源
|
||||
|
||||
|
||||
为了防止 [集群插件](https://releases.k8s.io/{{page.githubbranch}}/cluster/addons) 内存泄漏或者其他资源问题导致消耗完节点的所有资源，Kubernetes 对插件容器设定了资源限制，以限制他们使用 CPU 和内存资源。（参见 PR [#10653](http://pr.k8s.io/10653/files) 和 [#10778](http://pr.k8s.io/10778/files)）
|
||||
|
||||
|
||||
举例:
|
||||
|
||||
```yaml
|
||||
|
|
@ -122,13 +94,10 @@ title: 搭建大型集群
|
|||
memory: 200Mi
|
||||
```
|
||||
|
||||
|
||||
除了 Heapster 之外，这些限制是固定的，并且是基于我们对于插件运行在4节点集群的采样数据（见 [#10335](http://issue.k8s.io/10335#issuecomment-117861225)）。运行在大规模集群上时，插件会消耗更多的资源（见 [#5880](http://issue.k8s.io/5880#issuecomment-113984085)）。所以，如果大规模集群没有调整这些参数时，插件容器可能会被持续杀死，因为他们总是达到限制。
|
||||
|
||||
|
||||
为了避免集群的插件资源问题出现，当创建一个许多节点的集群时，考虑如下问题：
|
||||
|
||||
|
||||
* 为以下每个插件调整内存和 CPU 限制，使用时，随着你的集群扩容（每个插件有一个 replica 来处理整个集群，所以 CPU/内存 使用量会随着集群的 规模/负载 按比例增加）:
|
||||
* [InfluxDB and Grafana](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
|
||||
* [kubedns, dnsmasq, and sidecar](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/kubedns-controller.yaml.in)
|
||||
|
|
@ -139,21 +108,16 @@ title: 搭建大型集群
|
|||
* [FluentD with ElasticSearch Plugin](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
|
||||
* [FluentD with GCP Plugin](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
|
||||
|
||||
|
||||
Heapster 的资源限制是基于集群的初始规模动态配置的（见 [#16185](http://issue.k8s.io/16185) 和 [#22940](http://issue.k8s.io/22940)）。
|
||||
如果你发现 Heapster 的资源不够，你应该调整 Heapster 对于内存的请求的计算公式（详见这些 PRs）。
|
||||
|
||||
|
||||
对于如何检查插件容器是否达到了资源使用限制，参考 [计算资源的问题排查章节](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting)。
|
||||
|
||||
|
||||
在 [未来](http://issue.k8s.io/13048)，我们预期会基于集群规模来设置所有集群插件的资源限制，并且会在你的集群扩容或缩容时进行动态调整。
|
||||
我们欢迎致力于实现这些功能的 PR 。
|
||||
|
||||
|
||||
### 允许少数节点在启动时失败
|
||||
|
||||
|
||||
由于各种原因 (详细信息见 [#18969](https://github.com/kubernetes/kubernetes/issues/18969))，运行 `kube-up.sh` 建立非常大
|
||||
的 `NUM_NODES` 数量的集群会由于个别的节点的启动失败而失败。目前你有两个选择：重启集群（再次运行 `kube-down.sh` 和 `kube-up.sh`），
|
||||
或者，在运行 `kube-up.sh` 之前，将 `ALLOWED_NOTREADY_NODES` 环境变量设置成合适的值。这会让 `kube-up.sh` 在少于 `NUM_NODES`
|
||||
|
|
|
|||
|
|
@ -1,109 +0,0 @@
|
|||
---
|
||||
assignees:
|
||||
- bprashanth
|
||||
- davidopp
|
||||
- lavalamp
|
||||
- liggitt
|
||||
title: 管理服务帐号（Service Accounts）
|
||||
---
|
||||
|
||||
|
||||
|
||||
*本文是服务帐户管理员手册。需要[服务帐户用户手册](/docs/user-guide/service-accounts)的知识背景。*
|
||||
|
||||
*对于认证和用户帐号（user accounts）的支持已经在计划中，但是还未完成。为了更好地解释用户帐户，有时会提到一些未完成的功能特性。*
|
||||
|
||||
|
||||
## 用户账号 vs 服务账号
|
||||
|
||||
|
||||
Kubernetes 将用户账号和服务账号的概念区分开，主要基于以下几个原因：
|
||||
|
||||
- 用户账号是给人使用的。服务账号是给 pod 中运行的进程使用的。
|
||||
- 用户账号为全局设计的。命名必须在一个集群的所有命名空间中唯一，未来的用户资源不会被设计到命名空间中。
|
||||
服务账号是在命名空间里的。
|
||||
- 典型场景中，一个集群的用户账号是从企业数据库的同步来的，在数据库中新用户帐号一般需要特殊权限，并且账号是与复杂的业务流程关联的。
|
||||
服务账号的创建往往更轻量，允许集群用户为特定的任务创建服务账号（即，权限最小化原则）。
|
||||
- 对于人和服务的账号，审计要求会是不同的。
|
||||
- 对于复杂系统而言，配置包可以包含该系统各类组件的服务账号定义，
|
||||
因为服务账号能被临时创建，并且有命名空间分类的名字，这类配置是便携式的。
|
||||
|
||||
|
||||
## 服务账号自动化
|
||||
|
||||
|
||||
服务账号的自动化由三个独立的组件共同配合实现：
|
||||
|
||||
- 用户账号准入控制器（Service account admission controller）
|
||||
- 令牌控制器（Token controller）
|
||||
- 服务账号控制器（Service account controller）
|
||||
|
||||
|
||||
### 服务账号准入控制器
|
||||
|
||||
|
||||
对于 pods 的操作是通过一个叫做 [准入控制器](/docs/admin/admission-controllers) 的插件（plugin）实现的。它是 APIserver 的一部分。
|
||||
当 pod 被创建或更新时，它会同步更改 pod。当这个插件是活动状态时（大部分版本默认是活动状态），在 pod 被创建或者更改时，
|
||||
它会做如下操作：
|
||||
|
||||
1. 如果 pod 没有配置 `ServiceAccount`，它会将 `ServiceAccount` 设置为 `default`。
|
||||
2. 确保被 pod 关联的 `ServiceAccount` 是存在的，否则就拒绝请求。
|
||||
3. 如果 pod 没有包含任何的 `ImagePullSecrets`，那么 `ServiceAccount` 的 `ImagePullSecrets` 就会被添加到 pod。
|
||||
4. 它会把 `volume` 添加给 pod，该 pod 包含有一个用于 API 访问的令牌。
|
||||
5. 它会把 `volumeSource` 添加到 pod 的每个容器，挂载到 `/var/run/secrets/kubernetes.io/serviceaccount`。
|
||||
|
||||
|
||||
### 令牌控制器
|
||||
|
||||
|
||||
令牌控制器（TokenController）作为 controller-manager 的一部分运行。它异步运行。它会：
|
||||
|
||||
- 监听对于 serviceAccount 的创建动作，并创建对应的 Secret 以允许 API 访问。
|
||||
- 监听对于 serviceAccount 的删除动作，并删除所有对应的 ServiceAccountToken Secret。
|
||||
- 监听对于 secret 的添加动作，确保相关联的 ServiceAccount 是存在的，并根据需要为 secret 添加一个令牌。
|
||||
- 监听对于 secret 的删除动作，并根据需要删除对应 ServiceAccount 的关联。
|
||||
|
||||
你必须给令牌控制器传递一个服务帐号的私钥（private key），通过 `--service-account-private-key-file` 参数完成。传递的私钥将被用来对服务帐号令牌进行签名。
|
||||
类似的，你必须给 kube-apiserver 传递一个公钥（public key），通过 `--service-account-key-file` 参数完成。传递的公钥在认证过程中会被用于验证令牌。
|
||||
|
||||
|
||||
#### 创建额外的 API 令牌（API token）
|
||||
|
||||
|
||||
控制器的循环运行会确保对于每个服务帐号都存在一个带有 API 令牌的 secret。
|
||||
如需要为服务帐号创建一个额外的 API 令牌，可以创建一个 `ServiceAccountToken`
|
||||
类型的 secret，并添加与服务帐号对应的 annotation 属性，控制器会为它更新令牌：
|
||||
|
||||
secret.json:
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "Secret",
|
||||
"apiVersion": "v1",
|
||||
"metadata": {
|
||||
"name": "mysecretname",
|
||||
"annotations": {
|
||||
"kubernetes.io/service-account.name": "myserviceaccount"
|
||||
}
|
||||
},
|
||||
"type": "kubernetes.io/service-account-token"
|
||||
}
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl create -f ./secret.json
|
||||
kubectl describe secret mysecretname
|
||||
```
|
||||
|
||||
|
||||
#### 删除/作废服务账号令牌
|
||||
|
||||
```shell
|
||||
kubectl delete secret mysecretname
|
||||
```
|
||||
|
||||
|
||||
### 服务账号控制器
|
||||
|
||||
|
||||
服务帐号控制器在命名空间内管理 ServiceAccount，需要保证名为 "default" 的 ServiceAccount 在每个命名空间中存在。
|
||||
Loading…
Reference in New Issue