來源：才雲科技

美國時間 6 月 19 日，Kubernetes 迎來了 2019 年的第二個新版本 1.15。 K8sMeetup 社區第一時間整理了 Kubernetes v1.15 的亮點內容，為大家詳細介紹此版本的主要功能。

作為上海 KubeCon 前發布的最新版本，Kubernetes v1.15 由 25 個增強功能組成：2 個進入穩定，13 個進入 Beta，10 個進入 Alpha。

新版本緊緊圍繞兩大主題展開——可擴展性和持續改進：

  • 可擴展性。社區一直呼籲 Kubernetes 更好地支持可擴展性，因此新版本包含更多關於 CRD 和 API Machinery 的工作，大多數增強功能來自 SIG API Machinery 及相關領域；
  • 持續改進。項目的持續改進不僅與功能有關，許多 SIG 一直致力於提高測試覆蓋率，確保基礎功能的可靠、核心功能集的穩定以及現有功能的完善和清理工作。

圍繞核心 Kubernetes API 的可擴展性

圍繞 CRD 而新開發的主要目的是確保數據一致性和更貼近原生行為。用戶不應去關注交互是使用 CustomResource 還是原生 Kubernetes 對象資源。如今，開發團隊正努力在下一版本發布 CRD 的 GA 版本和 admission webhooks 的 GA 版本。

在這個方向上，團隊重新考慮了在 CRD 中使用基於 OpenAPI 的驗證模式，並且從 v1.15 開始，團隊根據 structural schema 的限制檢查資源定義。這基本上強制了 CustomResource 中每個欄位使用非多態和完整類型。

接下來，團隊將會要求具有 structual schemas，尤其是對於所有新功能，包括下面列出的功能，在 NonStructural 這個 Condition 中列出違規行為。非 structural schemas 在 v1beta1 API 組中暫時保持工作。但是，未來，所有的 CRD 應用都會被要求遷移到 structural schemas 中。

Beta：CustomResourceDefinition Webhook 轉換

自 v1.14 起，團隊在多個版本的 Beta 階段中支持了 CRD。而在 Kubernetes v1.15 中，它們可以即時在不同版本之間進行轉換，就像用戶長期使用 Kubernetes 原生對象資源一樣。CRD的轉換是通過集羣管理員在集羣內部署的 webhook 實現的。此功能在 Kubernetes v 1.15 中被升級為 Beta 版，將 CRD 升級到一個全新的易於使用的水平。

Beta：CustomResourceDefinition OpenAPI Publishing

kube-apiserver 在 /OpenAPI/v2 上為 Kubernetes 原生類型提供 OpenAPI 規範已經有很長一段時間了，它們被許多組件使用，尤其是在 kubectl 客戶端驗證、kubectl 解釋和基於 OpenAPI 的客戶端生成器。

用於 CRD 的 OpenAPI 發布將以 Kubernetes v1.15 作為測試版提供，但僅適用於 structural schemas。

Beta：CustomResourceDefinitions Pruning

Pruning 是自動刪除發送到 Kubernetes API 對象中的未知欄位。如果未在 OpenAPI 驗證模式中指定欄位，則該欄位是未知的。這是一個和數據一致性以及安全相關的功能。它強制只將 CRD 開發人員指定的數據結構持久化到 etcd 中。這是 Kubernetes 原生對象資源行為，也可用於 CRD，從 Kubernetes v1.15 開始，它進入測試階段。

在 CustomResourceDefinition 中，通過 spec.preserveUnknownFields: false 來激活 Pruning。未來從屬於 apiextensions.k8s.io/v1 的 CRD 可能會強制執行 Pruning 。

Pruning 要求 CRD 開發人員提供完整的結構驗證模式，無論是頂級還是所有版本的 CRD。

Alpha：CustomResourceDefinition 默認值

CustomResourceDefinitions 設置默認值。默認值是使用 OpenAPI 驗證模式中的 default 關鍵字指定的。在發送到 API 的對象中以及從 etcd 讀取時，為未指定的欄位設置默認值。

