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

本文轉載自查看原文 2019-07-17 23:10 878 雲原生/ kubernetes/ Kubernetes

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

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

#492 : 前面是 GitHub issue 編號，后面是具體的特性

進度 : 表示該特性目前處於什么階段，如 Alpha，Beta，Stable

特性分類 : 表示該特性屬於哪個分類，如 API，CLI，Network 等。

這里是具體的特性介紹，例如改進了什么，為什么要這么做，有的特性還會有簡單的使用范例。

1. 核心功能

#1024 NodeLocal DNSCache

進度：邁向 Beta

特性分類：Network

NodeLocal DNSCache 通過在集群節點上以 Deamonset 的方式運行 DNS 緩存代理來提高集群的 DNS 性能，從而可以避免使用 iptables DNAT 規則和連接跟蹤。如果本地 DNS 緩存代理在內存中找不到相應的 DNS 記錄，就會向 kube-dns 服務發起查詢請求（默認情況下以 cluster.local 為后綴）。

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

#383 Redesign event API

進度：Alpha

特性分類：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 一樣具有相同的生命周期和工作流程。使用該特性時，需要注意以下事項：