走過了突飛猛進的2018年，Kubernetes在2019年終于迎來了第一個大動作：Kubernetes 1.14版本的正式發布！Kubernetes 本次發布的 1.14 版本，包含了 31 項增強，其中 10 項為 GA，12 項進入 beta 試用階段，7 個為全新的 alpha 功能。1.14 版本的主題是可擴展性，并且支持更多的業務場景，其中三個主要的功能具備生產可用，一個重要功能進入 beta 試用階段。總體而言，1.14 版本相比之前的版本更著重于將更多的功能推進到穩定狀態，尤其是部分關鍵功能對于用戶來說具有重大的里程碑意義。
Windows節點支持：生產可用
截至目前，1.14版本Windows節點支持已經穩定，支持將Windows節點作為工作節點，并向其調度Windows容器。Windows容器支持的引入，允許用戶通過Kubernetes的接口界面來體驗Windows容器，并見證Kubernetes對于Windows容器的價值。在同一集群中同時編排Windows與Linux應用，對于擁有混合應用技術棧的企業，尤其是傳統企業，具有里程碑式的意義。
Windows容器關鍵特性包含：
- 支持Windows Server 2019作為工作節點
- 支持與Azure-CNI、OVN-Kubernetes 和 Flannel等外置容器網絡插件對接
- 改進了對Pod、服務類型、工作負載控制器和 metric/quota 的支持，使Windows容器基本匹配Linux容器所提供的能力
隨著1.14版本的發布，Kubernetes已經能為提供相對完善的Windows容器基礎功能集，但如果考慮端到端商用落地Windows容器商用方案，用戶仍然不得不關注以下方面的成熟度限制：
1、操作系統版本限制：Windows容器對Windows系統以及docker版本都有更加嚴格的要求，例如Windows Server 2019/1809需要Docker EE-basic 18.09版本。
2、Hyper-V和Native容器的成熟度：整體相對弱于Linux容器，Native容器的安全隔離能有限，Hyper-V隔離方案仍然是alpha特性，需要持續完善；而對于依賴GPU、GUI的應用支持較弱，相關商用案例也較少。
3、Windows容器鏡像生態：
- 當前可用于Windows容器的base image有限，主要就是windowsservercore和nanoserver，針對實際場景的使用靈活度不高；
- Windows容器的基礎鏡像尺寸較大，而微軟的MCR服務(Microsoft Container Registry)尚未明確中國區CDN的上線時間，用戶往往需要花費較長的時間下載鏡像。
4、 網絡方面：Windows容器目前支持5種不同的網絡模式，雖然已有一些網絡插件宣稱可以滿足基本的使用要求，但性能和成熟度仍需驗證。
5、其他限制：
- 控制面master節點目前不能部署在Windows系統中，這意味著Kubernetes集群必須包含使用Linux系統的主節點。
- 目前 Windows 容器并不支持 Pod 優雅刪除。并且在 Windows 容器環境中，對單文件映射、特權容器、大頁內存支持、Node Problem Detection 等能力也都沒有提供支持。
在1.14版本穩定之后，Kubernetes社區將繼續完善對Windows容器支持，包括但不限于：
- 優化使用kubeadm在Windows環境下安裝節點
- 支持Calico CNI網絡
- Hyper-V隔離模式下支持一個Pod內包含多個容器
- 支持Pod優雅刪除
kubectl插件機制宣布穩定，命令行插件生態蓬勃發展
kubectl插件機制GA
kubectl插件機制允許開發者已獨立的二進制的形式發布自定義的kubectl子命令。這可以用于擴展kubectl具有更高級別的功能和附加的porcelain(例如添加set-ns命令)。
插件必須具有kubectl-的命名前綴，并保存在用戶PATH中，為了GA，插件機制已經被大大簡化了。目前有點類似Git的插件系統。
集成kustomize
kustomize（https://GitHub.com/Kubernetes-sigs/kustomize）是K8s社區命令行興趣小組（SIG-CLI）的一個子項目，致力于為用戶提供一種可以重復使用配置的聲明式應用管理工具，讓用戶在配置工作中只需要管理和維護kubernetes的原生API對象，而不需要使用和管理復雜的模版。
在這次發布的版本中，kustomize提供聲明式資源配置的創建修改等能力可以kubectl –k參數和kustomize子命令來執行。kustomize使用Kubernetes原生概念幫助用戶創建和復用資源配置。用戶可以利用 kubectl apply -k dir/將指定目錄的kustomization.yaml提交到集群中。用戶還可以直接將自定義的資源配置發送到標準輸入，而不是通過 kubectl kustomize dir/應用。
更多的kustomize子命令將會在kustomize代碼倉庫中繼續開發完善，用戶可以通過更新獨立的kustomize二進制文件來體檢最新的kustomize特性。
?
據不完全統計，GitHub 上有超過 200 種 kubectl 相關的第三方命令行工具，隨著 kubectl 插件機制穩定，相信這些工具很快會基于插件機制標準化，更好地與 kubectl 集成，給用戶提供強大的擴展命令集。
隨本次 Kubernetes 1.14 版本發布的，還有全新的 kubectl 文檔及 Logo。社區重寫了 kubectl 文檔，并重點聚焦使用聲明式的資源配置管理資源。目前 kubectl 文檔已作為獨立的站點上線，地址為：https://kubectl.docs.kubernetes.io，新的 kubectl Logo 及吉祥物（kubee-cuddle）也被啟用。
持久化本地存儲卷：生產可用
歷經漫長的改進，持久化本地存儲卷特性終于在1.14版本中達到生產可用。
本地持久卷可以使用K8s節點上掛載的本地存儲設備作為持久卷的來源。相對于遠程磁盤來說，持久化本地存儲擁有優越的性能，使用更少的系統開銷，更加適合分布式文件系統以及數據庫等場景。相比于云盤，本地SSD盤比遠程磁盤就具有更好的IO性能。相比于裸機，除了性能以外，本地存儲通常更加便宜，并且使用它是配置分布式文件系統的必要條件。
雖然本地持久卷特性達到生產可用，但是易用性仍然沒有得到顯著的改進。用戶可以通過兩種相對手動的方式來使用持久化本地存儲特性：
- 用戶手動指定塊設備的方式提供本地持久卷
- 使用 sig-storage-local-static-provisioner 插件靜態維護本地卷的生命周期。
根據Pod及PVC狀態自動地維護各節點中本地持久卷的能力，仍然需要較長的時間在社區推進。
應用就緒狀態判斷的改進：Pod Readiness Gates (Pod Ready++)生產可用
對于Pod的狀態，Kubernetes為用戶提供了兩項判斷Pod運行情況的能力：Readiness（就緒狀態）和Liveness（存活狀態）。一個Pod被判斷為Ready（就緒），意味著所有初始化相關的工作已經完成，Pod可以接收處理外部訪問的請求。而Liveness則用于判斷已就緒的Pod是否持續處于正常工作中。
然而在實際使用中，特別是針對大型應用，情況往往比較復雜。由于K8s中大量采用的異步機制、以及多種對象關系設計上的解耦，當應用實例數增加/刪除、或者應用版本發生變化觸發滾動升級時，系統并不能保證應用相關的Service、負載均衡器配置總是及時完成刷新。在一些情況下，往往只是新的Pod完成自身初始化，系統尚未完成Endpoint、負載均衡器等外部可達的訪問信息刷新，老的Pod就立即被刪除，最終造成服務不可用。這對用戶來說是不可接受的。
Pod Ready++的引入正是為了修正Pod就緒狀態的判斷機制——用戶可以通過 ReadinessGates 自定義Pod就緒的條件（如，從外部訪問入口判斷新建的Pod開始處理外部請求），當用戶自定義的條件以及容器狀態都就緒時，kubelet才會標記Pod準備就緒。
在1.14版本中，Pod ready++特性達到了穩定，用戶可以在生產系統中直接使用該特性。需要注意的是：對于用戶自定義的就緒條件，一定需要有自定義的控制器配合更新Pod狀態，否則，Pod永遠不會變成就緒狀態。
Pod優先級與搶占式調度：生產可用
Pod優先級與搶占可以使K8s調度器在集群資源耗盡的情況下優先調度更加重要的Pod，并且驅逐集群中正在運行的相對不重要的Pod，為更重要的Pod騰出資源。Pod的重要性通過PriorityClassName定義，其中\u0026quot;system-node-critical\u0026quot; 和 “system-cluster-critical” 是兩個特殊的最高優先級的關鍵詞。優先級低的Pod在資源不足時，容易首先被驅逐，因而對于重要的daemonset或者重要的應用組件，用戶可以設置較高的優先級防止被搶占。
要使用優先級與搶占，管理員必須開啟Priority Admission Controller。用戶在為Pod設置PriorityClassName時，必須指向集群中已創建的PriorityClass對象，否則Pod創建失敗。
PID限制：beta試用階段
進程ID (PID) 是Linux主機基本的資源，以往K8s沒有任何措施限制容器內的進程創建PID，如果PID資源耗盡，即使其他的資源充足，也可能導致主機不穩定。在引入PID限制特性后，K8s管理員可以通過kubelet啟動參數–pod-max-pids來設置每個Pod最大可啟動的進程數目，并通過–system-reserved和–kube-reserved兩項參數設置系統預留的PID數目。
PID限制特性帶來的主要好處有：
- 防止Pod因PID資源匱乏而不能正常運行
- 隔離Pod之間以及Pod與node之間的PID資源
Kubeadm
- 在高可用集群中自動執行控制面之間的證書復制。
- *kubeadm join *命令使得用戶自定義集群納管節點的工作流程變為可能。
總結：核心趨于穩定，面向用戶場景開枝散葉
結合最近幾次版本發布來看，Kubernetes核心的發展越來越趨于穩定，1.14版本幾乎沒有引入大的新特性，而是把重點放在了讓已有特性的穩定上。正如許多人會說，Kubernetes正在變得無聊，事實上放眼整個云原生生態，面向最終用戶的各種落地場景，仍有巨大的發展空間，許許多多圍繞Kubernetes的新項目仍然在如雨后春筍般地涌現，而K8s本身一些子項目的動態也開始進入人們的視野，不斷地被商業落地。相信2019年會是Kubernetes和云原生技術面向用戶場景開枝散葉的一年。
回調中檢索服務UUID)
)
