Kubernetes 1.18新特性

Kubernetes作为近几年火爆的容器管理平台,带来的是更多人的参与,新功能也不断增加。了解新版本的特性有助于了解k8s未来的发展方向和找到自己需要的功能。

一.新发布

最新版本v1.18已经发布,其包含了38项功能增强,其中15项为稳定版功能、11项beta版功能以及12项alpha版功能。在本文中,我们将探索其中一些功能,希望能帮助你决定是否需要升级。那么,我们现在开始吧!
file

二.具体特性

将Service Account Token作为通用身份验证方法

Kubernetes使用service account来验证集群内的服务。例如,如果你想要一个pod来管理其他Kubernetes资源,如Deployment或者Service,你可以与Service Account相关联并创建必要的角色和角色绑定。

Kubernetes Service Account(KSA)发送JSON Web Tokens(JWT)到API server以验证它们。这使API server成为service account身份验证的唯一来源。

那么,如果实体需要针对集群外的其他服务进行身份验证,该怎么办?为了使用其KSA,外部身份验证器必须联系API server以验证请求。

但是,API server不应公开访问。因为这使你可以使用其他身份验证系统进行验证,这会增加复杂性。即使第三方服务位于可以访问API server的集群中,也会增加负载。

于是在Kubernetes 1.18中增加了一个功能(#1393),该功能使API server提供OpenID Connect发现文档,该文档包含Token的公共密钥以及其他元数据。OIDC身份验证器可以使用此数据对token进行身份验证,而不必先引用API server。

为特定Pod配置HPA速率

Horizontal Pod Autoscaler(HPA)可以使你的Kubernetes集群对高/低流量自动做出反应。通过HPA,你可以指示controller根据CPU峰值、其他指标或者应用程序提供的指标来创建更多的Pod。

为了优化成本,HPA会在不需要多余的Pod(例如不再有高负载时)时将其终止。而HPA是以配置的速率增加/减少Pod,以避免在不稳定时间内产生/破坏波动的pod。但是,目前该功能仅在集群级别可以配置。在典型的微服务应用程序中,你经常拥有一些比其他服务更重要的服务。假设你在Kubernetes上托管一个Web应用程序,该程序执行以下任务:

  1. 响应最终客户的请求(前端)
  2. 处理客户端提供的数据(包括执行大量CPU操作,例如map-reduce)。
  3. 处理不太重要的数据(例如,存档、清理等)

从上述内容明显看出,任务1要求pod更快地扩展,以便应用程序可以快速有效地处理增加的客户端流量。此外,它们应该非常缓慢地缩小规模,以防再次出现流量高峰。

任务2需要pod也可以非常快地扩展以响应增加的数据量。在关键任务应用程序中,不应延迟数据处理。但是,它们也应该非常迅速地缩减规模,因为一旦不再需要,它们会消耗大量地资源,而无法将这些资源用于其他服务。

由于它们的重要性,我们可以在一定程度上容忍属于任务1和2的pod对误报做出响应。毕竟,浪费一些资源比失去客户要更好。

服务于任务3的pod不需要特别地安排,因为它们按照常规的方式扩展和缩小即可。

在Kubernetes 1.18中提供了功能(#853),允许通过HPA行为字段配置弹性伸缩。在行为字段下的scaleUp或scaleDown部分中分别指定了用于按比例缩放的行为。

在集群级别定义偶数Pod扩展规则

在Kubernetes 1.16中首次引入Even Pod Spreading,它可以确保以最高的可用性和资源利用率的方式在可用区上(如果你使用的是多区域集群)调度Pod。

该功能通过指定topologySpreadConstraints来发挥作用,通过搜索具有相同topologyKey标签的节点来识别区域。具有相同topologyKey标签的节点属于同一区域。该设置将pod均匀分配到不同区域中。但是,它的缺点是必须在Pod级别应用此设置。没有配置参数的pod将不会在故障域之间分布。

这一功能(#895)允许你为不提供任何topologySpreadConstraints的Pod定义default spreading constraints。已定义此设置的Pod将覆盖全局级别。

在Windows上支持Containerd 1.3

当我们谈论“Kubernetes”时,我们几乎第一时间想到的是Linux。即使在教程、大部分的书籍和文献中也普遍将Linux视为运行Kubernetes的事实上的操作系统。

然而,Microsoft Windows已经采取相应的措施来支持Kubernetes在Windows Server系列产品上运行。这些措施包括添加对Containerd运行时版本1.3的支持。Windows Server2019包含更新的主机容器服务(HCS v2),其功能是增强了对容器管理的控制,这可能会改善Kubernetes API的兼容性。

但是,当前的Docker版本(EE18.09)还未与Windows HCSv2兼容,只有Containerd可以使用。使用Containerd运行时可以在Windows操作系统和Kubernetes之间实现更好的兼容性,也将提供更多功能。该功能(#1001)引入了对Windows的Containerd 1.3版本的支持,并将其作为容器运行时的接口(CRI)。

在同一集群中支持RuntimeClass和多个Windows版本的标签

既然Microsoft Windows正在积极支持Kubernetes的各种功能,因此今天能够看到在Linux和Windows节点上运行的混合集群并不稀奇。早在Kubernetes 1.12就引入了RuntimeClass,而Kubernetes 1.14引入了主要的增强功能。

它可以让你选择容器运行时,并且其上运行特定的pod。现在,在Kubernetes 1.18中,RuntimeClass支持Windows节点。所以你可以选择节点来调度应仅在Windows上运行的Pod,该节点运行特定的Windows构建。

跳过Volume所有权更改

默认情况下,将volume安装到Kubernetes集群中的容器时,该volume内的所有文件和目录所有权都将更改为提供的fsGroup值。这样做的原因是使该volume可由fsGroup读取和写入。但是,这种行为在某些情况下并不是那么受欢迎。例如:

  • 某些应用程序(如数据库)对文件许可权和所有权修改很敏感。装入volume后,这些应用程序可能会停止启动。
  • 当volume很大(> 1TB)或者其中包含的文件和目录的数量很大时,chown和chmod操作可能会太长。在某些情况下,启动Pod时可能会导致超时。

该功能(#695)提供了FSGroupChangePolicy参数,将该参数设置为“always”,将保持当前行为。而设置为OnRootMismatch时,它只会在顶级目录与预期的fsGroup值不匹配时更改volume权限。

允许Secret和ConfigMap不可变

在Kubernetes早期,我们就已经使用ConfigMap来将配置数据注入到我们的容器中。如果数据十分敏感,那么则会使用Secret。将数据呈现给容器最常见的方式是通过挂载一个包含数据的文件。

但是,当对ConfigMap或Secret进行更改时,此更改将会立刻传递到安装了该配置文件的所有pod。也许这并不是将更改应用于正在运行的集群的最佳方式。因为如果新配置有问题,我们将面临停止运行应用程序的风险。

修改Deployment时,将通过滚动更新策略应用更改,在该策略中,将创建新的Pod,而旧的Pod在删除之前仍然有作用。该策略可以确保如果新的Pod无法启动,则该应用程序仍将在旧的Pod上运行。ConfigMap和Secret也采用了类似的方法,它们通过在不可变字段中启用不可变性。当对象不可变时,API将拒绝对其进行任何更改。

为了修改对象,你必须删除它并重新创建它,同事还要重新创建使用它的所有容器。使用Deployment滚动更新,可以在删除旧的Pod之前确保新的pod在新的配置中正常工作,以避免由于配置更改错误而导致应用程序中断。

另外,将ConfigMaps和Secrets设置为不可变,可以节省API server不必定期轮询它们的更改。通过启用ImmutableEmphemeralVolumes功能门,可以在Kubernetes 1.18中启用该功能(#1412)。

然后在ConfigMap或Secret资源文件中将不可变值设置为true,对资源键所做的任何更改都将被拒绝,从而保护集群不受意外的坏更新的影响。

使用Kubectl调试为用户提供更多故障排除功能

作为Kubernetes用户,当你需要查看正在运行的Pod时,你将受到kubectl exec和kubectl port-forward的限制。而在Kubernetes 1.18中,你还可以使用kubectl debug命令。该命令允许你执行以下操作:

将临时容器部署到正在运行的Pod。临时容器声明周期短,它们通常包含必要的调试工具。由于它们是在同一pod中启动的,因此它们可以访问具有相同网络和文件系统的其他容器。这在极大程度上可以帮助你解决问题或跟踪问题。

使用修改后的PodSpec重新就地启动Pod。这使你可以进行诸如更改容器的源镜像或权限之类的操作。

你甚至可以在主机命名空间中启动特权容器。这使你可以对节点问题进行故障排除。

三.总结

Kubernetes是一项不断变化的技术,每个版本中都添加了越来越多的功能。在本文中,我们简要讨论了Kubernetes 1.18中一些最有趣的新功能。但是,毋庸置疑,升级Kubernetes集群并不是一个容易做出的决定。希望文章里对一些功能的介绍,可以给予你一些有意义的参考。

如果你还想更详细地了解Kubernetes 1.18中的新功能以及其应用场景,赶紧来报名参加下周四晚上的Webinar!我们的宗旨是:demo、demo and more demo!

0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论