對於 structural schemas，默認值將在 Kubernetes v1.15 中以 Alpha 形式提供。

測試版：Admission Webhook 重構和改進

使用 Mutating and validating admission webhooks 來擴展 Kubernetes API 變得越來越主流。到目前為止，mutating webhooks 只按字母順序調用過一次。早期運行的 webhook 無法對調用鏈中後調用的 webhook 的輸出做出反應。使用 Kubernetes v1.15 的發布，情況將發生變化：

通過指定 reinvocationPolicy: IfNeeded ，mutating webhook 可以通過指定選擇加入至少一次重新調用。如果後來的 webhook 修改了對象，那麼早期的 webhook 將獲得第二次機會。

這要求 webhooks 具有類似於 idem-potent 的行為，可以應對第二次調用。

如果沒有計劃添加另一輪調用，那麼 webhook 作者仍然需要小心他們實現的認可對象所做的更改。最後，調用 webhook 來驗證所承諾的變更已經完成。

團隊允許 webhook 有更多更小的更改，特別是 objectSelector ，用於從 admission webhook 中排除具有特定標籤的對象，並且在 webhook 中使用任意埠（不再限定 443 埠）。

集羣生命週期穩定性和可用性改進

SIG Cluster Lifecycle 現週期的主要任務是使 Kubernetes 安裝、升級、配置更穩健，因此在 1.15 版本中，Bug 修復和生產就緒的用戶場景（如高可用性用例）被列入高優先順序。

作為集羣生命週期構建工具，kubeadm 高效創建生產集羣的功能和穩定性將進一步提高，它已將高可用性（HA）功能列入 Beta，允許用戶使用熟悉的 kubeadm init 和 kubeadm join 命令來配置和部署 HA 控制平面。官方也已設計了一個全新的測試套件，以確保這些功能隨著時間推移保持穩定。

此外，證書管理在 1.15 版本中也變得更加強大，在升級時，kubeadm 現在可以自動把所有證書在其過期前進行更新。有關如何管理證書的信息，請查看 kubeadm 文檔。

kubeadm 配置文件 API 現已從 v1beta1 移動到 v1beta2。最後，kubeadm 現在終於有自己的標誌啦！

CSI 持續改善

在 Kubernetes v1.15 中，SIG Storage 將繼續發力，以支持將內置的卷插件遷移到 Container Storage Interface（CSI），它會繼續為 CSI 增加內置的卷插件的功能特性，包括調整大小、內聯卷等功能。除此之外，SIG Storage 也在 CSI 中引入了新的 Alpha 功能，如卷克隆，這在 Kubernetes 存儲子系統中尚不存在。

卷克隆允許用戶在配置新卷時將另一個 PVC 指定為 「DataSource」。如果底層存儲系統支持此功能並在其 CSI 驅動程序中實現了「CLONE_VOLUME」功能，那麼這個新卷將成為源卷的克隆。

其他值得注意的功能更新：

  • Kubernetes Core 支持 Go modules；
  • 繼續籌備雲提供商的提取和代碼組織。雲提供商代碼現已移至 kubernetes/legacy-cloud-providers，以便以後更容易刪除和方便外部使用；
  • Kubectl 的 get 和 describe 現在適用於擴展；
  • 節點現在支持第三方監控插件；
  • 一個用於調度插件的新調度框架已進入 Alpha；
  • 用於在容器中觸發 hook 命令的 ExecutionHook API 現在已進入 Alpha；
  • 繼續棄用 extensions/v1beta1、apps/v1beta1 和 apps/v1beta2 API，這些擴展將在 1.16 版本退役！

緊急升級說明

API Machinery

  • k8s.io/kubernetes 和已發布的組件（如 k8s.io/client-go 和 k8s.io/api）現在包含 Go modules 文件，包括依賴版本信息。

Apps

  • Hyperkube 短別名已從源代碼中刪除，因為 Hyperkube docker 鏡像當前創建了這些別名。

