Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

This page has notes, recipes, and tips for Qserv developers concerning monitoring and maintenance of the Qserv instances at the Rubin Interim Data Facility (IDF) on the Google cloud.

...

Use the copy-to-clipboard button, then paste and execute at your local command-line where you have installed the Google Cloud SDK.  You should see some mumbles about how appropriate credentials have been locally installed, and your local kubectl should now be configured to point to the appropriate cluster.  Try "kubectl get nodes" and "kubectl get pods", perhaps, to test.

Info

...

If you don't want to work from or install software on the local machine, you can use the "Run in Cloud Shell" button to spin up a temporary shell in the IDF that has tools like gcloud, watch, and git pre-installed.  Since this is always for a specific project, you don't need the --context arguments below.

...

Credentials obtained this way are locally additive – if you do this once for each of qserv-dev, qserv-int, and qserv-prod, you will have access credentials for all three cached locally in your .kube/config file (and your kubectl default will be left pointing at the last one executed). You can then further edit .kube/config to give each of these cached of credentials a convenient "nickname", so any given invocation of kubectl can be directed explicitly to any of the clusters, without having to further return to or interact with the web-based cloud console.  This is highly recommended, and further examples below will assume you have taken this step.

...

Code Block
contexts:
- context:
    cluster: gke_qserv-dev-3d7e_us-central1_qserv-dev
    user: gke_qserv-dev-3d7e_us-central1_qserv-dev
  name: qserv-dev
- context:
    cluster: gke_qserv-int-8069_us-central1_qserv-int
    user: gke_qserv-int-8069_us-central1_qserv-int
  name: qserv-int
- context:
    cluster: gke_qserv-prod-4d7d_us-central1_qserv-prod
    user: gke_qserv-prod-4d7d_us-central1_qserv-prod
  name: qserv-prod

After this has been done, you can supply an argument such as "--context=qserv-prod" to any kubectl command invocation to redirect just that invocation to a particular cluster.  Try for example "kubectl --context=qserv-prod get nodes" and "kubectl --context=qserv-int get nodes", perhaps, to see how this works.  If you want to redirect the default, do e.g. "kubectl config use-context qserv-int".  But always supplying a "--context=" argument explicitly when invoking kubectl seems a good habit to get into to avoid the otherwise more-or-less inevitable tragedy of issuing some destructive kubectl  incantation against qserv-prod when you thought you had left it pointing at qserv-int ...

...