深度解读k8s1.17新特性

Kubernetes 1.17的发行版引入了一些强大的新功能，并且看到其他功能趋于成熟或趋于普遍可用。此概述提供了一些最值得注意的更改的摘要，其中包括：

• 集群网络和路由控制以及可伸缩性方面的重大改进；
• 集群存储，pod调度和运行时选项的新功能；
• 更好的自定义资源支持。

请注意，要尝试这些功能，您将需要有权访问运行Kubernetes 1.17的集群，并且在某些情况下还需要为Kubernetes组件设置启用某些新功能。托管Kubernetes集群通常不支持最新的Kubernetes版本，或者不允许用户启用alpha或beta功能。您可以使用诸如kubeadm或kops之类的工具在裸机或云提供商的虚拟机服务上安装特定版本的Kubernetes。

EndpointSlice API

• Graduating Status: Beta
• Kubernetes API Group/Component:discovery.k8s.io
• Expected GA Release: 1.19+
• Kubernetes Enhancement Proposal or Design Doc:KEP
• How to Try It:Instructions for enabling.

EndpointSlice API加入了现有的Endpoints API，以允许管理集群网络上的服务目标并与之交互。古老的Endpoints API及其控制器在大型或复杂集群中都遇到了严重的可伸缩性问题。新的EndpointSlice API旨在与现有API一起运行，并有可能最终取代它，并提供一个可扩展的框架，以适应并支持不断发展的Kubernetes用例和服务网格，多集群拓扑，以及需要与集群服务发现和网络拓扑紧密结合的其他框架。新的API还支持端点的双栈IPv4 / IPv6寻址，为更广泛的集群双栈支持做准备。

IPv4/IPv6 双栈支持

• Status: Alpha (ongoing major change)
• Kubernetes API Group/Component: multiple
• Expected GA Release: unknown
• Kubernetes Enhancement Proposal or Design Doc:KEP
• How to Try It:Instructions for enabling.Dual-stack support also requires any Container Network Interface (CNI) plugins in use to support and honor the changes. (Support in the Kubenet plugin ships with this release.)

尽管Kubernetes从v1.9开始增加了在Pod网络中使用IPv6的支持，但是集群网络仍必须使用IPv4或IPv6。但是，许多生产环境确实需要同时可通过IPv4和IPv6寻址，这需要NAT网关或代理来桥接使用不同协议的网络之间的差距。此增强功能旨在为Kubernetes Pod和节点网络层添加真正的双栈支持，这意味着节点和Pod现在可以通过同一资源的IPv4地址和IPv6地址进行寻址。 （请注意，尽管该协议可以是IPv4或IPv6，但Kubernetes Service网络仍仅支持单栈网络。对Kubernetes Services的双栈支持不在此增强范围之内。）

双栈支持最初是在Kubernetes 1.16中引入的，但是此增强功能被认为是对Kubernetes核心功能的重大更改，因此，对基础更改的增量引入将跨越多个版本，并逐步升级为Beta状态。 1.17版本的更新包括设置IPv6网络掩码和Pod IP地址验证支持的功能。

CSI中的PersistentVolume快照备份/还原支持

• Graduating Status: Beta
• Kubernetes API Group/Component:snapshot.storage.k8s.io
• Expected GA Release: 1.19+
• Kubernetes Enhancement Proposal or Design Doc:KEP
• How to Try It: Volume Snapshots require using a Container Storage Interface (CSI) plugin that implements this API.

尽管卷快照（尤其是在高度虚拟化的环境中）并不总是一种可靠且可靠的数据备份方法，但由于行业普遍需要对越来越大的数据集进行零宕机时间备份，因此它们被广泛使用。 （有关为什么快照不可靠备份的解释，请尝试搜索“快照不是备份”。）此增强功能增加了对Kubernetes Container Storage Interface插件的API支持，以创建PersistentVolumes快照并进行还原。

为了在任何平台上使用卷快照作为可靠的关键数据还原介质，用户必须采取许多步骤，从应用程序级别到主机服务器的操作系统，再到实际的存储硬件，以确保数据一致性。在将所有内存中的数据刷新到存储介质之前拍摄的快照可能导致快照的文件系统无法恢复。

感知拓扑的服务路由

• Graduating Status: Alpha
• Kubernetes API Group/Component:k8s.io(core)
• Expected GA Release: unknown
• Kubernetes Enhancement Proposal or Design Doc:KEP
• How to Try It:Instructions for enabling.

