allow scaling based on gcs resources

[sirdarckcat]

https://github.com/google/kctf/blob/v1/kctf-operator/pkg/controller/challenge/volumes/persistentvolumeclaim.go#L14
https://github.com/google/kctf/blob/v1/kctf-operator/pkg/controller/challenge/volumes/persistentvolume.go#L25

I think we just need to define the capacity of the persistent volume accordingly to what we have in the node.

we would need to find a way to throttle access to the fuse fs somehow.

without it, it's possible for someone to spam the FS and make things slow for other tasks.

[sirdarckcat]

https://www.kernel.org/doc/html/v5.5/admin-guide/cgroup-v1/blkio-controller.html seems like cgroups supports this

this could also be implemented by having multiple gcsfuse daemons per node (eg, /mnt/disks/gcs{1..10}) and only allow up to 10 persistenvolumeclaims/node. the capacity would just need to be making sure the node still has slots left.

still sounds hard, though, but less than before maybe

[sirdarckcat]

generally, though, having a gcsfuse per pod doesnt sound terrible..

[sirdarckcat]

as a one-off, if people have service accounts they can mount it directly =/

      containers:
        - name: challenge
          volumeMounts:
            - name: admin-gcs
              mountPath: /mnt/disks/admin-gcs
      initContainers:
        - name: admin-gcsfuse
          image: gcr.io/kctf-docker/gcsfuse@sha256:#######################
          securityContext:
            privileged: true
          volumeMounts:
            - name: admin-gcs
              mountPath: /mnt/disks/admin-gcs
            - name: admin-gcs-config
              mountPath: /config
      volumes:
        - name: admin-gcs
          hostPath:
            path: /mnt/disks/admin-gcs
        - name: admin-gcs-config
          configMap:
            name: gcs-config
            items:
              - key: gcs_bucket
                value: ################