Kubernetes 1.18 福履将之

Kubernetes 1.18即将发布! 在发布了1.17的小版本之后,1.18变得日益健壮并充满了新颖性。 关于新版本的介绍从哪里开始?

有一些新功能,例如API Server对OIDC的支持以及kubelet关于Windows节点的功能增强,这些都会对用户产生重大影响。

我们也很高兴看到长时间处于Alpha状态的某些功能被重新考虑而备受关注,例如Ingress或API Server Network Proxy。

此外,我们庆祝即将升级到稳定版的13个功能。 这涵盖了所有新变化的三分之一内容!

以下为Kubernetes 1.18中新功能的详细列表。


一、版本维护

维护周期

Kubernetes 发现版本的通常只维护支持九个月,在维护周期内,如果发现有比较重大的 bug 或者安全问题的话,
可能会发布补丁版本。下面是 Kubernetes 的发布和维护周期。

Kubernetes 版本 发行月份 终止维护月份
v1.11.x 2018 年 6 月 2019 年 3 月
v1.12.x 2018 年 9 月 2019 年 6 月
v1.13.x 2018 年 12 月 2019 年 9 月
v1.14.x 2019 年 3 月 2019 年 12 月
v1.15.x 2019 年 6 月 2020 年 3 月
v1.16.x 2019 年 9 月 2020 年 6 月
v1.17.x 2019 年 12 月 2020 年9 月

二、Kubernetes 1.18 主要变更

核心变更

  1. #1393 为服务帐户提供OIDC的支持

维护阶段:Alpha
SIG-Group:auth

Kubernetes服务帐户(KSA)可以使用令牌(JSON Web令牌或JWT)对Kubernetes API进行身份验证,例如使用kubectl –token 。需要注意的是,Kubernetes API是唯一可以验证这些令牌的服务。

由于无法(也不应该)从公共网络访问Kubernetes API服务器,因此某些工作负载必须使用单独的系统进行身份验证。比如跨群集进行身份验证时,从群集内部到其他地方进行身份验证。

此增强功能旨在让KSA令牌更实用,从而使群集外部的服务可以将它们用作常规身份验证方法,而不会使API Server过载。为此,API服务器提供了一个OpenID Connect(OIDC)相关文档,其中包含令牌公共密钥以及其他数据。现有的OIDC身份验证者可以使用这些密钥来验证KSA令牌等。

可以使用ServiceAccountIssuerDiscovery功能门启用OIDC发现,但需要进行一些配置才能使用。

  1. #853 HPA的扩展速度可配

维护阶段:Alpha
SIG-Group:autoscaling

HPA可以自动扩展Pod的数量,以满足调整工作负载的需求。 到目前为止,您只能为整个集群定义全局缩放速度。 但是,并非所有应用场景的使用资源情况都一样,因此您可能更需要的是针对特殊群体的扩展效率的个性化方案。

现在,可以将这些需求添加到HPA配置中:

1
2
3
4
5
6
7
8
9
10
11
behavior:
scaleDown:
policies:
- type: Percent
value: 100
periodSeconds: 15
scaleUp:
policies:
- type: Pods
value: 4
periodSeconds: 60

在此示例中,pod可以每15秒加倍。 缩容时,每分钟可以减少四个pod。 检查文档中的完整语法。

  1. #1513 CertificateSigningRequest API

维护阶段:Beta
SIG-Group:auth

每个Kubernetes集群都有一个根证书颁发机构,该CA用于保护核心组件之间的通信,这些组件由Certificates API处理,它开始用于为非核心用途提供证书。

此增强功能旨在适应新的应用场景,从而改善签名过程及其安全性。

注册机构的数字,即批准者,确保实际的请求者已经提交了证书签名请求(CSR); 同时他们还确保请求者具有提交该请求的适当权限。

CertificateSigningRequest-API

调度

  1. #1451 运行多个调度配置文件

维护阶段:Alpha
SIG-Group:scheduling

并非Kubernetes集群中的所有工作负载都相同。您很可能希望将Web服务器分布在尽可能多的节点上,同时您可能希望在同一节点中捆绑尽可能多的对延迟敏感的资源。这就是为什么您需要在同一集群中配置多个调度程序,并指定每个Pod使用哪个调度程序的原因。

