集群管理

本文描述了和集群生命周期相关的几个主题：创建新集群、更新集群的 master 和 worker 节点、执行节点维护（例如升级内核）以及升级运行中集群的 Kubernetes API 版本。

创建和配置集群

要在一组机器上安装 Kubernetes，请根据您的环境，查阅现有的入门指南

升级集群

集群升级当前是配套提供的，某些发布版本在升级时可能需要特殊处理。推荐管理员在升级他们的集群前，同时查阅发行说明和版本具体升级说明。

升级到 1.6

升级 Google Compute Engine 集群

Google Compute Engine Open Source (GCE-OSS) 通过删除和重建 master 来支持 master 升级。通过维持相同的 Persistent Disk (PD) 以保证在升级过程中保留数据。

GCE 的 Node 升级采用管理实例组，每个节点将被顺序的删除，然后使用新软件重建。任何运行在那个节点上的 Pod 需要用 Replication Controller 控制，或者在扩容之后手动重建。

开源 Google Compute Engine (GCE) 集群上的升级过程由 cluster/gce/upgrade.sh 脚本控制。

运行 cluster/gce/upgrade.sh -h 获取使用说明。

例如，只将 master 升级到一个指定的版本 (v1.0.2):

cluster/gce/upgrade.sh -M v1.0.2

或者，将整个集群升级到最新的稳定版本：

cluster/gce/upgrade.sh release/stable

升级 Google Kubernetes Engine 集群

Google Kubernetes Engine 自动升级 master 组件（例如 kube-apiserver、kube-scheduler）至最新版本。它还负责 master 运行的操作系统和其它组件。

节点升级过程由用户初始化，Google Kubernetes Engine 文档里有相关描述。

在其他平台上升级集群

不同的供应商和工具管理升级的过程各不相同。建议您查阅它们有关升级的主要文档。

调整集群大小

如果集群资源短缺，您可以轻松的添加更多的机器，如果集群正运行在节点自注册模式下的话。如果正在使用的是 GCE 或者 Google Kubernetes Engine，这将通过调整管理节点的实例组的大小完成。在 Google Cloud Console page 的 Compute > Compute Engine > Instance groups > your group > Edit group 下修改实例数量或使用 gcloud CLI 都可以完成这个任务。

gcloud compute instance-groups managed resize kubernetes-minion-group --size 42 --zone $ZONE

实例组将负责在新机器上放置恰当的镜像并启动它们。Kubelet 将向 API server 注册它的节点以使其可以用于调度。如果您对 instance group 进行缩容，系统将会随机选取节点来终止。

在其他环境上，您可能需要手动配置机器并告诉 Kubelet API server 在哪台机器上运行。

集群自动伸缩

如果正在使用 GCE 或者 Google Kubernetes Engine，您可以配置您的集群，使其能够基于 pod 需求自动重新调整大小。

如 Compute Resource 所述，用户可以控制预留多少 CPU 和内存来分配给 pod。这个信息被 Kubernetes scheduler 用来寻找一个运行 pod 的地方。如果没有一个节点有足够的空闲容量（或者不能满足其他 pod 的需求），这个 pod 就需要等待某些 pod 结束，或者一个新的节点被添加。

集群 autoscaler 查找不能被调度的 pod 并检查添加一个新节点（和集群中其它节点类似的）是否有帮助。如果是的话，它将调整集群的大小以容纳等待调度的 pod。

如果发现在一段延时时间内（默认10分钟，将来有可能改变）某些节点不再需要，集群 autoscaler 也会缩小集群。

集群 autoscaler 在每一个实例组（GCE）或节点池（Google Kubernetes Engine）上配置。

如果您使用 GCE，那么您可以在使用 kube-up.sh 脚本创建集群的时候启用它。要想配置集群 autoscaler，您需要设置三个环境变量：

KUBE_ENABLE_CLUSTER_AUTOSCALER - 如果设置为 true 将启用集群 autoscaler。
KUBE_AUTOSCALER_MIN_NODES - 集群的最小节点数量。
KUBE_AUTOSCALER_MAX_NODES - 集群的最大节点数量。

示例：

KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh

