做线上网站需要钱吗,网站网络推广推广,成都市住建局平台官网,wordpress 4.3.4下载Kubernetes 1.14.0 Release 已经于3月25日正式发布。相信你也已经注意到#xff0c;相比于1.13 和 1.12 版本#xff0c;这次发布包含的重要变更非常多#xff0c;其对应的 Release Note 的篇幅长度也创下了“新高”。
面对这样一份“海量信息”的 Release Note#xff0c…Kubernetes 1.14.0 Release 已经于3月25日正式发布。相信你也已经注意到相比于1.13 和 1.12 版本这次发布包含的重要变更非常多其对应的 Release Note 的篇幅长度也创下了“新高”。
面对这样一份“海量信息”的 Release Note我们该如何从这份文档里进行高效的信息过滤和挖掘帮助团队更精准、快速的梳理出这次发布最主要的技术脉络呢
在本篇文章中我们将 1.14 的Release Note 按照主题进行了重新归纳和梳理按照类别对重要变更进行了技术剖析和讨论。希望这种“分类解读”的方式能够帮助大家更好的理解 1.14 这个发布的核心内容。 Windows Node 正式生产可用
随着1.14的发布Kubernetes 对windows节点的生产级支持无疑是一个重要的里程碑。具体来说1.14 版本针对 Windows 做了大量增强
PodPod内支持readiness和liveness探针支持进程隔离和volume共享的多容器PodPod支持原生configmap和sercretPod支持emptyDir支持对Pod进行资源配额等但是像优雅删除、Termination message、Privileged Containers、HugePages、Pod驱逐策略等部分特性还未在1.14版本提供Service支持服务环境变量提供DNS解析支持NodePort、ClusterIP、LoadBalancer、Headless service暂不支持Pod的hostnetwork模式常规 Workload controllerRS、deployment、statefulset、daemonset、job、cronjob均支持windows容器除此之外支持Pod和container维度的metrics、HPA、“kubectl exec”、调度抢占、resource quotas、CNI 网络支持等多种特性让windows workload更加云原生由于windows的特殊兼容性目前 host OS的版本必须和容器镜像OS版本一致1.14版本支持win server 2019未来版本中会考虑使用Hyper-V隔离机制来解决版本兼容性问题。
而伴随着 Windows 容器的生态正在慢慢壮大能够在生产级别支持 Windows 节点的容器服务开始见诸各大云厂商。阿里云容器服务ACK近期已经推出了 Windows Container 的支持提供了linux/windows应用混合部署的统一管理能力。
参见Support for Windows Nodes is Graduating to Stable (#116 ) 本地持久化数据卷Local PV 正式可用
长期以来能够让 Kubernetes 直接用宿主机的本地存储设备比如本地 SSD 硬盘来提供持久化数据卷即Local PV 功能一直是社区里非常强烈的一个诉求。这个原因很容易理解相对于远程存储网络存储Local PV 在时延性、易用性、稳定性和费用上具有独特的优势尤其是对于相关特性比较敏感的应用如数据库应用和搜索引擎应用来说有着重要的意义。
而在 1.14 中Local PV 终于正式宣布 GA为云上的持久化存储选择增加了一种重要的的可能。
不过必须要明确的是 选择使用 Local PV也意味着用户必须自己承担一些潜在的风险这包括
目前社区的开源方案无法动态创建卷调度器需要由额外的调度逻辑工作以确保调度的节点可以分配出足够的磁盘容量容错性差如果pod正在运行的宿主机宕机或者磁盘发生异常那么它的持久化卷里的信息可能丢失
第一个问题可以通过比如阿里云的 local-volume-provisioner 实现本地 SSD Nvme实例自动创建数据卷来解决但对于容错性和健壮性的问题就是比较棘手的了。
参见Durable Local Storage Management is Now GA (#121)
Pod 优先级与抢占机制稳定可用
Kubernetes 里的任务优先级priority和抢占机制preemption的目的十分明确保证高优先级的任务可以在需要的时候通过抢占低优先级任务的方式得到运行。
这其中优先级定义了一个Pod在集群中的重要程度这个重要程度体现且仅体现在两个地方1高优先级的Pod在调度阶段更容易被优先调度K8s采用队列调度模型注意这里并不保证高优先级Pod永远被优先调度实际影响调度顺序的因素有很多2在集群整体负载较高时如果出现高优先级Pod无法被调度的情况集群中没有满足条件的Node供Pod运行K8s会启动抢占机制通过抢占已经运行的低优先级的Pod的方式让高优先级的Pod可以运行起来。抢占机制便是在这里引入的。
抢占机制指当调度器发现某个Pod如Pod-A无法在集群中找到合适的节点部署时所有节点Predicates全部失败会试图通过删除一些优先级低于Pod-A的Pod来“腾出空间”部署Pod-A这样Pod-A就可以被调度了。这样一个“看似简单”的需求在分布式环境中实施起来有很多细节例如如何决定删除哪个节点的哪些Pod、如何保证为Pod-A腾出的空间不被其它Pod占用、如何保证Pod-A不被饿死Starvation、如何处理有亲和性需求的Pod调度约束、是否需要支持跨节点Preemption以支持某些特定的约束例如某Failure Domain的反亲和约束等等。这些内容可以参见Pod Priority and Preemption in Kubernetes (#564) 你一定要知道什么是 Pod Ready
在 1.14 版本之前Kubernetes 判断一个Pod是否Ready就是检查这个Pod的容器是否全部正常运行。但是这里有个问题那就是容器或者说里面的主进程Ready并不一定意味着这个应用副本就一定是就绪的。为了确认Pod确实可以正常可用我们希望给它增加一些外部指标比如该 Pod 需要的 ServiceDNS存储等服务全部就绪来反应这个Pod是否“真正”Ready。
这个特性就是1.14 里一个叫做“Pod Readiness Gates”、也叫做 Pod Ready 的特性。它为pod的“Ready 状态” 提供了一个非常强大的扩展点。需要注意的是用户需要编写一个外部控制器Controller来为这个Pod Readiness Gates 字段对应的指标设置值。
参见Pod Ready (#580) Kubernetes 原生应用管理能力
1.14之后Kubernetes 项目本身开始具备了原生的应用管理能力这其中最重要的一个功能就是 Kustomize。
Kustomize 允许用户从一个基础 YAML 文件通过 overlay 的方式生成最终部署应用所需的 YAML 文件而不是像 Helm 那样通过字符串替换的方式来直接修改基础 YAML 文件模板。这样在一个用户通过 overlay 生成新的 YAML 文件的同时其他用户可以完全不受影响的使用任何一个基础 YAML 或者某一层生成出来的 YAML 。这使得每一个用户都可以通过 fork/modify/rebase 这样 Git 风格的流程来管理海量的 YAML 文件。这种 PATCH 的思想跟 Docker 镜像是非常类似的它既规避了“字符串替换”对 YAML 文件的入侵也不需要用户学习蹩脚的 DSL 语法比如 Lua。
在1.14之后Kustomize 已经成为了 kubectl 的一个内置命令。不难看到Kubernetes 社区正在探索一种 Helm 之外的、更加 Kubernetes 原生的应用管理方法。具体效果如何我们不妨拭目以待。 参见Added Kustomize as a subcommand in kubectl (#73033, Liujingfang1) 用户友好度进一步提升
随着大家对Kubernetes越来越熟悉对kubectl依赖也越来越强烈需求也越来越多样化。而在 1.14 中kubectl 着重在以下几个方面提升用户体验加强对日常运维能力的支持。 之前 kubectl cp 操作每次只能 copy 一个文件没办法使用通配符拷贝一批文件非常不方便。在1.14中蚂蚁金服的工程师提交了一个拷贝操作的通配符功能方便对容器中的文件进行操作。 参见#72641 以往用户通常无法方便的知道自己被管理员通过 RBAC 配置的权限到底有哪些。而从v1.14开始用户可以通过 kubectl auth can-i --list --namespacens1 来查看自己在 ns1 这个namespace下可以访问哪些资源 比如PodService等并有哪些操作的权限比如GetListPatchDelete等了。 参见#64820 Kubernetes 用户需要删除的API 资源往往分散在多个namespace中删除非常不方便。在v1.14新版本中用户终于可以借助于 kubectl delete xxx --all-namespaces 来进行统一的删除操作了这里 XXX 可以是PodServicesDeployment自定义的CRD等等并且还可以配合 -l 和 --field-selector 可以更精确地删除满足特定条件的资源。 参见#73716稳定性进一步提升
和之前每个版本一样Kubernetes 的新版本发布对稳定性和可靠性增强的关注一直是重中之重下面我们列举出一些值得注意的修复和升级。 在做Pod驱逐时会优先尝试使用优雅删除模式而不是暴力删除etcd内的Pod数据。这个修复能够使被驱逐的 Pod更加优雅的退出。 参见#72730 Kubelet要重建Pod的容器时如果旧容器是unknown状态现在Kubelet会首先尝试Stop容器。这避免了一个 Pod的同一个容器申明会有多个实例同时运行的风险。 参见#73802 在大规模集群中节点因为个别Pod使用了大量磁盘 IO可能会导致节点频繁的在Ready/NotReady状态之间变化。这种状态会引起大规模的、不可预期的 Pod Eviction导致线上故障。蚂蚁金服的工程师针对 Docker 环境下的这个问题提交了修复建议大家也排查一下其它运行时的集群里是否有同样的问题。 参见#74389 当 Kubelet在压力较大情况下可能会发生 Kubelet 的Pod 生命周期事件消费频次弱于事件产生频次导致负责这个事件的 Channel 被占满这种情况持续一段时间后会直接导致Kubelet 死锁。阿里巴巴的工程师针对修这个问题提交了修复。 参见#72709大规模场景下的性能提升与优化
在 Kubernetes 的主干功能日趋稳定之后社区已经开始更多的关注大规模场景下 Kubernetes 项目会暴露出来的各种各样的问题。在v1.14中Kubernetes 社区从面向最终用户的角度做出了很多优化比如 kubectl 在实现中会顺序遍历 APIServer暴露出的全部资源的Group/Version/Kind直到查找到需要处理的资源。这种遍历方式导致了用户在大规模集群下使用 kubectl 的性能体验受到很大影响。在v1.14版本中kubectl的顺序遍历行为终于改为了并行极大地提升了kubectl的使用体验经过测试性能指标提升了10倍以上。 参见 #73345 在 1.14 中APIServer 里的一个重要变更是对单次 PATCH 请求内容里的操作个数做出了限制不能超过10000个否则就不处理此请求。这样做的目的是防止 APIServer 因为处理海量的甚至是恶意PATCH 请求导致整个集群瘫痪。这也其实也是社区的 CVE-2019-1002100 主要的修复方法。 参见#74000 Kubernetes 的 Aggregated API允许 k8s 的开发人员编写一个自定义服务并把这个服务注册到k8s的 API 里面像原生 API 一样使用。在这个情况下APIServer 需要将用户自定义 API Spec 与原生的 API Spec 归并起来这是一个非常消耗CPU 的性能痛点。而在v1.14中社区大大优化了这个操作的速率极大地提升了APIServer 归并 Spec 的性能提升了不止十倍。 参见#71223
原文链接 本文为云栖社区原创内容未经允许不得转载。
