Cluster Lifecycle 層面對 kubeadm 添加了 self-hosted 功能，意味著可以將 Kubernetes 運行在 Kubernetes 上，即自舉。自舉被認為是系統”優雅”的一種體現，實際上 Kubernetes 在很早期就開始嘗試自舉，現在 kubeadm 直接添加此功能，無疑是更近一步。另外，盡管沒有對外發布，kubeadm 社區也一直在嘗試直接部署高可用（HA）Kubernetes 集群。可以預見 kubeadm 在會進一步解決 Kubernetes 最為詬病的部署問題，降低使用門檻。

存儲功能的更新是本次發布更新相對較多的模塊，也是才雲科技非常重視並且持續投入的小組。首先，Kubernetes 的存儲模型已經穩定，在 1.8 的發布中開始增加更多的擴展性和附加功能，例如支持掛載選擇，支持 StorageClass 參數化等。快照、擴容、本地存儲無疑是存儲模塊本次發布的亮點，盡管目前都是 alpha，甚至是 pre-alpha。由於文件系統擴容方案暫未統一，擴容在本次發布中只支持 GlusterFS，但才雲科技已經在 ceph、cinder 上進行了 prototype，相信在 1.9 中可以在社區中推出。本地臨時存儲在經過 1.7 和 1.8 兩次叠代已經處於穩定的 alpha 版本，後續方案不會再改變，我們會持續增強其穩定性。本地持久化存儲由於需要與調度討論設計，進展較慢。快照現在處於 prototype 階段，Kubernetes 對使用中的 Volume 快照會出現不一致的情況。

另外一個值得註意的情況是 SIG 的融合。目前，Kubernetes Node、Storage、Scheduling 等小組在合作形成 Resource Group，旨在使 Kubernetes 能夠支持更多類型的應用。Auth、Node 等小組合作成立 Container Identity Group，確保容器在對外通信時的安全、可靠。在各個小組的合作下，Kubernetes 現在提出了 Device Plugin、CPU Manager、HugePage、Resource Claas，可以支持多樣化的硬件。Kubernetes 1.8 是此類 Group 的成立後的首次較大範圍功能發布，期待後續更多的進展。

下面看一下 Kubernetes 1.8 中都有哪些發布內容。

發布主題

Kubernetes 通過興趣小組（SIG）管理社區與開發，下面根據興趣小組來解讀 Kubernetes 1.8 的發布內容。

SIG Apps

SIG Apps 的工作集中在 Kubernetes API 上，提供多種管理不同類型應用的基本工具。

在 1.8 的發布版本中，SIG Apps 將應用相關的一些 API 遷移到了 apps/v1beta2，包括 DaemonSet，Deployment，ReplicaSet 和 StatefulSet。在 apps/v1beta2 中，也有部分內容被棄用或者行為發生變更，這樣做的目的在於給開發者提供一個穩定且一致的 API 集合，方便開發者基於 Kubernetes 構建應用。在後續的發布中，SIG Apps 會逐步推動該版本走向穩定版本。

SIG Auth

SIG Auth 負責 Kubernetes 認證，授權和集群安全策略相關的工作。

在 Kubernetes 1.8 中 SIG Auth 主要專註於穩定之前的發布中引入的功能。RBAC（基於角色的訪問控制）功能已經提升到 v1，advanced auditing （高級審計）功能已經發布 beta 版本。Encryption of resources at rest （靜態資源加密）功能依舊是 alpha 版本，開始嘗試集成外部的密鑰管理系統。

SIG Cluster Lifecycle

SIG Cluster Lifecycle 負責部署升級和刪除集群的用戶體驗。

在 1.8 發布中，SIG Cluster Lifecycle 繼續關註於擴展 kubeadm 的功能，它既是一個面向用戶的集群管理工具，也作為一個構建單元提供給高層次的系統。從 1.8 版本開始，kubeadm 支持一個新的升級命令，並且對集群控制組件的 self hosting 提供 alpha 支持。

SIG Node

SIG Node 負責 Pod 和 Host 主機之間資源交互的組件，以及管理節點上 Pod 的生命周期

對於 1.8 版本，SIG Node 繼續專註於支持更廣泛的工作負載類型，包括支持硬件和對性能敏感的工作負載，如數據分析和深度學習，同時不斷增強 Node 的可靠性。SIG Network 負責 Kubernetes 中的網絡組件，API 和插件。

SIG Network

SIG Network 負責 Kubernetes 中的網絡組件，API 和插件。