但是,这可能会导致竞争状况,因为每个调度程序在给定时刻可能具有不同的集群资源数据。

此增强功能使您可以运行一个具有不同配置的调度程序,每个配置都有其自己的调度名称。 Pod会继续使用schedulerName来定义要使用的配置文件,但是它将由相同的调度程序来完成工作,从而避免出现竞争情况。

  1. #895 topologySpreadConstraints

维护阶段:升级到Beta
SIG-Group:scheduling

使用topologySpreadConstraints,您可以定义规则以在整个多区域群集中均匀分布pod,因此高可用性将正确运行,并且资源利用率将得到提高。

在1.16版本的Kubernetes新增功能中了解更多信息。

  1. #1258添加可配置的默认Even Pod传播规则

维护阶段:Alpha
SIG-Group:scheduling

为了利用均匀的pod扩散优势,每个pod都需要有自己的扩散规则,这可能是一项繁琐的任务。

通过此增强功能,您可以定义全局defaultConstraints,这些默认defaultConstraints将在群集级别应用到所有未定义其自己的topologySpreadConstraints的Pod。

  1. #166基于污点驱逐

维护阶段:GA
SIG-Group:scheduling

在Kubernetes 1.13中,基于污点的驱逐的功能,在从alpha阶段变为beta阶段后,默认启用此功能(–feature-gates中的TaintBasedEvictions = true),NodeController(或kubelet)会自动添加污点,并且基于Ready NodeCondition禁用了从节点逐出pod的逻辑。

在1.13版本的Kubernetes新增功能中了解更多信息。

Node

  1. #1539扩展HugePages功能

维护阶段:GA
SIG-Group:node

HugePages是一种保留具有预定义大小的大内存块的机制,由于硬件优化,这些块可以更快地访问。这对于处理内存中的大的数据集或对内存访问延迟敏感的应用程序(例如数据库或虚拟机)特别有用。

在Kubernetes 1.18中,此功能添加了两个增强配置。

首先,现在允许Pod请求不同大小的HugePage。

1
2
3
4
5
6
7
8
9
10
apiVersion: v1
kind: Pod

spec:
containers:

resources:
requests:
hugepages-2Mi: 1Gi
hugepages-1Gi: 2Gi

其次,已经实现了HugePages的容器隔离,以解决Pod可能使用比请求更多的内存,最终导致资源匮乏的问题。

  1. #688 Pod Overhead:帐户资源绑定到Pod沙箱,但不包含特定的容器

维护阶段:升级到Beta
SIG-Group:节点

除了请求的资源之外,您的Pod还需要额外的资源来维护其运行时环境。

启用PodOverhead功能后,Kubernetes将在调度Pod时考虑到此开销。此开销与pod使用的RuntimeClass相关联。

在1.16版本的Kubernetes新增功能中了解更多信息。

  1. #693节点拓扑管理器

维护阶段:升级到Beta
SIG-Group:节点

机器学习,科学计算和金融服务是计算密集型且要求超低延迟的系统的场景。这些类型的工作负载受益于隔离到一个CPU内核的进程,而不是在内核之间切换或与其他进程共享。

节点拓扑管理器是一个kubelet组件,可集中协调硬件资源分配。当前方法将此任务划分为几个组件(CPU管理器,设备管理器,CNI),这有时会导致分配未优化。

在1.16版本的Kubernetes新增功能中了解更多信息。

  1. #950为慢启动的pod添加pod-startup、liveness-probe

维护阶段:升级到Beta
SIG-Group:节点

探针使Kubernetes可以监视应用程序的状态。如果Pod启动所需的时间太长,这些探针可能会认为Pod已死,从而导致重新启动循环。此功能使您可以定义一个启动探针,该探针将推迟所有其他探针,直到容器完成其启动。例如,“在给定的HTTP端点可用之前,请勿测试活动性”。

在1.16版本的Kubernetes新增功能中了解更多信息。

网路

  1. #752 EndpointSlice API

维护阶段:Beta重大更新
SIG-Group:network

新的EndpointSlice API将把端点分为几个Endpoint Slice资源。这解决了当前API中与大型Endpoints对象有关的许多问题。该新API还旨在支持其他将来的功能,例如每个吊舱有多个IP。

