kubernetes 1.15 有哪些讓人眼前一亮的新特性？

時間 2019-11-06

標籤 kubernetes 1.15 哪些讓人眼前亮的特性简体版

原文原文鏈接

> 原文連接：kubernetes 1.15 有哪些讓人眼前一亮的新特性？html

2019 年 6 月 20 日，Kubernetes 重磅發佈了 1.15 版本，不過筆者忙到如今纔有空認真來看一下到底更新了哪些東西。這一版本更新主要是針對穩定性的持續改善和可擴展性，仔細把 25 個新增或改動的功能看完後，發現許多之前的小痛點都在這個版本中解決了，本文對每一個特性的介紹格式以下：前端

> #492 : 前面是 GitHub issue 編號，後面是具體的特性<br> > 進度 : 表示該特性目前處於什麼階段，如 Alpha，Beta，Stable<br> > 特性分類 : 表示該特性屬於哪一個分類，如 API，CLI，Network 等。<br> > > 這裏是具體的特性介紹，例如改進了什麼，爲何要這麼作，有的特性還會有簡單的使用範例。git

1. 核心功能

#1024 NodeLocal DNSCache

進度：邁向 Betagithub

特性分類：Networkweb

NodeLocal DNSCache 經過在集羣節點上以 Deamonset 的方式運行 DNS 緩存代理來提升集羣的 DNS 性能，從而能夠避免使用 iptables DNAT 規則和鏈接跟蹤。若是本地 DNS 緩存代理在內存中找不到相應的 DNS 記錄，就會向 kube-dns 服務發起查詢請求（默認狀況下以 cluster.local 爲後綴）。數據庫

想了解該特性的更多細節能夠閱讀 Kubernetes Enhancement Proposal (KEP) 文檔中的設計說明。編程

#383 Redesign event API

進度：Alphaapi

特性分類：Scalability緩存

這項工做主要有兩個目標：安全

減小 Events 對集羣其他部分的性能影響；
向 Event 對象添加更多的數據結構，這是使 Event 分析自動化的必要步驟，也是第一步。

目前 Event API 的主要問題是包含太多垃圾信息，致使其難以攝取和分析有效信息。除此以外還有數個性能問題，例如當集羣出現問題時，Events 可能會使 API server 過載（例如常見的 crashloop）

關於該 issue 的討論以及建議的解決方案和改進工做能夠參考這裏的設計提案。

#492 Admission webhook

進度：Beta

特性分類：API

Mutating 和 Validating Admission Webhook 已經成爲擴展 API 的主流選擇。在 1.15 之前，全部的 webhook 只會按照字母表順序調用一次，這樣就會致使一個問題：一個更早的 webhook 不能應對後面的 webhook 的更新，這可能會致使未知的問題，例如前面的 webhook 設置某個 pod 的啓動參數，而隨後的 webhook 將其更改或者移除了。

在 Kubernetes 1.15 中，容許 webhook 被重複調用，即便是對同一對象的修改。若是想啓用該特性，必需要確保你引入的任何 admission webhook 都是冪等操做，也就是說，同一個對象被執行任意屢次操做與執行一次操做產生的效果相同。

#624 Scheduling framework

進度：Alpha

特性分類：Scheduling

該特性爲 Kubernetes 1.15 的調度器設計了一個新的可插拔結構，主要是爲了解決日益增長的定製化調度需求。Scheduler Framework 在原有的 Priority/Predicates 接口的基礎上增長了 reserve, pre-bind 等十幾個接口。

下圖顯示了 Pod 在新的 Scheduling framework 中的調度過程：

關於該特性的更多信息請查閱官方設計文檔。

#606 Support 3rd party device monitoring plugins

進度：邁向 Beta

特性分類：Node

該特性容許 Kubelet 將容器 binding 信息暴露給第三方監控插件，這樣系統管理員就可使用第三方的設備監控代理來監控自定義資源分配給 Pod 的使用率（例如，每一個 Pod 的 GPU 使用率）。

未解耦前，Kubelet 會檢測全部支持的設備是否存在，即便節點並無安裝該設備。

使用新的框架以後，Kubelet 會經過 /var/lib/kubelet/pod-resources/kubelet.sock 提供一個新的 GRPC 服務，該服務會把容器和設備所分配到資源相關的信息都暴露出來。

#757 Pid limiting

進度：邁向 Beta

特性分類：Node

Pid 是 Linux 系統中很重要的資源，系統很容易在 CPU 或內存的使用量還沒達到上限以前，進程數量就達到了上限。所以管理員必須得想辦法確保 Pod 不會把系統的 Pid 用完，進而形成其餘重要的服務沒法運行（例如，container runtime，kubelet 等）。

