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

將 Kubernetes 支持窗口增加到一年

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

儲存容量追蹤

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

通用臨時存儲

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

CSI Volume 健康監(jiān)測

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

Ingress 升級為 GA

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

結(jié)構(gòu)化日志

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

新的 klog 方法

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

Kubelet 的客戶端 TLS 證書輪轉(zhuǎn)

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

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

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

其他更新

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

•  Seccomp
•  Kubelet客戶端TLS證書輪替
•  限制節(jié)點(diǎn)對API的訪問
•  重新設(shè)計Event API
•  Ingress畢業(yè)為V1穩(wěn)定版
•  CertificateSigningRequest API
•  無需Docker構(gòu)建Kubelet

重大變化

• 節(jié)點(diǎn)拓?fù)涔芾砥?/li>
•  新的端點(diǎn)API
•  將Kubernetes支持周期延長至一年

其他重要變化

•  運(yùn)行多個Scheduling Profiles
•  CertificateSigningRequest API
•  不可變Secrets與ConfigMaps

發(fā)行說明

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

可用性

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é)點(diǎn)”運(yùn)行本地 Kubernetes 集群。您還可以使用kubeadm 輕松安裝1.19 。

發(fā)布團(tuán)隊

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

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

發(fā)布 Logo 

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

[[341738]]

Kubernetes 1.19 發(fā)布 Logo

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

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

從長遠(yuǎn)來看

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

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

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

•  CNCF 剛剛結(jié)束了它的第一屆虛擬 KubeCon。所有講座均為點(diǎn)播，凡是注冊的人都可以參加，現(xiàn)在還來得及!
•  認(rèn)證 Kubernetes 安全專家(CKS)將于11月推出！CKS專注于集群與系統(tǒng)加固、最小化微服務(wù)漏洞和供應(yīng)鏈的安全。
•  CNCF發(fā)布了第二份《云原生開發(fā)現(xiàn)狀》，顯示使用容器和無服務(wù)器技術(shù)的云原生開發(fā)者數(shù)量大規(guī)模增長。
•  Kubernetes.dev，一個專注于 Kubernetes 貢獻(xiàn)者的網(wǎng)站已經(jīng)推出。它將貢獻(xiàn)者文檔、資源和項目活動信息集中到一個中心位置。

項目速度

Kubernetes DevStats 儀表盤(https://k8s.devstats.cncf.io/d/12/dashboards?orgId=1)說明了公司主要貢獻(xiàn)者的貢獻(xiàn)明細(xì)，以及一套令人印象深刻的預(yù)配置報告，從個人貢獻(xiàn)者到拉動請求生命周期時間。如果你想從 Kubernetes 和 CNCF 社區(qū)收集數(shù)字、事實(shí)和數(shù)據(jù)，它是最好的開始。

在4月到8月的這個發(fā)布周期中，有382家不同的公司和超過2464名個人為Kubernetes 做出了貢獻(xiàn)。查看 DevStats(https://k8s.devstats.cncf.io/d/11/companies-contributing-in-repository-groups?orgId=1&var-period=m&var-repogroup_name=All&from=1585692000000&to=1598392799000)，可以了解更多關(guān)于 Kubernetes 項目和社區(qū)的整體速度。