[转帖]重磅前瞻！Kubernetes 1.18即将发布：OIDC发现、Windows节点支持，还有哪些新特性值得期待？

重磅前瞻！Kubernetes 1.18即将发布：OIDC发现、Windows节点支持，还有哪些新特性值得期待？

https://www.kubernetes.org.cn/7036.html

 

根据Kubernetes官方计划，明日Kubernetes 1.18版本即将发布!

一些将对社区产生影响的新特性日渐完善，如 KSA（Kubernetes Service Account） tokens的OIDC发现和对Windows节点的支持。此外，一些在Alpha状态下运行了很久的特性，也重新成为新的焦点，如ingress或API Server网络代理。1.18版本共有13个特性逐渐稳定，这是所有新变化的1/3! 究竟都有哪些强大且新奇的功能更新，一起拭目以待！

翻译：小雀
技术校对：Jay/晓曦
Kubernetes 1.18 精选

在这个版本中，这些功能看起来最令人兴奋：

1393 OIDC discovery for service account token issuer

使用Kubernetes API令牌作为通用身份验证机制，可以改变企业组建基础设施的方式。它允许我们进一步集成服务，如集群之间的通信，通过简化外部不必要的身份验证服务来简化设置。

1513 CertificateSigningRequest API

Certificate API是用于核心组件的另一特性，已开始用于第三方服务。这一增强是Kubernetes适应社区需求的例子，它使得提供证书更便捷，更安全。

1441 kubectl调试

在调试运行pods时，新命令将带来巨大的差异。创建调试容器或使用不同配置重新部署pod，这些常见任务从此刻起将变得更快。

1301在Windows上实现RuntimeClass

能够指定哪些pod必须在Windows机器上运行，这将允许在同一集群上混合Windows和Linux工作负载，从而打开了新的维度。

1001在Windows上支持CRI ContainerD

这是提高Windows节点上Kubernetes兼容性的一大步，不过我们在将来的版本中才能看到它的全貌。通过这样的小升级，Kubernetes展示出他们对Windows支持的认真态度。

Kubernetes 1.18核心

1393为服务帐户令牌发布方提供OIDC发现

阶段:Alpha
功能组:身份验证

Kubernetes服务帐户(KSA)可以使用令牌(JSON Web令牌或JWT)对KubernetesAPI进行身份验证，例如使用kubectl –token .但是，Kubernetes API是目前唯一能够验证这些令牌的服务。

由于Kubernetes API服务器不能(也不应该)从公共网络访问，一些工作负载必须使用独立的系统进行身份验证。比如，跨集群身份验证。

此增强的目的是提高KSA令牌的实用性，允许集群之外的服务用作通用身份验证方法，而无需重载API服务器。为实现这点，API服务器提供了一个OpenID Connect (OIDC)发现文档，其中包含令牌公钥和其他数据。验证者可以使用这些密钥来验证KSA令牌。

使用ServiceAccountIssuerDiscovery功能开关启用OIDC发现，并且进行一些配置使其工作。

853 HPA可配置伸缩速率

阶段：Alpha
功能组：自动伸缩

Horizontal Pod Autoscaler（HPA）可以自动缩放资源中的Pod数量，调整工作负载需求。目前，只能为整个群集定义全局资源伸缩。而无法为你希望选择的核心服务提供资源调节。

现在，将行为添加到HPA配置中：

 

在上述示例中，当需要增加时，pod每15秒可以翻倍。当需要减少时，每分钟可以移除4个pod。

1513 CertificateSigningRequest API

阶段:Beta版的重大变化
功能组:身份验证

每个Kubernetes集群都有根证书颁发权限组件，用于保护核心组件之间的通信，这些组件由Certificates API处理。最终它开始用于为非核心用例提供证书。

这一改进的目的是适应新的形势，改进签署进程及其安全。

注册中心不仅需要确保实际请求者提交了证书签名请求(CSR);还要确保请求者具有提交请求的适当权限。

调度

1451运行多个调度配置文件

阶段:Alpha
功能组:调度

