Question

我在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。

我最近还发现新Pod的部署非常缓慢，如果有帮助的话，在由StatefulSet或Deployment创建它们之后，可能最多需要5分钟才能开始部署。

您对正在发生的事情，甚至我能做些什么有任何见解？请注意，我的Kubernetes集群是托管的，因此我对底层系统没有任何控制，我仅具有cluster-admin特权（作为客户）。但是如果我能给管理员任何指示，那还是很有帮助的。

谢谢！

Answer 1

非常感谢您的回答！

事实证明，我们当然永远不会对所发生的事情有最后的了解。集群提供者刚刚重新启动了kube-apiserver，这解决了该问题。

我认为诸如缓存或其他暂时性故障之类的错误，不能定义为可复制错误。

为了给将来的读者提供更多数据，该错误发生在由OVH管理的Kubernetes集群上，其特殊性是将控制平面本身作为吊舱运行在其一侧的Kubernetes主集群中。

Kubernetes：在rbac检查期间看不到在集群中创建的ClusterRole

1 个答案: