当前,云原生技术以容器技术为基础,通过标准可扩展的调度、网络、存储、容器运行时接口来提供基础设施。同时,通过标准可扩展的声明式资源和控制器来提供运维能力,两层标准化推动了开发与运维关注点分离,各领域进一步提升规模化和专业化,达到成本、效率、稳定性的全面优化。 在这样的大技术背景下,越来越多的公司引入了云原生技术来开发、运维业务应用。正因为云原生技术带来了越发纷繁复杂的可能性,业务应用出现了微服务众多、多语言开发、多通信协议的鲜明特征。同时,云原生技术本身将复杂度下移,给可观测性带来了更多挑战:
我们知道Kubernetes在容器编排市场中占据了主导地位,用户基数呈逐年上升的趋势。K8s提供了强大的运维部署、弹性伸缩、故障恢复能力,极大地便利了分布式系统的开发和管理,但是随之而来的安全问题却也比较突出。
在云原生场景下,为了使CPU利用率更高,以及各容器之间不会由于激烈竞争而引起性能下降,容器的资源分配需要更精细化。
K8s社区主要通过Extender Resource和Device Plugin方式给为用户提供GPU物理资源支持。 每个GPU厂商都会实现自己的Device Plugin Agent,Agent在底层节点层会将物理卡扫描上报到集群。用户用拓展资源方式在Pod创建时指定需要物理卡的数量,Device Plugin在每个Kubelet节点上做启动,并且调用各个GPU厂商的设备工具,将设备卡资源扫描上报。
In this article, you will learn how to recreate the Kubernetes RBAC authorization model from scratch and practice the relationships between Roles, ClusterRoles, ServiceAccounts, RoleBindings and ClusterRoleBindings.
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 工具可能无法做到灵活的部署和交付。