不是Kubernetes集群的所有工作负载都是相同的，有的希望将web服务器分布在尽量多的节点上，也可能希望同一节点捆绑更多的延迟敏感资源。这就是为什么可以在同一集群内配置多个调度器，并指示每个pod使用哪个调度器的原因。

但是，这可能会导致竞争，因为每个调度器在特定时刻可能有不同的集群视图。

此增强允许使用不同的配置或配置文件运行一个调度器，每个调度器都有自己的schedulerName。Pods将使用schedulerName来定义要使用什么配置文件，它将由同一个调度器来完成这项工作，从而避免竞争。

895 Pod跨故障域均匀扩展

阶段:升级到Beta版
功能组:调度

使用topologySpreadConstraints，可以定义规则，在多区域集群中均匀分布pods，保证高可用性，并提高资源利用率。

1258添加可配置的默认偶数Pod扩展规则

阶段:Alpha
功能组:调度

为了充分利用even pod的扩展，每一个pod都需要自己的扩展规则。此增强功能允许定义全局defaultConstraints，这些约束将在群集级别应用于，所有未定义自己的topologySpreadConstraints的pods。

166基于污点的驱逐

阶段：稳定版
功能组：调度

在Kubernetes 1.13中，基于污点的驱逐从alpha阶段转移到beta阶段。启用此功能时（TaintBase Devitions=true in–feature gates），NodeController（或kubelet）会自动添加污点，并禁用以前基于就绪NodeCondition从节点逐出pod的逻辑。

节点

#1539扩展Hugepage特性
阶段：稳定版的重要变化
功能组：节点

HugePages是一种机制，它可以预留具有预定义大小的大内存块，由于硬件优化，访问速度更快。这对于处理内存中的大数据集或对内存访问延迟敏感的应用（如数据库或虚拟机）尤其有用。

在Kubernetes 1.18中，该特性增加了两个增强功能。

首先，pod现在可以请求不同大小的HugePages。

其次，已经对HugePages进行了容器隔离，解决pod可能会使用比请求更多的内存，从而导致资源匮乏的问题。

688 Pod开销:计算绑定到Pod沙箱的资源，但不是特定容器

阶段:升级到Beta版
功能组:节点

除了请求的资源外，pod还需要额外资源来维护其运行时环境。

启用Pod Overhead特性后，Kubernetes在调度pod时将考虑这一开销。Pod overhead将在开始时被计算并固定下来，它与Pod的运行时类相关联。

693节点拓扑管理器

阶段:升级到Beta版
功能组:节点

机器学习、科学计算和金融服务都是计算密集型系统，需要超低延迟。这些类型的工作负载需要将进程隔离到一个CPU内核，而不是在内核之间跳转或与其他进程共享。

节点拓扑管理器是一个kubelet组件，它集中协调硬件资源分配。当前的方法将此任务分配给几个组件(CPU管理器、设备管理器、CNI)，有时会导致分配不是最优化。

950为启动缓慢的pod增加启动存活探测延迟

阶段:升级到Beta版
功能组:节点

探测器允许Kubernetes监视应用程序的状态。如果pod启动时间过长，探测器会认为pod已经死亡，导致一次重启。该特性允许定义startupProbe，推迟所有其他探测，来保证pod完成启动。例如，“在给定的HTTP端点可用之前，不要测试活性”。

网络

752EndpointSlice API

阶段：Beta版的重大变化
功能组：网络

新的Endpoint Slice API将端点拆分为多个endpoint slice资源。这解决了当前API中与大型endpoints对象相关的许多问题。新的API还支持未来的其他特性，如每个pod支持多个ip。

508 增加IPv6支持

阶段:升级到Beta版
功能组:网络

早在Kubernetes 1.9就引入了对IPv6集群的支持。这一特性已在社区进行过广泛测试，现在升级到Beta版。

1024NodeLocal DNSCache升级到GA版

阶段：GA
功能组：网络

NodeLocalDNSCache通过在集群节点上以Daemonset运行DNS缓存代理来提高集群DNS性能，该节点作为守护进程，从而避免了iptables DNAT规则和连接跟踪。该本地缓存代理查询kube-dns服务，以查找集群主机名的缓存缺失（默认情况下后缀为cluster.local）。

