kubernetes 1.8

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