Kubernetes v1.19版有哪些更新

今天就跟大家聊聊有關Kubernetes v1.19版有哪些更新，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

Kubernetes 1.19 版本終于來啦！這是2020年的第二個版本，也是迄今為止最長的發(fā)布周期，總共持續(xù)20周。它由33項增強功能組成。12個增強功能進入穩(wěn)定版，18個增強功能進入測試版，13個增強功能進入alpha版。

將 Kubernetes 支持窗口增加到一年

長期支持（LTS）工作組在2019年初進行的一項調(diào)查顯示在當前的9個月支持期內(nèi)，很大一部分 Kubernetes 用戶未能升級。這一點以及調(diào)查中的其他反應表明，如果將補丁支持期延長至12-14個月，則30%的用戶能夠將其部署保持在支持的版本上。無論用戶使用的是自建版還是商業(yè)發(fā)行版，情況都是如此。因此，延長支持期將導致超過 80% 的用戶使用受支持的版本，而不是現(xiàn)在的 50-60%。一年一度的支持期可為用戶提供所需的緩沖期，并且更符合熟悉的年度規(guī)劃周期。從 Kubernetes 1.19 版本開始，支持窗口將延長到一年。

儲存容量追蹤

傳統(tǒng)上，Kubernetes 調(diào)度器基于這樣的假設：集群中任何地方都可以使用額外的持久性存儲，并具容量無限。拓撲約束解決了第一點，但到目前為止，Pod 調(diào)度仍然沒有考慮剩余的存儲容量可能不足以啟動一個新的 pod。存儲容量追蹤是一個新的 Alpha 特性，它通過為 CSI 驅動程序添加一個 API 來解決這個問題，以報告存儲容量，并在 Kubernetes 調(diào)度器中為 Pod 選擇節(jié)點時使用該信息。該功能可作為支持本地卷和其他容量限制較大的卷類型的動態(tài)預配置的基礎。

通用臨時存儲

Kubernetes 提供了卷插件，其生命周期與 Pod 綁定，可用作臨時空間（例如內(nèi)置的 emptydir 卷類型），也可以將一些數(shù)據(jù)加載到 Pod 中（例如內(nèi)置的configmap 和 secret 卷類型）。新的通用暫存卷 alpha 功能允許任何現(xiàn)有的支持動態(tài)供應的存儲驅動程序被用作 ephemeral 卷，并將該卷的生命周期綁定到 Pod。它可以用來提供不同于根磁盤的臨時存儲，例如持久內(nèi)存或者該節(jié)點上的獨立本地磁盤。支持所有用于卷供應的 StorageClass 參數(shù)。支持 PersistentVolumeClaims 支持的所有功能，如存儲容量跟蹤、快照和還原以及卷的大小調(diào)整。

CSI Volume 健康監(jiān)測

CSI 健康狀況監(jiān)控的 Alpha 版本隨 Kubernetes 1.19 一起發(fā)布。該功能使 CSI 驅動程序能夠與 Kubernetes 共享來自底層存儲系統(tǒng)的異常卷狀況，以便將其作為事件報告在 PVC 或 Pod 上。此功能是 Kubernetes 進行程序檢測和解決單個卷健康問題的基礎。

Ingress 升級為 GA

就將 Ingress API 推向 GA 而言，API 本身在 Beta 版中已經(jīng)存在了很長時間，以至于通過使用和采用（包括用戶和負載均衡器 Ingress 控制器提供商），它已經(jīng)達到了事實上的 GA 狀態(tài)。在沒有全面替代的情況下放棄它不是一個可行的方法。它顯然是一個有用的 API，并且捕獲了一組不平凡的用例。在這一點上，似乎更謹慎的做法是將當前的 API 聲明為社區(qū)將支持的 V1 版本，同時開發(fā) V2 Ingress API 或具有超集功能的完全不同的 API。

結構化日志

在 v1.19 之前，Kubernetes 控制平面中的日志記錄無法保證日志消息和這些日志中對 Kubernetes 對象的引用有任何統(tǒng)一的結構。這使得對日志的解析、處理、存儲、查詢和分析變得困難，并迫使管理員和開發(fā)人員在大多數(shù)情況下依靠基于一些正則表達式的臨時解決方案。由于這些問題，任何基于這些日志的分析解決方案都很難實現(xiàn)和維護。

新的 klog 方法

這個 Kubernetes 版本為 klog 庫引入了新的方法，該方法提供了用于格式化日志消息的更結構化的接口。每個現(xiàn)有的格式化日志方法（Infof，Errorf）都通過結構化方法（InfoS，ErrorS）進行匹配。新的日志記錄方法將日志消息作為第一個參數(shù)，將鍵值對列表作為可變參數(shù)的第二個參數(shù)。這種方法允許逐步采用結構化日志記錄，而無需一次將所有 Kubernetes 轉換為新的API。

Kubelet 的客戶端 TLS 證書輪轉

kubelet 使用私鑰和證書對 kube-apiserver 進行認證。證書是在 kubelet 首次啟動時通過集群外機制提供給它的。自 Kubernetes v1.8 以來，集群已經(jīng)包含了一個（beta）流程，用于獲取初始的證書/密鑰對，并在證書到期臨近時進行輪轉，在 Kubernetes v1.19 中，這個功能可以穩(wěn)定下來了。

在 kubelet 啟動過程中，將對文件系統(tǒng)進行掃描，以查找由證書管理器管理的現(xiàn)有證書/密鑰對。如果有可用的證書/密鑰，則將加載它。如果沒有，則 kubelet 會檢查配置文件中的編碼證書值或 kubeconfig 中的文件引用。如果證書是一個 bootstrap 證書，則它將用于生成密鑰，創(chuàng)建證書簽名請求并向 API服務器請求簽名的證書。