對於 1.8 版本，SIG Network 增強了 NetworkPolicy API，以支持 Pod 出口流量策略，以及允許策略規則匹配源或目標 CIDR 的匹配條件。這兩個增強特性都被設計為 beta 版本。 SIG Network 還專註於改進 kube-proxy，除了當前的 iptables 和 userspace 模式，kube-proxy 還引入了一個 alpha 版本的 IPVS 模式。

SIG Storage

存儲興趣組主要包含存儲和各種存儲卷插件。

1.8 中，存儲興趣組擴展了 kubernetes 存儲 API，不再只是簡單的提供可使用的卷，又新增了卷擴容和快照功能。 除了這些 alpha/prototype 特性， 存儲興趣組主要聚焦在讓用戶更好的控制他們的存儲，提供了如下能力：能設置臨時存儲 requests & limits ，能指定掛載選項， 暴露更多存儲指標信息， 改善 Flex driver deployment。

SIG Scheduling

SIG Scheduling 主要負責通用調度器和調度相關組件。

在 1.8 的發布版本中，SIG Scheduling 通過引入 Pod 優先級和搶占特性擴展了共享集群的概念。這些特性允許在單一集群中混合運行不同類型的應用和任務，提高了集群的利用率和可用性。這些特性目前都是 alpha 版本。SIG Scheduling 還將逐步優化調度相關的內部 API，讓其他組件和外部調度器能夠輕松的使用這些 API。

SIG Autoscaling

SIG Autoscaling 主要負責彈性伸縮相關的組件，比如 Horizontal Pod Autoscaler 和 Cluster Autoscaler。

在 1.8 的發布版本中，SIG Autoscaling 主要在提升現有組件的穩定性和功能。比如新版的 Horizontal Pod Autoscaler 將支持自定義指標，Cluster Autoscaler 提升了性能和錯誤報告能力。

SIG Instrumentation

SIG Instrumentation 負責指標的輸出和收集。

在 1.8 版本中，SIG Instrumentation 的工作重心是支持新版本 HPA API，將所依賴的 API 和組件升級到穩定版本，包括：resource metrics API，custom metrics API 和 metrics-server（metrics-server 將會在替代 heapster 在默認監控流水線中的作用）。

SIG Scalability

SIG Scalability 負責可擴展性測試，測量和改進系統性能，並回答有關可擴展性的問題。

對於 1.8 版本, SIG Scalability 集中於在持續集成（CI）環境中自動化大型集群可擴展性測試。除了定義可擴展性測試的具體過程之外，SIG Scalability 還為當前可擴展性閾值創建了文檔，並定義了跨系統的一組新的服務級別指標（SLI）和服務級別目標（SLO)。

本次發布的scalability validation report：

https://github.com/kubernetes/features/blob/master/release-1.8/scalability_validation_report.md

主要內容

Workload API (apps/v1beta2)

Kubernetes 1.8 中添加了 apps/v1beta2，這個版本中包含了 DaemonSet，Deployment，ReplicaSet 和 StatefulSet。這些 API 將在未來的版本中逐步走向穩定。

API 的添加和遷移

• DaemonSet，Deployment，ReplicaSet 和 StatefulSet 的當前版本是 apps/v1beta2。

• 在 apps/v1beta2 中，StatefulSet 增加了 Scale 子資源。

• apps/v1beta2 中的所有類型都添加了相應的 Condition 類型。

行為變更

• 對於 apps/v1beta2 中的所有類型，因為與 kubectl apply 和 strategic merge patch 不兼容，因此 spec.selector 默認被禁用。用戶必須要顯式設置 spec.selector，並且如果 spec.selector 與 spec.template 中的 labels 不匹配，那麽這個對象是無效的。

• 由於這些類型的控制器對於 selector 的處理方式不一致，因此在 apps/v1beta2 中這些類型的 selector 將不能修改。這個限制可能會在將來被移除，但是也有可能會保留到穩定版本。如果用戶有些代碼依賴了可變的 selector，那麽這些代碼可以繼續使用 apps/v1beta1 版本的類型，但是還是應該開始修改這些代碼，不再依賴可修改的 selector。

• Extended Resource 是除了 kubernetes.io 以外的合法域名。Extended Resource 的值必須是整數。用戶可以使用任意合法的資源名，比如 [aaa.]my-domain.bbb/ccc， 而不是繼續使用 Opaque Integer Resource。Extended Resource 不是動態的，因此在 request 和 limit 中，同樣的 Extended Resource 的值必須是相同的。

• 由 kubeadm init v1.8 版本創建的默認的 Bootstrap Token 默認會在 24 小時後被刪除，防止集群重要信息泄漏。 用戶可以通過 kubeadm token create 創建一個新的 Bootstrap Token 或者通過給 kubeadm init 設置 –token-ttl 0 讓 Bootstrap Token 不會過期。默認的 Token 可以通過 kubeadm token delete 刪除。

