升级Kubernetes 1.18前,你不得不知的9件事

摘要:
本文来自RancherLabs。昨天,Kubernetes的最新版本v1.18发布。它包含38项增强功能,包括15项稳定版功能、11项测试版功能和12项alpha版功能。使用ServiceAccountToken作为通用身份验证方法,Kubernetes使用serviceaccount验证集群中的服务。Kubernetes 1.18提供了通过HPA行为字段配置弹性缩放的功能。即使在教程、大多数书籍和文献中,Linux也被普遍认为是运行Kubernetes的实际操作系统。然而,Microsoft Windows已采取相应措施支持Kubernetes在Windows Server产品上运行。现在,在Kubernetes 1.18中,RuntimeClass支持Windows节点。

本文来自Rancher Labs

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

升级Kubernetes 1.18前,你不得不知的9件事第1张

将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前,你不得不知的9件事》仅用于学习参考。如对内容有疑问,请及时联系本站处理。

上篇java注解反射简单实例利用FileWatcher实现文件实时监视下篇

宿迁高防,2C2G15M,22元/月;香港BGP,2C5G5M,25元/月 雨云优惠码:MjYwNzM=

相关文章

流式实时分布式计算的设计

https://blog.csdn.net/anzhsoft/article/details/38168025 1. 流式计算的背景和特点 现在很多公司每天都会产生数以TB级的大数据,如何对这些数据进行挖掘,分析成了很重要的课题。比如: 电子商务:需要处理并且挖掘用户行为产生的数据,产生推荐,从而带来更多的流量和收益。最理想的推荐就是根据兴趣推荐给用户本来...

docker 安装jumpserver

#docker 安装mkdir /etc/dockerecho "{    "registry-mirrors" : [    "https://registry.docker-cn.com",    "https://docker.mirrors.ustc.edu.cn",    "http://hub-mirror.c.163.com",    "ht...

Vert X 干法总结

Vert X优势:   1. 与基于阻塞 I/O 的传统堆栈和框架相比,以更少的资源处理更多的请求。Vert.x 非常适合各种执行环境,包括虚拟机和容器等受限环境。   2. Vert.x 是一个工具包,不是一个框架,所以它自然是非常可组合和可嵌入的(不同语言都可以)。     Vert.x运行在Java虚拟机上,支持多种编程语言,Vert.x是高度模块化...

技术实践第三期|HashTag在Redis集群环境下的使用

​简介:欢迎了解友盟+技术干货第三期内容:Redis集群环境如何按照前缀批量删除缓存。希望能对开发者们在实际应用中有所帮助。 一、背景 数据源列表添加缓存支持,types字段可传多值,如app, mini, web等,会构建如下缓存key, application_list:123456:app application_list:123456:mini...

Redis——集群(cluster)

前言 在前面的文章中,已经介绍了Redis的几种高可用技术:持久化、主从复制和哨兵,但这些方案仍有不足,其中最主要的问题是存储能力受单机限制,以及无法实现写操作的负载均衡。 Redis集群解决了上述问题,实现了较为完善的高可用方案。本文将详细介绍集群。 主要内容包括:集群的作用;集群的搭建方法及设计方案;集群的基本原理;客户端访问集群的方法;以及其他实践中...

k8s学习笔记之二:Pod

一、deployment部署pod 备注:// 部署pod到指定节点 在启动Pod的yaml文件中与containers同级别的位置添加如下两行即可 apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3...