kubernetes1.15有哪些新特性

本篇內(nèi)容主要講解“kubernetes1.15有哪些新特性”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“kubernetes1.15有哪些新特性”吧!

1. 核心功能

#1024 NodeLocal DNSCache

進(jìn)度：邁向 Beta

特性分類：Network

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

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

#383 Redesign event API

進(jìn)度：Alpha

特性分類：Scalability

這項(xiàng)工作主要有兩個目標(biāo)：

1. 減少 Events 對集群其余部分的性能影響；

2. 向 Event 對象添加更多的數(shù)據(jù)結(jié)構(gòu)，這是使 Event 分析自動化的必要步驟，也是第一步。

目前 Event API 的主要問題是包含太多垃圾信息，導(dǎo)致其難以攝取和分析有效信息。除此之外還有數(shù)個性能問題，例如當(dāng)集群出現(xiàn)問題時(shí)，Events 可能會使 API server 過載（例如常見的 crashloop）

關(guān)于該 issue 的討論以及建議的解決方案和改進(jìn)工作可以參考這里的設(shè)計(jì)提案。

#492 Admission webhook

進(jìn)度：Beta

特性分類：API

Mutating 和 Validating Admission Webhook 已經(jīng)成為擴(kuò)展 API 的主流選擇。在 1.15 以前，所有的 webhook 只會按照字母表順序調(diào)用一次，這樣就會導(dǎo)致一個問題：一個更早的 webhook 不能應(yīng)對后面的 webhook 的更新，這可能會導(dǎo)致未知的問題，例如前面的 webhook 設(shè)置某個 pod 的啟動參數(shù)，而隨后的 webhook 將其更改或者移除了。

在 Kubernetes 1.15 中，允許 webhook 被重復(fù)調(diào)用，即使是對同一對象的修改。如果想啟用該特性，必須要確保你引入的任何 admission webhook 都是冪等操作，也就是說，同一個對象被執(zhí)行任意多次操作與執(zhí)行一次操作產(chǎn)生的效果相同。

#624 Scheduling framework

進(jìn)度：Alpha

特性分類：Scheduling

該特性為 Kubernetes 1.15 的調(diào)度器設(shè)計(jì)了一個新的可插拔結(jié)構(gòu)，主要是為了解決日益增加的定制化調(diào)度需求。Scheduler Framework 在原有的 Priority/Predicates 接口的基礎(chǔ)上增加了 reserve, pre-bind 等十幾個接口。

下圖顯示了 Pod 在新的 Scheduling framework 中的調(diào)度過程：

關(guān)于該特性的更多信息請查閱官方設(shè)計(jì)文檔。

#606 Support 3rd party device monitoring plugins

進(jìn)度：邁向 Beta

特性分類：Node

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

未解耦前，Kubelet 會檢測所有支持的設(shè)備是否存在，即使節(jié)點(diǎn)并沒有安裝該設(shè)備。

使用新的框架之后，Kubelet 會通過 /var/lib/kubelet/pod-resources/kubelet.sock 提供一個新的 GRPC 服務(wù)，該服務(wù)會把容器和設(shè)備所分配到資源相關(guān)的信息都暴露出來。

#757 Pid limiting

進(jìn)度：邁向 Beta

特性分類：Node

Pid 是 Linux 系統(tǒng)中很重要的資源，系統(tǒng)很容易在 CPU 或內(nèi)存的使用量還沒達(dá)到上限之前，進(jìn)程數(shù)量就達(dá)到了上限。因此管理員必須得想辦法確保 Pod 不會把系統(tǒng)的 Pid 用完，進(jìn)而造成其他重要的服務(wù)無法運(yùn)行（例如，container runtime，kubelet 等）。

新的特性允許修改 Kubelet 配置來限制每個 Pod 的 Pid 數(shù)量。在 Node 層面限制 Pid 的功能現(xiàn)在可以直接使用，不再需要通過 feature gate 的參數(shù) SupportNodePidsLimit=true 顯示設(shè)置。

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

