摘要：升級(jí)注意事項(xiàng)使用推薦使用，但仍然支持和。如果內(nèi)核不支持，會(huì)包含一個(gè)無(wú)法使用的警告。在使用創(chuàng)建對(duì)象時(shí)，如果不指定，使用讀取該字段會(huì)顯示中指定的默認(rèn)值。如果要，推薦使用中的命令。分配相關(guān)的問(wèn)題。

之前，我們介紹了kubernetes 1.2.0的新特性，還不清楚的童鞋查看這里。

本文討論的是使用 kubernetes 1.2.0 的注意事項(xiàng)，包括對(duì)周邊組件的要求（比如docker的兼容性）、目前已知的bug（kubernetes和docker 1.9）和如何平穩(wěn)升級(jí)。

1.使用kubernetes 1.2.0 推薦使用Docker v1.9.1，但仍然支持v1.8.3和v1.10。如果你使用的Docker版本太低，請(qǐng)先升級(jí)Docker。但Docker v1.9.1存在一些問(wèn)題，下面我們?cè)敿?xì)討論。

2.如果內(nèi)核支持CPU hardcapping，并且容器設(shè)置了CPU limit，那么CPU hardcapping選項(xiàng)將默認(rèn)啟用。可以通過(guò)調(diào)整CPU limit或者只設(shè)置CPU request來(lái)避免hardcapping。如果內(nèi)核不支持CPU Quota，NodeStatus會(huì)包含一個(gè)“無(wú)法使用CPU limit”的警告。

3.這條注意事項(xiàng)只在你使用 Go 語(yǔ)言 client（/pkg/client/unversioned）創(chuàng)建Job時(shí)適用，比如使用 ”k8s.io/kubernetes/pkg/apis/extensions”.Job 來(lái)定義 GO 變量。這種做法并不常用，如果你不明白這里在討論什么，那你暫時(shí)無(wú)須關(guān)注這個(gè)問(wèn)題。如果你使用Go語(yǔ)言client創(chuàng)建Job，并且重新發(fā)布了"k8s.io/kubernetes/"，那么需要設(shè)置job.Spec.ManualSelector = true，或者設(shè)置job.Spec.Selector = nil。否則你創(chuàng)建的 jobs 可能被駁回，具體操作點(diǎn)擊這里查看。

4.Deployment（apiVersion extensions/v1beta1）在v1.1中是Alpha版，默認(rèn)不集成到release中。由于我們對(duì)API做了向后不兼容的變更，所以在v1.1中創(chuàng)建的Deployment對(duì)象將無(wú)法在v1.2中使用。具體變更如下：

a)升級(jí)到v1.2之前，務(wù)必刪除所有Alpha版本的Deployment資源，包括Deployment管理的ReplicationController和Pod。升級(jí)到v1.2之后，創(chuàng)建Beta版本的Deployment資源。不刪除Deployment資源的話(huà)，由于選擇器API的變更，可能導(dǎo)致deployment
controller錯(cuò)誤地匹配和刪除其他pods。
b)進(jìn)行Deployment相關(guān)的操作時(shí)，客戶(hù)端（kubectl）和服務(wù)器端的版本必須匹配（均為1.1或者1.2）。
c) API行為變更：①Deployment創(chuàng)建ReplicaSets而不是ReplicationController；②scale
subresource的狀態(tài)結(jié)構(gòu)體中增加了一個(gè)字段
targetSelector，該字段支持基于集合（set-based）的選擇器，但格式必須是序列化后的結(jié)果。
d)規(guī)格（Spec）變更：①Deployment對(duì)象的選擇器更加通用（支持基于集合的選擇器，而在v1.1中支持基于比較的選擇器）；②.spec.uniqueLabelKey字段已被刪除，用戶(hù)將不能自定義unique
label
key，它的默認(rèn)值也由"deployment.kubernetes.io/podTemplateHash"變成了"pod-template-hash"；③.spec.strategy.rollingUpdate.minReadySeconds字段被.spec.minReadySeconds代替。

5.DaemonSet（apiVersion extensions/v1beta1）在v1.1中是Alpha版本，默認(rèn)不包含在release中。由于我們對(duì)API做了向后不兼容的變更，所以在v1.1中創(chuàng)建的DaemonSet對(duì)象將無(wú)法在v1.2中使用。具體變更如下：

a) 升級(jí)到v1.2之前，務(wù)必刪除所有Alpha版本的DaemonSet資源。如果你不想破壞原有的Pod，可以使用命令kubectl
delete daemonset –cascade=false。升級(jí)到v1.2之后，創(chuàng)建Beta版本的Deployment資源。
b) 進(jìn)行DaemonSet相關(guān)的操作時(shí)，客戶(hù)端（kubectl）和服務(wù)器端的版本必須匹配（均為1.1或者1.2）。
c) API行為變更：①即便節(jié)點(diǎn)設(shè)置了.spec.unschedulable=true，DaemonSet
pod也會(huì)在該節(jié)點(diǎn)上創(chuàng)建，即便節(jié)點(diǎn)Ready狀態(tài)為False，pod也不會(huì)被刪除。②允許 更新Pod
template。如果對(duì)DaemonSet進(jìn)行rolling update，可以更新pod
template，然后把pod一個(gè)個(gè)刪除，新的pod將根據(jù)新的pod template創(chuàng)建。
d) 規(guī)格(Spec)變更: ①DaemonSet對(duì)象的選擇器更加通用（支持基于集合的選擇器，而在v1.1中支持基于比較的選擇器）。

