Kubernetes 1.10 Beta 發布

Kubernetes 社區發布了 Kubernetes 1.10 的第一個 Beta 版本，因此用戶現在就可以對 1.10 中的部分新功能進行試用，在官方發布正式版本之前，可以向發布團隊提交試用反饋。這次發布預計是在 2018 年 3 月 21 日，其中包含了超過一打的 Alpha 功能以及不止兩打的更加成熟的特性。

Kubernetes 1.10 的眾多特性中，需要強調的是：生產就緒的 Kubelet TLS Bootstrap 功能、API 聚合以及詳細的存儲指標。

本文提到的一些功能可能讓人覺得面熟，這是因為他們在之前的版本就已經出現，隨著功能的逐步成熟，我們會為他定義不同的階段：

Stable（穩定版）：等價於「Generally available」，處於這一階段的功能經過了完善的測試，可以用於生產環境。

Beta：這類功能已經出現了一段時間，開發團隊認為這類功能一定能夠提升到穩定階段，任何 API 調用都不會發生變更。可以使用和測試這類功能，但其完善程度有限，因此不建議用在生產環境的關鍵任務之中。

Alpha：新功能從這一階段開始，這類功能還在摸索期間。API 和配置項可能會隨著版本發生變化，甚至這些功能本身也有移除的風險。很明顯，不應該在生產環境中投入使用。

可以從下載 Kubernetes 1.10。在 3 月 9 日之前，還可以在 Kubernetes 1.10 里程碑上提交 Issue(注 1)給開發社區，並打上合適的 SIG 標籤。

下面的內容是用戶更關心的，但是需要注意，這只是成文期間的計劃，在發布之時可能發生變更。

首先說說認證問題。

認證（SIG-Auth）

Kubelet TLS Bootstrap（注 2）進入穩定階段：Kubelet TLS Bootstrap 可能是這次發布中的頭條信息，這是因為這一功能可以交付生產環境進行使用了。他為新加入的 Kubelet 提供了一個創建認證簽名請求的功能，這樣在加入新節點的時候，就不用手工加入證書或者自行簽署證書，免除了很多手工過程特有的不便之處。

Pod Security Policy（Pod 安全策略）有了自己的 API 組（注 3），Pod 安全策略的 Beta 版本，讓管理員來決定 Pod 運行的上下文，換個說法就是，可以禁止無權用戶運行特權 Pod，可以在特定 Namespace 中進行文件訪問或訪問 Secret 這樣的操作。

限制節點的 API 訪問（Beta）（注 4），現在可以把針對節點的 API 調用限制在指定節點上，這樣就可以保障讓節點只調用自己的 API，而不會越權訪問其他節點的 API。

Client-go 的外部認證提供者（alpha）(注 5)：Client-go 是用於訪問 Kubernetes API 的 Go 語言客戶庫。這一功能提供了使用外部認證提供者的能力。例如 Amazon 可能想要創建其自有的認證體系，來給 EKS 集群的交互提供認證能力。現在就可以在不變更 Kubernetes 代碼的情況下完成這一任務了。

TokenRequest API（注 6），這個 API 讓 Service Account Token 有了一個上升空間；這一功能使得 Token 的創建過程不再是 Secret API 中的持久化過程，其目標是特定場景的應用（例如外部 Secret 存儲），具備可配置的有效期，並可以綁定到特定 Pod。

網路（SIG-Network）

支持對 Pod 中的配置（注 7）：現在可以在 單個 Pod 中繞開集群 DNS 進行 DNS 控制。

雖然這一功能被稱為預設 DNS 插件切換為 CoreDNS（Beta）（注 8），但是在這一階段內還不會發生。社區正在投入工作，進行 kube-dns（也包括 dnsmasq）到 CoreDNS 的遷移，CoreDNS 是 CNCF 的另外一個項目，這一項目已經運行了一段時間，結構上更為緊湊。在 Kubernetes 1.10 中的預設 DNS 仍然會是 kube-dns，但是當 CoreDNS 完成和 Kube-DNS 的匹配，團隊就會嘗試令其作為預設 DNS 伺服器。

拓撲感知的服務路由(Alpha)（注 9），Kubernetes 的長處就是分布工作負載的能力。但是目前為止，都缺少一個功能，讓工作負載和服務能夠在地理上盡量靠近以降低延遲。拓撲感知的路由功能就有效的改善了這一狀況（這一功能會延遲，在 1.11 版本中發布）。

可以對 NodePort 的 IP 地址進行配置（注 10）：在 Kubernetes 集群中，不必指定 IP，這種情況多數時候是個好事——除非你要提前獲得地址。現在用戶就可以配置 NodePort 的 IP 地址了（這一功能也會延遲到 1.11 版本中）

Kubernetes API（SIG-API-machinery）

API 聚合（Stable）（注 11）：Kubernetes 中，用戶可以實現自己的功能，然後進行註冊，之後就可以用類似核心 K8S 功能的方式進行使用了。這一能力在 Kubernetes 1.11 中升級到了 Stable 階段，這意味著可以進入生產環境的應用之中了。另外 SIG-CLI 正在加入一個功能，讓服務端對 Kubectl 的 Get 和 Describe 操作返回擴展信息（Alpha）（注 12），以提供更好的用戶體驗。