在1.16版本的Kubernetes新增功能中了解更多信息。

  1. #508 IPv6支持添加

维护阶段:升级到Beta
SIG-Group:network

早在Kubernetes 1.9上就引入了对仅IPv6群集的支持。此功能已由社区进行了广泛的测试,现在正逐步升级为Beta。

  1. #1024 节点本地DNS缓存到GA

阶段:毕业至稳定
功能组:网络

NodeLocal DNSCache通过在群集节点上作为Daemonset运行dns缓存代理来提高群集DNS性能,从而避免了iptables DNAT规则和连接跟踪。本地缓存代理将查询dns服务以获取集群主机名的未命中缓存(默认为cluster.local后缀)。

您可以阅读其Kubernetes增强建议(KEP)文档中的设计说明,以了解有关此Beta功能的更多信息。

在1.15版本的Kubernetes新增功能中了解更多信息。

  1. #1453 ingress功能增强

维护阶段:升级到Beta
SIG-Group:network

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

该API对象包含在Kubernetes 1.1中,成为事实上的稳定功能。此增强功能消除了Ingress实施之间的不一致之处。

例如,您现在可以定义一个pathType来显式声明将路径视为前缀还是完全匹配。如果Ingress中的多个路径与请求匹配,则最长的匹配路径将优先。

另外,不建议使用kubernetes.io/ingress.class注释。现在应该使用新的ingressClassName字段和IngressClass资源。

  1. #1507将AppProtocol添加到服务和端点

维护阶段:GA
SIG-Group:network

EndpointSlice API在Kubernetes 1.17中添加了一个新的AppProtocol字段,以允许为每个端口指定应用程序协议。此增强功能将该字段带入ServicePort和EndpointPort资源中,替换了可能引起不良用户体验的非标准注释。

API相关

  1. #1040 API服务器请求的优先级和公平性

维护阶段:Alpha
SIG-Group:api-machinery

在高负载期间,Kubernetes API服务器需要负责管理和维护任务。现有的–max-requests-inflight和–max-mutating-requests-inflight命令行标志可以限制传入的请求,但它们的粒度过于粗糙,并且在流量繁忙时会过滤掉重要的请求。

APIPriorityAndFairness功能门可在apiserver中启用新的请求处理流程。您可以使用FlowSchema对象定义不同类型的请求,并使用RequestPriority对象为它们设定资源优先级。

例如,垃圾收集器是低优先级服务:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
kind: FlowSchema
meta:
name: system-low
spec:
matchingPriority: 900
requestPriority:
name: system-low
flowDistinguisher:
source: user
match:
- and:
- equals:
field: user
value: system:controller:garbage-collector

因此,您可以为其分配很少的资源:

1
2
3
4
5
6
7
kind: RequestPriority
meta:
name: system-low
spec:
assuredConcurrencyShares: 30
queues: 1
queueLengthLimit: 1000

但是,自我维护请求具有更高的优先级:

1
2
3
4
5
6
7
8
kind: RequestPriority
meta:
name: system-high
spec:
assuredConcurrencyShares: 100
queues: 128
handSize: 6
queueLengthLimit: 100

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

  1. #1601 client-go签名相关重构,以标准化选项和上下文处理

维护阶段:GA
SIG-Group:api-machinery

在client-go上已经完成了一些代码重构,许多文件都使用该库来连接到Kubernetes API,以保持方法签名的一致性。

这包括向一些方法中添加上下文对象,该对象在API边界和进程之间承载请求范围的值。访问此对象可简化一些功能的实现,例如在超时和取消后释放调用线程,或添加对分布式跟踪的支持。

  1. #576 APIServer DryRun

维护阶段:GA
SIG-Group:api-machinery

ryRun运行模式使您可以模拟真实的API请求,并查看请求是否成功(准入控制器链,验证,合并冲突等)和在不实际修改状态的情况下会发生什么。该请求的响应主体应尽可能接近非空运行响应。此核心功能将启用其他用户级别的功能,例如kubectl diff子命令。

在1.13版本的Kubernetes新增功能中了解更多信息。

  1. #1281 API服务器网络代理KEP到Beta

维护阶段:升级到Beta
SIG-Group:api-machinery

