Release Note 解讀(1.15, 1.16)
作者 | 張曉宇、黃珂、魯金達、李傳雲、陳俊、高相林
前言
- Kubernetes v1.15 由 25 個增強功能組成:2 個進入穩定,13 個進入 Beta,10 個進入 Alpha;
- Kubernetes v1.16 由 31 個增強功能組成:8 個進入穩定,8 個進入 Beta,15 個進入 Alpha。
是以從 1.14 盡快更新至 1.16 非常必要,以下将一一進行解讀。
Node
1.15
- 已廢棄的 kubelet 安全控制參數 AllowPrivileged、HostNetworkSources、HostPIDSources 和 HostIPCSources 已被移除。取而代之的是一些準入控制(例如 PodSecurityPolicy)來增強這些限制;
- 已棄用的 kubelet 啟動參數
已被删除,相關 kubelet 腳本需要同步進行清理;--allow-privileged
- kubelet 僅收集節點、container runtime、kubelet、Pod 和容器的 cgroups metrics。
1.16
- Node 的 labels beta.kubernetes.io/metadata-proxy-ready, beta.kubernetes.io/metadata-proxy-ready 和 beta.kubernetes.io/kube-proxy-ds-ready 将不再打給新的 Node,而被以下 label 替換:
- beta.kubernetes.io/masq-agent-ds-ready -> node.kubernetes.io/masq-agent-ds-ready
- beta.kubernetes.io/kube-proxy-ds-ready -> node.kubernetes.io/kube-proxy-ds-ready
- beta.kubernetes.io/metadata-proxy-ready -> cloud.google.com/metadata-proxy-ready
- kubelet 的功能啟動參數
,HugePages
VolumeScheduling
和CustomPodDNS
已經被移除。PodReadinessGates
-
在 1.14 被廢棄,在 1.16 正式被移除;--containerized
- Node 的 label
和beta.kubernetes.io/os
在 1.14 被廢棄,在 v1.18 将正式被移除;beta.kubernetes.io/arch
- cadvisor metric 的 pod_name 字段 container_name 被 pod 和 container 替代,所有 Prometheus 相關的查詢需要做相關更新更新。
scheduler
- 當 QOS 為 Best effort 的 Pod 的 Tolerations 出現沖突時,即它的 key 和 effect 均相同,則用使用最後一個 Toleration 作為最終排程的依據;
- PodAffinity 的性能優化,提升了約兩倍。
- 排程器使用 v1beta1 Event API。涉及改 API 的相關的工具需要同步更新;
- Pod 打散限制已經進入 alpha 階段。使用者可以通過這些限制在整個叢集對 Pod 進行打散部署。
CRD
- Custom resources:CRD 作為對 Kubernetes 的擴充,被廣泛運用。自 v1.7 版本起,CRD 已經在 Beta 版中可用。在 1.16 版本中,CRD 正式步入 GA 階段(穩定階段);
- Admission webhook:Admission webhooks 作為 Kubernetes 擴充機制被廣泛使用。自 v1.9 版本以來已經在 Beta 版中可用。在 1.16 版本中,Admission webhook 也正式步入 GA 階段(穩定階段);
- Overhauled metrics:Kubernetes 廣泛使用一個全局 metrics registry 來注冊要公開的 metrics。通過實作 metrics registry,metrics 可以以更透明的方式注冊。而在這之前,Kubernetes metrics 被排除在任何穩定性需求之外;
- Volume Extension:新版本有大量和 Volume 及 Volume 修改相關的增強。CSI 規範中對 Volume 調整的支援正在轉向 Beta 版,它允許任何 CSI spec Volume plugin 都可以調整大小。
API Server
- PodPriority 預設為 true,相關 featuregate 将在 1.18 被廢除;
- WatchBookmark 特性進入 beta 階段,并預設開啟。該功能修複了長時間沒有獲得 event 的 Watch 請求在下一次 Watch 請求時需要重新 List 資源的問題。
API changes
- 所有 apps/v1beta1 和 apps/v1beta1 下的資源,使用 apps/v1 替代
- 位于 extensions/v1beta1 下的資源 daemonsets, deployments, replicasets, etc. 使用 apps/v1 替代
- 位于 extensions/v1beta1 下的資源 networkpolicies,使用 http://networking.k8s.io/v1 替代
- 位于 extensions/v1beta1 下的資源 podsecuritypolicies,使用 policy/v1beta1 替代
使用 --runtime-config 标志可以臨時啟用這些資源(不建議使用,建議切換到更穩定的 Scheme 版本):
- apps/v1beta1=true
- apps/v1beta2=true
- extensions/v1beta1/daemonsets=true,extensions/v1beta1/deployments=true,extensions/v1beta1/replicasets=true,extensions/v1beta1/networkpolicies=true,extensions/v1beta1/podsecuritypolicies=true
這些資源的 API 将在 1.18 中被完全删除。
- Aggregated discovery requests 現在會 timeout. Aggregated API servers 必須在 5 秒内完成 discovery calls。(其他請求可以長一些)
使用啟動參數
EnableAggregatedDiscoveryTimeout=false
可以将逾時時間延長至之前的 30 秒。但是
EnableAggregatedDiscoveryTimeout
将會在 1.17 時被移除。
storage
之前要想使用 CSI,隻能通過 PV 和 PVC 組合的方式。有了 Inline CSI volume 這個能力,可以在定義 Pod 的時候,聲明一個與其密切相關的 CSI Volume。Volume 随着 Pod 的建立而建立,Pod 的銷毀而銷毀。
在建立 PVC 時,可以克隆已經存在的一個 PVC,包括卷的規格以及卷的資料。可用于資料遷移,構模組化拟線上環境等場景。需要注意的是該能力隻會支援 CSI,In-tree 插件和 FlexVolume 不會有支援。
- 同時 storage sig 也一直在為 In-tree 存儲插件遷移到 CSI 而努力, 點選了解更多 。
- ephemeral-storage 額度監控增強
過去 kubelet 通過定期掃描檔案方式采集 ephemeral-storage 空間使用情況。在 1.15 中引入了
project quotas。project quota 相比定期掃描方式,擁有更快的速度和準确性。如果檔案被打開,後來删除了,掃描的方式是無法追蹤到它,實際檔案還占着空間,
未來,還可以利用 project quotas 的能力,來強制限制每個 Volume 可使用的空間(拒絕達到空間後的 IO 寫操作)。這樣可以避免因為某個不重要的容器的存儲寫滿,導緻整個 Pod 被驅逐的情況,也更加貼近 "isolation" 的語義。
Feature 穩定性變化
- PVs 線上容量調整進入 Beta 階段。
線上容量調整,可以在 Pod 不進行重建的情況下,完成容量的擴容。
- SubPath 支援使用環境變量進入 Beta 階段。
利用 subPath 可以實作多個 Pod 使用同一 Volume 的子路徑。使用 subPathExpr 參數,可以使用 Downward API 環境變量來為每個 Pod 建構獨特的子路徑。比如以每個 Pod 的 Name(subPathExpr: $(POD_NAME) 将 Volume 的子路徑綁定到 Pod 的同一個挂載點,實作 Pod 間資料的隔離。
- CSI 支援 Windows 。Windows 使用者福音,從 1.16 開始,CSI 也支援 Windows node 了;
- 克隆 PVC 進入 Beta 階段;
- Ephemeral Inline CSI volumes 支援進入 Beta 階段;
- CSI Volume resizing 支援進入 Beta 階段。
Network
- kube-proxy 允許在使用 ipvs 時無感重新開機、切換模式時不再自動清理規則、禁用 UDP 平滑終止;
- service.spec.externalName 允許結尾有個 dot;
- 其它一些小的 bugfix
IPv4/IPv6雙棧(alpha)
可以将 IPv4 和 IPv6 位址配置設定給 Pods 和 Services,為 IPv6 化程序邁出重要的一步,在 Kubernetes 叢集上啟用 IPv4/IPv6 雙協定棧可提供下面的功能:
- 每個 pod 配置設定一個 IPv4 和 IPv6 位址
- 可使用支援 IPv4 or IPv6 的 Service
- Pod 的出站流量可通過 IPv4 和 IPv6 路由
EndpointSlice API(alpha)
目前的一個 Service 對象在實作上對應了一個 K8s Endpoints 對象,該對象包含了所有的 backend Pods 資訊,随着 backend Pods 的規模的增大,單個 backend Pod 的 Add/Update/Delete 對管控元件 (apiserver, etcd, endpoints-controller, kube-proxy) 會造成很大的壓力。
通過引入 EndpointSlice API,将 backend Pods 資訊分片放入不同 EndpointSlice (一個 Service 包含多個 EndpointSlice 對象,一個 EndpointSlice 包含多個 Endpoint <一個 Endpoint 對應一個backend執行個體資訊> - 預設最多 100 個) 解決性能問題的同時也為提供其他網絡特性保留了高度的擴充性,如在 Endpoint 中包含了 backend 服務執行個體的拓撲位置資訊 (region, zone,hostname 等) 可以用來幫助就近路由通路 Service 的請求。
對于 Service LoadBalancers 的 Finalizer Protection 進入 beta 階段
這個功能確定 Service 資源對象不會被徹底删除直到相關的 load balancer 被删除。
API Changes
- NetworkPolicy: extensions/v1beta1 棄用,用 networking.k8s.io/v1 API 替代;
- Ingress: extensions/v1beta1 棄用,用 networking.k8s.io/v1beta1 API 替代。