如何在属于另一个命名空间的部署 yaml 中指定 serviceAccount（在默认命名空间中创建）答案

【问题标题】：How to specify serviceAccount (created in default namespace) in the deployment yaml belonging to another namespace如何在属于另一个命名空间的部署 yaml 中指定 serviceAccount（在默认命名空间中创建）
【发布时间】：2020-10-01 01:07:21
【问题描述】：

我在默认命名空间中创建了一个 serviceaccount(dm-sa)，并在 clusterRole（绑定到 PodSecurityPolicy）和 clusterRoleBinding 中使用了这个 serviceaccount。接下来，在部署 yaml（将在命名空间“dm”中运行）中，我在 template:spec 下指定了 serviceAccount: dm 和 serviceAccountName: default。有了这个，kubernetes 在命名空间 dm 下搜索 dm-sa，而不是 在 default 下查找命名空间。如何解决这个问题。请帮忙。

模板：规格： automountServiceAccountToken: 真服务帐户：dm-sa serviceAccountName：默认

【问题讨论】：

为什么在部署的命名空间中没有服务帐户

标签： kubernetes

【解决方案1】：

一般来说，当 Kubernetes 对象相互引用时，它们需要在同一个命名空间中。如果一个 Deployment 管理一个 Pod，并且它引用了一个 ConfigMap、一个 Secret、一个 ServiceAccount 和一个 PersistentVolumeClaim，那么所有这些东西都需要在同一个命名空间中。

我将在目标 (dm) 命名空间中重新部署服务帐户。如果您不使用，可以删除default 命名空间中的服务帐户。

【讨论】：

我在默认命名空间中使用了 serviceAccount，因为它允许我执行一些 API，例如 /api/v1/namespaces、/apis/apps/v1/deployments。否则，它会报错说 serviceAccount 没有管理员权限
我解决了这个问题。我按照以下步骤操作： 1. 在 dm 命名空间中创建服务帐户 dm-sa。 2. 授予使用ClusterRole 文件中api 的权限。 3. ClusterRoleBinding文件中的ClusterRole和Service账号绑定。关于对 api 的访问，需要在 ClusterRole 文件中定义要使用的 api 列表。有了这个，我能够消除对在默认命名空间内创建的服务帐户的依赖。