有些用户(大多数是云提供商)更喜欢将其群集API Server隔离在单独的控制网络中,而不是在集群网络中。实现此功能的一种方法是保持与其他集群组件的连通性,同时使用API Server网络代理。

具有此额外的层可以启用其他功能,例如元数据审核日志记录和传出API服务器连接的验证。

在Kubernetes 1.18中,API Server代理允许在服务,节点,webhooks和Pods之外的单独网络中分离API。

Kubernetes-1.18-enhancement-1281-API-Server-Network-Proxy.png

此增强功能涵盖了解决一些已知问题并让该代理支持一般性的工作,例如从Kubernetes API服务器中删除SSH隧道代码,以及改善控制网络与集群网络的隔离。

Windows变更

  1. #1001在Windows上支持CRI-ContainerD

维护阶段:Alpha
SIG-Group:windows

ContainerD是与Kubernetes兼容的OCI兼容运行时。与Docker相反,ContainerD在Windows Server 2019中包括对主机容器服务(HCS v2)的支持,该服务可更好地控制容器的管理方式并可以改善Kubernetes API的兼容性。

此增强功能引入了Windows中作为容器运行时接口(CRI)的ContainerD 1.3支持。在此增强页面中查看更多详细信息。

  1. #1301在Windows上实现RuntimeClass

维护阶段:Alpha
SIG-Group:windows

使用RuntimeClass,您可以定义集群中存在的不同类型的节点,然后使用runtimeClassName指定可以将Pod部署在哪些节点中。此功能在Kubernetes 1.12上引入,并在Kubernetes 1.14上进行了重大更改。

此增强功能将此功能扩展到Windows节点,这在异构集群包含Windows Pod时,对部署在Windows节点上非常有用。这是定义RuntimeClass的方法,以将pod限制为Windows Server 1903版(10.0.18362)。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: node.k8s.io/v1beta1
kind: RuntimeClass
metadata:
name: windows-1903
handler: 'docker'
scheduling:
nodeSelector:
kubernetes.io/os: 'windows'
kubernetes.io/arch: 'amd64'
node.kubernetes.io/windows-build: '10.0.18362'
tolerations:
- effect: NoSchedule
key: windows
operator: Equal
value: "true"

然后,您需要在pod中使用runtimeClassName,如下所示:

1
2
3
4
5
6
7
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
runtimeClassName: windows-1903
# ...

检查增强页面以获取更多详细信息。

  1. #689为Windows工作负载支持GMSA

维护阶段:GA
SIG-Group:windows

这将使操作员可以在部署时选择GMSA,并使用它运行容器以连接到现有应用程序(例如数据库或API服务器),而无需更改组织内部对身份验证和授权的管理方式。

在1.14版本的Kubernetes新增功能中了解更多信息。

  1. #1043 Windows版RunAsUserName

维护阶段:升级到Beta
SIG-Group:windows

现在,Kubernetes支持组托管服务帐户,我们可以使用Windows的runAsUserName特定属性来定义哪个用户将运行容器的入口点。

在1.16版本的Kubernetes新增功能中了解更多信息。

  1. #995 Windows版Kubeadm

维护阶段:升级到Beta
SIG-Group:cluster-lifecycle

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

从Kubernetes 1.16开始,具有部分功能的Windows用户可以使用kubeadm join。它将缺少一些功能,例如kubeadm init或kubeadm join –control-plane。

在1.16版本的Kubernetes新增功能中了解更多信息。

存储

  1. #695跳过卷所有权更改

维护阶段:Alpha
SIG-Group:storage

在将卷绑定安装到容器内之前,其所有文件权限都将更改为提供的fsGroup值。这最终会导致非常大的卷上的缓慢过程,还会破坏一些对权限敏感的应用程序,例如数据库。

已添加新的FSGroupChangePolicy字段以控制此行为。如果设置为始终,它将保持当前行为。但是,当设置为OnRootMismatch时,仅当顶级目录与预期的fsGroup值不匹配时,它才会更改卷权限。

  1. #1412不可变的Secrets和ConfigMap

维护阶段:Alpha
SIG-Group:storage

新的不可变字段已添加到Secrets和ConfigMaps中。设置为true时,将拒绝对资源密钥所做的任何更改。这样可以保护集群数据,避免意外或错误更新从而破坏应用程序。

