Kubernetes:在集群中创建的 ClusterRole 在 rbac 检查期间不可见

Kubernetes: ClusterRole created in the cluster are not visible during rbac checks

我的 Kubernetes 集群有问题,两周前突然出现。在解析给定 ServiceAccount 的 RBAC 时,我创建的 ClusterRoles 不可见。这是重现问题的最小集合。

default 命名空间中创建相关的 ClusterRole、ClusterRoleBinding 和 ServiceAccount 以有权查看具有此 SA 的端点。

# test.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: test-sa
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: test-cr
rules:
- apiGroups: [""]
  resources: ["endpoints"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: test-crb
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: test-cr
subjects:
- kind: ServiceAccount
  name: test-sa
  namespace: default
$ kubectl apply -f test.yaml
serviceaccount/test-sa created
clusterrole.rbac.authorization.k8s.io/test-cr created
clusterrolebinding.rbac.authorization.k8s.io/test-crb created

如果直接请求,所有对象(尤其是 ClusterRole)都是可见的。

$ kubectl get serviceaccount test-sa
NAME      SECRETS   AGE
test-sa   1         57s

$ kubectl get clusterrolebinding test-crb
NAME       AGE
test-crb   115s

$ kubectl get clusterrole test-cr
NAME      AGE
test-cr   2m19s

但是,当我尝试解析此 ServiceAccount 的有效权限时,我得到的错误是:

$ kubectl auth can-i get endpoints --as=system:serviceaccount:default:test-sa
no - RBAC: clusterrole.rbac.authorization.k8s.io "test-cr" not found

破坏前创建的RBAC规则正常工作。例如,这里是我几个月前使用 Helm 部署的 etcd-operator 的 ServiceAccount:

$ kubectl auth can-i get endpoints --as=system:serviceaccount:etcd:etcd-etcd-operator-etcd-operator
yes

本集群的Kubernetes版本为1.17.0-0.

我最近还发现新 Pods 的部署速度非常慢,在由 StatefulSet 或 Deployment 创建后最多可能需要 5 分钟才能开始部署,如果这有帮助的话。

您是否了解正在发生的事情,或者我能做些什么?请注意,我的 Kubernetes 集群是托管的,所以我对底层系统没有任何控制权,我只有作为客户的 cluster-admin 权限。但无论如何,如果我能给管理员任何指示,那将会有很大帮助。

提前致谢!

非常感谢您的回答!

事实证明,我们肯定永远不会对发生的事情有最终的看法。集群提供者刚刚重启了 kube-apiserver,这解决了这个问题。

我想是出了问题,比如缓存或其他暂时性故障,不能定义为可重现的错误。

为将来提供更多数据reader,错误发生在由 OVH 管理的 Kubernetes 集群上,它们的特殊性是 运行 控制平面本身 pods 部署在他们这边的主 Kubernetes 集群中。