新的特性容許修改 Kubelet 配置來限制每一個 Pod 的 Pid 數量。在 Node 層面限制 Pid 的功能如今能夠直接使用，再也不須要經過 feature gate 的參數 SupportNodePidsLimit=true 顯示設置。

Kubernetes 官方博客有對此特性的詳細介紹。

#902 Add non-preempting option to PriorityClasses

進度：Alpha

特性分類：Scheduling

Kubernetes 1.15 在 PriorityClass 中添加 PreemptionPolicy 字段做爲 Alpha 特性。

PreemptionPolicy 字段的默認值爲 PreemptLowerPriority，表示容許該優先級的 Pod 搶佔低優先級的 Pod（這是默認的搶佔行爲）。若是 PreemptionPolicy 字段的值爲 Never，則該 Pod 會被放置到調度隊列中，而且放置的位置排在低優先級 Pod 的前面，可是不能搶佔其餘的 Pod。

以數據科學領域爲例：用戶提交了一個 job，他但願此 job 的優先級比其餘 job 高，可是不但願由於搶佔 Pod 而致使目前的任務被擱置。

#917 Add go module support to k8s.io/kubernetes

進度：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。

#956 Add Watch bookmarks support

進度：Alpha

特性分類：API

一個 Kubernetes 集羣只會保留一段時間內的變動歷史記錄，好比使用 etcd3 的集羣默認會保留 5 分鐘的變動歷史記錄。而爲 Kubernetes Watch 事件添加一個書籤（bookmark）能夠想象成多了一個檢測點，全部 Client 請求的對象若是符合預先想查找的資源版本（resourceVersion）就會被這個書籤給篩選出來。

例如：新增一個 Watch 的請求去查找全部資源版本爲 X 的事件，這時 API server 知道該 Watch 請求對其餘資源版本的事件沒有興趣，就會使用書籤來略過全部其餘事件，只將特定的事件發送給客戶端，從而避免增長 API server 的負載。

#962 Execution hooks

進度：Alpha

特性分類：storage

ExecutionHook 提供了一種通用機制，讓用戶能夠在容器中觸發想要執行的 hook 命令，例如：

應用程序備份
升級
數據庫遷移
從新加載配置文件
重啓容器

hook 的定義中包含兩條重要信息：

須要執行什麼命令
在哪執行命令（經過 Pod Selector）

下面提供一個簡單示例：

想了解該特性的更多細節能夠閱讀 Kubernetes Enhancement Proposal (KEP) 文檔中的設計說明。

#981 PDB support for custom resources with scale subresource

進度：邁向 Beta

特性分類：Apps

Pod Disruption Budget (PDB) 是一種 Kubernetes API，用於限制在同一時間自願中斷的應用程序（如 Deployment 或 ReplicaSet）中宕機的 Pod 的數量。PDB 能夠經過指定最小可用數量或最大不可用數量的 Pod 來自定義中斷預算。

例如，對於一個無狀態的前端應用：

要求：服務能力不能減小超過 10%
解決方案：使用一個包含 minAvailable 90% 值的 PDB

使用 PDB 後，就能夠容許管理員在不下降服務的可用性和性能的前提下操做 Kubernetes 的工做負載。

2. 自定義資源

#95 CustomResourceDefinitions

進度：Beta

特性分類：API

該特性沒有什麼實質性的功能，只是把在 Kubernetes 1.15 版本中跟 CRD 相關的修復和改進進行了分組：

#692 Publish CRD OpenAPI schema

進度：邁向 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 的發展方向更加清晰，文檔格式更加簡潔精煉。

#575 Defaulting and pruning for custom resources

進度：Alpha

特性分類：API

下面的這兩個特性主要是爲了使與 CRD 相關的 JSON 處理更加方便。

Pruning : CRD 傳統的存儲方式是以 JSON 格式存儲在 ETCD 中。如今若是它是以 OpenAPI v3 的規範來定義的，而且 preserveUnknownFields 的值爲 false，未被定義的字段在建立或更新時便會被刪除。

Defaulting : 此特性在 Kubernetes 1.15 版本處於 Alpha 階段，默認處於關閉狀態，能夠經過 feature gate 的參數 CustomResourceDefaulting 來開啓。Defaulting 和 Pruning 同樣，在一開始就要將規範定好，不符合規範的就會被去掉。

#598 Webhook conversion for custom resources

進度：邁向 Beta

特性分類：API

不一樣的 CRD 版本能夠有不一樣的規範，如今你能夠在操做中處理不一樣版本之間的轉換，而且實現了版本轉換的 webhook。這個 webhook 會在下面幾種狀況下被調用：

