<p>I am discovering Google Cloud Kubernetes being fairly new to the topic. I have created couple of clusters and later deleted them (that is what I thought).
When I go to the console I see one new cluster:</p>
<p><a href="https://i.stack.imgur.com/aYgFC.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/aYgFC.png" alt="enter image description here" /></a></p>
<p>But when I run the command:</p>
<pre><code>kubectl config view
</code></pre>
<p>I see other clusters defined</p>
<pre><code>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: true
</code></pre>
<ol>
<li><p>Where in the Google Cloud Dashboard  I can see the clusters mentioned in the config file (gke_question-tracker_us-central1-c_hello-java-cluster, gke_quizdev_us-central1_autopilot-cluster-1)?</p>
</li>
<li><p>Where in the Google Cloud Dashboard  I can see the users mentioned in the config file?</p>
</li>
<li><p>Why I do not see the questy-java-cluster after running the kubectl  config view command?</p>
</li>
</ol>

fascynacja
<p>This <strong>is</strong> a tad confusing.</p>
<p>There are 2 related but <strong>disconnected</strong> &quot;views&quot; of the clusters.</p>
<p>The first view is Google Cloud's &quot;view&quot;. This is what you're seeing in Cloud Console. You would see the same (!) details using e.g. <code>gcloud container clusters list --project=quizdev</code> (see <a href="https://cloud.google.com/sdk/gcloud/reference/container/clusters/list" rel="nofollow noreferrer">docs</a>). This is the current set of Kubernetes clusters resources (there's one cluster <code>questy-java-cluster</code> in the current project (<code>quizdev</code>).</p>
<p><code>kubectl</code> generally (though you can specify the projects on the command line too) uses a so-called kubeconfig file (default Linux location: <code>~/.kube/config</code>) to hold the configuration information for clusters, contexts (combine clusters with user and possible more) with users. See <a href="https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/" rel="nofollow noreferrer">Organizing Cluster Access using kubeconfig files</a>.</p>
<p>Now, it's mostly up to you (the developer) to keep the Google Cloud view and the <code>kubectl</code> view in sync.</p>
<p>When you <code>gcloud container clusters create</code> (or use Cloud Console), <code>gcloud</code> creates the cluster (and IIRC) configures the default kubeconfig file for you. This is to make it easier to immediately use <code>kubectl</code> after creating the cluster. You can also always <a href="https://cloud.google.com/sdk/gcloud/reference/container/clusters/get-credentials" rel="nofollow noreferrer"><code>gcloud container clusters get-credentials</code></a> to repeat the credentials step (configuring kubeconfig).</p>
<p>If you create clusters using Cloud Console, you <strong>must</strong> <code>gcloud container clusters get-credentials</code> manually in order to update your local kubeconfig file(s) with the cluster's credentials.</p>
<p>I don't recall whether <code>gcloud container clusters delete</code> deletes the corresponding credentials in the default kubeconfig file; I think it <strong>doesn't</strong>.</p>
<p>The result is that there's usually 'drift' between what the kubeconfig file contains and the clusters that exist; I create|delete clusters daily and periodically tidy my kubeconfig file for this reason.</p>
<p>One additional complication is that (generally) there's one kubeconfig file (<code>~/.kube/config</code>) but you may also have multiple Google Cloud Projects. The clusters that you've <code>get-credentials</code> (either manually or automatically) that span multiple (!) Google Cloud Projects will all be present in the one local kubeconfig.</p>
<p>There's a one-to-one mapping though between Google Cloud Projects, Locations and Cluster Names and kubeconfig <code>cluster</code>'s:</p>
<pre><code>gke_{PROJECT}_{LOCATION}_{CLUSTER-NAME}
</code></pre>
<p>Lastly, if one (or more developers) use multiple hosts to access Kubernetes clusters, each host will need to reflect the kubeconfig configuration (<code>server</code>, <code>user</code>, <code>context</code>) for each cluster that it needs to access.</p>
<p>GKE does a decent job in helping you manage kubeconfig configurations. The complexity|confusion arises because it does some of this configuration implicitly (<code>gcloud container clusters create</code>) and it would be better to make this more transparent. If you use any managed Kubernetes offering (AWS, Azure, Linode, Vultr etc. etc.), these all provide some analog of this process either manual or automatic for helping manage the entries in kubeconfig.</p>
