使用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可能出现无响应的状况（极少出现）。