k8s原生调度器默认资源平衡是根据Node节点的空闲request来实现的,但是我们配置Pod request预设值时基本是虚拟机的思想,会比实际程序使用值偏大并且和实际偏差较大,造成Node的request已分配比和资源实际利用率(水位)偏差较大,如下图所示。如果集群规模较大或集群运行时间较长,每个节点中request分配虽然接近,但是节点间资源水位相差很大。负载很高的主机其上的业务存在运行不稳定,同时负载很低的主机资源被大量浪费,哈啰自研的基于水位平衡的调度器主要就是为了解决这个问题。
本文将从一个普通开发者的角度去探索Kubernetes,从应用部署方式的演变方式说起,再到搭建一个简易的K8s集群,去了解它的资源管理方式,然后再去实战。当对K8s有了一定了解后,再将其中的核心组件的原理进行剖析,从而深入理解Kubernetes的原理与架构。相信可以在读完本文后对Kubernetes有一个初步认识。
利用率提升的大背景可以归纳为4个字——降本增效。通常来说,集群的利用率低会导致成本居高不下。集群、应用等配置,使用不合理,可能无法持续提升集群资源利用率,导致恶性循环。
Knative 是在 Kubernetes 基础之上的 Serverless 计算的技术框架,可以极大简化 Kubernetes 应用的开发与运维体验。在 2022 年 3 月成为 CNCF 孵化项目。Knative 由两个主要部分组成:一个是支持 HTTP 在线应用的 Knative Serving,一个是支持 CloudEvents 和事件驱动应用的 Knative Eventing。Knative 可以支持各种容器化的运行时环境,我们今天来探索一下利用 WebAssembly 技术作为一个新的 Serverless 运行时。
Helm Charts 如今已是一种非常流行的软件打包方式,在其应用市场中你可以找到接近一万款适用于云原生环境的软件。然后在如今的混合云多集群环境中,业务越来越依赖部署到不同的集群、不同的环境、同时指定不同的配置。再这样的环境下,单纯依赖 Helm 工具可能无法做到灵活的部署和交付。
这是我们的《Kubernetes资源编排系列》的第三篇——Kustomize篇,在上篇《Kubernetes资源编排系列之二: Helm篇》,我们见识到了Helm强大的管理能力,但是Helm对于服务的定制仅限于预置变量,那么如果需要更多更灵活的YAML定制,有什么办法吗?于是本篇我们来介绍一下Kustomize。
kubernetes调度器,通过watch机制来发现集群中新创建且未调度的pod,通过过滤node列表,打分策略,以及各个时机的插件调用机制,选择合适的node与之绑定。
Helm是Kubernetes生态系统中的一个软件包管理工具,类似于Ubuntu中的apt、CentOS中的yum等,它用于自动创建、打包、配置和部署应用程序和服务到Kubernetes 集群。
我们特推出《Kubernetes资源编排系列》,从底层的Pod YAML开始,逐步递进地讲解相关内容,希望能够解答大家对于Kubernetes的一些疑问,让用户对于云原生相关技术有更深入的了解。