remove docs/admin (#14941)
This commit is contained in:
Jinhua Tan
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
0ef6f561f1
commit
d7d268f38f
@@ -0,0 +1,122 @@
|
||||
---
|
||||
approvers:
|
||||
- davidopp
|
||||
- lavalamp
|
||||
title: 创建大规模集群
|
||||
---
|
||||
|
||||
## 支持规格
|
||||
|
||||
在 {{< param "version" >}}，Kubernetes支持最多5000节点规模的集群。 更具体地说，我们支持满足以下 *所有* 标准的配置：
|
||||
|
||||
* 不超过5000节点
|
||||
* 总共不超过15000个pod
|
||||
* 总共不超过300000个容器
|
||||
* 每个节点不超过100个pod
|
||||
|
||||
<br>
|
||||
|
||||
* TOC
|
||||
{{< toc >}}
|
||||
|
||||
## 创建
|
||||
|
||||
集群是一组运行Kubernetes代理组件的节点(物理或虚拟机)，它们被 "master" (集群管理平面)所管理。
|
||||
|
||||
一般来说，集群的节点数量通过平台相关的 `config-default.sh` 文件中的 `NUM_NODES` 值来控制，(例如，详见 [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh))。
|
||||
|
||||
对很多云提供商来说，单纯地修改`NUM_NODES` 为一个非常大的值，可能会导致集群的创建脚本失败。 例如，在GCE中部署时，会因配额不足，导致集群启动失败。
|
||||
|
||||
当建立一个大型的Kubernetes集群，以下几个问题必须考虑。
|
||||
|
||||
### 配额问题
|
||||
|
||||
为了避免出现配额问题，当创建包含大量节点的集群时，考虑：
|
||||
|
||||
* 提高相关配额，如CPU，IP等。
|
||||
* 如，在 [GCE](https://cloud.google.com/compute/docs/resource-quotas)中，你可能需要提高以下资源的配额：
|
||||
* CPU
|
||||
* 虚机实例
|
||||
* 磁盘
|
||||
* 使用的IP地址
|
||||
* 防火墙规则
|
||||
* 转发规则
|
||||
* 路由
|
||||
* 对象池
|
||||
* 设置创建脚本，使其以较小的规模分批次拉起新的节点，并在其间设置一定的等待时间，因为一些云供应商可能对虚机的创建速率进行了限制。
|
||||
|
||||
### Etcd存储
|
||||
|
||||
为了提升大规模集群的性能，我们将事件对象存储到独立的etcd实例中。
|
||||
|
||||
创建集群时，当前的salt脚本：
|
||||
|
||||
* 启动并配置额外的etcd实例
|
||||
* 配置api-server，将该etcd实例用于事件对象的存储
|
||||
|
||||
### 管理节点和组件的规格
|
||||
|
||||
在 GCE/Google Kubernetes Engine 或 AWS平台中， `kube-up` 会根据集群的节点规模合理地设置管理节点的规格。 在其他云平台上，用户需要手动配置。 作为参考，GCE使用的规格为：
|
||||
|
||||
* 1-5 节点： n1-standard-1
|
||||
* 6-10 节点： n1-standard-2
|
||||
* 11-100 节点： n1-standard-4
|
||||
* 101-250 节点： n1-standard-8
|
||||
* 251-500 节点： n1-standard-16
|
||||
* 500节点以上： n1-standard-32
|
||||
|
||||
AWS使用的规格为：
|
||||
|
||||
* 1-5 节点： m3.medium
|
||||
* 6-10 节点： m3.large
|
||||
* 11-100 节点： m3.xlarge
|
||||
* 101-250 节点： m3.2xlarge
|
||||
* 251-500 节点： c4.4xlarge
|
||||
* 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))。
|
||||
|
||||
例如：
|
||||
|
||||
```yaml
|
||||
containers:
|
||||
- name: fluentd-cloud-logging
|
||||
image: k8s.gcr.io/fluentd-gcp:1.16
|
||||
resources:
|
||||
limits:
|
||||
cpu: 100m
|
||||
memory: 200Mi
|
||||
```
|
||||
|
||||
除 Heapster 外，这些限制是静态的，基于4个节点规模的集群上运行的插件所采集的数据 (详见 [#10335](http://issue.k8s.io/10335#issuecomment-117861225))。 而实际大规模集群中插件所消耗的资源要多得多 (详见 [#5880](http://issue.k8s.io/5880#issuecomment-113984085))。 所以如果部署大规模集群时不对这些值进行调整，插件可能会因为资源占用达到上限而不断被杀死。
|
||||
|
||||
为了避免集群插件的资源问题，创建多节点的集群时，考虑以下几点：
|
||||
|
||||
* 当扩大集群规模时，如果涉及，相应扩大以下插件的内存和CPU限制 (通过一个实例处理整个集群，因此其内存和CPU使用量往往与集群的大小/负载成比例增长)：
|
||||
* [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)
|
||||
* [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-controller.yaml)
|
||||
* 当扩大集群规模时，如果涉及，相应扩大以下插件副本数 (每个组件有多个副本，因此增加副本将有助于处理增加的负载，但是，由于每个副本的负载也略有增加，也应考虑提高CPU /内存上限)：
|
||||
* [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-controller.yaml)
|
||||
* 当扩大集群规模时，如果涉及，略微扩大以下插件的内存和CPU限制 (每个节点一个副本， 但是CPU/内存使用随集群的大小/负载增长变化不明显)：
|
||||
* [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)
|
||||
|
||||
Heapster的资源限制是基于集群的初始规模动态设置的 (参考 [#16185](http://issue.k8s.io/16185)
|
||||
和 [#22940](http://issue.k8s.io/22940))。 当发现Heapster资源耗尽，应考虑调整计算Heapster内存请求的公式 (参考上述PR)。
|
||||
|
||||
关于如何检测插件是否达到资源上限 参考 [计算资源的故障排除章节](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting)。
|
||||
|
||||
[将来](http://issue.k8s.io/13048)，我们期望基于集群规模来设置集群插件的资源限制，并且在集群规模增长或缩小时能够动态调整。
|
||||
欢迎提出PR来实现这些特性。
|
||||
|
||||
### 启动时允许部分失败
|
||||
|
||||
因为种种原因 (详见 [#18969](https://github.com/kubernetes/kubernetes/issues/18969))，在 `NUM_NODES` 值很大的情况下执行
|
||||
`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`。
|
||||
@@ -0,0 +1,291 @@
|
||||
---
|
||||
approvers:
|
||||
- jlowdermilk
|
||||
- justinsb
|
||||
- quinton-hoole
|
||||
title: 多区域运行
|
||||
---
|
||||
|
||||
## 介绍
|
||||
|
||||
Kubernetes 从v1.2开始支持将集群运行在多个故障域中。
|
||||
(GCE 中称其为 "区（Zones）"， AWS 中称其为 "可用区（Availability Zones）"，这里我们也称其为 "区")。
|
||||
它是广泛意义上的集群联邦特性的轻量级版本 (之前被称为 ["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md))。
|
||||
完整的集群联邦能够将多个分别运行在不同区或云供应商（或本地数据中心）的集群集中管理。
|
||||
然而，很多用户只是希望通过将单一云供应商上的Kubernetes集群运行在多个区域，来提高集群的可用性，
|
||||
这就是1.2版本中提供的对多区域的支持。
|
||||
(之前被称为 "Ubernetes Lite")。
|
||||
|
||||
多区域的支持是有明确限制的： Kubernetes集群能够运行在多个区，但必须在同一个地域内 (云供应商也须一致)。
|
||||
目前只有GCE和AWS自动支持 (尽管在其他云甚至裸机上，也很容易通过为节点和卷添加合适的标签来实现类似的支持)。
|
||||
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## 功能
|
||||
|
||||
节点启动时，Kubelet自动为其添加区信息的标签。
|
||||
|
||||
在单一区域的集群中，Kubernetes 会自动将副本管理器或服务的pod分布到各节点上 (以减轻单实例故障的影响)。
|
||||
在多区域的集群中，这种分布的行为扩展到了区域级别
|
||||
(以减少区域故障对整体的影响)。 (通过 `SelectorSpreadPriority` 来实现)。
|
||||
这种分发是尽力而为（best-effort）的，所以如果集群在各个区之间是异构的
|
||||
(比如，各区间的节点数量不同、节点类型不同、pod的资源需求不同等)可能导致pod无法完全均匀地分布。
|
||||
如果需要的话，用户可以使用同质的区(节点数量和节点类型相同)来减少区域之间分配不均匀的可能。
|
||||
|
||||
当卷被创建时， `PersistentVolumeLabel`准入控制器会自动为其添加区域的标签。
|
||||
调度器 (通过 `VolumeZonePredicate` 断言) 会确申领该卷的pod被调度到该卷对应的区域，
|
||||
因为卷是不支持跨区挂载的。
|
||||
|
||||
## 限制
|
||||
|
||||
对多区的支持有一些重要的限制：
|
||||
|
||||
* 我们假设不同的区域间在网络上离得很近，所以我们不做任何的区域感知路由。 特别是，通过服务的网络访问可能跨区域 (即使该服务后端pod的其中一些运行在与客户端相同的区域中)，这可能导致额外的延迟和损耗。
|
||||
|
||||
* 卷的区域亲和性只对 `PersistentVolume`有效。 例如，如果你在pod的spec中直接指定一个EBS的卷，则不会生效。
|
||||
|
||||
* 集群不支持跨云平台或地域 (这些功能需要完整的集群联邦特性支持)。
|
||||
|
||||
* 尽管节点位于多区域，目前默认情况下 kube-up 创建的管理节点是单实例的。 所以尽管服务是高可用的，并且能够容忍跨区域的性能损耗，管理平面还是单区域的。 需要高可用的管理平面的用户可以按照 [高可用](/docs/admin/high-availability) 指导来操作。
|
||||
|
||||
* 目前StatefulSet的卷动态创建时的跨区域分配，与pod的亲和性/反亲和性不兼容。
|
||||
|
||||
* StatefulSet的名称包含破折号 ("-")时，可能影响到卷在区域间的均匀分布。
|
||||
|
||||
* 为deployment或pod指定多个PVC时，要求其StorageClass处于同一区域内，否则，相应的PV卷需要在一个区域中静态配置。 另一种方式是使用StatefulSet，这可以确保同一副本所挂载的卷位于同一区内。
|
||||
|
||||
|
||||
## 演练
|
||||
|
||||
接下来我们将介绍如何同时在 GCE 和 AWS 上创建和使用多区域的集群。 为此，你需要创建一个完整的集群
|
||||
(指定 `MULTIZONE=true`)，然后再次执行 `kube-up`（指定 `KUBE_USE_EXISTING_MASTER=true`）来添加其他区域的节点。
|
||||
|
||||
### 创建集群
|
||||
|
||||
按正常方式创建集群，但是传入 MULTIZONE 来通知集群对多区域进行管理。 在 us-central1-a 区域创建节点。
|
||||
|
||||
GCE:
|
||||
|
||||
```shell
|
||||
curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a NUM_NODES=3 bash
|
||||
```
|
||||
|
||||
AWS:
|
||||
|
||||
```shell
|
||||
curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash
|
||||
```
|
||||
|
||||
该步骤按正常方式创建了集群，仍然运行在单个区域中。
|
||||
但 `MULTIZONE=true` 已经开启了多区域的能力。
|
||||
|
||||
### 标记节点
|
||||
|
||||
查看节点，你可以发现节点上打了区域信息的标签。
|
||||
节点位于 `us-central1-a` (GCE) 或者 `us-west-2a` (AWS)。 标签 `failure-domain.beta.kubernetes.io/region` 用于区分地域，
|
||||
标签 `failure-domain.beta.kubernetes.io/zone` 用于区分区域。
|
||||
|
||||
```shell
|
||||
> kubectl get nodes --show-labels
|
||||
|
||||
|
||||
NAME STATUS AGE VERSION LABELS
|
||||
kubernetes-master Ready,SchedulingDisabled 6m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
|
||||
kubernetes-minion-87j9 Ready 6m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
|
||||
kubernetes-minion-9vlv Ready 6m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
|
||||
kubernetes-minion-a12q Ready 6m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
|
||||
```
|
||||
|
||||
### 添加其它区中的节点
|
||||
|
||||
接下来我们复用已有的管理节点，添加运行于其它区域 （us-central1-b或us-west-2b）中的节点。
|
||||
再次执行 kube-up， 通过指定 `KUBE_USE_EXISTING_MASTER=true`，
|
||||
kube-up 不会创建新的管理节点，而是会复用之前创建的。
|
||||
|
||||
GCE:
|
||||
|
||||
```shell
|
||||
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh
|
||||
```
|
||||
|
||||
在 AWS 中我们还需要为新增的子网指定网络CIDR，还有管理节点的内部IP地址。
|
||||
|
||||
```shell
|
||||
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
|
||||
```
|
||||
|
||||
|
||||
再次查看节点，3个新增的节点已经启动，并被标记为us-central1-b：
|
||||
|
||||
```shell
|
||||
> kubectl get nodes --show-labels
|
||||
|
||||
NAME STATUS AGE VERSION LABELS
|
||||
kubernetes-master Ready,SchedulingDisabled 16m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
|
||||
kubernetes-minion-281d Ready 2m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
|
||||
kubernetes-minion-87j9 Ready 16m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
|
||||
kubernetes-minion-9vlv Ready 16m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
|
||||
kubernetes-minion-a12q Ready 17m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
|
||||
kubernetes-minion-pp2f Ready 2m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
|
||||
kubernetes-minion-wf8i Ready 2m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i
|
||||
```
|
||||
|
||||
### 卷的亲和性
|
||||
|
||||
使用动态创建卷的功能创建一个卷 (只有PV持久卷才支持区域亲和性)：
|
||||
|
||||
```json
|
||||
kubectl create -f - <<EOF
|
||||
{
|
||||
"kind": "PersistentVolumeClaim",
|
||||
"apiVersion": "v1",
|
||||
"metadata": {
|
||||
"name": "claim1",
|
||||
"annotations": {
|
||||
"volume.alpha.kubernetes.io/storage-class": "foo"
|
||||
}
|
||||
},
|
||||
"spec": {
|
||||
"accessModes": [
|
||||
"ReadWriteOnce"
|
||||
],
|
||||
"resources": {
|
||||
"requests": {
|
||||
"storage": "5Gi"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
EOF
|
||||
```
|
||||
|
||||
**注意：** Kubernetes 1.3以上的版本中可以将PVC分发到多个已配置的区域中，在1.2版本中， 动态卷只能创建在管理节点所在的区域内(即这里的 us-central1-a / us-west-2a)；相关issue
|
||||
([#23330](https://github.com/kubernetes/kubernetes/issues/23330))
|
||||
在1.3后续的版本中已解决。
|
||||
|
||||
现在我们验证一下 Kubernetes 自动为创建的PV打上了所在地域和区域的标签。
|
||||
|
||||
```shell
|
||||
> kubectl get pv --show-labels
|
||||
NAME CAPACITY ACCESSMODES STATUS CLAIM REASON AGE LABELS
|
||||
pv-gce-mj4gm 5Gi RWO Bound default/claim1 46s failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a
|
||||
```
|
||||
|
||||
现在我们将创建使用这些PVC的pod。
|
||||
因为 GCE 的PD存储 / AWS 的EBS 卷 不支持跨区域挂载，
|
||||
这意味着相应的pod只能创建在卷所在的区域中。
|
||||
|
||||
```yaml
|
||||
kubectl create -f - <<EOF
|
||||
kind: Pod
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: mypod
|
||||
spec:
|
||||
containers:
|
||||
- name: myfrontend
|
||||
image: nginx
|
||||
volumeMounts:
|
||||
- mountPath: "/var/www/html"
|
||||
name: mypd
|
||||
volumes:
|
||||
- name: mypd
|
||||
persistentVolumeClaim:
|
||||
claimName: claim1
|
||||
EOF
|
||||
```
|
||||
|
||||
注意pod被自动创建在了卷所在的区域中，因为云供应商通常不支持卷的跨区域挂载（attach）。
|
||||
|
||||
```shell
|
||||
> kubectl describe pod mypod | grep Node
|
||||
Node: kubernetes-minion-9vlv/10.240.0.5
|
||||
> kubectl get node kubernetes-minion-9vlv --show-labels
|
||||
NAME STATUS AGE VERSION LABELS
|
||||
kubernetes-minion-9vlv Ready 22m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
|
||||
```
|
||||
|
||||
### Pod的跨区域分布
|
||||
|
||||
副本管理器或服务的pod被自动创建在了不同的区域。 首先，在第三个区域内启动节点：
|
||||
|
||||
GCE:
|
||||
|
||||
```shell
|
||||
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-f NUM_NODES=3 kubernetes/cluster/kube-up.sh
|
||||
```
|
||||
|
||||
AWS:
|
||||
|
||||
```shell
|
||||
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
|
||||
```
|
||||
|
||||
验证你现在在3个区域内拥有节点:
|
||||
|
||||
```shell
|
||||
kubectl get nodes --show-labels
|
||||
```
|
||||
|
||||
创建 guestbook-go 示例应用， 它包含一个副本数为3的RC，运行一个简单的网络应用：
|
||||
|
||||
```shell
|
||||
find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl create -f {}
|
||||
```
|
||||
|
||||
Pod应该分布在全部3个区域上：
|
||||
|
||||
```shell
|
||||
> kubectl describe pod -l app=guestbook | grep Node
|
||||
Node: kubernetes-minion-9vlv/10.240.0.5
|
||||
Node: kubernetes-minion-281d/10.240.0.8
|
||||
Node: kubernetes-minion-olsh/10.240.0.11
|
||||
|
||||
> kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels
|
||||
NAME STATUS AGE VERSION LABELS
|
||||
kubernetes-minion-9vlv Ready 34m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
|
||||
kubernetes-minion-281d Ready 20m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
|
||||
kubernetes-minion-olsh Ready 3m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh
|
||||
```
|
||||
|
||||
|
||||
负载平衡器覆盖集群中的所有区域； guestbook-go 示例包含一个
|
||||
负载均衡服务的例子：
|
||||
|
||||
```shell
|
||||
> kubectl describe service guestbook | grep LoadBalancer.Ingress
|
||||
LoadBalancer Ingress: 130.211.126.21
|
||||
|
||||
> ip=130.211.126.21
|
||||
|
||||
> curl -s http://${ip}:3000/env | grep HOSTNAME
|
||||
"HOSTNAME": "guestbook-44sep",
|
||||
|
||||
> (for i in `seq 20`; do curl -s http://${ip}:3000/env | grep HOSTNAME; done) | sort | uniq
|
||||
"HOSTNAME": "guestbook-44sep",
|
||||
"HOSTNAME": "guestbook-hum5n",
|
||||
"HOSTNAME": "guestbook-ppm40",
|
||||
```
|
||||
|
||||
负载平衡器正确指向了所有的pod，即使它们位于不同的区域内。
|
||||
|
||||
### 停止集群
|
||||
|
||||
使用完成后，进行清理：
|
||||
|
||||
GCE:
|
||||
|
||||
```shell
|
||||
KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-f kubernetes/cluster/kube-down.sh
|
||||
KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-b kubernetes/cluster/kube-down.sh
|
||||
KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a kubernetes/cluster/kube-down.sh
|
||||
```
|
||||
|
||||
AWS:
|
||||
|
||||
```shell
|
||||
KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c kubernetes/cluster/kube-down.sh
|
||||
KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.sh
|
||||
KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh
|
||||
```
|
||||
@@ -0,0 +1,84 @@
|
||||
---
|
||||
approvers:
|
||||
- Random-Liu
|
||||
title: 节点设置校验
|
||||
---
|
||||
|
||||
* TOC
|
||||
{{< toc >}}
|
||||
|
||||
## 节点合规性测试
|
||||
|
||||
*节点合规性测试* 是一个容器化的测试框架，提供了针对节点的系统验证和功能测试。 该测试主要检测节点是否满足 Kubernetes 的最低要求，通过检测的节点有资格加入 Kubernetes 集群。
|
||||
|
||||
## 限制
|
||||
|
||||
在 Kubernetes 1.5版本中，节点合规性测试存在以下限制：
|
||||
|
||||
* 节点合规性测试只支持 Docker 作为容器运行时环境。
|
||||
|
||||
## 节点的前提条件
|
||||
|
||||
为运行节点合规性测试，节点必须满足与标准的 Kubernetes 节点同样的前提条件。最基本地， 节点应安装以下组件：
|
||||
|
||||
* 容器运行时 (Docker)
|
||||
* Kubelet
|
||||
|
||||
## 运行节点合规性测试
|
||||
|
||||
执行以下步骤来运行节点合规性测试：
|
||||
|
||||
1. 因为测试框架会启动一个本地的 master 来测试 Kubelet，
|
||||
所以将 Kubelet 指向本机 `--api-servers="http://localhost:8080"。 还有一些其他 Kubelet 参数可能需要注意：
|
||||
* `--pod-cidr`： 如果使用 `kubenet`， 需要为 Kubelet 任意指定一个 CIDR， 例如 `--pod-cidr=10.180.0.0/24`。
|
||||
* `--cloud-provider`： 如果使用 `--cloud-provider=gce`，需要移除这个参数来运行测试。
|
||||
|
||||
2. 执行以下命令来运行节点合规性测试：
|
||||
|
||||
```shell
|
||||
# $CONFIG_DIR 是 Kubelet 的 manifest 文件路径。
|
||||
# $LOG_DIR 是测试结果输出的路径。
|
||||
sudo docker run -it --rm --privileged --net=host \
|
||||
-v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
|
||||
k8s.gcr.io/node-test:0.2
|
||||
```
|
||||
|
||||
## 针对其他硬件体系结构运行节点合规性测试
|
||||
|
||||
Kubernetes 也为其他硬件体系结构的系统提供了节点合规性测试的 Docker 镜像：
|
||||
|
||||
Arch | Image |
|
||||
--------|:-----------------:|
|
||||
amd64 | node-test-amd64 |
|
||||
arm | node-test-arm |
|
||||
arm64 | node-test-arm64 |
|
||||
|
||||
## 运行选定的测试
|
||||
|
||||
为运行指定的测试，用正则表达式来描述将要运行的测试，并重载 `FOCUS` 环境变量。
|
||||
|
||||
```shell
|
||||
sudo docker run -it --rm --privileged --net=host \
|
||||
-v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
|
||||
-e FOCUS=MirrorPod \ # 只运行MirrorPod测试
|
||||
k8s.gcr.io/node-test:0.2
|
||||
```
|
||||
|
||||
为跳过指定的测试，用正则表达式来描述将要跳过的测试，并重载 `SKIP` 环境变量。
|
||||
|
||||
```shell
|
||||
sudo docker run -it --rm --privileged --net=host \
|
||||
-v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
|
||||
-e SKIP=MirrorPod \ # 运行除MirrorPod外的所有测试
|
||||
k8s.gcr.io/node-test:0.2
|
||||
```
|
||||
|
||||
节点合规性测试是[节点端到端测试](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/e2e-node-tests.md)的一个容器化的版本。
|
||||
默认情况下， 它会运行所有的合规性测试用例。
|
||||
|
||||
理论上，只要合理地配置容器和挂载所需的卷，就可以运行任何的节点端到端测试用例。 但是这里 **强烈建议只运行合规性测试**，因为运行非合规性测试需要很多复杂的配置。
|
||||
|
||||
## 注意事项
|
||||
|
||||
* 测试会在节点上遗留一些Docker镜像， 包括节点合规性测试本身的镜像，和功能测试相关的镜像。
|
||||
* 测试会在节点上遗留一些死的容器。这些容器是在功能测试的过程中创建的。
|
||||
Reference in New Issue
Block a user