内容简介：文末点击【阅读原文】或访问以下链接即可报名：http://z-mz.cn/lMe8
最抢鲜的Kubernetes 1.18 线上Demo来了！ 下周四（4月2日）晚上8点半，《Kubernetes 1.18网研会》为你带来K8S 1.18的 新特性详解和实操演示 ，包括K8S拓扑管理器、IngressClass以及kubectl debug等等内容。
文末点击【阅读原文】或访问以下链接即可报名：
http://z-mz.cn/lMe8
昨天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应用程序，该程序执行以下任务：
-
响应最终客户的请求（前端）
-
处理客户端提供的数据（包括执行大量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是一项不断变化的技术，每个版本中都添加了越来越多的功能。在本文中，我们简要讨论了Kubernetes 1.18中一些最有趣的新功能。但是，毋庸置疑，升级Kubernetes集群并不是一个容易做出的决定。希望文章里对一些功能的介绍，可以给予你一些有意义的参考。
如果你还想更详细地了解Kubernetes 1.18中的新功能以及其应用场景，赶紧来报名参加下周四晚上的Webinar！我们的宗旨是：demo、demo and more demo！
原文链接：
https://www.magalix.com/blog/kubernetes-1.18-what-you-should-know
推荐阅读
Rancher 2.3实现K8S一键式升级！再也不用同步升级Rancher啦！
About Rancher Labs
Rancher Labs由CloudStack之父梁胜创建。旗舰产品Rancher是一个开源的企业级Kubernetes管理平台，实现了Kubernetes集群在混合云+本地数据中心的集中部署与管理。Rancher一向因操作体验的直观、极简备受用户青睐，被Forrester评为2018年全球容器管理平台领导厂商，被Gartner评为2017年全球最酷的云基础设施供应商。
目前Rancher在全球拥有超过三亿的核心镜像下载量，并拥有包括中国人寿、华为、中国平安、兴业银行、民生银行、平安证券、海航科技、厦门航空、上汽集团、海尔、米其林、丰田、本田、中船重工、中联重科、迪斯尼、IBM、Cisco、Nvidia、辉瑞制药、西门子、CCTV、中国联通等全球著名企业在内的共40000家企业客户。
点击【阅读原文】，预约K8S网研会！
↓↓↓
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
- 那些你不得不知的抢购业务要点
- 关于React Hooks，你不得不知的事
- 字符串格式化你不得不知的那些事儿
- 前端开发不得不知的ES6十大新特性
- Google开发者大会：你不得不知的Tensorflow小技巧
- 作为DBA不得不知的5大管理MYSQL的开源免费利器
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Programming Python
Mark Lutz / O'Reilly Media / 2006-8-30 / USD 59.99
Already the industry standard for Python users, "Programming Python" from O'Reilly just got even better. This third edition has been updated to reflect current best practices and the abundance of chan......一起来看看 《Programming Python》 这本书的介绍吧!
