本篇內(nèi)容主要講解“kubernetes1.15有哪些新特性”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“kubernetes1.15有哪些新特性”吧!
專注于為中小企業(yè)提供成都網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計服務(wù),電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)響水免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了1000多家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。
進度：邁向 Beta
特性分類：Network
NodeLocal DNSCache 通過在集群節(jié)點上以 Deamonset 的方式運行 DNS 緩存代理來提高集群的 DNS 性能，從而可以避免使用 iptables DNAT 規(guī)則和連接跟蹤。如果本地 DNS 緩存代理在內(nèi)存中找不到相應(yīng)的 DNS 記錄，就會向 kube-dns 服務(wù)發(fā)起查詢請求（默認情況下以 cluster.local 為后綴）。
想了解該特性的更多細節(jié)可以閱讀 Kubernetes Enhancement Proposal (KEP) 文檔中的設(shè)計說明。
進度：Alpha
特性分類：Scalability
這項工作主要有兩個目標：
減少 Events 對集群其余部分的性能影響；
向 Event 對象添加更多的數(shù)據(jù)結(jié)構(gòu)，這是使 Event 分析自動化的必要步驟，也是第一步。
目前 Event API 的主要問題是包含太多垃圾信息，導(dǎo)致其難以攝取和分析有效信息。除此之外還有數(shù)個性能問題，例如當集群出現(xiàn)問題時，Events 可能會使 API server 過載（例如常見的 crashloop）
關(guān)于該 issue 的討論以及建議的解決方案和改進工作可以參考這里的設(shè)計提案。
進度：Beta
特性分類：API
Mutating 和 Validating Admission Webhook 已經(jīng)成為擴展 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)生的效果相同。
進度：Alpha
特性分類：Scheduling
該特性為 Kubernetes 1.15 的調(diào)度器設(shè)計了一個新的可插拔結(jié)構(gòu)，主要是為了解決日益增加的定制化調(diào)度需求。Scheduler Framework 在原有的 Priority/Predicates 接口的基礎(chǔ)上增加了 reserve, pre-bind 等十幾個接口。
下圖顯示了 Pod 在新的 Scheduling framework 中的調(diào)度過程：
關(guān)于該特性的更多信息請查閱官方設(shè)計文檔。
進度：邁向 Beta
特性分類：Node
該特性允許 Kubelet 將容器 binding 信息暴露給第三方監(jiān)控插件，這樣系統(tǒng)管理員就可以使用第三方的設(shè)備監(jiān)控代理來監(jiān)控自定義資源分配給 Pod 的使用率（例如，每個 Pod 的 GPU 使用率）。
未解耦前，Kubelet 會檢測所有支持的設(shè)備是否存在，即使節(jié)點并沒有安裝該設(shè)備。
使用新的框架之后，Kubelet 會通過 /var/lib/kubelet/pod-resources/kubelet.sock 提供一個新的 GRPC 服務(wù)，該服務(wù)會把容器和設(shè)備所分配到資源相關(guān)的信息都暴露出來。
進度：邁向 Beta
特性分類：Node
Pid 是 Linux 系統(tǒng)中很重要的資源，系統(tǒng)很容易在 CPU 或內(nèi)存的使用量還沒達到上限之前，進程數(shù)量就達到了上限。因此管理員必須得想辦法確保 Pod 不會把系統(tǒng)的 Pid 用完，進而造成其他重要的服務(wù)無法運行（例如，container runtime，kubelet 等）。
新的特性允許修改 Kubelet 配置來限制每個 Pod 的 Pid 數(shù)量。在 Node 層面限制 Pid 的功能現(xiàn)在可以直接使用，不再需要通過 feature gate 的參數(shù) SupportNodePidsLimit=true 顯示設(shè)置。
Kubernetes 官方博客有對此特性的詳細介紹。
進度：Alpha
特性分類：Scheduling
Kubernetes 1.15 在 PriorityClass 中添加 PreemptionPolicy 字段作為 Alpha 特性。
PreemptionPolicy 字段的默認值為 PreemptLowerPriority，表示允許該優(yōu)先級的 Pod 搶占低優(yōu)先級的 Pod（這是默認的搶占行為）。如果 PreemptionPolicy 字段的值為 Never，則該 Pod 會被放置到調(diào)度隊列中，并且放置的位置排在低優(yōu)先級 Pod 的前面，但是不能搶占其他的 Pod。
以數(shù)據(jù)科學(xué)領(lǐng)域為例：用戶提交了一個 job，他希望此 job 的優(yōu)先級比其他 job 高，但是不希望因為搶占 Pod 而導(dǎo)致目前的任務(wù)被擱置。
進度：Stable
特性分類：Architecture
自從 Kubernetes 開源以來，一直使用 godep 來 vendoring 所有依賴庫。隨著 Go 生態(tài)系統(tǒng)越來越成熟，vendoring 已經(jīng)變成主流，而 godep 已經(jīng)不再維護了，于是 Kubernetes 一開始使用 godep 的定制版，這期間還有一些其他的 vendoring 工具（例如 glide 和 dep）也跟著出現(xiàn)，而現(xiàn)在 Go 的依賴庫管理終于可以以 go module 的形式直接添加到 Go 中。
Go 從 1.13 已經(jīng)默認開啟 go module，并且移除了 $GOPATH 模式。為了支持這個改動，Kubernetes 1.15 版本調(diào)整了好幾個組件的代碼以使用 go module。
進度：Alpha
特性分類：API
一個 Kubernetes 集群只會保留一段時間內(nèi)的變更歷史記錄，比如使用 etcd3 的集群默認會保留 5 分鐘的變更歷史記錄。而為 Kubernetes Watch 事件添加一個書簽（bookmark）可以想象成多了一個檢測點，所有 Client 請求的對象如果符合預(yù)先想查找的資源版本（resourceVersion）就會被這個書簽給篩選出來。
例如：新增一個 Watch 的請求去查找所有資源版本為 X 的事件，這時 API server 知道該 Watch 請求對其他資源版本的事件沒有興趣，就會使用書簽來略過所有其他事件，只將特定的事件發(fā)送給客戶端，從而避免增加 API server 的負載。
進度：Alpha
特性分類：storage
ExecutionHook 提供了一種通用機制，讓用戶可以在容器中觸發(fā)想要執(zhí)行的 hook 命令，例如：
應(yīng)用程序備份
升級
數(shù)據(jù)庫遷移
重新加載配置文件
重啟容器
hook 的定義中包含兩條重要信息：
需要執(zhí)行什么命令
在哪執(zhí)行命令（通過 Pod Selector）
下面提供一個簡單示例：
想了解該特性的更多細節(jié)可以閱讀 Kubernetes Enhancement Proposal (KEP) 文檔中的設(shè)計說明。
進度：邁向 Beta
特性分類：Apps
Pod Disruption Budget (PDB) 是一種 Kubernetes API，用于限制在同一時間自愿中斷的應(yīng)用程序（如 Deployment 或 ReplicaSet）中宕機的 Pod 的數(shù)量。PDB 可以通過指定最小可用數(shù)量或最大不可用數(shù)量的 Pod 來自定義中斷預(yù)算。
例如，對于一個無狀態(tài)的前端應(yīng)用：
要求：服務(wù)能力不能減少超過 10%
解決方案：使用一個包含 minAvailable 90% 值的 PDB
使用 PDB 后，就可以允許管理員在不降低服務(wù)的可用性和性能的前提下操作 Kubernetes 的工作負載。
進度：Beta
特性分類：API
該特性沒有什么實質(zhì)性的功能，只是把在 Kubernetes 1.15 版本中跟 CRD 相關(guān)的修復(fù)和改進進行了分組：
Structural schema using OpenAPI
CRD pruning
CRD defaulting
Webhook conversion moved to beta
Publishing the CRD OpenAPI schema
進度：邁向 Beta
特性分類：API
該特性允許開發(fā)者使用 OpenAPI v3 schema 來定義 Custom Resource Definition (CRD) ，以便開啟 Server 端對 CustomResources (CR) 的驗證。
發(fā)布使用 OpenAPI 規(guī)范的 CRD 便可以開啟客戶端驗證（例如 kubectl create 和 kubectl apply 時），也可以對規(guī)范進行描述（例如 kubectl explain），Client 也會因為 CRs 而自動生成，所以開發(fā)者可以輕易使用任何支持的編程語言來和 API 進行交互。
使用 OpenAPI 規(guī)范有助于使 CRD 開發(fā)者和 Kubernetes API 的發(fā)展方向更加清晰，文檔格式更加簡潔精煉。
進度：Alpha
特性分類：API
下面的這兩個特性主要是為了使與 CRD 相關(guān)的 JSON 處理更加方便。
Pruning: CRD 傳統(tǒng)的存儲方式是以 JSON 格式存儲在 ETCD 中?，F(xiàn)在如果它是以 OpenAPI v3 的規(guī)范來定義的，并且 preserveUnknownFields 的值為 false，未被定義的字段在創(chuàng)建或更新時便會被刪除。
Defaulting: 此特性在 Kubernetes 1.15 版本處于 Alpha 階段，默認處于關(guān)閉狀態(tài)，可以通過 feature gate 的參數(shù) CustomResourceDefaulting 來開啟。Defaulting 和 Pruning 一樣，在一開始就要將規(guī)范定好，不符合規(guī)范的就會被去掉。
進度：邁向 Beta
特性分類：API
不同的 CRD 版本可以有不同的規(guī)范，現(xiàn)在你可以在操作中處理不同版本之間的轉(zhuǎn)換，并且實現(xiàn)了版本轉(zhuǎn)換的 webhook。這個 webhook 會在下面幾種情況下被調(diào)用：
請求的自定義資源版本與原來儲存的版本不一致
自定義資源在 Watch 時創(chuàng)建了某一版本，但在下次修改時發(fā)現(xiàn)跟存儲的版本不一致
使用 PUT 請求自定義資源時，發(fā)現(xiàn)請求的版本與存儲的版本不一致
這里有一個實現(xiàn)自定義資源之間相互轉(zhuǎn)換的 webhook server 的示例，大家可以作為參考。
進度：邁向 Stable
特性分類：Cli
目前已經(jīng)可以使用 kubectl get 和 describe 來讓第三方 API 擴展和 CRD 提供自定義格式化輸出。該特性使輸出可以打印到服務(wù)器端，從而實現(xiàn)了更好的擴展性，并且讓 Kubectl 和擴展的實現(xiàn)細節(jié)進行解耦。
想了解關(guān)于該特性的更多詳細信息，可以查閱相關(guān)設(shè)計文檔。
進度：邁向 Beta
特性分類：Cluster lifecycle
隨著時間的推移，在 kubeadm 的配置文件中配置 Kubernetes 集群創(chuàng)建時的選項數(shù)量已經(jīng)大大增加，然后 CLI 參數(shù)的數(shù)量還是沒有變化，所以導(dǎo)致使用配置文件來創(chuàng)建集群是目前唯一一個比較符合使用者需求方法。
該特性的目標是重新設(shè)計配置的存儲方式來改善當前版本遇到的問題，并放棄了使用包含所有選項的單個配置文件，使用子結(jié)構(gòu)來為高可用集群提供更好的支持。
進度：邁向 Beta
特性分類：Cluster lifecycle
Kubernetes 可以通過多個控制平面來提供高可用性。kubeadm 工具現(xiàn)在可以用來創(chuàng)建高可用集群，有兩種方式：
etcd 與 Control Plane 節(jié)點 (Master) 共存
etcd 與 Control Plane 節(jié)點 (Master) 是分開的
這個版本的 kubeadm 將會自動復(fù)制其中需要的證書，減少人為干預(yù)的需求，目前的做法是使用一個暫時加密的秘鑰來確保證書在傳輸過程中的安全性，更多細節(jié)可以參考 KEP 文檔。
進度：邁向 Beta
特性分類：AWS
在 Kubernetes 1.15 中可以通過 annotations 的方式，在 Service 的種類是 LoadBalancer 時，直接請求建立 AWS NLB：
與經(jīng)典的彈性負載均衡器不同，Network Load Balancers (NLBs) 會把客戶端的 IP 直接傳遞給節(jié)點。AWS NLB 其實從 1.9 的時候就已經(jīng)處于 Alpha 階段，現(xiàn)在代碼和 API 都已經(jīng)相對穩(wěn)定，所以準備遷移到 Beta 階段。
進度：Alpha
特性分類：Network
默認情況下，云服務(wù)商提供的 Load Balancer 資源，應(yīng)該要在 Kubernetes Service 被刪除的時候也跟著一起被刪除才對，然而在各種極端的案例中，可以發(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，當這類 Service 即將被刪除時，F(xiàn)inalizer 會先將 Serivce 的刪除動作給凍結(jié)住，直接確保 Load Balancer 資源被清除后，才會將 Service 真正刪除。
進度：Alpha
特性分類：Storage
存儲插件最初都在 Kubernetes 的基礎(chǔ)代碼庫中，增加了代碼維護的復(fù)雜性，也阻礙了其擴展性。因此該特性的目標是將所有存儲相關(guān)的代碼移出來變成可加裝的插件形式，并通過 Container Storage Interface（CSI）來和 Kubernetes 進行交互。如此一來便可降低開發(fā)的成本，并使其更加模塊化，可擴展性更強，讓不同版本的存儲插件與 Kubernetes 之間有更好的兼容性。想了解該特性的最新進展可以參考這里。
進度：Alpha
特性分類：Storage
該特性可以讓使用者復(fù)制現(xiàn)有的 PV。復(fù)制和備份其實還是不太一樣的，復(fù)制會產(chǎn)生一個新的且內(nèi)容和原來完全一樣的存儲卷。復(fù)制既有的 PV 會消耗用戶的存儲卷配額，并且會遵循和其他存儲卷創(chuàng)建時一樣的創(chuàng)建和檢查流程，復(fù)制出來的 PV 也和普通的 PV 一樣具有相同的生命周期和工作流程。使用該特性時，需要注意以下事項：
復(fù)制功能的 VolumePVCDataSource 參數(shù)僅適用于 CSI Driver。
復(fù)制功能僅適用于動態(tài)存儲卷配置。
到底能不能使用復(fù)制功能還要取決于 CSI Driver 有沒有實現(xiàn)存儲卷的復(fù)制功能。
進度：Alpha
特性分類：Node
目前限制臨時存儲卷使用量的機制是定期遍歷查看每個臨時存儲卷的大小，這種做法很慢，具有很高的延遲。該特性中提出的機制利用文件系統(tǒng)的 Project Quota 來監(jiān)控資源消耗程度，然后再決定要不要限制其使用量。希望能夠?qū)崿F(xiàn)以下目標：
通過以非強制方式使用 Project Quota 來收集有關(guān)臨時卷的使用情況，進而改善監(jiān)控的性能。
檢測出在 Pod 中已經(jīng)被刪除掉，但是因為文件還處于打開的狀態(tài)下而被隱藏起來的存儲卷。
如此一來便可以通過 Project Quota 來限制每一個存儲卷的使用量。
進度：邁向 Beta
特性分類：Storage
該特性讓使用者可以通過修改 PVC 來在線擴展存儲卷使用到的文件系統(tǒng)，而不需要重啟使用到該存儲卷的 PVC。在線擴展 PVC 的功能目前還處于 Beta 階段，且默認是開啟的，你也可以通過 feature gate 參數(shù) ExpandInUsePersistentVolumes 顯示開啟。
文件系統(tǒng)的擴展行為會在以下情況下被觸發(fā)：
當 Pod 啟動時
當 Pod 正在運行且底層的文件系統(tǒng)支持在線擴展（例如，XFS，ext3 或 ext4）
關(guān)于該特性的更多消息信息請參考 Kubernetes 官方文檔。
進度：邁向 Beta
特性分類：Storage
目前 Kubernetes 對于掛載節(jié)點本地存儲卷的支持有一個限制：如果有大于等于兩個 Pod 運行在同一個節(jié)點上，同時把相同的 log 文件名稱寫入相同的存儲卷會導(dǎo)致這些 Pod 發(fā)生沖突。
使用 subPath 是個不錯的選擇，但 subPath 目前只能寫死，無法提供靈活性。之前的解決辦法是創(chuàng)建一個帶有掛載路徑的軟鏈接的 Sidecar 容器。
為了更方便地解決這個問題，現(xiàn)在提出了向 subPath 中添加環(huán)境變量來緩和這個限制，參考以下示例：
也可以寫成這種格式：
到此，相信大家對“kubernetes1.15有哪些新特性”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！
重慶分公司
重慶分公司
