CLI 命令排序，用于在两个带有两封电子邮件的 GKE/kubectl 帐户之间切换

Question

几周前我问了这个问题，并得到了一个非常有用的答案。这个问题的要点是：">如何在同一台机器上的两个不同的 K8s/GCP 帐户之间来回切换？" 我有 2 个不同的 K8s 项目，其中包含 2 个不同的电子邮件 (gmail)，它们存在于 2 个不同 GCP 帐户的 2 个不同 GKE 集群上。我想知道如何在它们之间来回切换，以便在我运行kubectl和gcloud命令时，我不会无意中将它们应用于错误的项目/帐户。

答案基本上是利用kubectl config set-context和脚本。

这个问题(今天)是这个问题的情有可原，可以说是"第二部分"。

---

我对以下顺序感到困惑：

• 设置 K8s 上下文(再次通过kubectl config set-context ...);
和
• 运行gcloud init; 和
• 运行gcloud auth; 和
• 可以安全地运行kubectl和gcloud命令，并确保我正在点击正确的 GKE 集群

我的理解是，gcloud init只需运行一次即可初始化系统上的gcloud控制台。我已经做到了。

所以我的想法是，我可以做到以下几点：

# 1. switch K8s context to Project 1
kubectl config set-context <context for GKE project 1>
# 2. authenticate w/ GCP so that now gcloud commands will only hit the GCP
# resources associated with Project 1 (and GCP Account 1)
gcloud auth
# 3. run a bunch of kubectl and gcloud commands for Project/GCP Account 1
# 4. switch K8s context to Project 2
kubectl config set-context <context for GKE project 2>
# 5. authenticate w/ GCP so that now gcloud commands will only hit the GCP
# resources associated with Project 2 (and GCP Account 2)
gcloud auth
# 6. run a bunch of kubectl and gcloud commands for Project/GCP Account 2

我在这里的理解是否正确，还是比这更复杂/更复杂(如果是这样，为什么)？

Answer 1

我会假设熟悉前面的答案

gcloud

gcloud init每台机器只需要运行一次，并且只有在您真的想重新init'亚化 CLI (gcloud) 时才需要再次运行。

gcloud auth login ${ACCOUNT}对(谷歌)(用户或服务)帐户进行身份验证并保留(在 Linux 上默认为${HOME}/.config/gcloud)并续订凭据。

gcloud auth list列出了已gcloud auth login的帐户。结果显示默认正在使用哪个帐户(ACTIVE*)。

有点不方便的是，在当前ACTIVE帐户之间切换的一种方法是使用gcloud config set account ${ACCOUNT}更改gcloud全局(计算机上的每个实例)配置。

kubectl

为了便于使用先前经过身份验证的(即gcloud auth login ${ACCOUNT})凭据与Kubernetes Engine，Google提供了命令gcloud container clusters get-credentials。这使用当前ACTIVEgcloud帐户创建一个kubectl上下文，该上下文将 Kubernetes 集群与用户以及可能也加入 Kubernetes 命名空间。gcloud container clusters get-credentials对kubectl配置进行更改(默认情况下在 Linux 上为${HOME}/.kube/config)。

什么是用户？请参阅 Kubernetes 中的用户。Kubernetes Engine(通过kubectl)想要(OpenID Connect)代币。而且，方便的是，gcloud可以为我们提供这些代币。

如何？根据之前的答案

user:
auth-provider:
config:
access-token: [[redacted]]
cmd-args: config config-helper --format=json
cmd-path: path/to/google-cloud-sdk/bin/gcloud
expiry: "2022-02-22T22:22:22Z"
expiry-key: '{.credential.token_expiry}'
token-key: '{.credential.access_token}'
name: gcp

kubectl使用配置文件调用gcloud config config-helper --format=json并从结果中提取access_token和token_expiry。然后，GKE 可以使用access_token对用户进行身份验证。并且，如有必要，可以在到期后使用 Google 的令牌端点续订令牌 (token_expiry)。

场景

那么，您如何结合上述所有内容。

1. 使用您的所有 Google 帐户验证gcloud

ACCOUNT="[e-mail]"
gcloud auth login ${ACCOUNT}
ACCOUNT="[e-mail]"
gcloud auth login ${ACCOUNT} # Last will be the `ACTIVE` account

2. 枚举这些

gcloud auth list

收益 率：

ACTIVE  ACCOUNT
[e-mail]
*       [e-mail] # This is ACTIVE
To set the active account, run:
$ gcloud config set account `ACCOUNT`

3. 在用户之间切换以gcloud命令

注意：这不会影响kubectl

也

gcloud config set account [e-mail]
gcloud auth list

收益 率：

ACTIVE  ACCOUNT
*       [e-mail] # This is ACTIVE
[e-mail]

或者，您可以将--account=${ACCOUNT}显式添加到任何gcloud命令中，例如：

# Explicitly unset your account
gcloud config unset account
# This will work and show projects accessible to client1
gcloud projects list --account=[e-mail]
# This will work and show projects accessible to client2
gcloud projects list --account=[e-mail]

2. 为您的任何|所有Google帐户创建kubectl上下文(通过gcloud)

也

ACCOUNT="[e-mail]"
PROJECT="..." # Project accessible to ${ACCOUNT}
gcloud container clusters get-credentials ${CLUSTER} 
--ACCOUNT=${ACCOUNT} 
--PROJECT=${PROJECT} 
...

或者等效地直接使用kubectl config set-context：

kubectl config set-context ${CONTEXT} 
--cluster=${CLUSTER} 
--user=${USER} 

但它避免了必须gcloud config get-clusters、gcloud config get-users等。

注意gcloud containers clusters get-credentials对上下文使用派生名称，GKE 对集群使用派生名称。如果您有信心，可以直接编辑kubectl配置(或使用kubectl config命令)来重命名这些集群、上下文和用户引用以满足您的需求。

3. 列出kubectl上下文

kubectl config get-context

收益 率：

CURRENT   NAME       CLUSTER    AUTHINFO   NAMESPACE
*         client1    a-cluster  client1
client2    b-cluster  client2

4. 在kubectl上下文(群集*用户)之间切换

注意：这不会影响gcloud

也

kubectl config use-context ${CONTEXT}

或者*您可以将--context标志显式添加到任何kubectl命令

# Explicitly unset default|current context
kubectl config unset current-context
# This will work and list deployments accessible to ${CONTEXT}
kubectl get deployments --context=${CONTEXT}