當?shù)狡谂R近時，證書管理器會負責提供正確的證書，生成新的私鑰和請求新的證書。隨著 kubelet 請求證書的簽名是其啟動過程的一部分，并且不斷地對來自 kubelet 的證書簽名請求進行自動批準，以使集群變得易于管理。

其他更新

以下功能迎來穩(wěn)定版

•  Seccomp

•  Kubelet客戶端TLS證書輪替

•  限制節(jié)點對API的訪問

•  重新設計Event API

•  Ingress畢業(yè)為V1穩(wěn)定版

•  CertificateSigningRequest API

•  無需Docker構建Kubelet

重大變化

• 節(jié)點拓撲管理器

•  新的端點API

•  將Kubernetes支持周期延長至一年

其他重要變化

•  運行多個Scheduling Profiles

•  CertificateSigningRequest API

•  不可變Secrets與ConfigMaps

發(fā)行說明

在我們的發(fā)行說明(https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md)中查看 Kubernetes 1.19 發(fā)行版的完整詳細信息。

可用性

Kubernetes 1.19可以在GitHub(https://github.com/kubernetes/kubernetes/releases/tag/v1.19.0)上下載。要開始使用 Kubernetes，請查看這些交互式教程(https://kubernetes.io/docs/tutorials/)或使用帶有 KinD（Docker中的Kubernetes）的 Docker 容器“節(jié)點”運行本地 Kubernetes 集群。您還可以使用kubeadm 輕松安裝1.19 。

發(fā)布團隊

這個版本的發(fā)布是通過數(shù)百人的努力，他們貢獻了技術和非技術內(nèi)容。特別感謝 HashiCorp 的高級開發(fā)人員倡導者T aylor Dolezal 領導的發(fā)布團隊。34位發(fā)布團隊成員協(xié)調(diào)了發(fā)布的各個方面，從文檔到測試、驗證和功能完整性。

隨著 Kubernetes 社區(qū)的發(fā)展，我們的發(fā)布過程代表了開源軟件開發(fā)中協(xié)作的驚人表現(xiàn)。Kubernetes 繼續(xù)以快速的速度獲得新用戶。這種增長創(chuàng)造了一個積極的反饋循環(huán)，更多的貢獻者提交代碼創(chuàng)造了一個更有活力的生態(tài)系統(tǒng)。迄今為止，Kubernetes 已經(jīng)有超過49,000名個人貢獻者，以及一個超過3,000人的活躍社區(qū)

發(fā)布 Logo 

所有人都啟發(fā)了這個 Kubernetes 1.19 版本 Logo！這個版本有點像是一場馬拉松比賽，也證明了當世界是一個狂野的地方，我們可以聚集在一起，做不可思議的事情。

Kubernetes 1.19 發(fā)布 Logo

之所以選擇“強調(diào)爪子-本地化”作為發(fā)布主題，是因為它捕捉了發(fā)布團隊盡管世界狀況良好的積極前景。1.19徽標中顯示的字符代表了我們發(fā)行團隊中每個人的個性，從emo到peppy，甚至更多！

關于設計師：漢娜貝絲·拉格洛夫（Hannabeth Lagerlof）是位于加利福尼亞州洛杉磯的視覺設計師，她在環(huán)境和圖形設計領域擁有廣泛的背景。漢娜貝斯（Hannabeth）創(chuàng)造藝術和用戶體驗來激發(fā)聯(lián)系。您可以在Twitter上以@emanate_design的身份找到Hannabeth。

從長遠來看

此次發(fā)布的內(nèi)容也與增強功能方面有所不同。傳統(tǒng)上，我們有3-4周的時間，從呼吁增強功能到增強功能凍結，這段時間結束后，貢獻者可以確認某項功能是否會成為周期的一部分。這次發(fā)布周期很特殊，我們有五個星期的時間來完成同一個里程碑。延長的時間給了貢獻者更多的時間來計劃和決定他們各自功能的畢業(yè)。

貢獻者實現(xiàn)功能的里程碑從通常的5周延長到7周。貢獻者們多了40%的時間來研究他們的功能，從而減少了疲勞，有更多的時間來思考如何實現(xiàn)。我們還注意到，最后一刻的忙碌也大大減少了。這個周期的異常請求數(shù)量也減少了--6個，而上一個發(fā)布周期是14個。

生態(tài)系統(tǒng)更新

•  CNCF 剛剛結束了它的第一屆虛擬 KubeCon。所有講座均為點播，凡是注冊的人都可以參加，現(xiàn)在還來得及!

•  認證 Kubernetes 安全專家(CKS)將于11月推出！CKS專注于集群與系統(tǒng)加固、最小化微服務漏洞和供應鏈的安全。

•  CNCF發(fā)布了第二份《云原生開發(fā)現(xiàn)狀》，顯示使用容器和無服務器技術的云原生開發(fā)者數(shù)量大規(guī)模增長。

•  Kubernetes.dev，一個專注于 Kubernetes 貢獻者的網(wǎng)站已經(jīng)推出。它將貢獻者文檔、資源和項目活動信息集中到一個中心位置。

看完上述內(nèi)容，你們對Kubernetes v1.19版有哪些更新有進一步的了解嗎？如果還想了解更多知識或者相關內(nèi)容，請關注億速云行業(yè)資訊頻道，感謝大家的支持。