• kubeadm join 現在將 TLS 啟動交給 kubelet 完成，而不是自己實現該過程。kubeadm join 會將啟動用的 KubeConfig 文件寫到 /etc/kubernetes/bootstrap-kubelet.conf。

默認值

• StatefulSet 和 DaemonSet 的 spec.updateStrategy 默認值在 apps/v1beta2 中為 RollingUpdate。如有必要，用戶可以手動設置為 OnDelete。

• selector 默認被禁用。

• apps/v1beta2 中相關類型的 spec.revisionHistoryLimit 的默認值均為 10。

• CronJob 的 spec.successfulJobsHistoryLimit 默認值為 3，spec.failedJobsHistoryLimit 的默認值為 1。

Workload API (batch)

• CronJob 已經遷移到了 batch/v1beta1。

• batch/v2alpha.CronJob 已經被廢棄並且在將來的版本中被移除。

• Job 現在能通過 spec.backoffLimit 設置失敗策略。該字段的默認值為 6。

• batch/v2alpha1.ScheduledJobs 已經被移除。

• Job 控制器現在分批創建 Pod，而不是之前的一次性創建。

• Job 現在可以設置一個較短的 spec.ActiveDeadlineSeconds。

Scheduling

• [alpha] 支持 Pod 優先級和 PriorityClass

• [alpha] 支持 Pod 基於優先級的搶占

• [alpha] 按條件給 node 打 taint

Storage

• [stable] 掛載選項

  • 把指定掛載選項能力從 beta 提升到穩定版

  • 在 PersistentVolume spec 中加入一個新的變量 MountOptions , 去指定掛載選項，從而代替原有的設置別名的方式

  • 在 StorageClass spec 中也加入 MountOptions，從而允許為動態提供的卷配置掛載選項。允許 k8s 管理員控制他們集群裏面使用的掛載選項

• [stable] 為 RWO 卷比如 iSCSI 和 FC 提供 Attach/Detach

• [stable] 暴露存儲使用信息

  • 通過 kubernetes metric API 暴露 PV 還剩下多少存儲空間可用

• [stable] 卷插件信息

  • 通過 kubernetes metric API 暴露執行某些操作的成功或者延遲信息，操作包括：mount/unmount/attach/detach/provision/delete

• [stable] 修改 Azure File, CephFS, iSCSI, Glusterfs 相應的 PV spec ，從而讓他們可以引用命名空間資源

• [stable] 支持 iSCSI 卷插件中定制每個卷 iSCSI initiator 名字

• [stable] 支持 FC 卷標識符的 WWID

• [beta] StorageClass 回收策略

  • 運行配置 StorageClass 中的回收策略，不像以前那樣，對於動態提供的卷，默認只能是 delete

• [alpha] 卷擴容

  • 運行通過 kubernetes API 對 volume 進行擴容

  • alpha 版本中，只對特定的 volume 進行擴容，但是並沒有做文件系統擴容

  • alpha 版本中，只實現了 Gluster 的擴容

• [alpha] 為本地臨時存儲提供隔離和管理功能

  • 對於新資源 ephemeral-storage, 運行設置容器的 requests/limits 和節點預留

  • ephemeral-stroage 包含了容器可能使用的所有磁盤空間

• [alpha] 掛載空間傳播

  • pod 聲明中，為 container 的 VolumeMount 新加一項 VolumeMount.Propagation

  • 這一新增項可以被設置為 Bidirectional, 從而讓容器的某個掛載傳播到主機或者其他容器中

• [alpha] 改進 Flexvolume 部署

  • 簡化 Flex volume driver 的部署

    • 自動發現並初始化新的 driver 文件，而不是像以前一樣，必須要求重啟 kubelet 和 controller-manager

    • 提供一個 DaemonSet 樣例，可以被用來部署 Flexvolume drivers

• [prototype] 卷快照

  • 允許通過 kubernetes API 觸發創建卷快照

  • 因為不支持快照前停止服務，所以，快照有可能數據不一致

  • 這個項目不在核心 kubernetes repo 裏面，在 https://github.com/kubernetes-incubator/external-storage/tree/master/snapshot 這裏

Node Component

kubelet

• [alpha] Kubelet 現在支持使用新的 CPU 管理器替代的容器級 CPU 關聯策略。

• [alpha] 應用程序現在可以通過在容器資源請求中使用新的 hugepages 資源來請求預先分配的 hugepages。

• [alpha] 增加對 Kubelet 動態配置的支持

