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 中的痛点。
