关于Kubernetes中ResourceQuota生效机制的技术问询

一、K8s 1.19 环境未配置--enable-admission-plugins仍生效的原因 #

在Kubernetes 1.10至1.22版本区间内，ResourceQuota属于默认启用的准入控制插件，无需手动在--enable-admission-plugins参数中指定。

查看K8s 1.19版本的pkg/server/options/admission.go源码，DefaultEnableAdmissionPlugins数组中明确包含ResourceQuota：

var DefaultEnableAdmissionPlugins = []string{
	"NamespaceLifecycle",
	"LimitRanger",
	"ServiceAccount",
	"DefaultStorageClass",
	"DefaultTolerationSeconds",
	"MutatingAdmissionWebhook",
	"ValidatingAdmissionWebhook",
	"ResourceQuota", // 默认包含该插件
}

apiserver启动时，若未显式配置--enable-admission-plugins，会自动加载上述默认插件列表，因此给Namespace配置ResourceQuota后会正常生效。官方文档的描述可能未及时同步默认插件的变更，导致误解。

二、K8s 1.28 源码中ResourceQuota注册逻辑的变化 #

1. Register方法未被引用的原因 #

Kubernetes演进过程中，准入插件分为两类：

• 可插拔插件：通过Register方法注册，允许用户动态启用/禁用
• 内置核心插件：直接集成到apiserver启动流程中，无需通过Register注册

在1.28版本中，ResourceQuota已转为内置核心插件，不再依赖传统的Register机制。它的实例化和加载逻辑直接写在apiserver的启动代码中，因此pkg/admission/plugin/resourcequota/admission.go中的Register方法不再被引用，属于遗留兼容代码。

2. AdmissionOptions.Validate与NewRecommendedOptions的关系 #

AdmissionOptions.Validate方法的作用是检查用户配置的准入插件是否已注册，但该方法仅在调用RecommendedOptions.Validate时才会触发，而NewRecommendedOptions是创建默认推荐配置的入口。

如果是自定义的apiserver启动流程（比如部分发行版的定制化部署），可能并未调用NewRecommendedOptions，而是直接构建AdmissionOptions实例，此时Validate方法可能不会被执行。但对于ResourceQuota这类内置插件，apiserver内部会直接确认其合法性，不会因未注册而报错。

三、ResourceQuota核心生效流程（通用逻辑） #

无论版本如何，ResourceQuota的核心生效逻辑都是基于准入控制阶段的拦截：

• 当创建/修改Pod、PVC等资源对象时，请求到达apiserver的准入控制链
• ResourceQuota插件会拦截请求，检查当前Namespace下的资源使用是否已达到配额限制
• 若未超出配额，允许请求通过；若超出，则拒绝请求并返回错误信息

内容的提问来源于stack exchange，提问作者Buddie.Wei