• [alpha] 增加 CRI 校驗測試集和 CRI CLI

• [alpha] 增加硬件設備插件的 API

• [stable] 支持 CRI-O，已經通過所有的 e2es

自動擴展和度量指標

• Horizontal Pod Autoscaler 對自定義度量指標升級到 beta 版本。關聯的度量指標的 APIs 升級到 v1beta1版本。升級前查看需要的操作。

• 推薦使用 metrics-server 作為提供資源度量指標 API 的組件。它可以部署為插件，類似於 Heapster 的部署方式。

集群自動擴展器

• 集群自動擴展器升級為 GA

• 擴展集群支持 1000 個節點

• Pod 優雅停止時間為 10分鐘

• 處理區域庫存和故障

• 改良監控和錯誤報告

Auth

• [GA] RBAC 的 API 組已經從 v1beta1 提升到 v1。沒有引入 API 相關的修改。

• [beta] Advanced auditing 已經從 alpha 到 beta。和 alpha 相比 webhook 和 logging policy 格式相關的部分有所變化，可能需要修改。

• [beta] Kubelet certificate rotation through the certificates API（通過證書 API 輪換證書）功能已經從 alpha 變為 beta。RBAC 針對 certificates controller（證書控制器）配置的 cluster role（集群角色）已經被創建，用於訪問 kubelet 等的通用證書 API。

• [beta] SelfSujectRulesReview 是一個用於讓一個用戶了解他在一個 namespace 下有什麽權限的 API，已經被加入到了 authorization.k8s.io 這個 API 組內。這個批量查詢是為 UIs 根據用戶來展現和隱藏一些功能而設計的。並且這個 API 能讓用戶快速的了解他們自己的權限。

• [alpha] 基於 1.7 版本的工作之上允許對 secrets 等資源加密，將 resource 加密用的 key 存儲到外部的 KMS 系統中。該機制的實現除了支持最初基於文件的存儲外還允許和各種 KMS 系統集成。Google Cloud KMS 插件已經添加進來，一旦 Google 端的集成完成就能夠使用。

• Websocket 請求現在可以通過在 websocket subprotocol base64url.bearer.authorization.k8s.io 中 設置 bearer token 來通過 API server 的認證。

• Advanced audit 現在能夠正確的報告 impersonated user（模擬用戶）的信息。

• Advanced audit 策略現在支持匹配子資源和資源名稱，但是頂級資源不再能匹配子資源。舉個例子，”pods” 不再能匹配對 logs 子資源的請求。要使用 “pods/logs” 去匹配子資源。

• 之前一個被刪除 service account 或者 bootstrapping token secret 會被認為有效直到它們真的被回收。現在當 deletionTimestamp 一被設置它們就會失效。

• –insecure-allow-any-token 參數已經從 API server 刪除。使用這個參數的用戶應當使用 impersonation 頭替代它進行調試。

• NodeRestriction admission 插件現在允許一個節點驅逐綁定到自己身上的 pods。

• OwnerReferencesPermissionEnforcement admission 插件為了在一個 owner reference （所有者引用）上設置 blockOwnerDeletion ，現在需要對 referenced owner（被引用的所有者）的 finalizers 子資源具有 update 權限。

• 在 authorization.k8s.io API 組下的 SubjectAccessReview API 現在允許提供用戶的 uid。

• 在 kubelet 輪換它的客戶端證書後，它將關閉跟 API server 的鏈接去強制使用新證書握手。之前 kubelet 會保持已經存在的連接始終開啟，即使連接使用的證書已經過期並且被 API server 拒絕連接。

• PodSecurityPolicies 現在能夠指定一個白名單，用於記錄允許作為主機數據卷的路徑。

• API server 的認證現在緩存了成功認證的 bearer token 幾秒鐘。

• OpenID Connect 認證插件現在能夠在 username 和 groups 兩個 claim 前添加自定義的前綴，或者使用默認的前綴。通過 –oidc-username-prefix 和 –oidc-groups-prefix 兩個參數設置。舉個例子，認證插件能夠將用戶名為 “jane” 的用戶映射為 “google:jane”，通過設置 “google:” 這個 username 前綴。

• bootstrap token 認證插件現在能夠在 tokens 中配置除了 system:bootstrappers 之外的 groups。

• Advanced audit 允許記錄失敗的登陸請求。

• kubectl auth reconcile 子命令已經被添加用來應用 RBAC 資源。當傳入一個文件包括 RBAC roles，rolebindings，clusterroles，或者 clusterrolebindings，該命令能夠計算出覆蓋的權限並且添加遺漏的規則。

Cluster Lifecycle

kubeadm

