Kubernetes 1.18 福履将之

zouyee

发布于 2021-02-01 14:59:28

8980

发布于 2021-02-01 14:59:28

Kubernetes 1.18即将发布！在发布了1.17的小版本之后，1.18变得日益健壮并充满了新颖性。关于新版本的介绍从哪里开始？有一些新功能，例如API Server对OIDC的支持以及kubelet关于Windows节点的功能增强，这些都会对用户产生重大影响。

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

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

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

“未来五年，是kubernetes的黄金五年。”

在这个黄金五年，CNCF组织依托kubernetes等开源项目推进现代云原生的发展，构建现代软件开发技术栈。

版本介绍

Kubernetes发布的版本通常只维护九个月，在维护周期内，如果发现重大的bug或则安全问题，可能会发布补丁版本，下面为Kubernetes的发布和维护时限，该时限同样适用于kubeadm。

Kubernetes 版本	发行月份	终止维护月份
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 月
v1.18.x	2019 年 3 月	2020 年 12 月

核心变更

a、＃1393 为服务帐户提供OIDC的支持

维护阶段：Alpha

SIG-Group：auth

Kubernetes服务帐户（KSA）可以使用令牌（JSON Web令牌或JWT）对Kubernetes API进行身份验证，例如使用kubectl --token <the_token_string>。需要注意的是，Kubernetes API是唯一可以验证这些令牌的服务。

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

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

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

b、＃853 HPA的扩展速度可配

维护阶段：Alpha

SIG-Group：autoscaling

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

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

behavior:
   scaleDown:
     policies:
     - type: Percent
       value: 100
       periodSeconds: 15
   scaleUp:
     policies:
     - type: Pods
       value: 4
       periodSeconds: 60

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

c、＃1513 CertificateSigningRequest API

维护阶段：Beta

SIG-Group：auth

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

此增强功能旨在适应新的应用场景，从而改善签名过程及其安全性。注册机构的数字，即批准者，确保实际的请求者已经提交了证书签名请求（CSR）；同时他们还确保请求者具有提交该请求的适当权限。

SIG变更

调度

a、＃1451 运行多个调度配置文件

维护阶段：Alpha

SIG-Group：scheduling

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

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

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

b、＃895 topologySpreadConstraints

维护阶段：升级到Beta

SIG-Group：scheduling

使用topologySpreadConstraints，您可以定义规则以在整个多区域群集中均匀分布pod，因此高可用性将正确运行，并且资源利用率将得到提高。在1.16版本的Kubernetes新增功能中了解更多信息。

c、＃1258添加可配置的默认Even Pod传播规则

维护阶段：Alpha

SIG-Group：scheduling

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

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

d、＃166基于污点驱逐

维护阶段：GA

SIG-Group：scheduling

在Kubernetes 1.13中，基于污点的驱逐的功能，在从alpha阶段变为beta阶段后，默认启用此功能（--feature-gates中的TaintBasedEvictions = true），NodeController（或kubelet）会自动添加污点，并且基于Ready NodeCondition禁用了从节点逐出pod的逻辑。在1.13版本的Kubernetes新增功能中了解更多信息。

节点

a、＃1539扩展HugePages功能

维护阶段：GA

SIG-Group：node

HugePages是一种保留具有预定义大小的大内存块的机制，由于硬件优化，这些块可以更快地访问。这对于处理内存中的大的数据集或对内存访问延迟敏感的应用程序（例如数据库或虚拟机）特别有用。在Kubernetes 1.18中，此功能添加了两个增强配置。首先，现在允许Pod请求不同大小的HugePage。

apiVersion: v1
kind: Pod
…
spec:
  containers:
…
    resources:
      requests:
        hugepages-2Mi: 1Gi
        hugepages-1Gi: 2Gi

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

b、＃688 Pod Overhead：帐户资源绑定到Pod沙箱，但不包含特定的容器

维护阶段：升级到Beta

SIG-Group：节点

除了请求的资源之外，您的Pod还需要额外的资源来维护其运行时环境。启用PodOverhead功能后，Kubernetes将在调度Pod时考虑到此开销。此开销与pod使用的RuntimeClass相关联。在1.16版本的Kubernetes新增功能中了解更多信息。

c、＃693节点拓扑管理器

维护阶段：升级到Beta

SIG-Group：节点

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

节点拓扑管理器是一个kubelet组件，可集中协调硬件资源分配。当前方法将此任务划分为几个组件（CPU管理器，设备管理器，CNI），这有时会导致分配未优化。在1.16版本的Kubernetes新增功能中了解更多信息。

d、＃950为慢启动的pod添加pod-startup、liveness-probe

维护阶段：升级到Beta

SIG-Group：节点

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

网络

a、＃752 EndpointSlice API

维护阶段：Beta重大更新

SIG-Group：network

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

b、＃508 IPv6支持添加

维护阶段：升级到Beta

SIG-Group：network

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

c、＃1024 节点本地DNS缓存到GA

阶段：毕业至稳定

功能组：network

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

您可以阅读其Kubernetes增强建议（KEP）文档中的设计说明，以了解有关此Beta功能的更多信息。在1.15版本的Kubernetes新增功能中了解更多信息。

