歷時5月，Kubernetes1.19正式發佈 ！Ingress迎來GA，存儲容量跟蹤新特性

咱們迎來了Kubernetes1.19，這是2020年發佈的第二個版本，也是迄今爲止最長的發佈週期，總共持續了20周。它包括33個加強功能：12個加強功能達到穩定版，18個加強處在beta版，還有13個是alpha版。

 

因爲COVID-1九、George Floyd抗議事件，以及咱們做爲發佈團隊經歷的其餘一些全球事件，1.19的發佈與常規版本有很大不一樣。因爲上述緣由，咱們決定調整時間表，讓SIG、工做組和貢獻者可以有更多時間來完成工做。同時，也讓你們有時間關注Kubernetes(http://www.alauda.cn)項目以外的生活，並確保他們良好的精神健康狀態。

 

貢獻者是Kubernetes的核心，而並不是相反。Kubernetes的行爲準則要求善待彼此、成就彼此，儘管咱們的世界動盪不安，咱們看到的依然是一個偉大且充滿謙遜的社區。

1Kubernetes支持窗口增長到一年

長期支持(LTS)工做組在2019年初進行的一項調查顯示，Kubernetes終端用戶中有至關一部分未能在當前9個月的支持期內升級。該調查的其餘結論還包括，若是補丁支持期限延長到12-14個月，30%的用戶將可以跟上新版本的部署。這彷佛是正確的，不管用戶使用的是自建，仍是商業銷售的發行版。

 

所以，將支持期延長將有超過80%的用戶享受到支持版本，而如今只有50-60%。一年的支持期爲最終用戶提供了必要的緩衝，而且與熟悉的年度規劃週期更加協調。所以，從Kubernetes 1.19版本開始，支持窗口將延長到一年。

2存儲容量跟蹤

 

傳統上，Kubernetes調度器基於這樣的假設：集羣中的任何地方都有額外的持久性存儲，而且具備無限的容量。拓撲約束解決了第一點，可是到目前爲止，pod調度仍然沒有考慮到剩餘的存儲容量可能不足以啓動新的pod。存儲容量跟蹤是一個新的alpha特性，經過爲CSI驅動程序添加API來報告存儲容量，並在爲pod選擇節點時在Kubernetes調度器中使用該信息。此功能可做爲支持本地卷和其餘容量受限的卷類型的動態資源調配的基礎。

3臨時通用卷

 

Kubernetes提供的卷插件的生命週期與pod相關，能夠用做臨時空間（例如，內置的emptydir卷類型）或將一些數據加載到pod中（例如，內置的configmap和secret卷類型，或「CSI inline volumes」）。新的通用臨時卷alpha功能容許任何支持動態資源調配的現有存儲驅動程序用做臨時卷，並將卷的生命週期綁定到Pod。它能夠用來提供與根磁盤不一樣的臨時存儲，例如持久內存，或者該節點上的一個單獨的本地磁盤。支持卷配置的全部Storage Class參數。支持Persistent Volume Claims支持的全部功能，例如存儲容量跟蹤、快照和恢復以及卷大小調整

4CSI卷運行情況監控

本次Kubernetes 1.19發佈了CSI運行情況監測的alpha版本。這個特性使CSI驅動程序可以與Kubernetes(https://www.alauda.cn)共享來自底層存儲系統的異常卷狀況，從而可以將它們做爲事件報告到PVC或Pod上。該特性能夠做爲Kubernetes程序化檢測和解決單卷運行情況問題的基礎。

 

5Ingress正式迎來 GA

 

在將Ingress API推向GA方面，API自己已經在beta版中可用了很長時間，因爲不斷被用戶和負載均衡/Ingress Controller提供商等所使用和採用，它已經得到了事實上的GA狀態。在沒有徹底替代的狀況下放棄它是不可行的作法。它是一個重要的API，並捕獲了一系列重要的用例。在這一點上，更謹慎的作法是將當前的API聲明做爲社區支持的V1版，並對其狀態進行編碼，同時開發 Ingress API V2版本，或具備超集特性的新的API。

6結構化日誌

在v1.19以前，在Kubernetes控制平面進行日誌記錄沒法保證日誌消息和對Kubernetes對象的引用保持統一的結構。這使得解析、處理、存儲、查詢和分析日誌變得困難，而且迫使管理員和開發人員在大多數狀況下依賴基於一些正則表達式的臨時解決方案。因爲這些問題的存在，任何基於這些日誌的分析解決方案都很難實現和維護。

 

7新的klog方法

 

Kubernetes 1.19版本引入了klog庫的新方法，這些方法爲格式化日誌消息提供了一個更結構化的接口。每一個現有的格式化日誌方法(Infof、Errorf)都與結構化方法(InfoS、ErrorS)相匹配。新的日誌記錄方法接受日誌消息做爲第一參數，並將鍵值對列表做爲第二變量參數。這種方法容許漸進地採用結構化日誌記錄，而不須要一次將全部Kubernetes指向新的API。

 

8kubelet的客戶端TLS證書輪換

 

kubelet使用私鑰和證書向kube-apiserver驗證kubelet。當kubelet第一次啓動時，經過集羣外機制將證書提供給kubelet。自從kubernetes v1.8以來，集羣開始引入一個beta過程，用於獲取初始證書/密鑰對，並在證書到期時對其進行輪替。在Kubernetes v1.19中，這一功能進入穩定版本。

 

在kubelet啓動期間，將掃描文件系統，以查找由證書管理器管理的現有證書/密鑰對。若是有可用的證書/密鑰，則將加載該證書/密鑰。若是沒有，kubelet將檢查其配置文件中的編碼證書值或文件引用。若是證書是引導證書，那麼它將用於生成密鑰、建立證書籤名請求並從API服務器請求籤名證書。

 

在證書到期後，證書管理器負責提供正確的證書，生成新的私鑰並請求新的證書。因爲kubelet請求將證書籤名做爲其引導序列的一部分，而且不斷對來自kubelet的證書籤名請求進行自動批准，所以整個集羣的可管理性將大幅提高。

 

9其餘更新

 

如下功能迎來穩定版：

• Seccomp

• Kubelet客戶端TLS證書輪換

• 限制節點對API的訪問

• 從新設計Event API

• Ingress進入V1穩定版

• Certificate Signing Request API

• 無需Docker構建 Kubelet

美國大學畢業證

重大變化：

• 節點拓撲管理器

• 新的端點API

• 將Kubernetes支持窗口延長到一年

 

其餘重要特性：

• 運行多個Scheduling Profiles

• Certificate Signing Request API

• 不可變Secrets 和ConfigMaps

http://www.sxyya.com

10Kubernetes 1.19版本logo

 

是大家激發了Kubernetes 1.19發佈標識的靈感！這個版本更像是一場馬拉松，它證實了當這個世界是一個荒蕪之地時，咱們能夠走到一塊兒，作一些難以想象的事情。