由于它们不变,因此Kubelet不需要定期检查其更新,这可以提高可伸缩性和性能。

启用ImmutableEmphemeralVolumes功能门之后,您可以执行以下操作:

1
2
3
4
5
6
7
apiVersion: v1
kind: Secret
metadata:

data:

immutable: true

但是,一旦将资源标记为不可变,就无法还原此更改。您只能删除并重新创建密钥,并且需要重新创建使用已删除密钥的Pod。

  1. #1495通用数据填充器

维护阶段:Alpha
SIG-Group:storage

这项增强功能为用户创建预先填充的卷奠定了基础。例如,使用操作系统映像预填充用于虚拟机的磁盘,或启用数据备份和还原。

为此,将取消对持久卷的DataSource字段的当前验证,从而允许将任意对象设置为值。有关如何填充卷的实现详细信息委托给专用控制器。

  1. #770

维护阶段:GA
SIG-Group:storage

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

对于这些驱动程序,Kubernetes Attach/Detach控制器始终创建VolumeAttachment对象,并一直等到它们被报告为“已绑定”。对CSI卷插件进行了更改,以跳过此步骤。

  1. #351使用永久卷源的BlockVolume

维护阶段:GA
SIG-Group:storage

BlockVolume在Kubernetes 1.18中达到了常规可用性。您可以仅将volumeMode的值设置为block即可访问原始块设备。使用不带文件系统抽象的原始块设备的能力使Kubernetes可以为需要高I/O性能和低延迟的高性能应用程序(如数据库)提供更好的支持。

在1.13版本的Kubernetes新增功能中了解更多信息。

  1. #565 CSI块存储支持

维护阶段:GA
SIG-Group:storage

使用不带文件系统抽象的原始块设备的能力使Kubernetes可以为需要高I/O性能和低延迟的应用程序(例如数据库)提供更好的支持。

在1.13版本的Kubernetes新增功能中了解更多信息。

  1. #603在CSI调用中传递Pod信息

维护阶段:GA
SIG-Group:storage

CSI存储驱动程序可以选择接收关于在NodePublish请求中请求卷的Pod的信息,例如Pod名称和名称空间。

CSI驱动程序可以使用此信息来授权或审核卷的使用,或生成针对Pod定制的卷内容。

在1.14版本的Kubernetes新增功能中了解更多信息。

  1. #989扩展允许的PVC数据源

维护阶段:GA
SIG-Group:storage

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

在1.15版本的Kubernetes新增功能中阅读更多内容。


Kubernetes 1.18 其他更新

  1. #1441 kubectl调试

维护阶段:Alpha
SIG-Group:功能组:cli

添加了新的kubectl debug命令以扩展调试功能。

此命令允许在正在运行的Pod中创建临时容器,使用修改后的PodSpec重新启动Pod,以及启动并附加到主机名称空间中的特权容器。

  1. #1020将kubectl软件包代码移至暂存

维护阶段:GA
SIG-Group:功能组:cli

kubectl代码的这种内部重组是将kubectl二进制文件移到其自己的存储库中的第一步。这有助于将kubectl与kubernetes代码库分离,并使树外项目更易于重用其代码。

  1. #1333禁用没有Beta REST API或功能

维护阶段:Beta
SIG-Group:architecture

此增强功能收集了所做的工作,以确保Kubernetes组件和Kubernetes一致性都不依赖于Beta REST API或功能。最终目标是确保各个发行版之间的一致性,因为启用非GA功能不需要使用非官方发行版(例如k3s,Rancher或Openshift)。

  1. #491 Kubectl Diff

维护阶段:GA
SIG-Group:cli

kubectl diff将为您预览kubectl将对您的集群进行哪些更改。尽管易于描述,但此功能对于群集操作员的日常工作确实非常方便。请注意,您需要在API服务器上启用dry run功能,此命令才能起作用。

在1.13版本的Kubernetes新增功能中了解更多信息。

  1. #670支持vSphere Cloud Provider

维护阶段:GA
SIG-Group:cloud-provider

提供对vSphere云提供商的支持。这涉及到经过测试的云控制器管理器版本,该版本具有与kube-controller-manager奇偶校验的功能。

在1.14版本的Kubernetes新增功能中了解更多信息。


参考资料