d、＃1453 ingress功能增强

维护阶段：升级到Beta

SIG-Group：network

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

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

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

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

e、＃1507将AppProtocol添加到服务和端点

维护阶段：GA

SIG-Group：network

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

API

a、＃1040 API服务器请求的优先级和公平性

维护阶段：Alpha

SIG-Group：api-machinery

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

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

例如，垃圾收集器是低优先级服务：

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

因此，您可以为其分配很少的资源：

kind: RequestPriority
meta:
  name: system-high
spec:
  assuredConcurrencyShares: 100
  queues: 128
  handSize: 6
  queueLengthLimit: 100

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

b、＃1601 client-go签名相关重构，以标准化选项和上下文处理

维护阶段：GA

SIG-Group：api-machinery

在client-go上已经完成了一些代码重构，许多文件都使用该库来连接到Kubernetes API，以保持方法签名的一致性。这包括向一些方法中添加上下文对象，该对象在API边界和进程之间承载请求范围的值。访问此对象可简化一些功能的实现，例如在超时和取消后释放调用线程，或添加对分布式跟踪的支持。

c、＃576 APIServer DryRun

维护阶段：GA

SIG-Group：api-machinery

DryRun运行模式使您可以模拟真实的API请求，并查看请求是否成功（准入控制器链，验证，合并冲突等）和在不实际修改状态的情况下会发生什么。该请求的响应主体应尽可能接近非空运行响应。此核心功能将启用其他用户级别的功能，例如kubectl diff子命令。在1.13版本的Kubernetes新增功能中了解更多信息。

d、＃1281 API服务器网络代理KEP到Beta

维护阶段：升级到Beta

SIG-Group：api-machinery

有些用户（大多数是云提供商）更喜欢将其群集API Server隔离在单独的控制网络中，而不是在集群网络中。实现此功能的一种方法是保持与其他集群组件的连通性，同时使用API Server网络代理。具有此额外的层可以启用其他功能，例如元数据审核日志记录和传出API服务器连接的验证。

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

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

Windows变更

a、＃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支持。在此增强页面中查看更多详细信息。

b、＃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）。

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，如下所示：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: windows-1903

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

c、＃689为Windows工作负载支持GMSA

维护阶段：GA

SIG-Group：windows

这将使操作员可以在部署时选择GMSA，并使用它运行容器以连接到现有应用程序（例如数据库或API服务器），而无需更改组织内部对身份验证和授权的管理方式。在1.14版本的Kubernetes新增功能中了解更多信息。

d、＃1043 Windows版RunAsUserName

维护阶段：升级到Beta

SIG-Group：windows

现在，Kubernetes支持组托管服务帐户，我们可以使用Windows的runAsUserName特定属性来定义哪个用户将运行容器的入口点。在1.16版本的Kubernetes新增功能中了解更多信息。

e、＃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新增功能中了解更多信息。

存储

a、＃695跳过卷所有权更改

维护阶段：Alpha

SIG-Group：storage

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

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

b、＃1412不可变的Secrets和ConfigMap

维护阶段：Alpha

SIG-Group：storage

新的不可变字段已添加到Secrets和ConfigMaps中。设置为true时，将拒绝对资源密钥所做的任何更改。这样可以保护集群数据，避免意外或错误更新从而破坏应用程序。由于它们不变，因此Kubelet不需要定期检查其更新，这可以提高可伸缩性和性能。启用ImmutableEmphemeralVolumes功能门之后，您可以执行以下操作：

apiVersion: v1
kind: Secret
metadata:
  …
data:
  …
immutable: true

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

c、＃1495通用数据填充器

维护阶段：Alpha

SIG-Group：storage

这项增强功能为用户创建预先填充的卷奠定了基础。例如，使用操作系统映像预填充用于虚拟机的磁盘，或启用数据备份和还原。为此，将取消对持久卷的DataSource字段的当前验证，从而允许将任意对象设置为值。有关如何填充卷的实现详细信息委托给专用控制器。

d、＃770

维护阶段：GA

SIG-Group：storage

这种内部优化将简化为不需要附加/分离操作的容器存储接口（CSI）驱动程序（例如NFS或临时机密卷）创建VolumeAttachment对象的操作。对于这些驱动程序，Kubernetes Attach/Detach控制器始终创建VolumeAttachment对象，并一直等到它们被报告为“已绑定”。对CSI卷插件进行了更改，以跳过此步骤。

e、＃351使用永久卷源的BlockVolume

维护阶段：GA

SIG-Group：storage

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

f、＃565 CSI块存储支持

维护阶段：GA

SIG-Group：storage

使用不带文件系统抽象的原始块设备的能力使Kubernetes可以为需要高I/O性能和低延迟的应用程序（例如数据库）提供更好的支持。在1.13版本的Kubernetes新增功能中了解更多信息。

g、＃603在CSI调用中传递Pod信息

维护阶段：GA

SIG-Group：storage

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

CSI驱动程序可以使用此信息来授权或审核卷的使用，或生成针对Pod定制的卷内容。在1.14版本的Kubernetes新增功能中了解更多信息。

h、＃989扩展允许的PVC数据源

维护阶段：GA

SIG-Group：storage