1453Graduate Ingress to V1

阶段：升级到Beta版
功能组：网络

Ingress资源将外部HTTP和HTTPS路由暴露为服务，集群中的其他服务可以访问这些路由。

API对象包含在Kubernetes 1.1中，是事实上的稳定特性。这次修改消除了Ingress实现之间的不一致，使它开始进入GA阶段。

例如，现在可以定义一个pathtype，以显式地声明路径是否应被视为前缀或完全匹配。如果Ingress中的多个路径匹配一个请求，那么最长的匹配路径优先。

此外，kubernetes.io/ingres.class注释已被弃用。现在使用新的ingresClassname字段和IngresClass资源。

#1507将AppProtocol添加到Services和Endpoints
阶段：GA
功能组：网络

EndpointSlice API在Kubernetes 1.17中添加了新的AppProtocol字段，允许为每个端口指定应用协议。此增强将该字段引入ServicePort和EndpointPort资源，替换体验不好的非标准注解。

Kubernetes1.18 API

#1040 API服务器请求的优先级和公平性
阶段: Alpha
功能组:api-machinery

高负载期间，Kubernetes API服务器负责管理和维护任务。现有的——max-requests-inflight和max-mutating-requests-inflight命令行标志可以限制传入的请求，但粒度太粗，在高流量期间会过滤掉重要的请求。

APIPriorityAndFairness功能开关在apiserver中启用了新的max-in-flight请求处理程序。使用FlowSchema对象定义不同类型的请求，RequestPriority对象分配资源。

例如，垃圾收集器就是一个低优先级的服务:

因此可以分配很少的资源给它：

自维护请求具有更高的优先级：

可以在增强建议中找到更多示例。

#1601 client-go签名重构，实现标准化选项和上下文处理
阶段:稳定版的重大变化
功能组:api-machinery

在client go上进行了一些代码重构，许多核心二进制文件使用这个库连接Kubernetes API，以保持方法签名的一致性。

包括向某些方法添加上下文对象，该对象跨API边界和进程之间carries request-scoped values。访问对象简化了一些特性的实现，比如在超时和取消后释放调用线程，或者添加对分布式跟踪的支持。

#576APIServer DryRun
阶段：升级到稳定版
功能组：api-machinery

Dry run模式允许模拟真实的API请求，并查看该请求是否成功（允许控制链、验证、合并冲突，…）和/或在不修改状态的情况下会发生什么。请求的响应主体应尽可能接近非dry-run运行响应。该核心特性将支持其他用户级特性，如kubectl diff子命令。

#1281 API服务器网络代理KEP迁移到Beta
阶段：升级到Beta版
功能组:api-machinery

云提供商更喜欢将集群APIServer隔离在单独的控制网络中，而非集群网络中。实现此目的的方法之一是，在保持与其他集群组件连接的同时，使用Kubernetes APIServer网络代理。

拥有这一额外层可以启用其他功能，如元数据审计、日志记录和对外API Server连接的验证。

增强包括修复问题和为实现一般可用性准备代理，比如从Kubernetes API服务器删除SSH隧道代码，以及改进控制网络与集群网络的隔离。

Kubernetes 1.18中的Windows支持

#1001Windows CRI ContainerD支持
阶段：Alpha
功能组：windows

ContainerD是一个与OCI兼容的运行时，它与Kubernetes一起工作。与Docker相反，ContainerD在WindowsServer 2019中包含对主机容器服务（HCS v2）的支持，这为如何管理容器提供了更多的控制，并可以改进Kubernetes API的一些兼容性。

此增强功能将Windows中的ContainerD1.3支持作为容器运行时接口（CRI）引入。

#1301 在Windows中实现RuntimeClass
阶段：Alpha
功能组：windows

使用RuntimeClass可以定义集群中存在的不同类型的节点，runtimeClassName指定在哪些节点中部署pod。这一特性是在Kubernetes 1.12中引入的，在kubernetes1.14上有较大变化。

此增强将功能扩展到Windows节点，这对于异构集群中，希望只在Windows节点上部署Windows pods非常有帮助。这是定义RuntimeClass的方法，从而将pods限制为WindowsServer1903（10.0.18362）版本。