請求的自定義資源版本與原來儲存的版本不一致
自定義資源在 Watch 時建立了某一版本，但在下次修改時發現跟存儲的版本不一致
使用 PUT 請求自定義資源時，發現請求的版本與存儲的版本不一致

這裏有一個實現自定義資源之間相互轉換的 webhook server 的示例，你們能夠做爲參考。

3. 配置管理

#515 Kubectl get and describe should work well with extensions

進度：邁向 Stable

特性分類：Cli

目前已經可使用 kubectl get 和 describe 來讓第三方 API 擴展和 CRD 提供自定義格式化輸出。該特性使輸出能夠打印到服務器端，從而實現了更好的擴展性，而且讓 Kubectl 和擴展的實現細節進行解耦。

想了解關於該特性的更多詳細信息，能夠查閱相關設計文檔。

#970 Kubeadm: New v1beta2 config format

進度：邁向 Beta

特性分類：Cluster lifecycle

隨着時間的推移，在 kubeadm 的配置文件中配置 Kubernetes 集羣建立時的選項數量已經大大增長，而後 CLI 參數的數量仍是沒有變化，因此致使使用配置文件來建立集羣是目前惟一一個比較符合使用者需求方法。

該特性的目標是從新設計配置的存儲方式來改善當前版本遇到的問題，並放棄了使用包含全部選項的單個配置文件，使用子結構來爲高可用集羣提供更好的支持。

#357 Ability to create dynamic HA clusters with kubeadm

進度：邁向 Beta

特性分類：Cluster lifecycle

Kubernetes 能夠經過多個控制平面來提供高可用性。kubeadm 工具如今能夠用來建立高可用集羣，有兩種方式：

etcd 與 Control Plane 節點 (Master) 共存
etcd 與 Control Plane 節點 (Master) 是分開的

這個版本的 kubeadm 將會自動複製其中須要的證書，減小人爲干預的需求，目前的作法是使用一個暫時加密的祕鑰來確保證書在傳輸過程當中的安全性，更多細節能夠參考 KEP 文檔。

4. 雲供應商

#423 Support AWS network load balancer

進度：邁向 Beta

特性分類：AWS

在 Kubernetes 1.15 中能夠經過 annotations 的方式，在 Service 的種類是 LoadBalancer 時，直接請求創建 AWS NLB：

與經典的彈性負載均衡器不一樣，Network Load Balancers (NLBs) 會把客戶端的 IP 直接傳遞給節點。AWS NLB 其實從 1.9 的時候就已經處於 Alpha 階段，如今代碼和 API 都已經相對穩定，因此準備遷移到 Beta 階段。

#980 Finalizer protection for service LoadBalancers

進度：Alpha

特性分類：Network

默認狀況下，雲服務商提供的 Load Balancer 資源，應該要在 Kubernetes Service 被刪除的時候也跟着一塊兒被刪除纔對，然而在各類極端的案例中，能夠發如今刪除關聯的 Kubernetes Service 後，Load Balancer 資源卻被孤立在一旁沒有被清除掉，而引入 Finalizer 就是爲了預防這種狀況的發生。

若是你的集羣已經開啓了和雲服務商的整合，Finalizer 將會附加到任何包含 type=LoadBalancer 字段的 Kubernetes Service，當這類 Service 即將被刪除時，Finalizer 會先將 Serivce 的刪除動做給凍結住，直接確保 Load Balancer 資源被清除後，纔會將 Service 真正刪除。

5. 存儲

#625 In-tree storage plugin to CSI Driver Migration

進度：Alpha

特性分類：Storage

存儲插件最初都在 Kubernetes 的基礎代碼庫中，增長了代碼維護的複雜性，也阻礙了其擴展性。所以該特性的目標是將全部存儲相關的代碼移出來變成可加裝的插件形式，並經過 Container Storage Interface（CSI）來和 Kubernetes 進行交互。如此一來即可下降開發的成本，並使其更加模塊化，可擴展性更強，讓不一樣版本的存儲插件與 Kubernetes 之間有更好的兼容性。想了解該特性的最新進展能夠參考這裏。

#989 Extend allowed PVC DataSources

進度：Alpha

特性分類：Storage

該特性可讓使用者複製現有的 PV。複製和備份其實仍是不太同樣的，複製會產生一個新的且內容和原來徹底同樣的存儲卷。複製既有的 PV 會消耗用戶的存儲卷配額，而且會遵循和其餘存儲卷建立時同樣的建立和檢查流程，複製出來的 PV 也和普通的 PV 同樣具備相同的生命週期和工做流程。使用該特性時，須要注意如下事項：