我们专注攀枝花网站设计 攀枝花网站制作 攀枝花网站建设
成都网站建设公司服务热线:400-028-6601

网站建设知识

十年网站开发经验 + 多家企业客户 + 靠谱的建站团队

量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决

升级Kubernetes1.18前要注意哪些问题

本篇内容主要讲解“升级Kubernetes 1.18前要注意哪些问题”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“升级Kubernetes 1.18前要注意哪些问题”吧!

网站建设哪家好,找创新互联建站!专注于网页设计、网站建设、微信开发、微信小程序定制开发、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了宜昌免费建站欢迎大家使用!

将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 1.18前要注意哪些问题”有了更深的了解,不妨来实际操作一番吧!这里是创新互联网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!


文章名称:升级Kubernetes1.18前要注意哪些问题
文章来源:http://shouzuofang.com/article/poopgg.html

其他资讯