先睹爲快 ▏Kubernetes 1.5有哪些你不得不知的新功能?

今年9月份咱們迎來了Kubernetes 1.4的驚喜發佈,一大波新功能讓人眼花繚亂。通過將近三個月時間的打磨,現在Kubernetes再推出新版本,翹首以盼的Kubernetes 1.5重磅發佈,本次版本更新涵蓋了4個主題、12個新特性以及4個原有基礎上的重大變動。期待不如眼疾手快,翻閱文章內容,享受一場Kubernetes 1.5的饕餮大餐吧~node

主題簡介:

一、StatefulSets (原名PetSets)docker

  • StatefulSets 如今是 beta 版 (主要是修復和穩定性)json

二、改善聯邦支持api

  • 新命令:kubefed安全

  • DaemonSets服務器

  • 部署網絡

  • Configmapsapp

三、簡化集羣部署運維

  • 改進kubeadmide

  • Master的HA設置

四、節點魯棒性及可擴展性

  • 支持Windows Service容器

  • 實現了CRI(容器運行時接口)

  • 添加kubelet API調用時身份驗證和受權

新特性簡介:

一、API 機制

  • [beta] kube-apiserver支持OpenAPI從alpha移動到beta, 第一個non-go客戶端是基於此特性。

二、應用

  • [Stable]當replica sets不能建立Pods時,它們將經過API報告失敗的詳細底層緣由。

  • [Stable] kubectl apply現可經過--prune刪除再也不須要的資源

  • [beta] Deployments現可經過API升級到新版本,而以前是沒法經過滾動來進行升級的

  • [beta] StatefulSets容許要求持久化identity或單實例存儲的工做負載從而在Kubernetes建立和管理。

  • [beta]爲了提供安全保障,集羣不會強行刪除未響應節點上的Pods,若是用戶經過CLI強行刪除Pods會收到警告。

三、認證

  • [Alpha]改進了基於角色的訪問控制alpha API。(包括一組默認的集羣角色)

  • [Beta]添加了對Kubelet API訪問的認證/受權機制。

四、AWS

  • [stable]角色出如今kubectl get nodes的結果裏。

五、集羣生命週期

  • [alpha] 提高了kubeadm二進制包的交互和可用性,從而更易於新建一個運行集羣。

六、集羣運維

  • [alpha] 在GCE上使用kube-up/kube-down腳原本建立/移除集羣高可用(複製)的主節點。

七、聯邦

  • [beta] 支持聯邦ConfigMaps。

  • [alpha] 支持聯邦Daemonsets。

  • [alpha] 支持聯邦Deployments。

  • [alpha]集羣聯邦:爲聯邦資源添加對於DeleteOptions.OrphanDependents的支持。

    • [alpha]引入新命令行工具:kubefed,簡化聯邦控制檯的部署以及集羣註冊/註銷體驗。

八、網絡

  • [stable]服務能夠經過DNS名稱被其餘服務引用,而不是隻有在pods裏才能夠。

  • [beta]爲NodePort類型和LoadBalancer的服務保留源IP的選項。

  • [stable]啓用beta ConfigMap參數支持的DNS水平自動伸縮

九、節點

  • [alpha]支持在容器運行時啓用用戶命名空間重映射的時候,保留對宿主用戶命名空間的訪問。

  • [alpha]引入了v1alpha1版本的CRI(容器運行時接口) API,它容許可插拔的容器運行時;現有一個已經就緒的用於測試和反饋的docker-CRI集成。

  • [alpha]Kubelet基於QoS層在每一個Pod的CGroup層級裏啓動容器。

  • [beta]Kubelet集成了memcg提示消息API,來檢測是否超過閾值。

  • [beta]引入了Beta版本的容器化節點一致性測試: gcr.io/google_containers/node-test:0.2。從而讓用戶驗證node設置。

十、調度

  • [alpha]添加了對不透明整數資源(node級)的審計支持。

  • [beta] PodDisruptionBudget已經升級到Beta版,當想要應用SLO時,能夠用來安全地drain節點。

十一、UI

  • [stable]Dashboard UI現在顯示面向用戶的對象及它們的資源使用狀況。

十二、Windows

  • [alpha]添加了對Windows Server 2016節點和調度Windows Server Container的支持。

已知問題

  • CRI已知問題及限制。

  • 當volume路徑包含空格時,DeviceNameFromMount()函數不能正確的返回volume路徑。

  • 聯邦alpha版的特性不具備特徵定義,所以默認啓用,在將來的版本中將修復這一問題。

  • 聯邦控制面板可經過更新控制面板組件Deployment規格的鏡像字段來進行升級,然而在該版本中聯邦控制面板升級還沒有進行測試。

