我发现Google Cloud Kubernetes对这个主题来说相当新。我创造了几个集群，后来删除了它们（这就是我所想的）。当我转到控制台时，我看到一个新的集群：
但当我运行命令时：
kubectl config view我看到其他集群定义
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://34.68.77.89
name: gke_question-tracker_us-central1-c_hello-java-cluster
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://34.135.56.138
name: gke_quizdev_us-central1_autopilot-cluster-1
contexts:
- context:
cluster: gke_question-tracker_us-central1-c_hello-java-cluster
user: gke_question-tracker_us-central1-c_hello-java-cluster
name: gke_question-tracker_us-central1-c_hello-java-cluster
- context:
cluster: gke_quizdev_us-central1_autopilot-cluster-1
user: gke_quizdev_us-central1_autopilot-cluster-1
name: gke_quizdev_us-central1_autopilot-cluster-1
current-context: gke_quizdev_us-central1_autopilot-cluster-1
kind: Config
preferences: {}
users:
- name: gke_question-tracker_us-central1-c_hello-java-cluster
user:
exec:
apiVersion: client.authentication.k8s.io/v1beta1
args: null
command: gke-gcloud-auth-plugin
env: null
installHint: Install gke-gcloud-auth-plugin for use with kubectl by following
https://cloud.google.com/blog/products/containers-kubernetes/kubectl-auth-changes-in-gke
interactiveMode: IfAvailable
provideClusterInfo: true
- name: gke_quizdev_us-central1_autopilot-cluster-1
user:
exec:
apiVersion: client.authentication.k8s.io/v1beta1
args: null
command: gke-gcloud-auth-plugin
env: null
installHint: Install gke-gcloud-auth-plugin for use with kubectl by following
https://cloud.google.com/blog/products/containers-kubernetes/kubectl-auth-changes-in-gke
interactiveMode: IfAvailable
provideClusterInfo: true1.在Google Cloud Dashboard中的哪里可以看到配置文件（gke_question-tracker_us-central 1-c_hello-java-cluster，gke_quizdev_us-central 1_autopilot-cluster-1）中提到的集群？
1.在Google Cloud Dashboard中的何处可以看到配置文件中提到的用户？
1.为什么运行kubectl config view命令后看不到questy-java-cluster？
3条答案
按热度按时间g6ll5ycj1#
这有点让人困惑。
集群有2个相关但断开的“视图”。
第一个视图是Google Cloud的“视图”。这就是您在Cloud Console中看到的内容。你会看到同样的（！）详细信息，例如
gcloud container clusters list --project=quizdev（参见docs）。这是当前的Kubernetes集群资源集（当前项目中有一个集群questy-java-cluster（quizdev））。kubectl通常（尽管您也可以在命令行上指定项目）使用所谓的kubeconfig文件（默认Linux位置：~/.kube/config）来保存集群的配置信息，上下文（将集群与用户和可能更多的用户组合在一起）。参见Organizing Cluster Access using kubeconfig files。现在，主要由您（开发人员）来保持Google Cloud视图和
kubectl视图的同步。当您使用
gcloud container clusters create（或使用Cloud Console）时，gcloud会创建集群（IIRC）为您配置默认的kubeconfig文件。这是为了在创建集群后更容易立即使用kubectl。您也可以始终使用gcloud container clusters get-credentials来重复凭据步骤（配置kubeconfig）。如果您使用云控制台创建集群，则需要手动
gcloud container clusters get-credentials，才能使用集群凭证更新本地kubeconfig文件。我不记得
gcloud container clusters delete是否删除了默认kubeconfig文件中的相应凭证;我觉得这不像。结果是kubeconfig文件包含的内容和现有的集群之间通常存在“漂移”;我创造|每天删除集群并定期整理我的kubeconfig文件。
一个额外的复杂性是（通常）有一个kubeconfig文件（
~/.kube/config），但您也可能有多个Google Cloud项目。您的get-credentials集群（手动或自动）跨越多个（！）Google Cloud项目将全部出现在一个本地kubeconfig中。Google Cloud Projects、Locations和Cluster Names与kubeconfig
cluster之间存在一对一的Map：最后，如果一个（或多个开发人员）使用多个主机访问Kubernetes集群，则每个主机都需要反映其需要访问的每个集群的kubeconfig配置（
server，user，context）。GKE在帮助您管理kubeconfig配置方面做得很好。复杂性|混淆的出现是因为它隐式地进行了一些配置（
gcloud container clusters create），最好使其更加透明。如果您使用任何托管Kubernetes产品（AWS，Azure，Linode，Vultr等）等等），这些都提供了这个过程的一些模拟，无论是手动的还是自动的，以帮助管理kubeconfig中的条目。col17t5w2#
另一个让kube配置与谷歌云控制台同步的解决方案是用途：
它将同时删除：
tp5buhyn3#
广告1）显然，我有一些集群手动删除使用谷歌云控制台，但他们留在我的kube配置文件。我听从了@DazWilkin的建议，整理了我的kube配置，删除了所有断开连接的条目：
广告2）为了看到我在这里https://console.cloud.google.com/iam-admin/serviceaccounts?project=quizdev去的用户：
或者调用命令：
Ad 3），为了将questy-java-cluster添加到我运行的kube配置文件中：
它将群集添加到配置文件中。现在一切都同步了。