400-565-1876
最新动态
时速云是一家专业的云原生应用及数据平台服务提供商,秉持“让计算产生价值,让数据成为资产”
的使命,致力于帮助客户实现数字化转型。

Kubernetes 1.19 正式发布,日志、存储、安全功能增强

Kubernetes 1.19 版本正式发布,这是2020年的第二个版本,也经历了 Kubernetes 诞生以来最长的发行周期,长达20周。新版本更新围绕以下主题:

结构化日志(Structured logging)


在 1.19 版本之前,Kubernetes 控制面的日志没有统一的格式,给后期的日志处理增加了困难。此次标准化了日志消息的结构,基于 klog 结构化的日志使得解析、处理、存储、查询和分析日志更加容易。

klog 库更新到了 v2.2.0 版本,增强了日志消息结构化,提供了用于格式化日志消息的接口,每个现有的格式化日志方法(Infof,Errorf)都通过结构化方法(InfoS,ErrorS)进行匹配,新的日志记录方法将日志消息作为第一个参数,将键值对列表作为可变参数的第二个参数。以此为基础可逐步引入结构化日志,而无需一次性调整个 Kubernetes 指向新的 API。

 

默认启用 EndpointSlices


EndpointSlices 是一个新的 API,提供了 Endpoints API 的可扩展的替代方案。EndpointSlice 跟踪支持服务的 Pod 的 IP 地址和端口,Readiness 探针和拓扑信息。

在 Kubernetes 1.19 中,默认将启用此功能,kube-proxy 从 EndpointSlices 而非 Endpoints 读取地址信息。该变化用户是无感知的,大型集群中伸缩性得到显着改善。它将在未来的 Kubernetes 版本中启用重要的新功能,例如拓扑感知路由。

 

CSI 卷运行状况监控(CSI Volume health monitoring)


CSI 运行健康监控的 alpha 版本随着 Kubernetes 1.19 同时发布。此功能可以让 CSI 驱动程序与 Kubernetes 共享来自底层存储系统卷的异常信息,可以将异常作为事件报告在PVC 或 Pod 上面,此功能也将是 Kubernetes 程序化检测和处理单个卷健康状况的基础。

 

存储容量追踪(Storage capacity tracking)


传统上,Kubernetes 调度器具有一项前提性的假设:在集群中任何地方都可以使用其他额外的持久性存储,并且它的容量都是无限的。拓扑已经约束处理了第一点,但是到目前为止,Pod 调度时却仍然不能感知到剩余的存储容量大小是否足够可以启动这个新的 Pod,存储容量追踪是一项新的 alpha 特性,它可以通过 CSI 驱动程序添加 API 来报告存储容量的具体信息,并在 Pod 调度选择节点的时候使用该信息,这项功能可以作为本地存储和其他对容量限制比较敏感的卷类型的动态预配置基础。

 

临时通用卷(Generic ephemeral volumes)


Kubernetes 提供了很多卷插件,它的生命周期与 Pod 绑定,可以用作临时空间,比如内置的 emptydir 卷类型,也可以将一些其他的数据挂载到 Pod 中,比如内置的 Configmap 和 Secret 卷类型等。新的通用临时卷 alpha 功能将可以实现把任何支持动态资源调配的现有存储驱动程序用作临时卷,可以用来提供与根磁盘不同的临时存储,比如持久内存或者当前节点上的独立本地磁盘,支持卷配置的所有 StorageClass 参数,同时 PersistentVolumeClaims 所具有的所有功能,比如存储容量跟踪、快照和恢复以及卷大小调整等,也都可以在临时通用卷中获得支持。

 

不可变 Secret 和 Configmap


Pod 使用 Secret 和 Configmap 最多的方式就是把它们挂载为一个文件, 对 Secret 和 Configmap 的更改会很快反映到 Pod 中相应的文件上, 如果将 Secret 或 Configmap 改成了错误的配置,则可能会影响所有使用了该 Secret 或Configmap 的Pod。当需要更新 Secret 或 Configmap 的时候,更加推荐的方式是创建新的 Secret 或 Configmap,然后更新 podTemplate. 同时由于 Secret 或 Configmap 是可变的,Kubelet 不得不 Watch 那些被 Running 状态的 Pod 所使用的 Secret 或Configmap。

在 Kubernetes 1.19 版本中,在创建 Secret 或 Configmap 的时候可以使用 “immutable: true” 将它们标记为不可变。这样做有两个好处:

  • 减少 API Server 的负载,因为有一些 Watch 不必要了。
  • 可以避免一些对 Secret 或 Configmap 错误更改导致的 Pod 崩溃的情况。

 

CVE-2020-8559 漏洞修复


CVE-2020-8559 是一个权限提升( Privilege escalation)的安全问题,当一个攻击者可以劫持发给 Kubelet 的请求,他们可以给请求端一个重定向响应,这样就可以让请求端使用刚才发起请求的时候所用的证书去向攻击者返回的 Location 发起请求。这可能会危害到其他的节点。如果多个集群使用了被客户端信任的同样的 CA 和认证证书,这个漏洞可能会允许攻击者通过构造重定向响应让客户端向其他集群发起请求。

目前的修复手段是在 apimachinery/pkg/util/proxy/upgradeaware.go 中的 ConnectWithRedirects 中如果开启requireSameHostRedirects 并且原始请求的 hostname 和重定向响应的 hostname 不一致的时候会直接返回异常,在apimachinery/pkg/util/proxy/upgradeaware.go 中的tryUpgrade 会进行 statusCode 检查,如果不是 101 且小于 400 则会向客户端发送一个自己构造的异常。

修复后 API Server 将不会再代理响应为非 101 的 upgrade requests。这个修复可能会影响一些对 upgraderequests 返回状态码不是 101 的并且由 APIServer 代理的服务(比如 extension API server)

 

DefaultPodTopologySpread 插件改名为 SelectorSpread


拓扑散布(Topology Spread)约束可以用来控制 Pod在集群多个失效域(如 region、zone、节点,或用户自定义的拓扑域)之间的分布,通过拓扑散布可以实现高可用,并提高集群资源利用率。用于该功能的插件 DefaultPodtopologySpread 由于与一个新的 Feature Gate 同名,为了避免产生混淆,将插件名字修改为 SelectorSpread。当启用 DefaultPodTopologySpread Feature Gate 的时候,SelectorSpread插件将会被禁用。

 

废弃 hyperkube


随着 Kubernetes 1.19 的发布,社区不再提供 hyperkube 的二进制文件,并且基础镜像也从kubernetes/kubernetes  仓库剥离到 kubernetes/release 中, 为后续基础镜像由 debian 转向 distroless 做准备。

原文链接:https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md