Kubernetes 1.14重磅来袭,多项关键特性详细为你解读

2019 年 4 月 1 日 高效开发运维
作者 | 华为云容器团队
编辑 | 赵钰莹
3 月 26 日,Kubernetes 1.14 版本正式发布,新版本包含 31 项增强,其中 10 项为 GA,12 项进入 beta 试用阶段,7 个为全新的 alpha 功能。本文详细解读了 Kubernetes 1.14 版本的几个关键特性。

走过了突飞猛进的 2018 年,Kubernetes 在 2019 年终于迎来了第一个大动作:Kubernetes 1.14 版本的正式发布!Kubernetes 本次发布的 1.14 版本,包含了 31 项增强,其中 10 项为 GA,12 项进入 beta 试用阶段,7 个为全新的 alpha 功能。1.14 版本的主题是可扩展性,并且支持更多的业务场景,其中三个主要的功能具备生产可用,一个重要功能进入 beta 试用阶段。总体而言,1.14 版本相比之前的版本更着重于将更多的功能推进到稳定状态,尤其是部分关键功能对于用户来说具有重大的里程碑意义。

Windows 节点支持:生产可用

截至目前,1.14 版本 Windows 节点支持已经稳定,支持将 Windows 节点作为工作节点,并向其调度 Windows 容器。Windows 容器支持的引入,允许用户通过 Kubernetes 的接口界面来体验 Windows 容器,并见证 Kubernetes 对于 Windows 容器的价值。在同一集群中同时编排 Windows 与 Linux 应用,对于拥有混合应用技术栈的企业,尤其是传统企业,具有里程碑式的意义。

Windows 容器关键特性包含:

  • 支持 Windows Server 2019 作为工作节点;

  • 支持与 Azure-CNI、OVN-Kubernetes 和 Flannel 等外置容器网络插件对接;

  • 改进了对 Pod、服务类型、工作负载控制器和 metric/quota 的支持,使 Windows 容器基本匹配 Linux 容器所提供的能力。

随着 1.14 版本的发布,Kubernetes 已经能为提供相对完善的 Windows 容器基础功能集,但如果考虑端到端商用落地 Windows 容器商用方案,用户仍然不得不关注以下方面的成熟度限制:

  • 操作系统版本限制:Windows 容器对 Windows 系统以及 docker 版本都有更加严格的要求,例如 Windows Server 2019/1809 需要 Docker EE-basic 18.09 版本。

  • Hyper-V 和 Native 容器的成熟度:整体相对弱于 Linux 容器,Native 容器的安全隔离能有限,Hyper-V 隔离方案仍然是 alpha 特性,需要持续完善;而对于依赖 GPU、GUI 的应用支持较弱,相关商用案例也较少。

  • Windows 容器镜像生态:

   1. 当前可用于 Windows 容器的 base image 有限,主要就是 windowsservercore 和 nanoserver,针对实际场景的使用灵活度不高;

   2. Windows 容器的基础镜像尺寸较大,而微软的 MCR 服务 (Microsoft Container Registry) 尚未明确中国区 CDN 的上线时间,用户往往需要花费较长的时间下载镜像。

  • 网络方面:Windows 容器目前支持 5 种不同的网络模式,在异构的集群中,很难选择同时兼容 Windows 和 Linux 的网络解决方案。尽管有一些可用的插件,但是不能保证与厂商已用的网络插件兼容。

  • 其他限制:

   1. 控制面 master 节点目前不能部署在 Windows 系统中,这意味着 Kubernetes 集群必须包含使用 Linux 系统的主节点。

   2. 目前 Windows 容器并不支持 Pod 优雅删除,单文件映射、特权容器、大页内存支持、Node Problem Detection 等能力在 Windows 容器环境中都尚未支持。

在 1.14 版本稳定之后,Kubernetes 社区将继续完善对 Windows 容器支持,包括但不限于:

1. 优化使用 kubeadm 在 Windows 环境下安装节点。

2. 支持 Calico CNI 网络。

3. Hyper-V 隔离模式下支持一个 Pod 内包含多个容器。

4. 支持 Pod 优雅删除。

kubectl 插件机制稳定
 kubectl 插件机制 GA

kubectl 插件机制允许开发者已独立的二进制的形式发布自定义的 kubectl 子命令。这可以用于扩展 kubectl 具有更高级别的功能和附加的 porcelain(例如添加 set-ns 命令)。

插件必须具有 kubectl- 的命名前缀,并保存在用户 PATH 中,为了 GA,插件机制已经被大大简化了。目前有点类似 Git 的插件系统。

 集成 kustomize

