Question

我具有以下部署规范：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sa-dep-non-root 
spec:
  selector:
    matchLabels:
      app: sa-dep-non-root # has to match .spec.template.metadata.labels
  #replicas: 3 # by default is 1
  template:
    metadata:
      labels:
        app: sa-dep-non-root # has to match .spec.selector.matchLabels
    spec:
      serviceAccountName: simon-sa
      securityContext:
        runAsUser: 1000
      tolerations:
      - key: "type"
        operator: "Equal"
        value: "ops"
        effect: "NoSchedule"
      containers:
      - name: sa-dep-non-root
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: sa-dep-non-root

在运行时可以正确创建部署及其相应的Pod： kubectl apply -f simon-sa-deployment-non-root.yaml -n test-ns 我没想到这会起作用，因为我将serviceAccountName设置为simon-sa，它没有创建Pod的权限：

Simons-MBP:test simon$ kubectl  --as=system:serviceaccount:test-ns:simon-sa auth can-i create pods -n test-ns
no

我的理解是，当未指定serviceAccountName时，则是k8s控制器管理器（通过具有正确权限的一些clusterrolebindings，例如system：controller：replicaset-controller）来创建Pod，而并非实际上是我自己的用户，在这个用户中，我为创建该部署的pod的用户进行了身份验证。

我的另一个理解是，在pod定义中指定serviceAccountName时可以覆盖此行为。在这种情况下，吊舱不是由控制器管理器创建的，而是由指定的serviceAccountName创建的。由于我指定的serviceAccountName没有创建pod的权限，因此应该失败。我在这里混合概念吗？

Answer 1

ServiceAccounts是Pod的权限，您正在做的就是将此权限分配给您在部署中实例化的Pod，因此kubectl apply -f simon-sa-deployment-non-root.yaml -n test-ns将使用您的用户使用{ {1}} API服务器，因此，如果您执行kubectl，它将返回是。

所以也许您想做的是创建一个对集群具有只读访问权限的用户，这是通过集群角色而不是服务域（仅限于Pod）完成的。

或者让我知道您正在尝试做什么，我可以解释

为什么在Kubernetes中不允许服务帐户创建Pod？

1 个答案: