Kubernetes v1.14 重磅發佈 | 新版本四大亮點 & 緊急升級說明

技術翻譯/評論:Wshi(才雲),星空下的文仔(才雲),小君君(才雲),bot(才雲)node

編輯:小君君(才雲)git

 

美國時間 3 月 25 日,Kubernetes 迎來了 2019 年的第一個新版本 1.14。與此前發佈的各版本 Kubernetes 相比,本版本中的加強功能更趨於穩定。這對那些把 Kubernetes 視爲重要戰略支撐的企業和運營商而言,是個重要里程碑。github

Kubernetes v1.14 由 31 項功能強化構成:10 個功能已經穩定,12 個功能進入 Beta,7 個全新功能。此次更新延續了以往的主題——可擴展性,且能支持 Kubernetes 上的更多工做負載,其中三個主要功能轉向通常可用性,一個重要安全功能轉向 Beta。docker

新版本四大主要特徵數據庫

  生產級 Windows 節點支持  json

截至目前,Kubernetes 中的 Windows 節點支持已經處於 Beta 階段,容許更多用戶檢驗並查看 Kubernetes 對 Windows 容器的價值。Kubernetes 如今正式支持將 Windows 節點添加爲工做節點並調度 Windows 容器,從而使 Windows 應用程序巨大的生態系統可以利用平臺的強大功能。api

對於那些使用基於 Windows 和 Linux 的應用程序企業,它們也不在須要單獨尋找編排系統來管理它們的工做負載,也不用擔憂操做系統是什麼,整個部署的操做效率大幅提升。緩存

爲了實現這一目標,Kubernetes v1.14 作了如下重點更新:安全

  • 工做站節點和容器新增 Windows Server 2019 支持;服務器

  • 使用 Azure-CNI、OVN-Kubernetes 和 Flannel 支持樹外網絡鏈接;

  • 改進了對 Pod、服務類型、工做負載控制器和 metrics/quotas 的支持,以更緊密的融合那些已經支持 Linux 容器的能力。

  值得關注的 kubectl 更新  

新的 kubectl 文檔和標誌

