1 manager.go:111] unable to fully collect metrics: unable to fully scrape metrics from source kubelet_summary:serco-node1: unable to get CPU for container "hpautoscale" in pod hpautoscale/hpautoscale-647478dcc-kmnzg on node "184.108.40.206", discarding data: missing cpu usage metric
[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.