使用 Kubernetes 1.2.0 的正确姿势

之前，我们介绍了kubernetes 1.2.0 的新特性，还不清楚的童鞋查看这里。

本文讨论的是使用 kubernetes 1.2.0 的注意事项，包括对周边组件的要求（比如 docker 的兼容性）、目前已知的 bug （ kubernetes 和 docker 1.9 ）和如何平稳升级。

Part I 升级注意事项

1.使用 kubernetes 1.2.0 推荐使用 Docker v1.9.1 ，但仍然支持 v1.8.3 和 v1.10 。如果你使用的 Docker 版本太低，请先升级 Docker 。但 Docker v1.9.1 存在一些问题，下面我们详细讨论。

2.如果内核支持 CPU hardcapping ，并且容器设置了 CPU limit ，那么 CPU hardcapping 选项将默认启用。可以通过调整 CPU limit 或者只设置 CPU request 来避免 hardcapping 。如果内核不支持 CPU Quota ， NodeStatus 会包含一个“无法使用 CPU limit ”的警告。

3.这条注意事项只在你使用 Go 语言 client （/pkg/client/unversioned ）创建 Job 时适用，比如使用 ” k8s.io/kubernetes/pkg/apis/extensions ”.Job 来定义 GO 变量。这种做法并不常用，如果你不明白这里在讨论什么，那你暂时无须关注这个问题。如果你使用 Go 语言 client 创建 Job ，并且重新发布了"k8s.io/kubernetes/"，那么需要设置 job.Spec.ManualSelector = true ，或者设置 job.Spec.Selector = nil 。否则你创建的 jobs 可能被驳回，具体操作点击这里查看。

4.Deployment （ apiVersion extensions/v1beta1 ）在 v1.1 中是 Alpha 版，默认不集成到 release 中。由于我们对 API 做了向后不兼容的变更，所以在 v1.1 中创建的 Deployment 对象将无法在 v1.2 中使用。具体变更如下：

a)升级到 v1.2 之前，务必删除所有 Alpha 版本的 Deployment 资源，包括 Deployment 管理的 ReplicationController 和 Pod 。升级到 v1.2 之后，创建 Beta 版本的 Deployment 资源。不删除 Deployment 资源的话，由于选择器 API 的变更，可能导致 deployment controller 错误地匹配和删除其他 pods 。

b)进行 Deployment 相关的操作时，客户端（ kubectl ）和服务器端的版本必须匹配（均为 1.1 或者 1.2 ）。

c) API 行为变更：①Deployment 创建 ReplicaSets 而不是 ReplicationController ；②scale subresource 的状态结构体中增加了一个字段 targetSelector ，该字段支持基于集合（ set-based ）的选择器，但格式必须是序列化后的结果。

d)规格（ Spec ）变更：①Deployment 对象的选择器更加通用（支持基于集合的选择器，而在 v1.1 中支持基于比较的选择器）；②.spec.uniqueLabelKey 字段已被删除，用户将不能自定义 unique label key ，它的默认值也由"deployment.kubernetes.io/podTemplateHash"变成了"pod-template-hash"；③.spec.strategy.rollingUpdate.minReadySeconds 字段被.spec.minReadySeconds 代替。

5.DaemonSet （ apiVersion extensions/v1beta1 ）在 v1.1 中是 Alpha 版本，默认不包含在 release 中。由于我们对 API 做了向后不兼容的变更，所以在 v1.1 中创建的 DaemonSet 对象将无法在 v1.2 中使用。具体变更如下：

a) 升级到 v1.2 之前，务必删除所有 Alpha 版本的 DaemonSet 资源。如果你不想破坏原有的 Pod ，可以使用命令 kubectl delete daemonset – cascade=false 。升级到 v1.2 之后，创建 Beta 版本的 Deployment 资源。

b) 进行 DaemonSet 相关的操作时，客户端（ kubectl ）和服务器端的版本必须匹配（均为 1.1 或者 1.2 ）。

c) API 行为变更：①即便节点设置了.spec.unschedulable=true ， DaemonSet pod 也会在该节点上创建，即便节点 Ready 状态为 False ， pod 也不会被删除。②允许 更新 Pod template 。如果对 DaemonSet 进行 rolling update ，可以更新 pod template ，然后把 pod 一个个删除，新的 pod 将根据新的 pod template 创建。

d) 规格(Spec)变更: ①DaemonSet 对象的选择器更加通用（支持基于集合的选择器，而在 v1.1 中支持基于比较的选择器）。

