在云原生场景下，为了使CPU利用率更高，以及各容器之间不会由于激烈竞争而引起性能下降，容器的资源分配需要更精细化。
Nacos 是 Dynamic Naming and Configuration-Service 的首字母简称，定位于一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。从 2018 年 7 月开始宣布开源以来，已经走过了第四个年头，在这四年里，备受广大开源用户欢迎，共收获 23.3K 的 star 数，10.3K 的 Fork 数，在开源中国发布的 2021 年度 OSC 中国开源项目评选中，Nacos 被评为云原生领域人气指数 Top5 的项目，发布电子书《Nacos 架构与原理》6w+阅读量，2w 下载量，发布半年的时间里在阿里云藏经阁历史下载榜前十。Nacos 在社区共同的建设下不断成长，逐步的开始帮助用户解决实际问题，助力企业数字化转型，目前已经广泛的使用在国内的公司中，根据微服务领域调查问卷，Nacos 在注册配置中心领域已经成为国内首选，占有 50%+国内市场份额，被头部企业广泛使用！
K8s社区主要通过Extender Resource和Device Plugin方式给为用户提供GPU物理资源支持。 每个GPU厂商都会实现自己的Device Plugin Agent，Agent在底层节点层会将物理卡扫描上报到集群。用户用拓展资源方式在Pod创建时指定需要物理卡的数量，Device Plugin在每个Kubelet节点上做启动，并且调用各个GPU厂商的设备工具，将设备卡资源扫描上报。
从“上云”到“云上”原生，云原生提供了最优用云路径，云原生的技术价值已被广泛认可。当前行业用户全面转型云原生已是大势所趋，用户侧云原生平台建设和应用云原生化改造进程正在加速。然而，云原生复杂的技术栈和传统IT的历史包袱给用户带来了巨大挑战，针对平台建设和应用改造的能力要求缺少统一规范成为企业转型的最大障碍。在用户侧，企业执行层面存在“三难”问题，即诊断难、规划难、选型难，需求和供给不能精准对应，缺少权威建设指南；在技术供给侧，技术迭代加速，产品能力构建缺少行业“灯塔”，技术押宝的风险掣肘发展。
社区的贡献者们是如何为 Apache APISIX 开发插件的呢？Apache APISIX 博客上的文章似乎都没有详细讲述过开发插件的流程。那么这次我们换一个视角，从插件开发者的角度出发，一起来看看一款插件诞生的全过程吧！本篇文章记录了一个没有后端经验的前端工程师在 API 网关上开发 file-logger 插件的过程。在详细说明实现过程之前，先向大家简单介绍下 file-logger 的功能。
云原生时代，动态和可观测性成为衡量 API 网关的标准之一。Apache APISIX 自诞生之初就一直跟随着云原生的脚步前行。然而 Apache APISIX 作为一个诞生刚刚三年的新一代网关，为什么可以从诞生 20 多年的 NGINX 与开源 8 年的 Kong 中突出重围，成为云原生时代最流行以及最活跃的网关？我认为其中最重要的原因是解决了开发者和企业在使用 NGINX 和 Kong 中的痛点。
