转载

使用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都将重启。