镜像下载、域名解析、时间同步请点击
阿里巴巴开源镜像站前言
- Kubernetes v1.15 由 25 个增强功能组成:2 个进入稳定,13 个进入 Beta,10 个进入 Alpha;
- Kubernetes v1.16 由 31 个增强功能组成:8 个进入稳定,8 个进入 Beta,15 个进入 Alpha。
因此从 1.14 尽快升级至 1.16 非常必要,以下将一一进行解读。
一、Node
Kubernetes v1.15
- 已废弃的 kubelet 安全控制参数 AllowPrivileged、HostNetworkSources、HostPIDSources 和 HostIPCSources 已被移除。取而代之的是一些准入控制(例如 PodSecurityPolicy)来增强这些限制;
- 已弃用的 kubelet 启动参数
已被删除,相关 kubelet 脚本需要同步进行清理;--allow-privileged
- kubelet 仅收集节点、container runtime、kubelet、Pod 和容器的 cgroups metrics。
Kubernetes v1.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 替代。
“ 提供全面,高效和稳定的系统镜像、应用软件下载、域名解析和时间同步服务。”