Kubernetes部署Fluent-bit报cannot list resource "pods/var"错误求助

serviceAccount与serviceAccountName字段区别 #

serviceAccount是Kubernetes早期版本的遗留废弃字段，自v1.24版本起已被正式移除，当前规范仅需使用serviceAccountName指定Pod关联的服务账号即可。两个字段同时配置时仅serviceAccountName的值生效，因此调整这两个字段的配置无法解决你的问题。

报错问题排查与解决方法 #

你的报错核心为服务账号system:serviceaccount:efk:k8s-logger无法访问work命名空间下的pods/var子资源，可按以下顺序排查：

1. 直接验证RBAC权限有效性 #

使用Kubernetes原生权限校验命令可快速确认权限配置是否生效：

# 验证访问标准日志子资源pods/log的权限
kubectl auth can-i list pods/log --as system:serviceaccount:efk:k8s-logger --namespace work
# 验证报错中提及的pods/var子资源权限
kubectl auth can-i list pods/var --as system:serviceaccount:efk:k8s-logger --namespace work

• 若第一条命令返回yes、第二条返回no：问题出在Fluent Bit配置错误，采集插件请求了不存在的pods/var子资源，只需修改Fluent Bit的Kubernetes输入/过滤器配置，将请求的子资源改为正确的pods/log即可。
• 若两条命令均返回no：说明你的ClusterRoleBinding未生效，可先尝试在work命名空间创建单独的RoleBinding绑定对应权限，避免全局ClusterRoleBinding被集群准入策略拦截：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: k8s-logger-work
  namespace: work
subjects:
- kind: ServiceAccount
  name: k8s-logger
  namespace: efk
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

2. 检查集群额外访问控制策略 #

如果权限验证正常但仍报错，排查集群是否部署了额外的访问控制组件：

• 是否开启了Pod安全准入、PodSecurityPolicy等内置限制
• 是否部署了OPA Gatekeeper、Kyverno等策略引擎，存在禁止该服务账号访问对应资源的规则

3. 升级Fluent Bit版本 #

部分旧版本Fluent Bit的Kubernetes采集插件存在资源请求路径错误的已知bug，升级到最新稳定版即可解决这类问题。

内容的提问来源于stack exchange，提问作者bsellersful