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

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

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

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。

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都將重啟。

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

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

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

4.由于內核死鎖，Docker daemon可能出現無響應的情況（極少出現）。