容器本质是一项隔离技术，很好的解决了他的前任 - 虚拟化未解决的问题：运行环境启动速度慢、资源利用率低，而容器技术的两个核心概念，Namespace 和 Cgroup，恰到好处的解决了这两个难题。Namespace 作为看起来是隔离的技术，替代了 Hypervise 和 GuestOS，在原本在两个 OS 上的运行环境演进成一个，运行环境更加轻量化、启动快，Cgroup 则被作为用起来是隔离的技术，限制了一个进程只能消耗整台机器的部分 CPU 和内存。
KubeVela 是一个简单易用且高度可扩展的应用交付和管理平台，基于 Kubernetes 与 OAM 技术构建。其核心功能是让开发人员方便快捷地在 Kubernetes 上定义与交付现代微服务应用，而无需了解任何 Kubernetes 本身相关的细节。
当前，云原生技术以容器技术为基础，通过标准可扩展的调度、网络、存储、容器运行时接口来提供基础设施。同时，通过标准可扩展的声明式资源和控制器来提供运维能力，两层标准化推动了开发与运维关注点分离，各领域进一步提升规模化和专业化，达到成本、效率、稳定性的全面优化。 在这样的大技术背景下，越来越多的公司引入了云原生技术来开发、运维业务应用。正因为云原生技术带来了越发纷繁复杂的可能性，业务应用出现了微服务众多、多语言开发、多通信协议的鲜明特征。同时，云原生技术本身将复杂度下移，给可观测性带来了更多挑战：
我们知道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个字——降本增效。通常来说，集群的利用率低会导致成本居高不下。集群、应用等配置，使用不合理，可能无法持续提升集群资源利用率，导致恶性循环。
