dynamic provisioning of pods in k8s

kubernetes (k8s) Subconscious Networks

To dynamically provision pods, we need to either store the full job spec in the calling code (eew) or have the calling code generate an instance of a Custom Resource Definition. That alone doesn’t do anything, you need to write a Custom Controller.

To have a pod call into k8s directly, we need a service account. There’s a default one, but it doesn’t have permissions for listing CRDs.

We can validate that the underlying resource is accessible via:

curl https://${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT}/apis/subconscious.cloud/v1/namespaces/default/gateways/abrahms \
     --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
     --header "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"

Those environment variables and files are present by default in all pods.

You can create the resource like this:

curl https://${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT}/apis/subconscious.cloud/v1/namespaces/default/gateways/test \
     --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
     --header "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
     -X POST \
     -H 'content-type: application/yaml' \
     -d '---
apiVersion: subconscious.cloud/v1
kind: NoosphereGateway
metadata:
  name: test
spec:
  sphereDid: did:key:z6MkpNG41cX5cYXtRXrGSzG6dt6c4SXAHQsK17DSUxo68x3G'