6.如果要在 https 运行 etcd ，则需要将下面的参数传递给 kube-apiserver （而不是 – etcd-config ）：

a) – etcd-certfile, --etcd-keyfile (如果使用 client cert auth)

b) – etcd-cafile （如果不使用 system roots ）

7.Kubernetes v1.2 将增加对 protocol buffer 的支持， API 也将直接支持 YAML 格式。作为准备，在当前 release 中，每个 HTTP spec 的 Content-Type 和 Accept headers 都会被处理。所以，你通过客户端发送请求给 API 时，如果 Content-Type 或 Accept headers 无效，将会返回 415 或 406 错误。目前唯一已知会影响到的客户端是 curl ，一个错误的做法是：使用-d 发送 JSON ，但是不设置 Content-Type （希望使用默认的"application/x-www-urlencoded"）。如果你使用的其他的客户端，那么需要检查确认发送了正确的 accept 和 content type headers ，或者不做任何设置（默认为 JSON ）。以 curl 为例： curl -H "Content-Type: application/json" -XPOST -d '{"apiVersion":"v1","kind":"Namespace","metadata":{"name":"kube-system"}}'

8.由于数据的存储格式发生变化， Kubernetes 要求 influxdb 的版本为 0.9 （之前为 0.8 ）。

9.将术语"minions"替换为"nodes"。如果运行 kube-up 时，你指定了 NUM_MINIONS 或 MINION_SIZE ，那么在 1.2 中，则需要指定 NUM_NODES 或 NODE_SIZE 。

Part II Kubernetes 中现存的问题

1.处于 Paused 状态的 deployments 不能被 resize ，也不会清空旧的 ReplicaSets 。

2.最小的内存 limit 是 4MB ，这里是 docker 的限制。

3.最小的 CPU limits 是 10m ，这里是 Linux 内核的限制。

4.对于 paused deployments ，" kubectl rollout undo"（比如 rollback ）操作会挂起，因为 paused deployments 不能被回滚（该结果符合预期），该命令会等待回滚时间返回结果。在回滚之前，用户应该使用" kubectl rollout resume"命令恢复一个 deployment 。

5." kubectl edit"操作会为每个资源代打开一次编辑器，因此编辑器会被打开很多次。

6.在使用 autoscaling/v1 API 创建 HPA 对象时，如果不指定 targetCPUUtilizationPercentage ，使用 kubectl 读取该字段会显示 extensions/v1beta1 中指定的默认值。

7.如果一个挂载了存储卷的节点或者 kubelet 意外崩溃，存储卷仍然属于那个节点。由于单个存储卷只能被挂载到一个节点上（比如 GCE PDs 以 RW 模式挂载），则必须手动卸载以后才能挂载到其它节点上。

8.如果一个存储卷已经被挂载到某个节点上，则后续再次尝试挂载到该节点的操作（ i.e. 由于 kubelet 重启）都将失败。解决方法有两个，或者手动卸载该存储卷，或者删除所有相关联的 pod ，该动作将自动触发卸载。

9.在规模非常大的集群中，在某些时间段，可能出现一些节点无法注册到 API Server 的问题，原因可能多种多样，比如网络问题、宕机等。正常情况下，使用 kube-up 脚本启动集群时，任意一个节点出现 NotReady 的情况（即便集群运行正常）， kube-up 也会返回失败。这里我们添加了变量 ALLOWED_NOTREADY_NODES ，它定义了最多允许 NotReady 节点的个数，即如果 NotReady 节点的个数超出设定的值时， kube-up 才会返回失败。

10."kubectl rolling-update"命令只支持 Replication Controllers ，不支持 Replica Sets 。如果要 rolling update Replica Sets ，推荐使用 Deployment 1.2 中的"kubectl rollout"命令。

11.在线升级 Kubelet 到 1.2 是，如果不清空运行在节点上的 pods 的话， kubelet 管理的所有 container 都将重启。

Part III Docker 中现存的问题（ v1.9.1 ）

1.docker ps 操作有时候非常慢，进而影响到 kubelet 的性能。

2.Docker daemon 重启可能失败。在重启时，必须删除 docker checkpoints 。

3.Pod IP 分配相关的问题。在重启 docker daemon 之前删除 docker checkpoint 有助于缓解这个问题，但是尚未验证是否能够完全解决该问题。

4.由于内核死锁， Docker daemon 可能出现无响应的情况（极少出现）。