重大改變

一、節點控制器再也不強行刪除來源於apiServer的pods

  • 對於有狀態的應用StatefulSet(原名爲 PetSet)而言,這個改動意味着建立替換的Pods被阻塞,直到舊的Pods肯定再也不運行(意味着kubelet從分區返回,Node對象的刪除,雲服務商裏實例的刪除,或強行刪除api-Server裏的Pod)。這裏經過確保不可達的Pod不會被認爲已經死亡來防止集羣應用出現「腦裂」的情況,除非一些「包圍」操做提供了上述之一的狀況。

  • 對於其餘現有的除StatefulSet外的控制器,這對於控制器替換Pods沒有影響,由於控制器不會重用Pods名稱(他們使用generate-name)

  • 用戶編寫的控制器會重用Pod對象的名稱,應該考慮這個變化。

  • 當使用kubectl delete ... --grace-period=0 刪除一個對象時,客戶端將開始進行優雅的刪除並等待,直到資源徹底被刪除。要當即強制刪除,使用--force 標誌。這能夠防止用戶不當心讓兩個Stateful Set共享可能致使數據損壞的相同的持久存儲。

二、容許匿名API服務器的訪問,經過受權組系統設置認證的用戶

  • kube-apiserver添加了--anonymous-auth 標誌,默認爲true。當它啓用時,訪問安全端口的請求不會被其餘配置的認證方法所拒絕,這些請求被當作匿名請求,而且用戶名爲system:anonymous,組織爲system:unauthenticated。
    認證的用戶被設爲system:authenticated組。

三、即便路徑是用於類型的有效字段,若是路徑在json文件下不提供字段,kubectl get -o jsonpath=... 將拋出一個錯誤。這個改變從pre-1.5版本開始,即便他們目前不在 json文件下,也會返回一些字段的默認值。

四、對於VolumeMounts的strategicmerge patchMergeKey是由「名稱」到「mountPath」的改變。這是必要的,由於名稱字段引用Volume的名稱,而且不是VolumeMount的惟一鍵。若是安裝多個相同的volume,多個VolumeMounts將有一樣的 Volume名稱。「mountPath」是獨一無二的,並能夠做爲mergekey。

升級前注意事項

一、升級前重要的安全相關改變

  • 必須在kube-apiserver設置--anonymous-auth=false參數,除非你是一個測試該功能的開發者而且瞭解它。若是不這樣,你會容許未經受權的用戶訪問你的apiserver。

  • 必須在聯邦apiserver設置--anonymous-auth=false參數,除非你是一個測試該功能的開發者而且瞭解它。若是不這樣,你會容許未經受權的用戶訪問你的聯邦apiserver。你不須要調整kublete的該參數:1.4的Kubelet APIs沒有受權。

二、batch/v2alpha1.ScheduledJob被重命名爲batch/v2alpha1.CronJob。

三、PetSet被重命名爲StatefulSet。若是你如今有PetSets,你要在升級爲StatefulSets先後進行一些額外的遷移操做。

四、若是你從v1.4.x升級你的集羣聯邦組件,請更新你的federation-apiserver和federation-controller-manager到新版本。

五、廢棄的kubelet --configure-cbr0參數被移除。經典的網絡模式也是。若是你依賴於此模式,請調研其餘的網絡插件kubenet或cni是否知足需求。

六、新的client-go結構,參考kubernetes/client-go進行版本控制策略。

七、廢棄的kube-scheduler --bind-pods-qps和--bind-pods burst參數被移除,替換爲--kube-api-qps和--kube-api-burst。

八、若是你須要使用1.4的特性:PodDisruptionBudget(例如建立了PodDisruptionBudget對象),那麼在從1.4升級爲1.5以前,你必定要刪除全部建立的PodDisruptionBudget對象(policy/v1alpha1/PodDisruptionBudget)。升級以後不可能刪除這些對象。它們的存在也會妨礙你使用1.5裏Beta版的PodDisruptionBudget特性(policy/v1beta1/PodDisruptionBudget)。若是你已經進行了升級,那麼你須要降級到1.4來刪除這些policy/v1alpha1/PodDisruptionBudget對象。

tips:查看更多精彩內容?關注公衆號:tenxcloud2(時速雲訂閱號),咱們後續還會發布kubernetes 1.5相關文章,你們持續關注哦~

相關文章
相關標籤/搜索