#902 Add non-preempting option to PriorityClasses

進(jìn)度：Alpha

特性分類：Scheduling

Kubernetes 1.15 在 PriorityClass 中添加 PreemptionPolicy 字段作為 Alpha 特性。

PreemptionPolicy 字段的默認(rèn)值為 PreemptLowerPriority，表示允許該優(yōu)先級的 Pod 搶占低優(yōu)先級的 Pod（這是默認(rèn)的搶占行為）。如果 PreemptionPolicy 字段的值為 Never，則該 Pod 會被放置到調(diào)度隊(duì)列中，并且放置的位置排在低優(yōu)先級 Pod 的前面，但是不能搶占其他的 Pod。

以數(shù)據(jù)科學(xué)領(lǐng)域?yàn)槔河脩籼峤涣艘粋€ job，他希望此 job 的優(yōu)先級比其他 job 高，但是不希望因?yàn)閾屨?Pod 而導(dǎo)致目前的任務(wù)被擱置。

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

進(jìn)度：Stable

特性分類：Architecture

自從 Kubernetes 開源以來，一直使用 godep 來 vendoring 所有依賴庫。隨著 Go 生態(tài)系統(tǒng)越來越成熟，vendoring 已經(jīng)變成主流，而 godep 已經(jīng)不再維護(hù)了，于是 Kubernetes 一開始使用 godep 的定制版，這期間還有一些其他的 vendoring 工具（例如 glide 和 dep）也跟著出現(xiàn)，而現(xiàn)在 Go 的依賴庫管理終于可以以 go module 的形式直接添加到 Go 中。

Go 從 1.13 已經(jīng)默認(rèn)開啟 go module，并且移除了 $GOPATH 模式。為了支持這個改動，Kubernetes 1.15 版本調(diào)整了好幾個組件的代碼以使用 go module。

#956 Add Watch bookmarks support

進(jìn)度：Alpha

特性分類：API

一個 Kubernetes 集群只會保留一段時(shí)間內(nèi)的變更歷史記錄，比如使用 etcd3 的集群默認(rèn)會保留 5 分鐘的變更歷史記錄。而為 Kubernetes Watch 事件添加一個書簽（bookmark）可以想象成多了一個檢測點(diǎn)，所有 Client 請求的對象如果符合預(yù)先想查找的資源版本（resourceVersion）就會被這個書簽給篩選出來。

例如：新增一個 Watch 的請求去查找所有資源版本為 X 的事件，這時(shí) API server 知道該 Watch 請求對其他資源版本的事件沒有興趣，就會使用書簽來略過所有其他事件，只將特定的事件發(fā)送給客戶端，從而避免增加 API server 的負(fù)載。

#962 Execution hooks

進(jìn)度：Alpha

特性分類：storage

ExecutionHook 提供了一種通用機(jī)制，讓用戶可以在容器中觸發(fā)想要執(zhí)行的 hook 命令，例如：

• 應(yīng)用程序備份

• 升級

• 數(shù)據(jù)庫遷移

• 重新加載配置文件

• 重啟容器

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

1. 需要執(zhí)行什么命令

2. 在哪執(zhí)行命令（通過 Pod Selector）

下面提供一個簡單示例：

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

#981 PDB support for custom resources with scale subresource

進(jìn)度：邁向 Beta

特性分類：Apps

Pod Disruption Budget (PDB) 是一種 Kubernetes API，用于限制在同一時(shí)間自愿中斷的應(yīng)用程序（如 Deployment 或 ReplicaSet）中宕機(jī)的 Pod 的數(shù)量。PDB 可以通過指定最小可用數(shù)量或最大不可用數(shù)量的 Pod 來自定義中斷預(yù)算。

例如，對于一個無狀態(tài)的前端應(yīng)用：

• 要求：服務(wù)能力不能減少超過 10%

• 解決方案：使用一個包含 minAvailable 90% 值的 PDB

