Kubernetes config file describes 3 objects: clusters, users, and contexts.

cluster - cluster name + details - the host and the certificates.

user - user name and credentials, to authorise you against any cluster host.

the context role is to make the connection between a user and a cluster, so when you use that context,kubectl will authorise you against the cluster specified in the context object, using the credentials of the user specified in the context object. an example context object:

apiVersion: v1
current-context: ""
kind: Config
preferences: {}

clusters:
- cluster:
    certificate-authority: xxxxxxxxx
    server: xxxxxxxxx
  name: gke_dev-yufuyjfvk_us-central1-a_standard-cluster-1

users:
- name: efrat-dev
  user:
    client-certificate: xxxxxxxxx
    client-key: xxxxxxxxx

contexts:
- context:
    cluster: gke_dev-yufuyjfvk_us-central1-a_standard-cluster-1
    user: efrat-dev
  name: gke-dev

the kubectl config subcommand has a set of commands to generate cluster, user & context entries in the config file.

multiple k8s clusters from docker-desktop

under the hood, when you enable k8s, docker desktop downloads kubernetes components as docker images, and the server listens https://localhost:6443. it is all done automatically so unless you have any intention to run the entire structure by yourself i dont suppose you can configure it to run multiple clusters.

about your further questions:

when you set a context, kubectl will set current-context to that one, and every kubectl you run will go to the context's cluster, using the context's user credentials. it doesnt mean the clusters are dead. it wont affect them at all.