近日，Kubernetes的新版本1.9发布，1.9是今年第四个Kubernetes 版本更新。它主要支持了Windows容器和一个最新的容器存储API的alpha版本。Kubernetes 1.9 现在可从 GitHub 下载：https://github.com/kubernetes/kubernetes/releases/tag/v1.9.0
Kubernetes 1.9发布：年度更新这些评论亮了！
稳定的负载API
根据CNCF开发者倡导者Ihor Dvoretskyi介绍，Kubernetes 1.9提升了一系列通用的稳定性，其中包括稳定的负载API——这是去年12月首次推出的一项主要功能。
总的来说，有四个API一般可用：
Deployment：描述正在运行的应用程序的理想状态的基本方法，包括ReplicaSet。
ReplicaSet：根据Deployment的配置，这可以确保应用程序有足够的正在运行的容器实例（“副本”）来满足其定义。
Daemonset：不管其他什么应用程序可能在运行而持续运行的应用程序的部署，如日志记录或监控解决方案。
StatefulSet：针对即使容器被终止并重新启动也需要持久状态的工作负载。
StatefulSets还为容器的网络标识或容器启动和停止的顺序提供持久性。
转向稳定意味着用户可将其用于关键任务工作负载，因为此时的API接口不会出现让他们重新编码应用才能继续使用的情况。
Windows Server支持
Kubernetes 原本是为 Linux 系统开发的，不过用户意识到了容器编排能力的收益之后，就产生了让 Kubernetes 支持 Windows 负载的需求。在 12 个月之前启动了为 Kubernetes 对 Windows Server 提供支持的开发工作。Windows SIG 现在把这一能力升级到 Beta 阶段，这表明可以进行使用(https://kubernetes.io/docs/getting-started-guides/windows/)评估了。
Windows Server支持已经处于beta状态，但还没有准备好用于生产环境，Dvoretskyi表示。
“与此同时，beta意味着它将很快稳定。如果你打算在Windows环境中使用Kubernetes进行构建，现在就是开始使用Kubernetes的好时机。一旦达到稳定的状态，你就已经有一些工作经验了。”它将允许你使用Windows服务器将节点添加到Kubernetes集群，并且Windows Workloads将在Windows服务器上本地运行。
Cloudbase、Apprenda和Red Hat已经宣布在Kubernetes 1.9中支持Windows Server Containers。
容器存储接口(CSI)
容器存储接口(CSI) 是一个跨行业标准草案，致力于降低云原生存储的开发门槛，并提高兼容能力。存储 SIG 和 CSI 社区 正在合作交付一个用于为 Kubernetes 供给、连接和加载存储的单一接口。
Kubernetes 1.9 实现了一个 CSI 的 Alpha 版本(https://github.com/kubernetes/features/issues/178)，这一功能让新的卷插件的安装像部署 Pod 一样简单；第三方存储的开发也不需要加入核心的 Kubernetes 代码了。
因为这一功能尚处于 Alpha 阶段，所以必须显式声明启用，也不推荐用在生产环境，但是这一尝试表明了 Kubernetes 存储系统的扩展性和标准化的未来路线。
Dvoretskyi谈到，“以前，如果你想在Kubernetes集群中使用其他存储解决方案，必须确保它们在Kubernetes的代码库中默认为可用。这也使得想要为Kubernetes提供存储解决方案的存储供应商感到困难。现在供应商更容易为Kubernetes提供存储选项。“
Cloud Provider
Kubernetes 1.9的一个重要变化是，如果用户手动部署Kubernetes，必须为- cloud- provider标志设置一个值；默认情况不再是“自动检测”。允许的选择是：AWS、Azure、Cloudstack、Fake、Gce、Mesos、Openstack、Ovirt、Photon、Rackspace、 Vsphere、以及Unset；自动检测将在Kubernetes 1.10中被移除。(如果用Minikube或Kubeadm之类的工具来安装Kubernetes，不必担心这个问题。)
此外，该版本中的一些更改是针对个别云供应商的。
OpenStack
如果使用OpenStack使用Kubernetes，用户会发现v1.9中的配置要简单得多。自动检测OpenStack服务和版本现在是“只要可行”的规则——在本例中意味着块存储API版本和安全组——用户现在可以将OpenStack负载平衡配置为服务v2提供者。支持OpenStack Octavia v2和中子LBaaS v2。
AWS
AWS的小组(SIG)一直致力于改善Kubernetes与EBS卷的集成。用户将不再使用被调度到“附加”状态的卷的工作负载。相反，节点将被“污染”，以便管理员能够处理问题。团队建议观看这些污染。此外，当停止节点时，卷将自动分离。
此外，Kubernetes现在支持AWS的新NVMe实例类型，以及使用AWS网络负载均衡器，而不是弹性负载均衡器。
Azure
如果用户在Windows上使用Kubernetes，特别是在Azure上，会发现安装卷的失误率更小，因为您现在可以创建Windows挂载路径，并消除驱动器号的需要，这是无限的挂载点。
还可以使用service . beta.kubernetes显式地为公共IP地址设置Azure DNS标签。在使用Azure NSG规则时，仍然能够使用Azure NSG规则，以确保只允许外部访问负载均衡器的IP地址。当更新时，负载均衡器还被增强以考虑更多NSG规则的属性，包括协议、sourceUNK ange和DestinationAddressPrefs。(以前这些字段的更改不会触发更新，因为负载均衡器认识不到已经发生了更改。)
其他新功能
硬件加速的alpha版本，允许使用GPU作为机器学习工作负载的资源。
对IPv6寻址的alpha支持。
更快地验证Custom Resource Definition（CRD）数据。 CRD使管理员可以自定义和扩展Kubernetes安装，而不会危害与新版本Kubernetes的兼容性。
此外，CNCF宣布了Certified Kubernetes Conformance Program，该计划验证在任何一个经认证的Kubernetes发行版或平台上运行的工作负载将在其他经认证的Kubernetes发行版或平台上正常工作，现在包括40多个项目。
业界评论
谷歌Kubernetes部门项目经理Aparna Sinha表示，网络、存储和运行时接口标准的出现，以及服务网格项目（如Istio）的一致性程序和相关的可扩展性机制都是Kubernetes成熟度的指标。她预测2018年将是容器和Kubernetes领域的安全年。
在CoreOS博客文章中，Eric Chiang评论，“在1.9版中，许多功能都是为了将Kubernetes整体存储库分成更小、更易使用的项目为目的而设计的。 Kubernetes使用容器网络接口（CNI）已经实现了丰富的网络选择生态系统。Custom Resource Definitions（CRDs）和聚合API服务器允许用户扩展API，同时保留自定义控制和运维熟悉的工作流程。用于身份验证和授权的Webhook插件允许与各种身份提供商和策略引擎进行集成。名单在不断增加。“
K8S技术社区特约评论员、EasyStack容器架构师王后明谈到，“Kubernetes 发展迅速，保持核心代码的稳定和组件本身的可扩展性成为社区的主要关注点：比如把 Cloud Provider 从 K8S 代码分支中抽离出来；添加Device Plugin 机制来提供对 GPU、FPGA、高性能网卡等硬件设备的支持；添加 external storage 机制集中为 K8S 提供丰富的存储如cinder/manila 等；采用CRD、initializer等机制提供 API 的可定制性。如上机制，都是为了在保证核心代码的稳定情况下，通过插件机制来丰富K8S 生态。此外，标准化的力量远大于单个厂商或产品正不断被证明。 CNI、CRI定义了网络和运行时接口的标准，CSI 也正在建立存储接口标准，Serverless 标准也正在逐步建立。”
K8S技术社区特约专家作者，TalkingData技术总监宋净超谈到，“从API的版本变化看来，Kubernetes本身尤其是底层的调度、容器编排已经趋于稳定了。该版本最大的改进是Apps Workloads API成为稳定版本，这消除了很多潜在用户对于该功能稳定性的担忧。另外一个重大更新，就是测试支持了Windows了，这打开了在Kubernetes中运行Windows工作负载的大门。”