[continued] when the need comes for restoring data to a new PersistentVolume, my general idea is the following :
I'm not entirely sure 1 can be done, and really not sure 2 can be done now that I'm writing it down... your inputs @jlecorre_gitlab ?
could someone look into my RBAC query from earlier? just trying to understand how kubernetes works in a few specific scenarios (ill copy paste it again here for ease of reading);
I am currently setting up RBAC permissions for all of my services, and I've just restarted my influxdb service without giving it permission to anything (see below)
--- kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: influxdb rules:  --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: influxdb roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: influxdb subjects: - kind: ServiceAccount name: influxdb namespace: my-namespace --- apiVersion: v1 kind: ServiceAccount metadata: name: influxdb namespace: my-namespace
however, whenever I deploy this influxdb instance, it can still read the secrets that are used in the deployment. Is this because kubernetes automatically gives access to the secret that is referenced in the deployment/statefulset, or did I do something wrong?
ReadWriteMany : le volume peut être installé en lecture/écriture par plusieurs nœuds. Ce mode d'accès n'est pas disponible pour les ressources PersistentVolume reposant sur des disques persistants Compute Engine.
@samuel-girard ... so once you have manually created a PersistentVolume that points on the Cinder volume of your choice, you can get a PersistentVolumeClaim to bind to this manually-created PersistentVolume through its
spec.volumeName attribute (tried to do it more elegantly with label matching using
spec.selectors.matchLabels but selectors are appanrently not supported on the k8s<->cinder config OVH uses)
@jlecorre_gitlab is this whole approach something you'd advise against for some reason I'm missing?