6.如果要在https運(yùn)行etcd，則需要將下面的參數(shù)傳遞給kube-apiserver（而不是 –etcd-config）：

a) –etcd-certfile, --etcd-keyfile (如果使用client cert auth)
b) –etcd-cafile（如果不使用system roots）

7.Kubernetes v1.2將增加對(duì)protocol buffer的支持， API也將直接支持YAML格式。作為準(zhǔn)備，在當(dāng)前release中，每個(gè)HTTP spec的 Content-Type和Accept headers都會(huì)被處理。所以，你通過(guò)客戶(hù)端發(fā)送請(qǐng)求給API時(shí)，如果Content-Type或Accept headers無(wú)效，將會(huì)返回415或406錯(cuò)誤。目前唯一已知會(huì)影響到的客戶(hù)端是curl，一個(gè)錯(cuò)誤的做法是：使用-d 發(fā)送JSON，但是不設(shè)置Content-Type（希望使用默認(rèn)的"application/x-www-urlencoded"）。如果你使用的其他的客戶(hù)端，那么需要檢查確認(rèn)發(fā)送了正確的 accept和 content type headers，或者不做任何設(shè)置（默認(rèn)為JSON）。以curl為例：curl -H "Content-Type: application/json" -XPOST -d "{"apiVersion":"v1","kind":"Namespace","metadata":{"name":"kube-system"}}"

8.由于數(shù)據(jù)的存儲(chǔ)格式發(fā)生變化，Kubernetes要求influxdb的版本為0.9（之前為0.8）。

9.將術(shù)語(yǔ)"minions"替換為"nodes"。如果運(yùn)行kube-up時(shí)，你指定了NUM_MINIONS或MINION_SIZE，那么在1.2中，則需要指定NUM_NODES或NODE_SIZE。

1.處于Paused狀態(tài)的deployments不能被resize，也不會(huì)清空舊的ReplicaSets。

2.最小的內(nèi)存limit是4MB，這里是docker的限制。

3.最小的CPU limits是10m，這里是Linux內(nèi)核的限制。

4.對(duì)于paused deployments，" kubectl rollout undo"（比如 rollback）操作會(huì)掛起，因?yàn)閜aused deployments不能被回滾（該結(jié)果符合預(yù)期），該命令會(huì)等待回滾時(shí)間返回結(jié)果。在回滾之前，用戶(hù)應(yīng)該使用" kubectl rollout resume"命令恢復(fù)一個(gè)deployment。

5." kubectl edit"操作會(huì)為每個(gè)資源代打開(kāi)一次編輯器，因此編輯器會(huì)被打開(kāi)很多次。

6.在使用 autoscaling/v1 API創(chuàng)建HPA對(duì)象時(shí)，如果不指定targetCPUUtilizationPercentage，使用kubectl讀取該字段會(huì)顯示extensions/v1beta1中指定的默認(rèn)值。

7.如果一個(gè)掛載了存儲(chǔ)卷的節(jié)點(diǎn)或者kubelet意外崩潰，存儲(chǔ)卷仍然屬于那個(gè)節(jié)點(diǎn)。由于單個(gè)存儲(chǔ)卷只能被掛載到一個(gè)節(jié)點(diǎn)上（比如GCE PDs以RW模式掛載），則必須手動(dòng)卸載以后才能掛載到其它節(jié)點(diǎn)上。

8.如果一個(gè)存儲(chǔ)卷已經(jīng)被掛載到某個(gè)節(jié)點(diǎn)上，則后續(xù)再次嘗試掛載到該節(jié)點(diǎn)的操作（i.e. 由于kubelet重啟）都將失敗。解決方法有兩個(gè)，或者手動(dòng)卸載該存儲(chǔ)卷，或者刪除所有相關(guān)聯(lián)的pod，該動(dòng)作將自動(dòng)觸發(fā)卸載。

9.在規(guī)模非常大的集群中，在某些時(shí)間段，可能出現(xiàn)一些節(jié)點(diǎn)無(wú)法注冊(cè)到API Server的問(wèn)題，原因可能多種多樣，比如網(wǎng)絡(luò)問(wèn)題、宕機(jī)等。正常情況下，使用kube-up腳本啟動(dòng)集群時(shí)，任意一個(gè)節(jié)點(diǎn)出現(xiàn)NotReady的情況（即便集群運(yùn)行正常），kube-up也會(huì)返回失敗。這里我們添加了變量ALLOWED_NOTREADY_NODES，它定義了最多允許NotReady節(jié)點(diǎn)的個(gè)數(shù)，即如果NotReady節(jié)點(diǎn)的個(gè)數(shù)超出設(shè)定的值時(shí)，kube-up才會(huì)返回失敗。

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

11.在線(xiàn)升級(jí)Kubelet到1.2是，如果不清空運(yùn)行在節(jié)點(diǎn)上的pods的話(huà)，kubelet管理的所有container都將重啟。

1.docker ps操作有時(shí)候非常慢，進(jìn)而影響到kubelet的性能。

2.Docker daemon重啟可能失敗。在重啟時(shí)，必須刪除docker checkpoints。

3.Pod IP分配相關(guān)的問(wèn)題。在重啟docker daemon之前刪除docker checkpoint有助于緩解這個(gè)問(wèn)題，但是尚未驗(yàn)證是否能夠完全解決該問(wèn)題。

4.由于內(nèi)核死鎖，Docker daemon可能出現(xiàn)無(wú)響應(yīng)的情況（極少出現(xiàn)）。