不使用 gcloud sdk 连接到 Kubernetes 集群

Question

我是 kubernetes 的新手，在谷歌云平台上创建了一个集群。 现在我正在尝试从 vsts 设置自动部署，需要为此创建一个 kubernetes 用户以获取 kubeconfig 文件进行身份验证。

现在我的问题是我该怎么做？ 我需要用 kubectl 创建这个用户吗（如果是的话怎么做？）？ 或者有没有办法通过 gcp 控制台创建用户？

我搜索了网络，但没有发现任何有用的东西。感谢您的任何建议！

编辑： 我现在如何使用这个 gcloud 命令连接到我的集群：gcloud container clusters get-credentials。这在我的本地开发机器上工作得很好。 但是在我的 vsts 构建代理上，我没有安装 gcloud（也不想安装它），并且只需要使用 kubectl 连接到我的集群，而无需使用 gcloud 命令。

我已经发现 gcloud 命令创建了一个 kubeconfig 文件，其中 gcloud 命令作为身份验证提供程序（所以我不能只复制创建的 kubeconifg 文件，因为它取决于安装的 gcloud）。然后当我运行 kubectl 时，它会在 kubeconfig 中创建一个临时访问令牌。但是这个令牌的有效期只有 30 分钟左右。 我需要一个无限有效的令牌，所以我可以在我的构建服务器上使用它。

Answer 1

要在 GCP 中连接到 Kubernetes 集群，您可以使用用户帐户或服务帐户。

如果您选择用户帐户，请运行以下命令：

gcloud init 

或

gcloud init --console-only

这将打开 GCP 身份验证对话框。当您通过身份验证后，您将能够在经过身份验证的用户的权限下进行操作。

如果您选择服务帐户，您需要创建它并为其生成一个新密钥。

您可以使用 GPC 控制台 -> IAM 和管理员 -> IAM -> 服务帐户 来完成此操作.
单击Create service account，选择帐户名称，选择适当的角色，然后单击Create。
您可以通过在帐户创建对话框中选择Furnish a new private key 来生成密钥，或者通过单击现有服务帐户行右侧的三个点并选择Create key 来生成新密钥。选择 JSON 格式并将文件保存在磁盘上。

然后运行命令：

gcloud auth activate-service-account <service@account.name>  --key-file=<previously_saved_file.json>

在此阶段，您已通过 CGP 进行身份验证并准备好连接到您的 Kubernetes 集群：

下一个命令将更新您的 kubectl 配置以与您的集群一起使用。

gcloud container clusters get-credentials <cluster_name> --zone <gcp_availability_zone> --project <gcp_project_name>

您可以通过在 GCP IAM 管理界面中为其选择另一个角色来扩展或减少帐户的权限。

官方文档：
gcloud auth activate-service-account
gcloud init
gcloud container clusters get-credentials

Answer 2

简答：

创建 RoleBinding 或 ClusterRoleBinding（取决于您的需要），其中 subjects: 包含 kind: User 和 name: username 的对象：

---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cluster-admin-users
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: starseed

说明：

此解释假设您谈论的是启用了 RBAC 的集群，如果您使用的是最新版本，则几乎总是会出现这种情况。

这个话题很容易混淆。用户和组仅在 RoleBindings 和 ClusterRoleBindings 的上下文中作为“主题”存在，如上所示。

以上代码是一个 YAML 对象，您可以在其上执行kubectl apply -f thisfile.yml。它将创建一个 CluserRoleBinding，它将“用户”（实际上只是一个字符串）starseed 绑定到名为“cluster-admin”的 ClusterRole。 “cluster-admin”是默认的 ClusterRoles 之一。 ClusterRoles（和角色）是 API 权限的集合，如下所述：https://kubernetes.io/docs/admin/authorization/rbac/#default-roles-and-role-bindings

没有用户或组的创建或删除 - 没有用户或组的 API 对象，也无法列出所有用户或所有组。

要理解为什么会这样，您必须了解一个基本概念 - 身份验证和授权在 kubernetes 中是完全独立的关注点。身份验证处理验证“这个用户就是他们所说的那个人”。如此处所述：https://kubernetes.io/docs/admin/authentication/ - 有许多有效的身份验证方法。常见的包括令牌、用户名/密码、x509 客户端证书，但还有更多。如果用户提供 kube-apiserver 的 --basic-auth=somefile.csv 标志中存在的用户名和密码，则 kube-apiserver 知道您就是该用户。如果您使用 CommonName=starseed 的 x509 客户端证书，并且该证书由 kube-apiserver 信任的 CA 签名，则它知道您就是该用户。

此时，当您尝试进行像 kubectl get pods 这样的 API 调用时，kube-apiserver 会检查启用了哪些 授权 方法（Node、RBAC 很常见）。它会发现名为 cluster-admin-users 的 ClusterRoleBinding 的主题是用户“starseed”，因此 starseed 可以执行关联的 ClusterRole 允许的任何事情。