• [beta] 一個新的 upgrade 子命令允許你使用 kubeadm 自動的升級一個 self-hosted 的集群。

• [alpha] 通過 kubeadm init 可以簡單的創建一個實驗性的 self-hosted 集群. 通過配置 SelfHosting 特性為 true: –feature-gates=SelfHosting=true 來開啟這個功能。

  • 註意: 在下一個發布版本，即 1.9 版本，Self-hosting 會作為部署控制組件的默認方式。

• [alpha] 一個新的 phase 子命令支持運行 kubeadm init 流程的子任務。結合更易獲取的配置，kubeadm 現在開始容易整合到高級的部署平臺中，比如 kops 和 GKE。

  • 註意: 這個命令目前放在 kubeadm alpha phase 子命令裏，在未來版本一定會放到頂級命令中。

kops

• [alpha] 支持裸機（非雲提供商）環境。

• [alpha] kops 現在支持 作為服務運行。

• [beta] GCE 支持從 alpha 升級為 beta。

Cluster Discovery/Bootstrap

• [beta] Bootstrap Tokens 這種認證和鑒別方法進一步優化。使用 Bootstrap Tokens 去添加新的節點變的容器很多。

Multi-platform

• [alpha] 一致的 e2e 測試套件開始支持 arm, arm64, 和 ppc64le 架構。

Cloud Providers

• [alpha] 支持可插拔的，out-of-tree 及 out-of-core 的雲提供商的功能得到了顯著的改善。

Network

network-policy

• [beta] 基於 CIDR 的 NetworkPlicy 策略支持。

• [beta] NetworkPolicy 中支持 EgressRules。

kube-proxy ipvs 模式

• [alpha] kube-proxy 支持 ipvs 模式。

API Machinery

kube-apiserver

• 修復了 APIService 自動註冊的問題。該問題曾影響添加或刪除 API 組的 HA API 的滾動重啟。

• [Alpha] Kubernetes API 現在支持指定條件的列表查詢。客戶端可以指定返回結果的數量，並且如果存在更多結果，則會返回一個token令牌，用於重復調用直到所有的結果被檢索到。歸功於 etcd3 提供的功能，結果列表與不執行分塊的列表調用相同。這允許服務器使用較少的內存和 CPU 響應非常大的列表。這個功能的入口是 APIListChunking 並且默認不開啟。1.9 版本，所有 informer 將會默認使用它。

• 忽視在 ResourceQuota 中超過寬限期即被標記為刪除的pod。

Dynamic Admission Control

• 當pod沒有初始化時，Pod spec 是變化的。API server 要求pod spec 是有效的, 即使pod未初始化。更新未初始化的pod的狀態是無效的。

• 現在使用 alpha 的初始化功能要求開啟 Initializers 功能入口。如果啟用 Initializersadmission 插件，此功能門將自動啟用。

• [Action required] metadata.initializers.pending[x].name 的驗證規則是收緊的. initializer 的名稱需要包括至少三個由點分隔的段。根據構建規則，你可以用pending initializers 創建對象，並且不依賴API server去添加pending initializers。如果你這樣做，更新現有的對象和配置文件中的initializer name，以符合新的驗證規則。

• 即使API服務器和節點在兩個單獨的網絡中，webhook admission 插件也能正常工作。例如，在GKE中。webhook author可以使用服務等DNS名稱作為共有名稱去生成wehhook的服務器證書。

• Action required:

• 以前，為admission webhook重新生成server證書, CN的值可以被忽略。現在，必須把它設為webhook服務的DNS名稱： <service.Name>.<service.Namespace>.svc.

Custom Resource Definitions (CRDs)

• [alpha] CustomResourceDefinition API現在可以選擇驗證CRD spec提供的基於JSON模式的自定義對象

• 你可以在 kube-apiserver 中通過 CustomResourceValidation 功能入口啟用這個功能。

Garbage Collector

• Garbage collector 現在支持通過 CustomResourceDefinition 或者 aggregated API servers 自定義API。Garbage collector controller 周期化的刷新，因此，期望在添加 API 與 Garbage collector開始管理它之間，有30秒的間隔。

Monitoring/Prometheus

• [action required] 在 prometheus 的 apiserver_request_* 系列中，WATCHLIST 作為動詞 WATCH。根據查詢的級別，一個新的 “scope” 標簽將被添加到所有的 apiserver_request_* 中，這個值可以是’cluster’, ‘resource’, 或者是 ‘namespace’。

Go Client

• 添加客戶端垃圾郵件過濾的支持

轉載: https://blog.csdn.net/qq_34463875/article/details/78250552

kubernetes 1.8