kustomize(https://GitHub.com/Kubernetes-sigs/kustomize)是 K8s 社区命令行兴趣小组(SIG-CLI)的一个子项目,致力于为用户提供一种可以重复使用配置的声明式应用管理工具,让用户在配置工作中只需要管理和维护 kubernetes 的原生 API 对象,而不需要使用和管理复杂的模版。

在这次发布的版本中,kustomize 提供声明式资源配置的创建修改等能力可以 kubectl –k 参数和 kustomize 子命令来执行。kustomize 使用 Kubernetes 原生概念帮助用户创建和复用资源配置。用户可以利用 kubectl apply -k dir/ 将指定目录的 kustomization.yaml 提交到集群中。用户还可以直接将自定义的资源配置发送到标准输入,而不是通过 kubectl kustomize dir/ 应用。

更多的 kustomize 子命令将会在 kustomize 代码仓库中继续开发完善,用户可以通过更新独立的 kustomize 二进制文件来体检最新的 kustomize 特性。

据不完全统计,GitHub 上有超过 200 种 kubectl 相关的第三方命令行工具,随着 kubectl 插件机制稳定,相信这些工具很快会基于插件机制标准化,更好地与 kubectl 集成,给用户提供强大的扩展命令集。

随本次 Kubernetes 1.14 版本发布的,还有全新的 kubectl 文档及 Logo。社区重写了 kubectl 文档,并重点聚焦使用声明式的资源配置管理资源。目前 kubectl 文档已作为独立的站点上线,地址为:https://kubectl.docs.kubernetes.io,新的 kubectl Logo 及吉祥物(kubee-cuddle)也被启用。

新的 Kubectl Logo
持久化本地存储卷:生产可用

历经漫长的改进,持久化本地存储卷特性终于在 1.14 版本中达到生产可用。

本地持久卷可以使用 K8s 节点上挂载的本地存储设备作为持久卷的来源。相对于远程磁盘来说,持久化本地存储拥有优越的性能,使用更少的系统开销,更加适合分布式文件系统以及数据库等场景。相比于云盘,本地 SSD 盘比远程磁盘就具有更好的 IO 性能。相比于裸机,除了性能以外,本地存储通常更加便宜,并且使用它是配置分布式文件系统的必要条件。

虽然本地持久卷特性达到生产可用,但是易用性仍然没有得到显著的改进。用户可以通过两种相对手动的方式来使用持久化本地存储特性:

  • 用户手动指定块设备的方式提供本地持久卷;

  • 使用 sig-storage-local-static-provisioner 插件静态维护本地卷的生命周期。

而根据 Pod 及 PVC 状态自动地维护各节点中本地持久卷的能力,仍然需要较长的时间在社区推进。

应用就绪状态判断的改进:Pod Readiness Gates (Pod Ready++) 生产可用

对于 Pod 的状态,Kubernetes 为用户提供了两项判断 Pod 运行情况的能力:Readiness(就绪状态)和 Liveness(存活状态)。一个 Pod 被判断为 Ready(就绪),意味着所有初始化相关的工作已经完成,Pod 可以接收处理外部访问的请求。而 Liveness 则用于判断已就绪的 Pod 是否持续处于正常工作中。

然而在实际使用中,特别是针对大型应用,情况往往比较复杂。由于 K8s 中大量采用的异步机制、以及多种对象关系设计上的解耦,当应用实例数增加 / 删除、或者应用版本发生变化触发滚动升级时,系统并不能保证应用相关的 Service、负载均衡器配置总是及时完成刷新。在一些情况下,往往只是新的 Pod 完成自身初始化,系统尚未完成 Endpoint、负载均衡器等外部可达的访问信息刷新,老的 Pod 就立即被删除,最终造成服务不可用。这对用户来说是不可接受的。

Pod Ready++ 的引入正是为了修正 Pod 就绪状态的判断机制——用户可以通过 ReadinessGates 自定义 Pod 就绪的条件(如,从外部访问入口判断新建的 Pod 开始处理外部请求),当用户自定义的条件以及容器状态都就绪时,kubelet 才会标记 Pod 准备就绪。

在 1.14 版本中,Pod ready++ 特性达到了稳定,用户可以在生产系统中直接使用该特性。需要注意的是:对于用户自定义的就绪条件,一定需要有自定义的控制器配合更新 Pod 状态,否则,Pod 永远不会变成就绪状态。

Pod 优先级与抢占式调度:生产可用

Pod 优先级与抢占可以使 K8s 调度器在集群资源耗尽的情况下优先调度更加重要的 Pod,并且驱逐集群中正在运行的相对不重要的 Pod,为更重要的 Pod 腾出资源。Pod 的重要性通过 PriorityClassName 定义,其中"system-node-critical" 和 "system-cluster-critical" 是两个特殊的最高优先级的关键词。优先级低的 Pod 在资源不足时,容易首先被驱逐,因而对于重要的 daemonset 或者重要的应用组件,用户可以设置较高的优先级防止被抢占。

要使用优先级与抢占,管理员必须开启 Priority Admission Controller。用户在为 Pod 设置 PriorityClassName 时,必须指向集群中已创建的 PriorityClass 对象,否则 Pod 创建失败。

PID 限制:beta 试用阶段

进程 ID (PID) 是 Linux 主机基本的资源,以往 K8s 没有任何措施限制容器内的进程创建 PID,如果 PID 资源耗尽,即使其他的资源充足,也可能导致主机不稳定。在引入 PID 限制特性后,K8s 管理员可以通过 kubelet 启动参数 --pod-max-pids 来设置每个 Pod 最大可启动的进程数目,并通过 --system-reserved 和 --kube-reserved 两项参数设置系统预留的 PID 数目。

PID 限制特性带来的主要好处有:

  • 防止 Pod 因 PID 资源匮乏而不能正常运行。

  • 隔离 Pod 之间以及 Pod 与 node 之间的 PID 资源。

Kubeadm

在高可用集群中自动执行控制面之间的证书复制。

kubeadm join 命令使得用户自定义集群纳管节点的工作流程变为可能。

总结:核心趋于稳定,面向用户场景开枝散叶

结合最近几次版本发布来看,Kubernetes 核心的发展越来越趋于稳定,1.14 版本几乎没有引入大的新特性,而是把重点放在了让已有特性的稳定上。正如许多人会说,Kubernetes 正在变得无聊,事实上放眼整个云原生生态,面向最终用户的各种落地场景,仍有巨大的发展空间,许许多多围绕 Kubernetes 的新项目仍然在如雨后春笋般地涌现,而 K8s 本身一些子项目的动态也开始进入人们的视野,不断地被商业落地。相信 2019 年会是 Kubernetes 和云原生技术面向用户场景开枝散叶的一年。


活动推荐

各互联网公司的一线专家也在不断提升运维能力,从被动救火式运维向主动精细化运维实践、基于机器学习的智能运维实践、基于 Kubernetes 的自动化运维实践、全链路日志监控实践等方面转换。QCon 北京 2019 可能会有适合你业务的方案:

云原生架构下的混沌工程实践

Uber 核心派单系统及其集群管理演化

Kubernetes 日志平台建设最佳实践

美团机房大规模容灾演练实践

点击 「 阅读原文 」或识别二维码查看大会日程,现在购票即享 9 折限时折扣,立减 880 元,团购还有更多优惠!有任何问题欢迎联系票务小姐姐 Ring:电话 / 微信:17310043226

登录查看更多
0

相关内容

Kubernetes 是一个自动化部署,扩展,以及容器化管理应用程序的开源系统。
【SIGMOD2020-腾讯】Web规模本体可扩展构建
专知会员服务
29+阅读 · 2020年4月12日
【2020新书】Kafka实战:Kafka in Action,209页pdf
专知会员服务
67+阅读 · 2020年3月9日
TensorFlow Lite指南实战《TensorFlow Lite A primer》,附48页PPT
专知会员服务
69+阅读 · 2020年1月17日
【阿里巴巴】 AI编译器,AI Compiler @ Alibaba,21页ppt
专知会员服务
44+阅读 · 2019年12月22日
【干货】大数据入门指南:Hadoop、Hive、Spark、 Storm等
专知会员服务
95+阅读 · 2019年12月4日
专访阿里亚顿:Serverless与BFF与前端
前端之巅
45+阅读 · 2019年5月8日
浅谈 Kubernetes 在生产环境中的架构
DevOps时代
11+阅读 · 2019年5月8日
官方解读:TensorFlow 2.0 新的功能特性
云头条
3+阅读 · 2019年1月23日
TF Boys必看!一文搞懂TensorFlow 2.0新架构!
引力空间站
18+阅读 · 2019年1月16日
官方解读:TensorFlow 2.0中即将到来的所有新特性
机器之心
5+阅读 · 2019年1月15日
推荐|Google最热门31款开源项目资源
全球人工智能
4+阅读 · 2017年11月24日
Advances in Online Audio-Visual Meeting Transcription
Arxiv
4+阅读 · 2019年12月10日
Arxiv
13+阅读 · 2019年11月14日
Self-Attention Graph Pooling
Arxiv
13+阅读 · 2019年6月13日
Mesh R-CNN
Arxiv
4+阅读 · 2019年6月6日
Accelerated Methods for Deep Reinforcement Learning
Arxiv
6+阅读 · 2019年1月10日
VIP会员
相关资讯
专访阿里亚顿:Serverless与BFF与前端
前端之巅
45+阅读 · 2019年5月8日
浅谈 Kubernetes 在生产环境中的架构
DevOps时代
11+阅读 · 2019年5月8日
官方解读:TensorFlow 2.0 新的功能特性
云头条
3+阅读 · 2019年1月23日
TF Boys必看!一文搞懂TensorFlow 2.0新架构!
引力空间站
18+阅读 · 2019年1月16日
官方解读:TensorFlow 2.0中即将到来的所有新特性
机器之心
5+阅读 · 2019年1月15日
推荐|Google最热门31款开源项目资源
全球人工智能
4+阅读 · 2017年11月24日
相关论文
Top
微信扫码咨询专知VIP会员