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

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

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

1.使用kubernetes 1.2.0 推薦使用Docker v1.9.1，但仍然支持v1.8.3和v1.10。如果你使用的Docker版本太低，請先升級Docker。但Docker v1.9.1存在一些問題，下面我們詳細(xì)討論。

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

3.這條注意事項只在你使用 Go 語言 client（/pkg/client/unversioned）創(chuàng)建Job時適用，比如使用 ”k8s.io/kubernetes/pkg/apis/extensions”.Job 來定義 GO 變量。這種做法并不常用，如果你不明白這里在討論什么，那你暫時無須關(guān)注這個問題。如果你使用Go語言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中。由于我們對API做了向后不兼容的變更，所以在v1.1中創(chuàng)建的Deployment對象將無法在v1.2中使用。具體變更如下：

a)升級到v1.2之前，務(wù)必刪除所有Alpha版本的Deployment資源，包括Deployment管理的ReplicationController和Pod。升級到v1.2之后，創(chuàng)建Beta版本的Deployment資源。不刪除Deployment資源的話，由于選擇器API的變更，可能導(dǎo)致deployment
controller錯誤地匹配和刪除其他pods。
b)進(jìn)行Deployment相關(guān)的操作時，客戶端（kubectl）和服務(wù)器端的版本必須匹配（均為1.1或者1.2）。
c) API行為變更：①Deployment創(chuàng)建ReplicaSets而不是ReplicationController；②scale
subresource的狀態(tài)結(jié)構(gòu)體中增加了一個字段
targetSelector，該字段支持基于集合（set-based）的選擇器，但格式必須是序列化后的結(jié)果。
d)規(guī)格（Spec）變更：①Deployment對象的選擇器更加通用（支持基于集合的選擇器，而在v1.1中支持基于比較的選擇器）；②.spec.uniqueLabelKey字段已被刪除，用戶將不能自定義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中。由于我們對API做了向后不兼容的變更，所以在v1.1中創(chuàng)建的DaemonSet對象將無法在v1.2中使用。具體變更如下：

a) 升級到v1.2之前，務(wù)必刪除所有Alpha版本的DaemonSet資源。如果你不想破壞原有的Pod，可以使用命令kubectl
delete daemonset –cascade=false。升級到v1.2之后，創(chuàng)建Beta版本的Deployment資源。
b) 進(jìn)行DaemonSet相關(guān)的操作時，客戶端（kubectl）和服務(wù)器端的版本必須匹配（均為1.1或者1.2）。
c) API行為變更：①即便節(jié)點(diǎn)設(shè)置了.spec.unschedulable=true，DaemonSet
pod也會在該節(jié)點(diǎn)上創(chuàng)建，即便節(jié)點(diǎn)Ready狀態(tài)為False，pod也不會被刪除。②允許 更新Pod
template。如果對DaemonSet進(jìn)行rolling update，可以更新pod
template，然后把pod一個個刪除，新的pod將根據(jù)新的pod template創(chuàng)建。
d) 規(guī)格(Spec)變更: ①DaemonSet對象的選擇器更加通用（支持基于集合的選擇器，而在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將增加對protocol buffer的支持， API也將直接支持YAML格式。作為準(zhǔn)備，在當(dāng)前release中，每個HTTP spec的 Content-Type和Accept headers都會被處理。所以，你通過客戶端發(fā)送請求給API時，如果Content-Type或Accept headers無效，將會返回415或406錯誤。目前唯一已知會影響到的客戶端是curl，一個錯誤的做法是：使用-d 發(fā)送JSON，但是不設(shè)置Content-Type（希望使用默認(rèn)的"application/x-www-urlencoded"）。如果你使用的其他的客戶端，那么需要檢查確認(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ù)的存儲格式發(fā)生變化，Kubernetes要求influxdb的版本為0.9（之前為0.8）。

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

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

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

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

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

5." kubectl edit"操作會為每個資源代打開一次編輯器，因此編輯器會被打開很多次。

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

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

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

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

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

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

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

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

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

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