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>
27 lines
565 B
YAML
27 lines
565 B
YAML
apiVersion: networking.k8s.io/v1
|
|
kind: Ingress
|
|
metadata:
|
|
annotations:
|
|
cert-manager.io/cluster-issuer: letsencrypt-prod
|
|
traefik.ingress.kubernetes.io/router.entrypoints: websecure
|
|
name: vaultwarden
|
|
namespace: vaultwarden
|
|
spec:
|
|
ingressClassName: traefik
|
|
rules:
|
|
- host: vaultwarden.chemavx.xyz
|
|
http:
|
|
paths:
|
|
- backend:
|
|
service:
|
|
name: vaultwarden
|
|
port:
|
|
number: 80
|
|
path: /
|
|
pathType: Prefix
|
|
tls:
|
|
- hosts:
|
|
- vaultwarden.chemavx.xyz
|
|
secretName: vaultwarden-tls
|
|
|