【问题标题】:Connect local instance of kubectl to GKE cluster without using gcloud tool?不使用 gcloud 工具将 kubectl 的本地实例连接到 GKE 集群?
【发布时间】:2018-07-01 20:28:39
【问题描述】:

有谁知道如何在不使用本地 gcloud 工具的情况下将 kubectl 的本地实例连接到 Google Kubernetes Engine (GKE) 集群?

例如:

如果您将gcloud 工具与此命令一起使用:

gcloud container clusters get-credentials NAME [--zone=ZONE, -z ZONE] [GCLOUD_WIDE_FLAG …]

你会在~/.kube/config找到这样的用户:

- name: gke_myproj_myzone
  user:
    auth-provider:
      config:
        access-token: TOKENSTRING
        cmd-args: config config-helper --format=json
        cmd-path: /google/google-cloud-sdk/bin/gcloud
        expiry: 2018-01-22 18:05:46
        expiry-key: '{.credential.token_expiry}'
        token-key: '{.credential.access_token}'
      name: gcp

如您所见,gcloud 工具提供的默认值需要 glcoud 工具作为 auth-provider 才能登录到您的集群。

现在,我正在寻找一种将kubectl 连接到未安装gcloud 的机器上的集群的方法。

【问题讨论】:

  • 看来你的问题和这个one很相似。如果不同,请提供有关您的用例的信息。
  • google cloud shell 呢?
  • @Fady,在那里找不到解决方案。
  • @AmiHollander 我应该如何使用 GCS 将我的笔记本电脑连接到远程集群?
  • @Rotareti 上面的 gcloud 命令会将所有必要的身份验证信息传递到 ~/.kube/config,如果您将该文件复制到您的笔记本电脑 ($HOME/.kube),您应该可以使用 kubectl命令就像经过身份验证一样。检查这个类似的answer

标签: kubernetes kubectl google-kubernetes-engine


【解决方案1】:

实现此目的的最简单方法是将~/.kube/config 文件(从经过 gcloud 身份验证的实例)复制到本地实例(笔记本电脑)中的此目录$HOME/.kube

但首先,使用经过身份验证的实例,您必须通过运行以下命令启用每个 document 的旧集群:

gcloud config set container/use_client_certificate True
export CLOUDSDK_CONTAINER_USE_CLIENT_CERTIFICATE=True

然后执行get-credentials命令,复制文件。

gcloud container clusters get-credentials NAME [--zone=ZONE, -z ZONE] [GCLOUD_WIDE_FLAG …]

请注意,您可能必须运行get-credentials 命令,并在每次身份验证令牌(保存在配置文件中)到期时复制配置文件。

【讨论】:

  • 没有别的办法了吗?我不想一次又一次地复制身份验证令牌。
  • 不确定是否可行。我知道的唯一选择是在您的机器上本地使用 gcloud,它应该会自动生成令牌。但是您需要安装并启动Cloud SDK
【解决方案2】:

您可以将kubectl 与用户帐户或服务帐户一起使用。

用户帐户是为人类使用而设计的,因此这些工具有明显的“限制”:如果您使用 GKE 集群,则假定用户已安装 gcloud 并使用它登录。

您可以改用专为软件使用而设计的服务帐户。 Kubernetes 有一个专用的资源类型ServiceAccount(不要将它与 GCP 服务帐户混淆!)。额外的好处 - 它是一个 k8s 功能,因此它不依赖于您使用的服务实现(GKE、AKS 等)。

方法:

第一次连接集群只需要gcloud工具。一旦您可以访问集群,您就可以创建一个新的 k8s ServiceAccount 并在 kubectl 配置文件中使用它的令牌。

但是,服务帐户需要以细粒度方式为 assigned necessary roles(k8s RoleRoleBinding 资源)。

您的集群需要启用 RBAC 身份验证才能正常工作。

注意事项:

服务帐户令牌不会过期,因此应特别注意不要暴露/损害它们。旋转它们可能是个好主意。

简单(主义)示例:

这是如何完成上述操作的简化示例。它相当简单,因为它使用默认命名空间,只添加了几个角色,并且需要大量手动操作,但它可以帮助您开始自己的实现。

创建文件my-service-account.yaml:

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-user
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: my-user-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: my-user-role-binding
subjects:
  - kind: ServiceAccount
    name: my-user
roleRef:
  kind: Role
  name: my-user-role
  apiGroup: rbac.authorization.k8s.io

然后运行kubectl apply -f my-service-account.yaml 来创建资源。

创建服务帐户后,您可以运行kubectl get secrets 来查找保存用户令牌的秘密(它的名称源自服务帐户名称),然后运行kubectl get secret <secret-name-here> -o yaml 来获取秘密数据,并找到输出中data.token 字段中的标记。令牌是 base64 编码的,因此在使用 kubectl 配置文件之前需要先对其进行解码(您可以在 Linux 中为此使用 base64 -d)。最后,kubectl 配置文件的相关部分可能如下所示:

apiVersion: v1
clusters:
  ...
contexts:
  ...
users:
- name: my-user
  user:
    token: <token-value-here>

现在您可以将kubectl 上下文切换到您为该用户创建的上下文,然后运行:

kubectl get pods

新创建的用户只能执行上述操作,几乎不能做其他任何事情,因为这是在关联角色中配置的。您可以在 Kubernetes 文档中找到有关 RBAC 和角色配置的更多信息:Using RBAC Authorization

【讨论】:

【解决方案3】:

所以我创建了这个名为gke-kubeconfig 的工具来执行此操作。我基本上对 gcloud 进行了逆向工程并做了同样的事情。它首先请求一个短期令牌,然后使用它来获取集群数据并创建 kube 配置。

您需要确保令牌在使用配置文件时不会过期,目前它会在 1 小时后过期,因此通常不会有问题。

我还创建了mie00/gke-kubeconfig 以在我的 CI 管道中使用。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2020-04-03
    • 2021-03-10
    • 2021-10-27
    • 2018-09-14
    • 1970-01-01
    • 2019-07-27
    • 2016-04-06
    相关资源
    最近更新 更多