使用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可能出現無響應的狀況（極少出現）。