运行大规模生产集群带来了许多挑战，包括在对冗余，高可用性服务的需求与最小化请求延迟之间取得平衡。无论服务是在云提供商上运行（鼓励用户将应用程序实例分布在多个区域中以避免出现单点故障），还是在本地数据中心上运行，应用程序实例之间的网络距离和响应时间都可能大相径庭。此外，AWS等云提供商对可用性区域之间的网络流量收费，集群管理员有很大的动机试图将请求保持在其分布式应用程序堆栈中尽可能“本地”。

Kubernetes ServiceSpec中增加了对拓扑感知路由的支持，解决了网络拓扑路由控件所需的问题。此功能将允许用户指定节点标签，以用于优先选择用于在支持目标服务的Pod之间路由请求的选择。

Node Taints by Condition

• Graduating Status: Stable/GA
• Kubernetes API Group/Component: scheduler, node controllers
• Kubernetes Enhancement Proposal or Design Doc:KEP
• How to Try It: This feature is enabled by default in 1.17.

根据节点条件自动对节点进行染色以稳定释放。这些污点使用户可以决定Kubernetes调度程序在放置应用程序Pod时可以遵循或忽略的节点条件。

自定义资源的API默认设置

• Graduating Status: Stable/GA
• Kubernetes API Group/Component:apiextensions.k8s.io
• Kubernetes Enhancement Proposal or Design Doc:KEP
• How to Try It: This feature is enabled by default in 1.17.

此功能增加了对通过OpenAPI v3验证架构提供Kubernetes自定义资源定义（CRD）的默认值的支持。核心Kubernetes API已经支持在处理API请求期间处理默认值，但是自定义资源缺少默认支持，这对开发人员和用户而言CRD API版本更改更加麻烦。

服务负载均衡器的Finalizer保护

• Graduating Status: Stable/GA
• Kubernetes API Group/Component: service controller
• Kubernetes Enhancement Proposal or Design Doc:KEP
• How to Try It: This feature is enabled by default in 1.17.

服务负载平衡器终结器保护可确保删除服务时，分配给Kubernetes服务对象的任何负载平衡器资源都将被破坏或释放。如果无法释放负载均衡器资源，则删除Service对象也将失败。此更改解决了用户经常看到的问题，即使从Kubernetes集群中删除了附加的负载均衡器，但负载均衡器仍然被静默保留，这意味着更高的云提供商费用或内部部署集群中的有限资源耗尽。

Pod中的进程命名空间共享

• Graduating Status: Stable/GA
• Kubernetes API Group/Component: core (pod), Container Runtime Interface (CRI)
• Kubernetes Enhancement Proposal or Design Doc:KEP
• How to Try It: This feature is enabled by default in 1.17.

此功能使共享一个容器的容器能够共享相同的进程名称空间。将Pod的shareProcessNamespace字段设置为true时，该Pod中的所有容器将在共享的（Linux）进程名称空间中运行，从而简化了进程间的信号传递和应用程序调试。

总结

随着Kubernetes的采用率增加，工作负载，用户需求和环境的多样性也随之增加。其中许多增强功能可满足大规模，关键生产环境中用户的需求。 Kubernetes指导委员会和社区团体将继续保持平衡，在为用户提供所需的控制权的同时，仍保持可适应许多不同组织和工作负载的灵活，可定制的平台。

对于Pod中的进程命名空间共享 ，

• 想到了configmap-reload组件, 当我们业务容器的配置文件来源于configmap，那么当配置文件改变的时候，我们业务容器无法感知到变化，一般会使用configmap-reload。但是之前不同容器的交互往往是通过调用http接口来实现，而现在完全可以通过发送SIGHUB信号即可。
• 我们业务容器的镜像遵守最精简的原则，当出现一些问题需要debug时候，启动一个debug容器，加入到目的pod中，共享命名空间，那么调试起来会非常方便。之前调试容器往往是关注点在networknamespace，现在可以做的更多。

对于自定义资源的API默认设置

之前通用的做法是与crd配合一个准入控制器，可以校验和修改一些crd值。如果是修改字段的默认值，现在可以直接通过crd 定义文件实现了。由此可以看出，crd 在k8s 体系中越来越重要。相信以后关于crd的增强会越来越多。

对于感知拓扑的服务路由

对于一些运行在公有云或是多AZ的场景特别合适，因为跨AZ的流量是收费的。该功能对于保持服务高可用（多AZ部署，容灾）的前提下，对于性能和资费都有一定的好处。