目錄

將 Kubernetes 支持窗口增加到一年

儲存容量追蹤

通用臨時存儲

CSI Volume 健康監(jiān)測

Ingress 升級為 GA

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

新的 klog 方法

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

其他更新

---

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ào)查中的其他反應(yīng)表明，如果將補(bǔ)丁支持期延長至12-14個月，則30%的用戶能夠?qū)⑵洳渴鸨３衷谥С值陌姹旧稀o論用戶使用的是自建版還是商業(yè)發(fā)行版，情況都是如此。因此，延長支持期將導(dǎo)致超過?80%?的用戶使用受支持的版本，而不是現(xiàn)在的?50-60%。一年一度的支持期可為用戶提供所需的緩沖期，并且更符合熟悉的年度規(guī)劃周期。從?Kubernetes 1.19?版本開始，支持窗口將延長到一年。

儲存容量追蹤

傳統(tǒng)上，Kubernetes?調(diào)度器基于這樣的假設(shè)：集群中任何地方都可以使用額外的持久性存儲，并具容量無限。拓?fù)浼s束解決了第一點，但到目前為止，Pod?調(diào)度仍然沒有考慮剩余的存儲容量可能不足以啟動一個新的?pod。存儲容量追蹤是一個新的?Alpha?特性，它通過為?CSI?驅(qū)動程序添加一個?API?來解決這個問題，以報告存儲容量，并在?Kubernetes?調(diào)度器中為?Pod?選擇節(jié)點時使用該信息。該功能可作為支持本地卷和其他容量限制較大的卷類型的動態(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é)點上的獨立本地磁盤。支持所有用于卷供應(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á)到了事實上的?GA?狀態(tài)。在沒有全面替代的情況下放棄它不是一個可行的方法。它顯然是一個有用的?API，并且捕獲了一組不平凡的用例。在這一點上，似乎更謹(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á)式的臨時解決方案。由于這些問題，任何基于這些日志的分析解決方案都很難實現(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é)點對API的訪問

• 重新設(shè)計Event API

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

• CertificateSigningRequest API

• 無需Docker構(gòu)建Kubelet

重大變化

• 節(jié)點拓?fù)涔芾砥?/p>

• 新的端點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é)點”運(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ā)布的各個方面，從文檔到測試、驗證和功能完整性。

隨著 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！這個版本有點像是一場馬拉松比賽，也證明了當(dāng)世界是一個狂野的地方，我們可以聚集在一起，做不可思議的事情。

Kubernetes 1.19 發(fā)布 Logo

?

之所以選擇“強(qiáng)調(diào)爪子-本地化”作為發(fā)布主題，是因為它捕捉了發(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ù)和用戶體驗來激發(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)者實現(xiàn)功能的里程碑從通常的5周延長到7周。貢獻(xiàn)者們多了40%的時間來研究他們的功能，從而減少了疲勞，有更多的時間來思考如何實現(xiàn)。我們還注意到，最后一刻的忙碌也大大減少了。這個周期的異常請求數(shù)量也減少了--6個，而上一個發(fā)布周期是14個。

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

• CNCF 剛剛結(jié)束了它的第一屆虛擬 KubeCon。所有講座均為點播，凡是注冊的人都可以參加，現(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ù)據(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ū)的整體速度。

總結(jié)

以上是生活随笔為你收集整理的Kubernetes v1.19版本来了，有哪些重磅更新？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。