chemavxandClaude Opus 5
4adbcbd4af
Los dos estaban en git sin ninguna Application que los gestionara: editar el repo no desplegaba nada. De ahi que un pin de imagen de abril nunca llegara al cluster y gitea se subiera solo de 1.25.5 a 1.27.0, y que vaultwarden se parcheara con kubectl replace. A partir de ahora manda git. Verificado en frio antes de adoptar: los 17 manifiestos coincidian campo a campo con lo vivo, asi que la adopcion no revierte nada. Con ServerSideApply/ServerSideDiff, igual que el kube-prometheus-stack: estos objetos arrastran un last-applied viejo y el merge clasico intentaria borrar lo que ese blob declaraba y git ya no; en un PVC eso es un campo inmutable y el sync falla. Limpieza que iba en el mismo paquete: - Fuera la basura de export de 5 ficheros: last-applied-configuration, la revision del Deployment y las anotaciones que pone el provisionador en los PVC (bind-completed, selected-node...). Es lo que dejaba los recursos OutOfSync para siempre. Verificado que el resto del manifiesto no cambia. - Fuera serviceaccount-default y kube-root-ca.crt de los dos: los crea k8s solo en cada namespace. - RESCATADO configmap-gitea-runner-config: config del act_runner escrita a mano en abril, montada por el runner y que NO estaba en git. Reconstruir gitea desde el repo levantaba el runner sin configuracion. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
16 lines
299 B
YAML
16 lines
299 B
YAML
apiVersion: v1
|
|
kind: PersistentVolumeClaim
|
|
metadata:
|
|
name: vaultwarden-pvc
|
|
namespace: vaultwarden
|
|
spec:
|
|
accessModes:
|
|
- ReadWriteOnce
|
|
resources:
|
|
requests:
|
|
storage: 5Gi
|
|
storageClassName: local-path
|
|
volumeMode: Filesystem
|
|
volumeName: pvc-419712d2-1b7c-4931-8fce-6b762b3b57a0
|
|
|