共计 3958 个字符，预计需要花费 10 分钟才能阅读完成。
本篇内容主要讲解“升级 Kubernetes 1.18 前要注意哪些问题”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让丸趣 TV 小编来带大家学习“升级 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 应用程序，该程序执行以下任务：
响应最终客户的请求（前端）
处理客户端提供的数据（包括执行大量 CPU 操作，例如 map-reduce）。
处理不太重要的数据（例如，存档、清理等）
从上述内容明显看出，任务 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 前要注意哪些问题”有了更深的了解，不妨来实际操作一番吧！这里是丸趣 TV 网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
