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

本文来自Rancher Labs

昨天Kubernetes最新版本v1.18已经发布，其包含了38项功能加强，其中15项为稳定版功能、11项beta版功能以及12项alpha版功能。在本文中，咱们将探索其中一些功能，但愿能帮助你决定是否须要升级。那么，咱们如今开始吧！

将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！