然后在pods中使用runtimeClassName，如下所示：

 

689针对Windows工作负载的GMSA支持

阶段：升级到稳定版
功能组：windows

允许运营人员在部署时选择GMSA，使用它运行容器连接到现有应用程序，如数据库或API服务器，而无需更改组织内部的身份验证和授权方式。

1043 Windows的RunAsUserName

阶段：升级到稳定版
功能组：windows

现在Kubernetes支持组托管服务帐户，使用runAsUserNameWindows的特定属性来定义运行容器的entrypoint.。

995 Kubeadm for Windows

阶段:升级到Beta版
功能组:cluster-lifecycle

Kubernetes 1.14中引入了对Windows节点的支持，但是没有一种简单的方法可以将Windows节点连接到集群。

从Kubernetes 1.16开始，kubeadm join可用于具有部分功能的Windows用户。它将缺少一些特性，如kubeadm init或kubeadm join——控制平面。

存储

695跳过卷所有权更改（Skip Volume Ownership Change）

阶段：Alpha
功能组：存储

在将卷绑定到容器之前，所有文件权限都将更改为提供的fsGroup值。这在大规模的卷上将是一个缓慢的过程，还会破坏一些权限敏感的应用程序，如数据库。

新添加的FSGroupChangePolicy字段用来控制此行为。如果设置为“always”，将保持当前行为。当设置为OnRootMismatch时，它只会在顶级目录与预期的fsGroup值不匹配时更改卷权限。

1412 不可变Secrets and ConfigMaps

阶段：Alpha
功能组：存储

一个新的不可变字段被添加到Secrets和ConfigMaps中。当设置为true时，对资源键所做的任何更改都将被拒绝，从而保护集群不受意外的坏更新的影响。

第二个好处来自不可变资源。由于没有变化，Kubelet不需要定期检查更新，从而提高可伸缩性和性能。

在启用ImmutableEmphemeralVolumes功能门之后，可执行以下操作：

然而，一旦资源被标记为不可变，就无法恢复更改。只能删除和重建Secret，并且需要重建使用已删除Secret的pod。

1495 通用数据填充插件

阶段：Alpha
功能组：存储

此增强为允许用户创建预填充卷奠定了基础。例如，使用OS映像为虚拟机预填充磁盘，或启用数据备份和恢复。

为此，将解除持久卷的DataSource字段的当前验证，允许将任意对象设置为值。关于如何填充卷的实现细节被委托给专门构建的控制器。

770跳过不可附加CSI卷的附加

阶段：稳定
功能组：存储

这种内部优化将简化容器存储接口（CSI）驱动程序的VolumeAttachment对象的创建，这些驱动程序不需要附加/分离操作，如NFS或类似临时机密的卷。

对于驱动程序，Kubernetes Attach/Detach控制器创建VolumeAttachment对象，并等待它们被报告为“attached”。更改CSI卷插件就可以跳过这步。

351 Raw block device using persistent volume source

阶段：升级到稳定版
功能组：存储

BlockVolume在Kubernetes 1.18中达到一般可用性。只需将volumeMode的值设为block，就可以访问原始块设备。使用原始块设备而不使用文件系统抽象的能力，使Kubernetes能够为高I/O性能和低延迟的高性能应用程序提供更好的支持。

565 CSI块存储支持

阶段：升级到稳定版
功能组：存储

使用原始块设备而不依赖文件系统抽象的能力，使Kubernetes能够为高I/O性能和低延迟的应用程序（如数据库）提供更好的支持。

603 Pass Pod information in CSI calls

阶段：升级到稳定版
功能组：存储

CSI树外存储驱动程序可以接收，NodePublish请求中请求卷的Pod信息，如Pod名称和命名空间。

CSI驱动程序可以使用这些信息来授权或审计卷的使用，或者生成适合pod的卷内容。

989扩展允许的PVC数据源

阶段：升级到稳定版
功能组：存储

使用此功能，可以“克隆”现有的持久卷。克隆会导致从现有卷配置新的重复卷。