使用 PDB 后，就可以允許管理員在不降低服務(wù)的可用性和性能的前提下操作 Kubernetes 的工作負(fù)載。

2. 自定義資源

#95 CustomResourceDefinitions

進(jìn)度：Beta

特性分類：API

該特性沒有什么實(shí)質(zhì)性的功能，只是把在 Kubernetes 1.15 版本中跟 CRD 相關(guān)的修復(fù)和改進(jìn)進(jìn)行了分組：

• Structural schema using OpenAPI

• CRD pruning

• CRD defaulting

• Webhook conversion moved to beta

• Publishing the CRD OpenAPI schema

#692 Publish CRD OpenAPI schema

進(jìn)度：邁向 Beta

特性分類：API

該特性允許開發(fā)者使用 OpenAPI v3 schema 來定義 Custom Resource Definition (CRD) ，以便開啟 Server 端對 CustomResources (CR) 的驗(yàn)證。

發(fā)布使用 OpenAPI 規(guī)范的 CRD 便可以開啟客戶端驗(yàn)證（例如 kubectl create 和 kubectl apply 時(shí)），也可以對規(guī)范進(jìn)行描述（例如 kubectl explain），Client 也會因?yàn)?CRs 而自動生成，所以開發(fā)者可以輕易使用任何支持的編程語言來和 API 進(jìn)行交互。

使用 OpenAPI 規(guī)范有助于使 CRD 開發(fā)者和 Kubernetes API 的發(fā)展方向更加清晰，文檔格式更加簡潔精煉。

#575 Defaulting and pruning for custom resources

進(jìn)度：Alpha

特性分類：API

下面的這兩個特性主要是為了使與 CRD 相關(guān)的 JSON 處理更加方便。

Pruning : CRD 傳統(tǒng)的存儲方式是以 JSON 格式存儲在 ETCD 中?，F(xiàn)在如果它是以 OpenAPI v3 的規(guī)范來定義的，并且 preserveUnknownFields 的值為 false，未被定義的字段在創(chuàng)建或更新時(shí)便會被刪除。

Defaulting : 此特性在 Kubernetes 1.15 版本處于 Alpha 階段，默認(rèn)處于關(guān)閉狀態(tài)，可以通過 feature gate 的參數(shù) CustomResourceDefaulting 來開啟。Defaulting 和 Pruning 一樣，在一開始就要將規(guī)范定好，不符合規(guī)范的就會被去掉。

#598 Webhook conversion for custom resources

進(jìn)度：邁向 Beta

特性分類：API

不同的 CRD 版本可以有不同的規(guī)范，現(xiàn)在你可以在操作中處理不同版本之間的轉(zhuǎn)換，并且實(shí)現(xiàn)了版本轉(zhuǎn)換的 webhook。這個 webhook 會在下面幾種情況下被調(diào)用：

• 請求的自定義資源版本與原來儲存的版本不一致

• 自定義資源在 Watch 時(shí)創(chuàng)建了某一版本，但在下次修改時(shí)發(fā)現(xiàn)跟存儲的版本不一致

• 使用 PUT 請求自定義資源時(shí)，發(fā)現(xiàn)請求的版本與存儲的版本不一致

這里有一個實(shí)現(xiàn)自定義資源之間相互轉(zhuǎn)換的 webhook server 的示例，大家可以作為參考。

3. 配置管理

#515 Kubectl get and describe should work well with extensions

進(jìn)度：邁向 Stable

特性分類：Cli

目前已經(jīng)可以使用 kubectl get 和 describe 來讓第三方 API 擴(kuò)展和 CRD 提供自定義格式化輸出。該特性使輸出可以打印到服務(wù)器端，從而實(shí)現(xiàn)了更好的擴(kuò)展性，并且讓 Kubectl 和擴(kuò)展的實(shí)現(xiàn)細(xì)節(jié)進(jìn)行解耦。

想了解關(guān)于該特性的更多詳細(xì)信息，可以查閱相關(guān)設(shè)計(jì)文檔。