AWS

  • system:aws-cloud-provider 不再自動創建在 v1.13 中棄用的集羣角色。用戶使用 AWS 雲提供商進行部署時，應將授予 kube-system 分區中的 aws-cloud-provider 服務帳戶所需許可權作為部署的一部分。

Azure

  • kubelet 現在可以在 Azure 上不帶身份地運行。示例：{"vmType": "vmss"， "useInstanceMetadata": true， "subscriptionId": ""；
  • 多個Kubernetes集羣現在可以共享同一個資源組；
    • 從先前版本升級時，如果多個集羣共享同一個資源組，那麼公有 IP 就會出現問題。要解決這些問題，請對集羣進行以下更改：重新創建相關的 LoadBalancer 服務，或者為現有的公有 IP 手工添加一個新標籤 kubernets -cluster-name:。使用 kube-controller-manager --cluster-name=<cluster-name> 為每個集羣配置一個不同的集羣名稱
  • Azure Cloud 提供商的雲配置現在可以使用在 kube-system 命名空間中的 Kubernetes secret azure-cloud-provider 初始化。
    • 這個 secret 是帶有關鍵 cloud-config 內容的 azure.json 文件的序列化版本,名稱是 azu -cloud-provider
    • cloud-config 文件中添加了一個新選項 cloudConfigType。支持的值分別是：file、secret 和 merge（merge 為默認值）
    • 為了允許 Azure 雲提供商讀取 secret，應配置 RBAC 規則

CLI

  • kubectl scale job 自 v1.10 以來已棄用，已被刪除；
  • kubectl exec 已棄用的 --pod/-p 已被刪除。自 Kubernetes v1.12 起，該標誌已被標記為已棄用。

生命週期

  • 對已棄用的 kubeadm v1alpha3 配置的支持已被完全刪除；
  • kube-up.sh不再支持「centos」和「本地」提供商。

網路

  • 已棄用的標誌 --conntrack-max 已從 kube-proxy 中刪除。此標誌的用戶應切換到 --conntrack-min 和 --conntrack-max-per-core 使用；
  • 已棄用的 kube-proxy 標誌 --cleanup-iptables 已被刪除。

Node

  • 已廢棄的 kubelet 安全控制 AllowPrivileged、HostNetworkSources、HostPIDSources 和HostIPCSources 已被刪除。執行這些限制應通過准入控制（例如 PodSecurityPolicy）來實現；
  • 已棄用的 kubelet 標誌 --allow-privileged 已被刪除。請從你的 kubelet 腳本或清單中刪除對該標誌的任何使用；
  • 現在，kubelet 僅收集節點、容器運行時、kubelet、Pod 和容器的 cgroups metrics。

存儲

  • CSI 卷不再設置 Node.Status.Volumes.Attached.DevicePath 欄位。你必須更新依賴於此欄位的任何外部 controllers；
  • CSI alpha CRD 已被刪除；
  • 因為 StorageObjectInUseProtection admission plugin 是默認啟用的，所以現在默認啟用的 admission 插件是NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,StorageObjectInUseProtection。請注意，如果你之前未設置該 --admission-control 標誌，則你的集羣行為可能會更改（更為標準）。

總結

對於新版本的突出特點，THE NEWS STACK 把它們總結為：新版本更重視通過自定義資源定義功能實現可擴展性。

Kubernetes v1.15 和 2018 年的四個更新版本一樣，非常重視項目的穩定性和可擴展性，這一點可以從兩個新的穩定功能以及自定義資源定義的大量增加（CRDs）得到證實。

例如，v1.15 新增 Go modules 支持，這允許 Kubernetes 核心開發人員以及希望構建第三方擴展的人使用最新的 Go 特性。而 kubectl 的 get 和 describe 現在可以很好地使用擴展，意味著第三方 API 擴展和 CRD 可以為 kubectl 提供自定義輸出，以避免 kubectl 必須有代碼來解析這些資源。

現在 Kubernetes v1.15 已經可從 GitHub 下載，您也可以使用 kubeadm 輕鬆安裝 v1.15。

GitHub：github.com/kubernetes/k

官方博客：kubernetes.io/blog/2019


推薦閱讀：
相關文章