技术翻译/评论:Wshi(才云),星空下的文仔(才云),小君君(才云),bot(才云)node
编辑:小君君(才云)git
美国时间 3 月 25 日,Kubernetes 迎来了 2019 年的第一个新版本 1.14。与此前发布的各版本 Kubernetes 相比,本版本中的加强功能更趋于稳定。这对那些把 Kubernetes 视为重要战略支撑的企业和运营商而言,是个重要里程碑。github
Kubernetes v1.14 由 31 项功能强化构成:10 个功能已经稳定,12 个功能进入 Beta,7 个全新功能。此次更新延续了以往的主题——可扩展性,且能支持 Kubernetes 上的更多工做负载,其中三个主要功能转向通常可用性,一个重要安全功能转向 Beta。docker
新版本四大主要特征数据库
生产级 Windows 节点支持 json
截至目前,Kubernetes 中的 Windows 节点支持已经处于 Beta 阶段,容许更多用户检验并查看 Kubernetes 对 Windows 容器的价值。Kubernetes 如今正式支持将 Windows 节点添加为工做节点并调度 Windows 容器,从而使 Windows 应用程序巨大的生态系统可以利用平台的强大功能。api
对于那些使用基于 Windows 和 Linux 的应用程序企业,它们也不在须要单独寻找编排系统来管理它们的工做负载,也不用担忧操做系统是什么,整个部署的操做效率大幅提升。缓存
为了实现这一目标,Kubernetes v1.14 作了如下重点更新:安全
-
工做站节点和容器新增 Windows Server 2019 支持;服务器
-
使用 Azure-CNI、OVN-Kubernetes 和 Flannel 支持树外网络链接;
-
改进了对 Pod、服务类型、工做负载控制器和 metrics/quotas 的支持,以更紧密的融合那些已经支持 Linux 容器的能力。
值得关注的 kubectl 更新
新的 kubectl 文档和标志
kubectl 的文档已经从头开始重写,重点是使用声明性 Resource Config 来管理资源。该文档目前以独立站点的形式发布,采用电子书格式,并在 k8s.io 文档中提供对应连接(详情见:https://kubectl.docs.kubernetes.io)。
新的 kubectl 徽标和吉祥物(音为 kubee-cuddle)也会在新的文档站点中展现出来。
kustomize Integration
kustomize 的声明性 Resource Config 创做功能如今可经过 -k 标志(如用于命令 apply、get 等命令)和 kustomize 子命令在 kubectl 中得到。kustomize 帮助用户使用 Kubernetes 原生概念建立和重用 Resource Config。用户如今可以利用 kubectl apply -k dir/ 将拥有 kustomization.yaml 的目录适用于集群。此外,用户还能够向 stdout 发出自定义的 Resource Config,而无需经过 kubectl kustomize dir/ 加以应用。新功能记录,见 https://kubect.docs.kubernetes.io。
社区还将继续经过 Kubernetes 的 kustomize repo 对 kustomize 子命令进行开发。最新的 kustomize 功能将以独立的 kustomize 二进制文件(发布到 kustomize repo)的形式更改成频率的发布,并将在每次 Kubernetes 发布以前在 kubectl 中更新。
kubectl 插件机制逐渐稳定
kubectl 插件机制容许开发人员以独立二进制文件的形式发布本身的自定义 kubectl 子命令。这些成果将可帮助 kubectl 与附加 porcelain 实现更多新的高级功能(如添加 set-ns 命令)。
插件必须具备 kubectl- 为命名的前缀,并保存于用户的 $PATH 中。在 GA 中,插件机制已经大幅简化。目前,其形式相似于 git 插件系统。
持久化本地存储进入 GA 阶段
新版本下,持久化本地存储更加稳定,使用户能够把本地链接存储用做持久存储源。因为性能和成本的考量,分布式文件系统和数据库一直是持久性本地存储的主要用例。相比云提供商,本地 SSD 提供的性能远比远程磁盘优秀。而相比裸机,除了性能,本地存储一般更便宜,而且使用它是配置分布式文件系统的必要条件。
PID 限制 Beta 预告
进程 ID(PID)是 Linux 主机上的基本资源。在不遇到任何其余资源限制的状况下,用户没法接受由于进程 ID 不足而影响任务运行,甚至致使主机稳定性下降。管理员须要一些机制来确保 Pod 中的 PID 不被耗尽,从而阻止主机守护程序(运行时、kubelet 等)运行。此外,管理员还须要确保在各 Pod 之间限制 PID,以确保它们不会影响到运行在节点上的其余工做负载。
在 Beta 版中,管理员能够经过预约义每一个 Pod 的 PID 数量,实现 Pod 之间的 PID 隔离。此外,管理员也能够经过节点可分配的方式为用户 Pod 保留大量可分配的 PID,这是 Alpha 版中实现 Pod 间的 PID 隔离的方法。在下一版本中,开发团队但愿能把 Beta 版带给开发者。
其余值得注意的功能更新
Pod 优先级和抢占使 Kubernetes 调度程序可以首先调度更重要的 Pod,当集群资源不足时,它会删除不过重要的 Pod,以便为更重要的 Pod 建立空间。重要性由优先级指定。
Pod Readiness Gates 如今为 Pod 就绪状况提供了外部反馈的扩展点。
增强默认 RBAC 的 clusterrolebindings 发现能力。移除了本来默承认经过未受权访问的 API 集发现功能,旨在提高 CRD 隐私性以及默认集群的整体安全水平。
可用性
Kubernetes v1.14 可从 GitHub 下载。要开始使用 Kubernetes,请查看各种交互式教程。你也可使用 kubeadm 轻松安装 1.14 版本 。
紧急升级说明
kube-apiserver
-
默认的 RBAC 策略已再也不授予未经身份验证的用户使用发现和权限检查的 APIs 的权限(经过 kubectl auth can-i)。升级后的集群会保留先前的行为,可是若是集群管理员但愿授予未身份验证的用户访问新集群,则必须明确指定 discovery 或者权限检查的 APIs;
-
--storage-versions 标志已经被移除。storage version 会一直以默认值方式编译到 kube-apiserver 里;
-
--repair-malformed-updates 标志被移除;
-
Kube-apiserver 如今只聚合来自 /openapi/v2 聚合 API 服务器端点的 openapi 模式。聚合的后备 /swagger.json 已被删除。确保聚合 API server 经过 /openapi/v2(自 v1.10 起可用)提供架构信息;
-
已删除前缀为“io.k8s.kubernetes.pkg”(自 v1.9 已弃用)的 OpenAPI 定义;
-
该 ValidateProxyRedirects 功能已升级为 Beta 并默认启用。此功能限制从 apiserver 到同一主机重定向的重定向跟踪。若是节点配置为响应不一样于 apiserver 请求的主机接口上的 CRI 流请求(仅在不使用内置 dockershim 和设置 kubelet 标志的状况下 --redirect-container-streaming=true),则这些请求将被破坏。在这种状况下,能够暂时禁用该功能,直到更正节点配置。咱们建议设置 --redirect-container-streaming=false 以免问题。
kubectl
-
已弃用的 kubectl get 的 --show-all 标记已被删除。
kubelet
-
已弃用的 --experimental-fail-swap-on 标志已被删除;
-
使用 HTTPGetAction 的运行情况检查(活动性和就绪性)探测将再也不遵循重定向到原始探测请求的不一样主机名。相反,这些非本地重定向将被视为成功(记录的行为)。在这种状况下,将生成具备“ProbeWarning”缘由的事件,指示重定向被忽略。若是你之前依赖重定向对不一样的端点运行情况检查,则须要在 kubelet 外部执行运行情况检查逻辑,例如经过代理外部端点而不是重定向到它。
client-go
-
已弃用的无版本 API 组访问(如 clientset.Apps())已被删除。使用显式版本(如 clientset.AppsV1());
-
磁盘缓存的发现客户端从 k8s.io/client-go/discovery 移至 k8s.io/client-go/discovery/cached/disk。内存缓存的发现客户端从 k8s.io/client-go/discovery/cached 移至 k8s.io/client-go/discovery/cached/memory。
kubeadm
-
kubeadm alpha preflight 和 kubeadm alpha preflight node 被移除;你如今可使用 kubeadm join phase preflight;
-
弃用的污点 node.alpha.kubernetes.io/notReady 和 node.alpha.kubernetes.io/unreachable 再也不支持或调整。应将这些替换为node.kubernetes.io/not-ready 和 node.kubernetes.io/unreachable;
-
任何匹配 pod_name 和 container_name 标签的 Prometheus 查询(例如 cadvisor 或 kubelet 探测指标)都应该更新为 Pod 和 Container。pod_name 和 container_name 标签将与一个过渡版本一块儿存在,并在未来删除。
1.14 更新细节
Windows 节点支持已进入稳定阶段
-
支持 Windows Server 2019 做为 worker nodes 和容器使用;
-
支持使用 Azure-CNI、OVN-Kubernetes 和 Flannel 组成树外网络链接;
-
改进了对 Pods、service types、workload controllers 和 metrics/quotas 的支持,以更紧密的融合那些已经支持 Linux 容器的能力。
kubectl 的插件机制逐步趋于稳定
-
kubectl 扩展性功能,支持添加新命令,还能够覆写指定的子命令。
本地存储管理达到 GA
-
使本地(非网络)存储可用做持久卷源;
-
容许用户利用本地持久存储一般更便宜且性能更好的优势。
Kubernetes 中的 Pod 优先级和抢占
-
Pod 优先级和抢占使 Kubernetes 调度程序可以首先调度更重要的 Pod,当集群资源不足时,它会删除不过重要的 Pod,以便为更重要的 Pod 建立空间。重要性由优先级指定。
Pod Ready ++
-
介绍了有关 Pod 准备就绪的外部反馈的扩展点。
kubeadm:在 HA 设置中自动执行控制平面之间的证书复制
-
如今,经过启用现有控制平面节点的可选自动证书副本,能够简化将控制平面节点链接到 HA 群集的过程;
-
你如今可使用 kubeadm init --experimental-upload-certs 和 kubeadm join --experimental-control-plane --certificate-key。
kubeadm:将 kubeadm join 工做流程公开为阶段
-
该 kubeadm join 命令如今能够分阶段使用。与 kubeadm init 在 1.13 中完成的工做相似,在 1.14 中,join 如今可使用 kubeadm join phase 子命令逐步/有选择地执行阶段。这使得能够进一步定制将节点加入集群的工做流程。
新版技术评论
「K8sMeetup 中国社区」特别邀请 Caicloud(才云科技) 工程师,第一时间为 Kubernetes 1.14 作了一个简短评论:
从 Kubernetes v1.13 开始,咱们渐渐发现 Kubernetes 在趋于稳定,并无太多新功能的增长,更多的是在稳定性,安全性和扩展性等功能方面的增强。在今天发布的 v1.14 中,这点也能够获得体现。
Kubernetes v1.14 依然延续 v1.13 在扩展性上作了不少工做,尤为对 Windows 的支持。在官方声明中, 新版本能够添加 Windows 节点做为工做节点,而且调度 Windows 容器。 其实,Kubernetes 对 Windows 的支持能够追溯到 1.5 版本,历经这么长时间的努力,如今用户终于能够配置使用 Linux + Windows 集群环境,而且同时运行 Windows 容器应用和 Linux 容器应用。这给想要使用 Kubernetes 编排系统而又基于 Windows 开发的企业带来了福音。
参考文献
1.https://kubernetes.io/blog/
2.https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.14.md#kubernetes-v114-release-notes