我有一个Kubernetes问题。
我们有一个主Pod，可以根据调用的REST端点部署其他Pod。例如，如果有人调用“ / start_work”端点，则它可以部署一个工作容器来完成与此请求相关的工作。
此主Pod已使用默认的ServiceAccount进行部署，并且为了允许其部署其他Pod，我们必须为其授予群集管理员访问权限。我们使用ClusterRoleBinding将默认的ServiceAccount绑定到集群管理员角色。
但是，现在我们遇到了一个更具挑战性的问题，即主集群在一个集群中运行，而工作集群需要在另一个集群中进行部署。这听起来可以实现吗？如果我们正在谈论另一个群集，授予默认的ServiceAccount群集管理员权限对我们没有帮助，对吧？
有人做过吗？您是如何实现的？
一吨。
答案 0 :(得分：1)
但是，现在我们遇到了一个更具挑战性的问题，即主集群在一个集群中运行，而工作集群需要在另一个集群中进行部署。这听起来可以实现吗？
当然，是的；您可以通过多种受支持的机制自由提供凭据，这些机制将使Pod格式正确的KUBECONFIG可以在您感到舒适的任何访问级别下与远程集群通信。默认情况下，注入的ServiceAccount仅受其自己的集群信任，但是似乎有无限的方法可以将组件或完全形成的KUBECONFIG提供到Pod的文件系统中，然后参加比赛
如果我们正在谈论另一个群集，授予默认的ServiceAccount群集管理员权限对我们没有帮助，对吧？
这取决于（始终是答案！）取决于两个群集是否共享相同的CA根目录；如果答案为是，则是，一个上的cluster-admin将同时成为两个上的cluster-admin。 Subject由出示的x509证书的CN=（有时是OU= / O=）确定，其有效性由证书之间的信任链确定。出示证书和群集的api服务器