支持自運行的授權 Webhook（Alpha）（注 13）：前面的 Kubernetes 中提供了授權 Webhook 功能，這一功能可以在命令執行之前對許可權的應用進行定製。然而這些功能的實現必須有個運行環境，這個新功能可以在集群之中運行 Webhook 進程。

存儲（SIG-Storage）

存儲指標提供了更多的內部狀態（Stable）（注 14）：對於 Kubernetes 這樣的分散式系統來說，獲得系統在任何時間的內部情況，不論是對於除錯，還是自動化工作，都是十分必要的。這一版本提供了穩定的對於存儲系統的內部信息的輸出，例如載入和卸載的時間、處於某一狀態的存儲卷數量、孤立狀態的 Pod 目錄等。設計文檔（注 15）中包含了完整的指標列表。

掛載名稱空間的掛載傳播（Beta）（注 16）讓容器以模式進行掛載，這樣在在容器中能夠看到主掛載。還可以用進行掛載，這樣容器內的掛載就反映了主機的掛載命名空間。這一功能的預設值是。

本地臨時存儲容量隔離（Beta）（注 17），沒有這種支持的時候，節點上每個使用臨時存儲的 Pod 都是從同一個池子進行拉取的，並分配為模式；換句話說，Pod 永遠不會知道到底有多少可用空間。這個功能讓 Pod 有辦法給自己的存儲進行空間保留。

外置的 CSI 卷插件（Beta）（注 18）：Kubernetes 1.9 宣布了 CSI，這一標準為廠商定義了向 Kubernetes 集群提供存儲的具體方式。這一功能讓驅動過程外置成為一種可能。廠商可以不必依賴社區的審查和批准來自行控制自己的插件。

本地持久卷（Beta）（注 19）：可以在本地盤上創建，不僅限於網路卷。

阻止刪除被 Pod 使用的 PVC（注 20），阻止刪除綁定在 PVC 上的 PV（注 21）：Kubernetes 的過去版本中，可以刪除被 Pod 使用的存儲，然後就會造成很多問題，這一改動進行了校驗，阻止了這種情況的發生。

[加入在線調整 PV 尺寸的能力（Alpha）（注 22）]：可以在不影響現有數據的情況下增大現有卷。這也對FlexVolume 的擴容支持（Alpha）（注 23）有效；FluxVolume 是一個 FluxVolume 插件實現的廠商支持的卷實現。

拓撲感知的卷調度（Beta）（注 24）：可以在持久卷定義中加入拓撲限制，以此影響調度器中對相關容器的調度。這一功能還把 PVC 綁定的初始化過程延遲到 Pod 調度之後，這樣卷綁定決策就能夠在已知 Pod 部署情況的條件下做到更好。目前這一功能對本地持久卷很有用，對動態供給卷的支持還在開發。

節點管理（SIG-Node）

Kubelet 的動態控制（Beta）（注 25）：Kubernetes 中對現存集群的變更是比較方便的，例如增加複製數量或者暴露服務等。這一功能則讓對 Kubernetes 自身的變更（或者說幕後的 Kubelet）

而無需停止 Kubelet 成為可能。

CRI 驗證測試套件（Beta）（注 26）：Kubernetes 的容器運行時提供了 Docker 之外的（例如 Rkt 甚至是運行 Virtlet 的虛擬機）運行容器的選擇。現在提供了一系列的驗證測試，來確認 CRI 的實現的有效性，讓開發者更方便的查找問題。

可配置的 Pod 進程命名空間共享（Alpha）（注 27）：雖然 Pod 能夠輕易地分享 Kubernetes 的命名空間，但是因為 Docker 的問題，進程或者 PID 命名空間是一個更困難的情況。這一功能讓用戶可以用 Pod 參數來決定容器使用自己的操作系統進程還是共享一個進程。

CRI 中加入對 Windows 容器配置的支持（Alpha）（注 28）：起初，容器運行是介面是為基於 Linux 的容器設計的，不可能為基於 Windows 的容器提供支持。這一功能解決了這一問題，可以指定

了。

容器除錯（Alpha）（注 29）：如果有合適的工具，為容器除錯很容易，但是沒有呢？這一功能提供了一種可能性：在容器中運行沒有內置在鏡像中的除錯工具。

其他變更

Deployment（SIG-Cluster Lifecycle）：支持進程外或代碼外的雲供應商（Beta）（注 30），Kubernetes 現在已經獲得了廣泛採用，越來越多的雲供應商希望運行 Kubernetes。為了讓這一進程更加方便，社區努力將供應商指定的二進位內容進行分離，便於供應商自行替換。

Kubernetes On Azure（SIG-Azure）：Kubernetes 具有集群伸縮能力，在負載過高時能夠自動向集群中加入節點，但是目前這一能力在 Azure 中尚未實現。現在為 Azure 添加了 cluster-autoscaler 支持（Alpha）（注 31）。另外添加 Azure 虛擬機伸縮集的支持（Alpha）（注 32），使用 Azure 自己的自動伸縮能力來實現資源的調整。

可以在https://github.com/kubernetes/kubernetes/releases下載 Kubernetes 1.10 Beta，另外再次強調（社區也是如此希望），有反饋請在 3 月 9 日之前，向 1.10 里程碑上提交 Issue 給合適的 SIG。

注

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！