- staging and prod clusters that are exactly the same,
  with just domain differences
- Uses traditional autohttps + LoadBalancer to get traffic
  into the cluster. Could be nginx-ingress later on if necessary.
- Manual DNS entries for staging.carbonplan.2i2c.cloud and
  carbonplan.2i2c.cloud. Initial manual deploy with
  `proxy.https.enabled` set to false to complete deployment,
  fetch externalIP of `proxy-public` service, setup DNS,
  then re-deploy with `proxy.https.enabled` set to true.

Ref 2i2c-org#291

We have three sets of labels:

1. What components of a JupyterHub can run here? core / user
2. What components of a dask gateway can run here? core / scheduler /
   worker
3. What are the features of the node pool we care about? For example,
   if we want to be on an r5.xlarge node, we should target the
   existing node.kubernetes.io/instance-type label

This gives us flexibility without adding too much overhead.

dask-gateway requires that the image used for it
contains the `dask-gateway` package. The scheduler image is
the same image as the user notebook image, to make sure that
versions match. The previously used image did not have
dask-gateway installed

Otherwise it doesn't know which instance group to scale up
when a pod wants a node with that label