本篇内容主要讲解“升级Kubernetes 1.18前要注意哪些问题”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“升级Kubernetes 1.18前要注意哪些问题”吧!
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。
Horizontal Pod Autoscaler（HPA）可以使你的Kubernetes集群对高/低流量自动做出反应。通过HPA，你可以指示controller根据CPU峰值、其他指标或者应用程序提供的指标来创建更多的Pod。为了优化成本，HPA会在不需要多余的Pod（例如不再有高负载时）时将其终止。而HPA是以配置的速率增加/减少Pod，以避免在不稳定时间内产生/破坏波动的pod。但是，目前该功能仅在集群级别可以配置。在典型的微服务应用程序中，你经常拥有一些比其他服务更重要的服务。假设你在Kubernetes上托管一个Web应用程序，该程序执行以下任务：
响应最终客户的请求（前端）
处理客户端提供的数据（包括执行大量CPU操作，例如map-reduce）。
处理不太重要的数据（例如，存档、清理等）
从上述内容明显看出，任务1要求pod更快地扩展，以便应用程序可以快速有效地处理增加的客户端流量。此外，它们应该非常缓慢地缩小规模，以防再次出现流量高峰。
任务2需要pod也可以非常快地扩展以响应增加的数据量。在关键任务应用程序中，不应延迟数据处理。但是，它们也应该非常迅速地缩减规模，因为一旦不再需要，它们会消耗大量地资源，而无法将这些资源用于其他服务。
由于它们的重要性，我们可以在一定程度上容忍属于任务1和2的pod对误报做出响应。毕竟，浪费一些资源比失去客户要更好。
服务于任务3的pod不需要特别地安排，因为它们按照常规的方式扩展和缩小即可。
在Kubernetes 1.18中提供了功能（#853），允许通过HPA行为字段配置弹性伸缩。在行为字段下的scaleUp或scaleDown部分中分别指定了用于按比例缩放的行为。
在Kubernetes 1.16中首次引入Even Pod Spreading，它可以确保以最高的可用性和资源利用率的方式在可用区上（如果你使用的是多区域集群）调度Pod。该功能通过指定topologySpreadConstraints来发挥作用，通过搜索具有相同topologyKey标签的节点来识别区域。具有相同topologyKey标签的节点属于同一区域。该设置将pod均匀分配到不同区域中。但是，它的缺点是必须在Pod级别应用此设置。没有配置参数的pod将不会在故障域之间分布。
这一功能（＃895）允许你为不提供任何topologySpreadConstraints的Pod定义default spreading constraints。已定义此设置的Pod将覆盖全局级别。
当我们谈论“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）。
既然Microsoft Windows正在积极支持Kubernetes的各种功能，因此今天能够看到在Linux和Windows节点上运行的混合集群并不稀奇。早在Kubernetes 1.12就引入了RuntimeClass，而Kubernetes 1.14引入了主要的增强功能。它可以让你选择容器运行时，并且其上运行特定的pod。现在，在Kubernetes 1.18中，RuntimeClass支持Windows节点。所以你可以选择节点来调度应仅在Windows上运行的Pod，该节点运行特定的Windows构建。
默认情况下，将volume安装到Kubernetes集群中的容器时，该volume内的所有文件和目录所有权都将更改为提供的fsGroup值。这样做的原因是使该volume可由fsGroup读取和写入。但是，这种行为在某些情况下并不是那么受欢迎。例如：
某些应用程序（如数据库）对文件许可权和所有权修改很敏感。装入volume后，这些应用程序可能会停止启动。
当volume很大（> 1TB）或者其中包含的文件和目录的数量很大时，chown和chmod操作可能会太长。在某些情况下，启动Pod时可能会导致超时。
该功能（#695）提供了FSGroupChangePolicy参数，将该参数设置为“always”，将保持当前行为。而设置为OnRootMismatch时，它只会在顶级目录与预期的fsGroup值不匹配时更改volume权限。
在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，对资源键所做的任何更改都将被拒绝，从而保护集群不受意外的坏更新的影响。
作为Kubernetes用户，当你需要查看正在运行的Pod时，你将受到kubectl exec和kubectl port-forward的限制。而在Kubernetes 1.18中，你还可以使用kubectl debug命令。该命令允许你执行以下操作：
将临时容器部署到正在运行的Pod。临时容器声明周期短，它们通常包含必要的调试工具。由于它们是在同一pod中启动的，因此它们可以访问具有相同网络和文件系统的其他容器。这在极大程度上可以帮助你解决问题或跟踪问题。
使用修改后的PodSpec重新就地启动Pod。这使你可以进行诸如更改容器的源镜像或权限之类的操作。
你甚至可以在主机命名空间中启动特权容器。这使你可以对节点问题进行故障排除。
到此，相信大家对“升级Kubernetes 1.18前要注意哪些问题”有了更深的了解，不妨来实际操作一番吧！这里是亿速云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