#970 Kubeadm: New v1beta2 config format

進(jìn)度：邁向 Beta

特性分類：Cluster lifecycle

隨著時(shí)間的推移，在 kubeadm 的配置文件中配置 Kubernetes 集群創(chuàng)建時(shí)的選項(xiàng)數(shù)量已經(jīng)大大增加，然后 CLI 參數(shù)的數(shù)量還是沒有變化，所以導(dǎo)致使用配置文件來創(chuàng)建集群是目前唯一一個比較符合使用者需求方法。

該特性的目標(biāo)是重新設(shè)計(jì)配置的存儲方式來改善當(dāng)前版本遇到的問題，并放棄了使用包含所有選項(xiàng)的單個配置文件，使用子結(jié)構(gòu)來為高可用集群提供更好的支持。

#357 Ability to create dynamic HA clusters with kubeadm

進(jìn)度：邁向 Beta

特性分類：Cluster lifecycle

Kubernetes 可以通過多個控制平面來提供高可用性。kubeadm 工具現(xiàn)在可以用來創(chuàng)建高可用集群，有兩種方式：

• etcd 與 Control Plane 節(jié)點(diǎn) (Master) 共存

• etcd 與 Control Plane 節(jié)點(diǎn) (Master) 是分開的

這個版本的 kubeadm 將會自動復(fù)制其中需要的證書，減少人為干預(yù)的需求，目前的做法是使用一個暫時(shí)加密的秘鑰來確保證書在傳輸過程中的安全性，更多細(xì)節(jié)可以參考 KEP 文檔。

4. 云供應(yīng)商

#423 Support AWS network load balancer

進(jìn)度：邁向 Beta

特性分類：AWS

在 Kubernetes 1.15 中可以通過 annotations 的方式，在 Service 的種類是 LoadBalancer 時(shí)，直接請求建立 AWS NLB：

與經(jīng)典的彈性負(fù)載均衡器不同，Network Load Balancers (NLBs) 會把客戶端的 IP 直接傳遞給節(jié)點(diǎn)。AWS NLB 其實(shí)從 1.9 的時(shí)候就已經(jīng)處于 Alpha 階段，現(xiàn)在代碼和 API 都已經(jīng)相對穩(wěn)定，所以準(zhǔn)備遷移到 Beta 階段。

#980 Finalizer protection for service LoadBalancers

進(jìn)度：Alpha

特性分類：Network

默認(rèn)情況下，云服務(wù)商提供的 Load Balancer 資源，應(yīng)該要在 Kubernetes Service 被刪除的時(shí)候也跟著一起被刪除才對，然而在各種極端的案例中，可以發(fā)現(xiàn)在刪除關(guān)聯(lián)的 Kubernetes Service 后，Load Balancer 資源卻被孤立在一旁沒有被清除掉，而引入 Finalizer 就是為了預(yù)防這種情況的發(fā)生。

如果你的集群已經(jīng)開啟了和云服務(wù)商的整合，F(xiàn)inalizer 將會附加到任何包含 type=LoadBalancer 字段的 Kubernetes Service，當(dāng)這類 Service 即將被刪除時(shí)，F(xiàn)inalizer 會先將 Serivce 的刪除動作給凍結(jié)住，直接確保 Load Balancer 資源被清除后，才會將 Service 真正刪除。

5. 存儲

#625 In-tree storage plugin to CSI Driver Migration

進(jìn)度：Alpha

特性分類：Storage

存儲插件最初都在 Kubernetes 的基礎(chǔ)代碼庫中，增加了代碼維護(hù)的復(fù)雜性，也阻礙了其擴(kuò)展性。因此該特性的目標(biāo)是將所有存儲相關(guān)的代碼移出來變成可加裝的插件形式，并通過 Container Storage Interface（CSI）來和 Kubernetes 進(jìn)行交互。如此一來便可降低開發(fā)的成本，并使其更加模塊化，可擴(kuò)展性更強(qiáng)，讓不同版本的存儲插件與 Kubernetes 之間有更好的兼容性。想了解該特性的最新進(jìn)展可以參考這里。