在 Google Kubernetes Engine 上，您可以在创建、更新集群或创建一个特别的节点池（您希望自动伸缩的）时，通过给对应的 gcloud 命令传递 --enable-autoscaling --min-nodes 和 --max-nodes 来配置集群 autoscaler。

示例：

gcloud container clusters create mytestcluster --zone=us-central1-b --enable-autoscaling --min-nodes=3 --max-nodes=10 --num-nodes=5

gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes=1 --max-nodes=15

集群 autoscaler 期望节点未被手动修改过（例如通过 kubectl 添加标签），因为那些属性可能不能被传递到相同节点组中的新节点上。

维护节点

如果需要重启节点（例如内核升级、libc 升级、硬件维修等），且停机时间很短时，当 Kubelet 重启后，它将尝试重启调度到节点上的 pod。如果重启花费较长时间（默认时间为 5 分钟，由 controller-manager 的 --pod-eviction-timeout 控制），节点控制器将会结束绑定到这个不可用节点上的 pod。如果存在对应的 replica set（或者 replication controller）时，则将在另一个节点上启动 pod 的新副本。所以，如果所有的 pod 都是复制而来，那么在不是所有节点都同时停机的前提下，升级可以在不需要特殊调整情况下完成。

如果您希望更多的控制升级过程，可以使用下面的工作流程：

使用 kubectl drain 优雅的结束节点上的所有 pod 并同时标记节点为不可调度：

kubectl drain $NODENAME

在您正试图使节点离线时，这将阻止新的 pod 落到它们上面。

对于有 replica set 的 pod 来说，它们将会被新的 pod 替换并且将被调度到一个新的节点。此外，如果 pod 是一个 service 的一部分，则客户端将被自动重定向到新的 pod。

对于没有 replica set 的 pod，您需要手动启动 pod 的新副本，并且如果它不是 service 的一部分，您需要手动将客户端重定向到这个 pod。

在节点上执行维护工作。

重新使节点可调度：

kubectl uncordon $NODENAME

如果删除了节点的虚拟机实例并重新创建，那么一个新的可调度节点资源将被自动创建（只在您使用支持节点发现的云服务提供商时；当前只有 Google Compute Engine，不包括在 Google Compute Engine 上使用 kube-register 的 CoreOS）。相关详细信息，请查阅节点。

高级主题

升级到不同的 API 版本

当新的 API 版本发布时，您可能需要升级集群支持新的 API 版本（例如当 'v2' 发布时从 'v1' 切换到 'v2'）。

这不是一个经常性的事件，但需要谨慎的处理。这里有一系列升级到新 API 版本的步骤。

  1. 开启新 API 版本。
  2. 升级集群存储来使用新版本。
  3. 升级所有配置文件。识别使用旧 API 版本 endpoint 的用户。
  4. 运行 `cluster/update-storage-objects.sh` 升级存储中的现有对象为新版本。
  5. 关闭旧 API 版本。

打开或关闭集群的 API 版本

可以在启动 API server 时传递 --runtime-config=api/<version> 标志来打开或关闭特定的 API 版本。例如：要关闭 v1 API，请传递 --runtime-config=api/v1=false。运行时配置还支持两个特殊键值：api/all 和 api/legacy，分别控制全部和遗留 API。例如要关闭除 v1 外全部 API 版本，请传递 --runtime-config=api/all=false,api/v1=true。对于这些标志来说，legacy API 指那些被显式废弃的 API（例如 v1beta3）。

切换集群存储的 API 版本

存储于磁盘中，用于在集群内部代表 Kubernetes 活跃资源的对象使用特定的 API 版本书写。当支撑的 API 改变时，这些对象可能需要使用更新的 API 重写。重写失败将最终导致资源不再能够被 Kubernetes API server 解析或使用。

kube-apiserver 二进制文件的 KUBE_API_VERSIONS 环境变量控制了集群支持的 API 版本。列表中的第一个版本被用作集群的存储版本。因此，要设置特定的版本为存储版本，请将其放在 KUBE_API_VERSIONS 参数值版本列表的最前面。您需要重启 kube-apiserver 二进制以使这个变量的改动生效。

切换配置文件为新 API 版本

可以使用 kubectl convert 命令对不同 API 版本的配置文件进行转换。

kubectl convert -f pod.yaml --output-version v1

更多选项请参考 kubectl convert 命令用法。

Black lives matter.

文档