原文連接:kubernetes 1.15 有哪些讓人眼前一亮的新特性?html
2019 年 6 月 20 日,Kubernetes 重磅發佈了 1.15 版本,不過筆者忙到如今纔有空認真來看一下到底更新了哪些東西。這一版本更新主要是針對穩定性的持續改善和可擴展性,仔細把 25 個新增或改動的功能看完後,發現許多之前的小痛點都在這個版本中解決了,本文對每一個特性的介紹格式以下:前端
#492 : 前面是 GitHub issue 編號,後面是具體的特性
進度 : 表示該特性目前處於什麼階段,如 Alpha,Beta,Stable
特性分類 : 表示該特性屬於哪一個分類,如 API,CLI,Network 等。node這裏是具體的特性介紹,例如改進了什麼,爲何要這麼作,有的特性還會有簡單的使用範例。git
進度:邁向 Betaes6
特性分類:Networkgithub
NodeLocal DNSCache 經過在集羣節點上以 Deamonset
的方式運行 DNS 緩存代理來提升集羣的 DNS 性能,從而能夠避免使用 iptables DNAT 規則和鏈接跟蹤。若是本地 DNS 緩存代理在內存中找不到相應的 DNS 記錄,就會向 kube-dns 服務發起查詢請求(默認狀況下以 cluster.local
爲後綴)。web
想了解該特性的更多細節能夠閱讀 Kubernetes Enhancement Proposal (KEP) 文檔中的設計說明。數據庫
進度:Alpha編程
特性分類:Scalabilityapi
這項工做主要有兩個目標:
目前 Event API 的主要問題是包含太多垃圾信息,致使其難以攝取和分析有效信息。除此以外還有數個性能問題,例如當集羣出現問題時,Events 可能會使 API server 過載(例如常見的 crashloop)
關於該 issue 的討論以及建議的解決方案和改進工做能夠參考這裏的設計提案。
進度:Beta
特性分類:API
Mutating 和 Validating Admission Webhook 已經成爲擴展 API 的主流選擇。在 1.15 之前,全部的 webhook 只會按照字母表順序調用一次,這樣就會致使一個問題:一個更早的 webhook 不能應對後面的 webhook 的更新,這可能會致使未知的問題,例如前面的 webhook 設置某個 pod 的啓動參數,而隨後的 webhook 將其更改或者移除了。
在 Kubernetes 1.15 中,容許 webhook 被重複調用,即便是對同一對象的修改。若是想啓用該特性,必需要確保你引入的任何 admission webhook 都是冪等操做,也就是說,同一個對象被執行任意屢次操做與執行一次操做產生的效果相同。
進度:Alpha
特性分類:Scheduling
該特性爲 Kubernetes 1.15 的調度器設計了一個新的可插拔結構,主要是爲了解決日益增長的定製化調度需求。Scheduler Framework 在原有的 Priority/Predicates 接口的基礎上增長了 reserve, pre-bind 等十幾個接口。
下圖顯示了 Pod 在新的 Scheduling framework 中的調度過程:
關於該特性的更多信息請查閱官方設計文檔。
進度:邁向 Beta
特性分類:Node
該特性容許 Kubelet 將容器 binding
信息暴露給第三方監控插件,這樣系統管理員就可使用第三方的設備監控代理來監控自定義資源分配給 Pod 的使用率(例如,每一個 Pod 的 GPU
使用率)。
未解耦前,Kubelet 會檢測全部支持的設備是否存在,即便節點並無安裝該設備。
使用新的框架以後,Kubelet 會經過 /var/lib/kubelet/pod-resources/kubelet.sock
提供一個新的 GRPC 服務,該服務會把容器和設備所分配到資源相關的信息都暴露出來。
進度:邁向 Beta
特性分類:Node
Pid
是 Linux 系統中很重要的資源,系統很容易在 CPU 或內存的使用量還沒達到上限以前,進程數量就達到了上限。所以管理員必須得想辦法確保 Pod 不會把系統的 Pid 用完,進而形成其餘重要的服務沒法運行(例如,container runtime,kubelet 等)。
新的特性容許修改 Kubelet 配置來限制每一個 Pod 的 Pid 數量。在 Node 層面限制 Pid 的功能如今能夠直接使用,再也不須要經過 feature gate 的參數 SupportNodePidsLimit=true
顯示設置。
Kubernetes 官方博客有對此特性的詳細介紹。
進度:Alpha
特性分類:Scheduling
Kubernetes 1.15 在 PriorityClass 中添加 PreemptionPolicy
字段做爲 Alpha 特性。
PreemptionPolicy
字段的默認值爲 PreemptLowerPriority
,表示容許該優先級的 Pod 搶佔低優先級的 Pod(這是默認的搶佔行爲)。若是 PreemptionPolicy
字段的值爲 Never
,則該 Pod 會被放置到調度隊列中,而且放置的位置排在低優先級 Pod 的前面,可是不能搶佔其餘的 Pod。
以數據科學領域爲例:用戶提交了一個 job,他但願此 job 的優先級比其餘 job 高,可是不但願由於搶佔 Pod 而致使目前的任務被擱置。
進度:Stable
特性分類:Architecture
自從 Kubernetes 開源以來,一直使用 godep 來 vendoring 全部依賴庫。隨着 Go 生態系統愈來愈成熟,vendoring 已經變成主流,而 godep 已經再也不維護了,因而 Kubernetes 一開始使用 godep 的定製版,這期間還有一些其餘的 vendoring 工具(例如 glide
和 dep
)也跟着出現,而如今 Go 的依賴庫管理終於能夠以 go module 的形式直接添加到 Go 中。
Go 從 1.13 已經默認開啓 go module,而且移除了 $GOPATH
模式。爲了支持這個改動,Kubernetes 1.15 版本調整了好幾個組件的代碼以使用 go module。
進度:Alpha
特性分類:API
一個 Kubernetes 集羣只會保留一段時間內的變動歷史記錄,好比使用 etcd3 的集羣默認會保留 5 分鐘的變動歷史記錄。而爲 Kubernetes Watch 事件添加一個書籤(bookmark
)能夠想象成多了一個檢測點,全部 Client 請求的對象若是符合預先想查找的資源版本(resourceVersion)就會被這個書籤給篩選出來。
例如:新增一個 Watch 的請求去查找全部資源版本爲 X 的事件,這時 API server 知道該 Watch 請求對其餘資源版本的事件沒有興趣,就會使用書籤來略過全部其餘事件,只將特定的事件發送給客戶端,從而避免增長 API server 的負載。
進度:Alpha
特性分類:storage
ExecutionHook 提供了一種通用機制,讓用戶能夠在容器中觸發想要執行的 hook 命令,例如:
hook 的定義中包含兩條重要信息:
Pod Selector
)下面提供一個簡單示例:
想了解該特性的更多細節能夠閱讀 Kubernetes Enhancement Proposal (KEP) 文檔中的設計說明。
進度:邁向 Beta
特性分類:Apps
Pod Disruption Budget (PDB) 是一種 Kubernetes API,用於限制在同一時間自願中斷的應用程序(如 Deployment 或 ReplicaSet)中宕機的 Pod 的數量。PDB 能夠經過指定最小可用數量或最大不可用數量的 Pod 來自定義中斷預算。
例如,對於一個無狀態的前端應用:
minAvailable 90%
值的 PDB使用 PDB 後,就能夠容許管理員在不下降服務的可用性和性能的前提下操做 Kubernetes 的工做負載。
進度:Beta
特性分類:API
該特性沒有什麼實質性的功能,只是把在 Kubernetes 1.15 版本中跟 CRD 相關的修復和改進進行了分組:
進度:邁向 Beta
特性分類:API
該特性容許開發者使用 OpenAPI v3 schema 來定義 Custom Resource Definition (CRD) ,以便開啓 Server 端對 CustomResources (CR) 的驗證。
發佈使用 OpenAPI 規範的 CRD 即可以開啓客戶端驗證(例如 kubectl create
和 kubectl apply
時),也能夠對規範進行描述(例如 kubectl explain
),Client 也會由於 CRs 而自動生成,因此開發者能夠輕易使用任何支持的編程語言來和 API 進行交互。
使用 OpenAPI 規範有助於使 CRD 開發者和 Kubernetes API 的發展方向更加清晰,文檔格式更加簡潔精煉。
進度:Alpha
特性分類:API
下面的這兩個特性主要是爲了使與 CRD 相關的 JSON 處理更加方便。
Pruning : CRD 傳統的存儲方式是以 JSON 格式存儲在 ETCD 中。如今若是它是以 OpenAPI v3 的規範來定義的,而且 preserveUnknownFields
的值爲 false,未被定義的字段在建立或更新時便會被刪除。
Defaulting : 此特性在 Kubernetes 1.15 版本處於 Alpha 階段,默認處於關閉狀態,能夠經過 feature gate 的參數 CustomResourceDefaulting
來開啓。Defaulting 和 Pruning 同樣,在一開始就要將規範定好,不符合規範的就會被去掉。
進度:邁向 Beta
特性分類:API
不一樣的 CRD 版本能夠有不一樣的規範,如今你能夠在操做中處理不一樣版本之間的轉換,而且實現了版本轉換的 webhook。這個 webhook 會在下面幾種狀況下被調用:
PUT
請求自定義資源時,發現請求的版本與存儲的版本不一致這裏有一個實現自定義資源之間相互轉換的 webhook server 的示例,你們能夠做爲參考。
進度:邁向 Stable
特性分類:Cli
目前已經可使用 kubectl get
和 describe
來讓第三方 API 擴展和 CRD 提供自定義格式化輸出。該特性使輸出能夠打印到服務器端,從而實現了更好的擴展性,而且讓 Kubectl 和擴展的實現細節進行解耦。
想了解關於該特性的更多詳細信息,能夠查閱相關設計文檔。
進度:邁向 Beta
特性分類:Cluster lifecycle
隨着時間的推移,在 kubeadm 的配置文件中配置 Kubernetes 集羣建立時的選項數量已經大大增長,而後 CLI 參數的數量仍是沒有變化,因此致使使用配置文件來建立集羣是目前惟一一個比較符合使用者需求方法。
該特性的目標是從新設計配置的存儲方式來改善當前版本遇到的問題,並放棄了使用包含全部選項的單個配置文件,使用子結構來爲高可用集羣提供更好的支持。
進度:邁向 Beta
特性分類:Cluster lifecycle
Kubernetes 能夠經過多個控制平面來提供高可用性。kubeadm 工具如今能夠用來建立高可用集羣,有兩種方式:
這個版本的 kubeadm 將會自動複製其中須要的證書,減小人爲干預的需求,目前的作法是使用一個暫時加密的祕鑰來確保證書在傳輸過程當中的安全性,更多細節能夠參考 KEP 文檔。
進度:邁向 Beta
特性分類:AWS
在 Kubernetes 1.15 中能夠經過 annotations
的方式,在 Service 的種類是 LoadBalancer 時,直接請求創建 AWS NLB:
與經典的彈性負載均衡器不一樣,Network Load Balancers (NLBs) 會把客戶端的 IP 直接傳遞給節點。AWS NLB 其實從 1.9 的時候就已經處於 Alpha 階段,如今代碼和 API 都已經相對穩定,因此準備遷移到 Beta 階段。
進度:Alpha
特性分類:Network
默認狀況下,雲服務商提供的 Load Balancer 資源,應該要在 Kubernetes Service 被刪除的時候也跟着一塊兒被刪除纔對,然而在各類極端的案例中,能夠發如今刪除關聯的 Kubernetes Service 後,Load Balancer 資源卻被孤立在一旁沒有被清除掉,而引入 Finalizer
就是爲了預防這種狀況的發生。
若是你的集羣已經開啓了和雲服務商的整合,Finalizer 將會附加到任何包含 type=LoadBalancer
字段的 Kubernetes Service,當這類 Service 即將被刪除時,Finalizer 會先將 Serivce 的刪除動做給凍結住,直接確保 Load Balancer 資源被清除後,纔會將 Service 真正刪除。
進度:Alpha
特性分類:Storage
存儲插件最初都在 Kubernetes 的基礎代碼庫中,增長了代碼維護的複雜性,也阻礙了其擴展性。所以該特性的目標是將全部存儲相關的代碼移出來變成可加裝的插件形式,並經過 Container Storage Interface(CSI)來和 Kubernetes 進行交互。如此一來即可下降開發的成本,並使其更加模塊化,可擴展性更強,讓不一樣版本的存儲插件與 Kubernetes 之間有更好的兼容性。想了解該特性的最新進展能夠參考這裏。
進度:Alpha
特性分類:Storage
該特性可讓使用者複製現有的 PV。複製和備份其實仍是不太同樣的,複製會產生一個新的且內容和原來徹底同樣的存儲卷。複製既有的 PV 會消耗用戶的存儲卷配額,而且會遵循和其餘存儲卷建立時同樣的建立和檢查流程,複製出來的 PV 也和普通的 PV 同樣具備相同的生命週期和工做流程。使用該特性時,須要注意如下事項:
VolumePVCDataSource
參數僅適用於 CSI Driver。進度:Alpha
特性分類:Node
目前限制臨時存儲卷使用量的機制是按期遍歷查看每一個臨時存儲卷的大小,這種作法很慢,具備很高的延遲。該特性中提出的機制利用文件系統的 Project Quota 來監控資源消耗程度,而後再決定要不要限制其使用量。但願可以實現如下目標:
如此一來即可以經過 Project Quota 來限制每個存儲卷的使用量。
進度:邁向 Beta
特性分類:Storage
該特性讓使用者能夠經過修改 PVC 來在線擴展存儲卷使用到的文件系統,而不須要重啓使用到該存儲卷的 PVC。在線擴展 PVC 的功能目前還處於 Beta 階段,且默認是開啓的,你也能夠經過 feature gate 參數 ExpandInUsePersistentVolumes
顯示開啓。
文件系統的擴展行爲會在如下狀況下被觸發:
關於該特性的更多消息信息請參考 Kubernetes 官方文檔。
進度:邁向 Beta
特性分類:Storage
目前 Kubernetes 對於掛載節點本地存儲卷的支持有一個限制:若是有大於等於兩個 Pod 運行在同一個節點上,同時把相同的 log 文件名稱寫入相同的存儲卷會致使這些 Pod 發生衝突。
使用 subPath 是個不錯的選擇,但 subPath 目前只能寫死,沒法提供靈活性。以前的解決辦法是建立一個帶有掛載路徑的軟連接的 Sidecar 容器。
爲了更方便地解決這個問題,如今提出了向 subPath 中添加環境變量來緩和這個限制,參考如下示例:
也能夠寫成這種格式:
本文除了告知讀者 Kubernetes 1.15 有什麼新特性以外,更重要的在於提供了一個機會去了解 Kubernetes 這麼龐大的系統在跟第三方整合或是某個組件的性能遇到瓶頸時該怎麼解決,爲咱們之後設計架構時提供了參考依據。