kubectl 的文檔已經從頭開始重寫,重點是使用聲明性 Resource Config 來管理資源。該文檔目前以獨立站點的形式發佈,採用電子書格式,並在 k8s.io 文檔中提供對應連接(詳情見:https://kubectl.docs.kubernetes.io)。

新的 kubectl 徽標和吉祥物(音爲 kubee-cuddle)也會在新的文檔站點中展現出來。

kustomize Integration

kustomize 的聲明性 Resource Config 創做功能如今可經過 -k 標誌(如用於命令 apply、get 等命令)和 kustomize 子命令在 kubectl 中得到。kustomize 幫助用戶使用 Kubernetes 原生概念建立和重用 Resource Config。用戶如今可以利用 kubectl apply -k dir/ 將擁有 kustomization.yaml 的目錄適用於集羣。此外,用戶還能夠向 stdout 發出自定義的 Resource Config,而無需經過 kubectl kustomize dir/ 加以應用。新功能記錄,見 https://kubect.docs.kubernetes.io。

社區還將繼續經過 Kubernetes 的 kustomize repo 對 kustomize 子命令進行開發。最新的 kustomize 功能將以獨立的 kustomize 二進制文件(發佈到 kustomize repo)的形式更改成頻率的發佈,並將在每次 Kubernetes 發佈以前在 kubectl 中更新。

kubectl 插件機制逐漸穩定

kubectl 插件機制容許開發人員以獨立二進制文件的形式發佈本身的自定義 kubectl 子命令。這些成果將可幫助 kubectl 與附加 porcelain 實現更多新的高級功能(如添加 set-ns 命令)。

插件必須具備 kubectl- 爲命名的前綴,並保存於用戶的 $PATH 中。在 GA 中,插件機制已經大幅簡化。目前,其形式相似於 git 插件系統。

  持久化本地存儲進入 GA 階段  

新版本下,持久化本地存儲更加穩定,使用戶能夠把本地鏈接存儲用做持久存儲源。因爲性能和成本的考量,分佈式文件系統和數據庫一直是持久性本地存儲的主要用例。相比雲提供商,本地 SSD 提供的性能遠比遠程磁盤優秀。而相比裸機,除了性能,本地存儲一般更便宜,而且使用它是配置分佈式文件系統的必要條件。

  PID 限制 Beta 預告  

進程 ID(PID)是 Linux 主機上的基本資源。在不遇到任何其餘資源限制的狀況下,用戶沒法接受由於進程 ID 不足而影響任務運行,甚至致使主機穩定性下降。管理員須要一些機制來確保 Pod 中的 PID 不被耗盡,從而阻止主機守護程序(運行時、kubelet 等)運行。此外,管理員還須要確保在各 Pod 之間限制 PID,以確保它們不會影響到運行在節點上的其餘工做負載。

在 Beta 版中,管理員能夠經過預約義每一個 Pod 的 PID 數量,實現 Pod 之間的  PID 隔離。此外,管理員也能夠經過節點可分配的方式爲用戶 Pod 保留大量可分配的 PID,這是 Alpha 版中實現 Pod 間的 PID 隔離的方法。在下一版本中,開發團隊但願能把 Beta 版帶給開發者。

  其餘值得注意的功能更新  

Pod 優先級和搶佔使 Kubernetes 調度程序可以首先調度更重要的 Pod,當集羣資源不足時,它會刪除不過重要的 Pod,以便爲更重要的 Pod 建立空間。重要性由優先級指定。

Pod Readiness Gates 如今爲 Pod 就緒狀況提供了外部反饋的擴展點。

增強默認 RBAC 的 clusterrolebindings 發現能力。移除了本來默承認經過未受權訪問的 API 集發現功能,旨在提高 CRD 隱私性以及默認集羣的整體安全水平。

  可用性  

Kubernetes v1.14 可從 GitHub 下載。要開始使用 Kubernetes,請查看各種交互式教程。你也可使用 kubeadm 輕鬆安裝 1.14 版本 。

緊急升級說明

  kube-apiserver  

  • 默認的 RBAC 策略已再也不授予未經身份驗證的用戶使用發現和權限檢查的 APIs 的權限(經過 kubectl auth can-i)。升級後的集羣會保留先前的行爲,可是若是集羣管理員但願授予未身份驗證的用戶訪問新集羣,則必須明確指定 discovery 或者權限檢查的 APIs;

  • --storage-versions 標誌已經被移除。storage version 會一直以默認值方式編譯到 kube-apiserver 裏;

  • --repair-malformed-updates 標誌被移除;

  • Kube-apiserver 如今只聚合來自 /openapi/v2 聚合 API 服務器端點的 openapi 模式。聚合的後備 /swagger.json 已被刪除。確保聚合 API server 經過 /openapi/v2(自 v1.10 起可用)提供架構信息;

  • 已刪除前綴爲「io.k8s.kubernetes.pkg」(自 v1.9 已棄用)的 OpenAPI 定義;

  • 該 ValidateProxyRedirects 功能已升級爲 Beta 並默認啓用。此功能限制從 apiserver 到同一主機重定向的重定向跟蹤。若是節點配置爲響應不一樣於 apiserver 請求的主機接口上的 CRI 流請求(僅在不使用內置 dockershim 和設置 kubelet 標誌的狀況下 --redirect-container-streaming=true),則這些請求將被破壞。在這種狀況下,能夠暫時禁用該功能,直到更正節點配置。咱們建議設置 --redirect-container-streaming=false 以免問題。

  kubectl  

  • 已棄用的 kubectl get 的 --show-all 標記已被刪除。

  kubelet  

  • 已棄用的 --experimental-fail-swap-on 標誌已被刪除;

  • 使用 HTTPGetAction 的運行情況檢查(活動性和就緒性)探測將再也不遵循重定向到原始探測請求的不一樣主機名。相反,這些非本地重定向將被視爲成功(記錄的行爲)。在這種狀況下,將生成具備「ProbeWarning」緣由的事件,指示重定向被忽略。若是你之前依賴重定向對不一樣的端點運行情況檢查,則須要在 kubelet 外部執行運行情況檢查邏輯,例如經過代理外部端點而不是重定向到它。

  client-go  

  • 已棄用的無版本 API 組訪問(如 clientset.Apps())已被刪除。使用顯式版本(如 clientset.AppsV1());

  • 磁盤緩存的發現客戶端從 k8s.io/client-go/discovery 移至 k8s.io/client-go/discovery/cached/disk。內存緩存的發現客戶端從 k8s.io/client-go/discovery/cached 移至 k8s.io/client-go/discovery/cached/memory。

  kubeadm  

  • kubeadm alpha preflight 和 kubeadm alpha preflight node 被移除;你如今可使用 kubeadm join phase preflight;

  • 棄用的污點 node.alpha.kubernetes.io/notReady 和 node.alpha.kubernetes.io/unreachable 再也不支持或調整。應將這些替換爲node.kubernetes.io/not-ready 和 node.kubernetes.io/unreachable;

  • 任何匹配 pod_name 和 container_name 標籤的 Prometheus 查詢(例如 cadvisor 或 kubelet 探測指標)都應該更新爲 Pod 和 Container。pod_name 和 container_name 標籤將與一個過渡版本一塊兒存在,並在未來刪除。

 

1.14 更新細節

 Windows 節點支持已進入穩定階段 

  • 支持 Windows Server 2019 做爲 worker nodes 和容器使用;

  • 支持使用 Azure-CNI、OVN-Kubernetes 和 Flannel 組成樹外網絡鏈接;

  • 改進了對 Pods、service types、workload controllers 和 metrics/quotas 的支持,以更緊密的融合那些已經支持 Linux 容器的能力。

 kubectl 的插件機制逐步趨於穩定 

  • kubectl 擴展性功能,支持添加新命令,還能夠覆寫指定的子命令。

  本地存儲管理達到 GA  

  • 使本地(非網絡)存儲可用做持久卷源;

  • 容許用戶利用本地持久存儲一般更便宜且性能更好的優勢。

 Kubernetes 中的 Pod 優先級和搶佔 

  • Pod 優先級和搶佔使 Kubernetes 調度程序可以首先調度更重要的 Pod,當集羣資源不足時,它會刪除不過重要的 Pod,以便爲更重要的 Pod 建立空間。重要性由優先級指定。

  Pod Ready ++  

  • 介紹了有關 Pod 準備就緒的外部反饋的擴展點。

 kubeadm:在 HA 設置中自動執行控制平面之間的證書複製  

  • 如今,經過啓用現有控制平面節點的可選自動證書副本,能夠簡化將控制平面節點鏈接到 HA 羣集的過程;

  • 你如今可使用 kubeadm init --experimental-upload-certs 和 kubeadm join --experimental-control-plane --certificate-key。

  kubeadm:將 kubeadm join 工做流程公開爲階段  

  • 該 kubeadm join 命令如今能夠分階段使用。與 kubeadm init 在 1.13 中完成的工做相似,在 1.14 中,join 如今可使用 kubeadm join phase 子命令逐步/有選擇地執行階段。這使得能夠進一步定製將節點加入集羣的工做流程。

新版技術評論

「K8sMeetup 中國社區」特別邀請 Caicloud(才雲科技) 工程師,第一時間爲 Kubernetes 1.14 作了一個簡短評論:

從 Kubernetes v1.13 開始,咱們漸漸發現 Kubernetes 在趨於穩定,並無太多新功能的增長,更多的是在穩定性,安全性和擴展性等功能方面的增強。在今天發佈的 v1.14 中,這點也能夠獲得體現。

Kubernetes v1.14 依然延續 v1.13 在擴展性上作了不少工做,尤爲對 Windows 的支持。在官方聲明中, 新版本能夠添加 Windows 節點做爲工做節點,而且調度 Windows 容器。 其實,Kubernetes 對 Windows 的支持能夠追溯到 1.5 版本,歷經這麼長時間的努力,如今用戶終於能夠配置使用 Linux + Windows 集羣環境,而且同時運行 Windows 容器應用和 Linux 容器應用。這給想要使用 Kubernetes 編排系統而又基於 Windows 開發的企業帶來了福音。

參考文獻

1.https://kubernetes.io/blog/

2.https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.14.md#kubernetes-v114-release-notes

 


 

相關文章
相關標籤/搜索