#989 Extend allowed PVC DataSources

進(jìn)度：Alpha

特性分類：Storage

該特性可以讓使用者復(fù)制現(xiàn)有的 PV。復(fù)制和備份其實(shí)還是不太一樣的，復(fù)制會產(chǎn)生一個新的且內(nèi)容和原來完全一樣的存儲卷。復(fù)制既有的 PV 會消耗用戶的存儲卷配額，并且會遵循和其他存儲卷創(chuàng)建時(shí)一樣的創(chuàng)建和檢查流程，復(fù)制出來的 PV 也和普通的 PV 一樣具有相同的生命周期和工作流程。使用該特性時(shí)，需要注意以下事項(xiàng)：

• 復(fù)制功能的 VolumePVCDataSource 參數(shù)僅適用于 CSI Driver。

• 復(fù)制功能僅適用于動態(tài)存儲卷配置。

• 到底能不能使用復(fù)制功能還要取決于 CSI Driver 有沒有實(shí)現(xiàn)存儲卷的復(fù)制功能。

#1029 Quotas for ephemeral storage

進(jìn)度：Alpha

特性分類：Node

目前限制臨時(shí)存儲卷使用量的機(jī)制是定期遍歷查看每個臨時(shí)存儲卷的大小，這種做法很慢，具有很高的延遲。該特性中提出的機(jī)制利用文件系統(tǒng)的 Project Quota 來監(jiān)控資源消耗程度，然后再決定要不要限制其使用量。希望能夠?qū)崿F(xiàn)以下目標(biāo)：

• 通過以非強(qiáng)制方式使用 Project Quota 來收集有關(guān)臨時(shí)卷的使用情況，進(jìn)而改善監(jiān)控的性能。

• 檢測出在 Pod 中已經(jīng)被刪除掉，但是因?yàn)槲募€處于打開的狀態(tài)下而被隱藏起來的存儲卷。

如此一來便可以通過 Project Quota 來限制每一個存儲卷的使用量。

#531 Add support for online resizing of PVs

進(jìn)度：邁向 Beta

特性分類：Storage

該特性讓使用者可以通過修改 PVC 來在線擴(kuò)展存儲卷使用到的文件系統(tǒng)，而不需要重啟使用到該存儲卷的 PVC。在線擴(kuò)展 PVC 的功能目前還處于 Beta 階段，且默認(rèn)是開啟的，你也可以通過 feature gate 參數(shù) ExpandInUsePersistentVolumes 顯示開啟。

文件系統(tǒng)的擴(kuò)展行為會在以下情況下被觸發(fā)：

• 當(dāng) Pod 啟動時(shí)

• 當(dāng) Pod 正在運(yùn)行且底層的文件系統(tǒng)支持在線擴(kuò)展（例如，XFS，ext3 或 ext4）

關(guān)于該特性的更多消息信息請參考 Kubernetes 官方文檔。

#559 Provide environment variables expansion in sub path mount

進(jìn)度：邁向 Beta

特性分類：Storage

目前 Kubernetes 對于掛載節(jié)點(diǎn)本地存儲卷的支持有一個限制：如果有大于等于兩個 Pod 運(yùn)行在同一個節(jié)點(diǎn)上，同時(shí)把相同的 log 文件名稱寫入相同的存儲卷會導(dǎo)致這些 Pod 發(fā)生沖突。

使用 subPath 是個不錯的選擇，但 subPath 目前只能寫死，無法提供靈活性。之前的解決辦法是創(chuàng)建一個帶有掛載路徑的軟鏈接的 Sidecar 容器。

為了更方便地解決這個問題，現(xiàn)在提出了向 subPath 中添加環(huán)境變量來緩和這個限制，參考以下示例：

也可以寫成這種格式：

到此，相信大家對“kubernetes1.15有哪些新特性”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！