Kubernetes迎来了2019年的第四次也是最后一次发布，Kubernetes v1.17版本正式亮相!
Kubernetes v1.17 包含22个增强功能，其中14个增强功能已逐渐稳定，4个增强功能已进入 beta 版本，4个增强功能已进入 alpha 版本。此次版本更新主要围绕Cloud Provider Labels 达到GA、Volume Snapshot 进入 Beta 版本、CSI Migration 达到Beta等几大主题。
Cloud Provider Labels 达到GA
创建节点和卷时，Kubernetes 会基于集群底层云提供商应用一组标准标签。节点将获得实例类型的标签，节点和卷都获得两个标签，通常按照 region 和 zone 描述资源在云提供商拓扑中的位置。
Kubernetes 组件使用标准标签来支持某些功能。例如，调度程序将确保将 Pod 与它们声明的卷放在相同的区域中;当调度属于某个部署的 Pod 时，调度程序会优先将它们分布在各个区域中。您还可以使用 Pod specs中的标签来配置诸如节点亲和性之类的东西。标准标签允许开发者在不同云提供商之间迁移的 Pod specs。
在 Kubernetes v1.17 版本中，这些标签已经可以普遍使用。
Volume Snapshot进入Beta版本
在Kubernetes v1.17版本中，Volume Snapshot进入Beta阶段。现在我们先了解下什么是 Volume Snapshot?
许多存储系统(例如Google Cloud Persistent Disks，Amazon Elastic Block Storage等)都可以创建持久卷的“快照”。快照表示卷的时间点副本，可用于设置新卷或将现有卷还原到先前状态。
为什么要将Volume Snapshot加入到Kubernetes?
Kubernetes Volume的插件系统提供了强大的抽象功能，可以自动生成、加载、挂载块和文件。
支持这些功能的目标是Kubernetes的工作负载可移植性：Kubernetes的目的是在分布式系统应用程序和底层集群之间创建一个抽象层，以便应用程序可以与它们所运行的集群的具体情况无关，并且在部署时不需要“特定于集群”。
Kubernetes Storage SIG将快照操作视为许多有状态工作负载的关键功能。例如，数据库管理员可能要在数据库运维之前对数据库卷进行快照。通过提供一种在Kubernetes API中触发快照操作的标准方式，Kubernetes用户可以在不使用Kubernetes API(手动执行存储系统特定的操作)的情况下轻松应对上述场景。
现在，Kubernetes用户被授权以与群集无关的方式将快照操作合并到他们的工具和策略中，并且知道它对任意Kubernetes群集有效，而与底层存储无关。
此外，这些Kubernetes快照原语作为基本功能，可用于为Kubernetes开发高级企业级存储管理功能的能力：包括应用程序或集群级备份解决方案。
CSI Migration 达到Beta
在Kubernetes v1.17版本中，容器存储接口CSI Migration 已进入Beta阶段。
为什么我们要将in-tree插件迁移到CSI?
在CSI之前，Kubernetes提供了功能强大的卷插件系统。这些插件是“in-tree”模式，这意味着它们的代码是核心Kubernetes代码的一部分，并随核心Kubernetes二进制文件一起发布。但是，向Kubernetes添加新的卷插件难度却很大。首先，存储供应商如果想要向Kubernetes添加其它存储系统的支持就必须与Kubernetes的发布进程保持一致。其次，第三方存储代码在核心Kubernetes二进制文件中可能会引起可靠性和安全性问题，并且对于运维人员来说，这些代码很难进行测试和维护。在Kubernetes中使用CSI却能解决这些难题。
未来，将会有更多的CSI驱动程序被开发出来并得到实际的应用，会有越来越多的Kubernetes用户从CSI模型中受益。
通过CSI Migration，可以使用相应的CSI驱动程序替换现有的in-tree存储插件，例如kubernetes.io/gce-pd或kubernetes.io/aws-ebs。迁移后，Kubernetes的终端用户不会体会到这两者之间的差异，同时可以继续使用现有接口依赖in-tree存储插件的所有功能。
当Kubernetes集群管理员更新集群启用CSI迁移时，现有的有状态部署和工作负载将继续像往常一样发挥作用;但实际上，Kubernetes已经将所有存储管理操作(以前针对in-tree驱动程序)都交给了CSI驱动程序。
基于Kubernetes打造全栈云原生服务平台
时速云是国内领先的全栈云原生技术服务提供商，公司以容器+Kubernetes作为架构核心，打造了全栈云原生服务平台。时速云全栈云原生服务平台包含基础设施和云原生应用架构的两大核心产品体系;其中云原生基础设施产品包含容器云PaaS、云原生DevOps、中间件服务、边缘云计算，为云原生应用提供敏捷、高弹性的运行支撑环境，提高应用交付运维的效率;云原生应用架构产品包含微服务治理、服务网格、API网关、Serverless服务，助力企业轻松应对大型分布式系统下高并发、高性能的业务场景，提高业务应用架构的敏捷性和扩展性。
时速云全栈云原生服务平台与Kubernetes的结合具体体现在以下几点：
1、对 Kubernetes 部署方式的改善，可以一键部署安全的 Kubernetes 集群，并最大程度保证环境的高可用，相对原生方案部署更简单，可用性更高;
2、对操作系统及 Kubernetes的相关调优，对系统组件资源调配和节点资源预留的把控，保障节点和服务的长时间稳定运行;
3、通过 Kubernetes 模型 + 控制器的友好扩展方式，实现了对数据库、缓存、消息队列以及第三方产品的完整生命周期管理;
4、基于 Kubernetes 自研 DevOps 产品体系，使 DevOps 和 PaaS 具备同样的架构背景和技术体系，任何 PaaS 层的经验积累都可以用来在 DevOps 平台上进行运用和创新;
目前，时速云全栈云原生服务平台已经服务了金融、能源、制造、广电、运营商等领域的诸多大型企业及世界500强客户，标杆客户包括国家电网、太平集团、海信集团、南方航空、中国电信、中核集团、奔驰、中国一汽等。
通过云原生技术助力企业数字化转型是时速云的核心使命，公司将紧跟前沿技术发展趋势，积极推动云原生技术的发展和落地，同时还会将Kubernetes云原生平台的更多优秀新功能融入到自身的产品中去，助力更多的企业顺利完成数字化转型。
Kubernetesv1.17其他功能更新：
1、基于条件的节点污点
2、可配置的Pod进程命名空间共享
3、通过kube-scheduler调度DaemonSet Pod
4、动态最大 Volume 计数
5、Kubernetes CSI拓扑支持
6、在SubPath Mount中提供环境变量扩展
7、自定义资源的默认设置
8、将频繁的Kubelet心跳移至Lease Api
9、拆分Kubernetes测试压缩包
10、支持监听标签
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
