theus-cli-linux-x64 1.2.2 → 1.4.0

package/vendor/theus-arsenal/skills/patrones-kubernetes/SKILL.md

@@ -1,754 +0,0 @@
----
-name: patrones-kubernetes
-description: Patrones de cargas de trabajo en Kubernetes, gestión de recursos, RBAC, probes, autoescalado, manejo de ConfigMap/Secret y depuración con kubectl para despliegues de grado producción.
----
-
-# Patrones de Kubernetes
-
-Patrones de Kubernetes de grado producción para desplegar, gestionar y depurar cargas de trabajo de forma confiable.
-
-## Cuándo activarla
-
-- Al escribir manifiestos de Kubernetes (Deployments, Services, Ingress, Jobs)
-- Al configurar requests/limits de recursos, probes de liveness/readiness
-- Al configurar RBAC, namespaces o ServiceAccounts
-- Al gestionar configuración y secretos en K8s
-- Al depurar CrashLoopBackOff, OOMKilled, pods pendientes o errores de pull de imagen
-- Al configurar HPA (Horizontal Pod Autoscaler) o PodDisruptionBudgets
-- Al revisar YAML de K8s por seguridad o corrección
-
-## Cuándo usarla
-
-> Igual que **Cuándo activarla** arriba. Este alias satisface las convenciones de formato de skills del repositorio. Usa esta skill siempre que estés escribiendo, revisando o depurando YAML y cargas de trabajo de Kubernetes.
-
-## Cómo funciona
-
-Esta skill proporciona **patrones YAML de grado producción listos para copiar y pegar** y **comandos de depuración con kubectl** organizados por tarea:
-
-1. **Plantilla de Deployment** — Un `Deployment` de producción totalmente configurado con contexto de seguridad, estrategia de rolling update, los tres tipos de probes, límites de recursos e inyección de entorno desde ConfigMap/Secret.
-2. **Probes** — Tabla de decisión de startup vs liveness vs readiness, con la aritmética correcta de `failureThreshold × periodSeconds`.
-3. **Services e Ingress** — Patrones de ClusterIP, LoadBalancer e Ingress con TLS con anotaciones de cert-manager.
-4. **ConfigMaps y Secrets** — `envFrom`, montaje como archivo y guía de secretos externos.
-5. **Gestión de recursos** — Reglas prácticas de requests vs limits por tipo de carga de trabajo (API web, JVM, worker, sidecar).
-6. **RBAC** — Cadena ServiceAccount → Role → RoleBinding de mínimo privilegio.
-7. **HPA y PDB** — Configuraciones de autoescalado y de seguridad ante drenado de nodos.
-8. **Jobs y CronJobs** — Patrones de cargas puntuales y programadas con el `restartPolicy` correcto.
-9. **Chuleta de kubectl** — Logs, exec, rollback, port-forward, dry-run y comandos de diagnóstico de errores comunes.
-10. **Antipatrones y lista de verificación** — Qué NO hacer, y una lista de verificación de seguridad/confiabilidad/observabilidad.
-
-## Ejemplos
-
-Consulta las secciones siguientes para ejemplos completos y ejecutables. Referencias rápidas:
-
-| Tarea | Ir a |
-|------|---------|
-| YAML completo de Deployment de producción | [Patrones de cargas de trabajo principales](#patrones-de-cargas-de-trabajo-principales) |
-| Configuración de probes | [Probes](#probes--liveness-readiness-startup) |
-| Configuración RBAC de mínimo privilegio | [RBAC](#rbac--roles-y-serviceaccounts) |
-| Depurar un CrashLoopBackOff | [Chuleta de depuración con kubectl](#chuleta-de-depuración-con-kubectl) |
-| Autoescalado | [HPA](#horizontal-pod-autoscaler-hpa) |
-
----
-
-## Patrones de cargas de trabajo principales
-
-### Deployment — Plantilla de producción
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: my-app
-  namespace: my-namespace
-  labels:
-    app: my-app
-    version: "1.0.0"
-spec:
-  replicas: 3
-  selector:
-    matchLabels:
-      app: my-app
-  strategy:
-    type: RollingUpdate
-    rollingUpdate:
-      maxSurge: 1          # Permite 1 pod extra durante la actualización
-      maxUnavailable: 0    # Nunca reducir por debajo del conteo deseado
-  template:
-    metadata:
-      labels:
-        app: my-app
-        version: "1.0.0"
-    spec:
-      # Contexto de seguridad a nivel de pod
-      securityContext:
-        runAsNonRoot: true
-        runAsUser: 1001
-        fsGroup: 1001
-
-      # Apagado ordenado (graceful shutdown)
-      terminationGracePeriodSeconds: 30
-
-      containers:
-        - name: my-app
-          image: ghcr.io/org/my-app:1.0.0   # Nunca usar :latest
-          imagePullPolicy: IfNotPresent
-
-          ports:
-            - containerPort: 8080
-              protocol: TCP
-
-          # Los requests Y los limits de recursos son ambos obligatorios
-          resources:
-            requests:
-              cpu: "100m"
-              memory: "128Mi"
-            limits:
-              cpu: "500m"
-              memory: "256Mi"
-
-          # Contexto de seguridad del contenedor
-          securityContext:
-            allowPrivilegeEscalation: false
-            readOnlyRootFilesystem: true
-            capabilities:
-              drop:
-                - ALL
-
-          # Probes (ver la sección Probes más abajo)
-          startupProbe:
-            httpGet:
-              path: /health
-              port: 8080
-            failureThreshold: 30
-            periodSeconds: 5
-          livenessProbe:
-            httpGet:
-              path: /health
-              port: 8080
-            initialDelaySeconds: 0
-            periodSeconds: 30
-            failureThreshold: 3
-          readinessProbe:
-            httpGet:
-              path: /ready
-              port: 8080
-            initialDelaySeconds: 5
-            periodSeconds: 10
-            failureThreshold: 2
-
-          # Entorno desde ConfigMap y Secret
-          envFrom:
-            - configMapRef:
-                name: my-app-config
-          env:
-            - name: DB_PASSWORD
-              valueFrom:
-                secretKeyRef:
-                  name: my-app-secrets
-                  key: db-password
-
-          # Directorio tmp escribible cuando readOnlyRootFilesystem: true
-          volumeMounts:
-            - name: tmp
-              mountPath: /tmp
-
-      volumes:
-        - name: tmp
-          emptyDir: {}
-```
-
----
-
-## Probes — Liveness, Readiness, Startup
-
-Entender cuándo usar cada probe es crítico:
-
-| Probe | Acción ante fallo | Usar para |
-|-------|---------------|---------|
-| `startupProbe` | Mata el contenedor si tarda en arrancar | Apps de arranque lento (JVM, Python) |
-| `livenessProbe` | Reinicia el contenedor | Detección de deadlock / proceso colgado |
-| `readinessProbe` | Lo retira de los endpoints del Service | Indisponibilidad temporal (reconexión a la BD) |
-
-```yaml
-# Patrón correcto: startupProbe cubre el arranque lento,
-# luego liveness/readiness toman el relevo
-startupProbe:
-  httpGet:
-    path: /health
-    port: 8080
-  failureThreshold: 30  # 30 * 5s = 150s de tiempo máximo de arranque
-  periodSeconds: 5
-
-livenessProbe:
-  httpGet:
-    path: /health
-    port: 8080
-  periodSeconds: 30
-  failureThreshold: 3   # 3 * 30s = 90s antes del reinicio
-
-readinessProbe:
-  httpGet:
-    path: /ready         # Endpoint separado: comprueba BD, caché, etc.
-    port: 8080
-  periodSeconds: 10
-  failureThreshold: 2
-```
-
-```yaml
-# INCORRECTO: initialDelaySeconds sin startupProbe
-# Si la app tarda 60s en arrancar, configura un startupProbe en su lugar
-livenessProbe:
-  httpGet:
-    path: /health
-    port: 8080
-  initialDelaySeconds: 60   # MAL: espera arbitraria, condición de carrera
-```
-
----
-
-## Services e Ingress
-
-### Tipos de Service
-
-```yaml
-# ClusterIP (por defecto) — solo interno
-apiVersion: v1
-kind: Service
-metadata:
-  name: my-app
-  namespace: my-namespace
-spec:
-  selector:
-    app: my-app
-  ports:
-    - port: 80
-      targetPort: 8080
-      protocol: TCP
-  type: ClusterIP
-```
-
-```yaml
-# LoadBalancer — tráfico externo (proveedores cloud)
-spec:
-  type: LoadBalancer
-  ports:
-    - port: 443
-      targetPort: 8080
-```
-
-### Ingress con TLS
-
-```yaml
-apiVersion: networking.k8s.io/v1
-kind: Ingress
-metadata:
-  name: my-app
-  namespace: my-namespace
-  annotations:
-    nginx.ingress.kubernetes.io/ssl-redirect: "true"
-    cert-manager.io/cluster-issuer: "letsencrypt-prod"
-spec:
-  ingressClassName: nginx
-  tls:
-    - hosts:
-        - myapp.example.com
-      secretName: my-app-tls
-  rules:
-    - host: myapp.example.com
-      http:
-        paths:
-          - path: /
-            pathType: Prefix
-            backend:
-              service:
-                name: my-app
-                port:
-                  number: 80
-```
-
----
-
-## ConfigMaps y Secrets
-
-### ConfigMap — Configuración no sensible
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: my-app-config
-  namespace: my-namespace
-data:
-  LOG_LEVEL: "info"
-  APP_ENV: "production"
-  MAX_CONNECTIONS: "100"
-  # Montar como archivo para configuración compleja
-  app.yaml: |
-    server:
-      port: 8080
-      timeout: 30s
-```
-
-```yaml
-# Montar un ConfigMap como archivo
-volumes:
-  - name: config
-    configMap:
-      name: my-app-config
-      items:
-        - key: app.yaml
-          path: app.yaml
-volumeMounts:
-  - name: config
-    mountPath: /etc/app
-    readOnly: true
-```
-
-### Secrets — Datos sensibles
-
-```bash
-# Crear un secret desde un literal (CLI; luego guárdalo en Vault/SOPS)
-kubectl create secret generic my-app-secrets \
-  --from-literal=db-password='s3cr3t' \
-  --namespace=my-namespace \
-  --dry-run=client -o yaml | kubectl apply -f -
-```
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  name: my-app-secrets
-  namespace: my-namespace
-type: Opaque
-# Los valores están codificados en base64 (NO cifrados — usa Sealed Secrets o ESO para cifrado real)
-data:
-  db-password: czNjcjN0  # base64 de 's3cr3t'
-```
-
-> **Importante:** Los Secrets crudos de Kubernetes solo están codificados en base64; no están cifrados en reposo salvo que tu clúster tenga el cifrado configurado. Usa [Sealed Secrets](https://github.com/bitnami-labs/sealed-secrets) o [External Secrets Operator](https://external-secrets.io) en producción.
-
----
-
-## Requests y Limits de recursos
-
-```yaml
-resources:
-  requests:       # El scheduler usa esto para ubicar el pod
-    cpu: "100m"   # 100 milicores = 0,1 CPU
-    memory: "128Mi"
-  limits:         # El contenedor es matado/limitado por encima de esto
-    cpu: "500m"
-    memory: "256Mi"
-```
-
-**Reglas prácticas:**
-
-| Tipo de carga | Request de CPU | Request de memoria | Notas |
-|---------------|-------------|----------------|-------|
-| API web | 100–250m | 128–256Mi | Configura limits de 2-4x los requests |
-| Worker/consumidor | 250–500m | 256–512Mi | Limit de memoria = request para previsibilidad |
-| App JVM | 500m–1 | 512Mi–2Gi | Deja margen por encima de `-Xmx` para el overhead de la JVM |
-| Sidecar | 10–50m | 32–64Mi | Mantenlo mínimo |
-
-```yaml
-# INCORRECTO: sin requests ni limits — planificación impredecible, expulsiones por OOM
-containers:
-  - name: app
-    image: myapp:latest
-    # Falta resources: {} — esto es peligroso en producción
-
-# INCORRECTO: limits sin requests — los requests toman por defecto los limits, sobre-reserva capacidad
-resources:
-  limits:
-    cpu: "2"
-    memory: "1Gi"
-  # Faltan los requests — tomarán por defecto los valores de los limits
-```
-
----
-
-## RBAC — Roles y ServiceAccounts
-
-### Principio de mínimo privilegio
-
-**Dos patrones según si la app llama a la API de Kubernetes:**
-
-#### Patrón A — La app NO necesita la API de Kubernetes (la mayoría de apps)
-
-Deshabilita el automontaje del token en el ServiceAccount. El Role/RoleBinding no son necesarios.
-
-```yaml
-# ServiceAccount con token deshabilitado — el valor por defecto más seguro
-apiVersion: v1
-kind: ServiceAccount
-metadata:
-  name: my-app-sa
-  namespace: my-namespace
-automountServiceAccountToken: false   # No se inyecta token de la API de K8s en los pods
-```
-
-```yaml
-# Referencia en el Deployment — sin token, sin acceso a la API
-spec:
-  template:
-    spec:
-      serviceAccountName: my-app-sa
-      automountServiceAccountToken: false   # Doble seguro: también se define a nivel de pod
-```
-
-#### Patrón B — La app SÍ necesita la API de Kubernetes (operadores, controladores, watchers de configuración)
-
-Habilita el token y concede solo los permisos realmente necesarios.
-
-```yaml
-# 1. ServiceAccount — habilitar el token para este SA
-apiVersion: v1
-kind: ServiceAccount
-metadata:
-  name: my-app-sa
-  namespace: my-namespace
-automountServiceAccountToken: true    # Token requerido: la app llama a la API de K8s
-```
-
-```yaml
-# 2. Role — concede solo lo que la app necesita (con alcance de namespace)
-apiVersion: rbac.authorization.k8s.io/v1
-kind: Role
-metadata:
-  name: my-app-role
-  namespace: my-namespace
-rules:
-  - apiGroups: [""]
-    resources: ["configmaps"]
-    verbs: ["get", "list", "watch"]    # Solo lectura, recurso específico
-  - apiGroups: [""]
-    resources: ["secrets"]
-    resourceNames: ["my-app-secrets"]  # Restringir a un secret específico por nombre
-    verbs: ["get"]
-```
-
-```yaml
-# 3. Vincular el Role al ServiceAccount
-apiVersion: rbac.authorization.k8s.io/v1
-kind: RoleBinding
-metadata:
-  name: my-app-rolebinding
-  namespace: my-namespace
-subjects:
-  - kind: ServiceAccount
-    name: my-app-sa
-    namespace: my-namespace
-roleRef:
-  kind: Role
-  apiGroup: rbac.authorization.k8s.io
-  name: my-app-role
-```
-
-```yaml
-# 4. Referenciar el SA en el Deployment
-spec:
-  template:
-    spec:
-      serviceAccountName: my-app-sa
-      # automountServiceAccountToken toma por defecto true desde el SA — el token se inyecta
-```
-
----
-
-## Horizontal Pod Autoscaler (HPA)
-
-```yaml
-apiVersion: autoscaling/v2
-kind: HorizontalPodAutoscaler
-metadata:
-  name: my-app-hpa
-  namespace: my-namespace
-spec:
-  scaleTargetRef:
-    apiVersion: apps/v1
-    kind: Deployment
-    name: my-app
-  minReplicas: 2      # Siempre al menos 2 para alta disponibilidad
-  maxReplicas: 10
-  metrics:
-    - type: Resource
-      resource:
-        name: cpu
-        target:
-          type: Utilization
-          averageUtilization: 70    # Escala hacia arriba cuando la CPU promedio > 70%
-    - type: Resource
-      resource:
-        name: memory
-        target:
-          type: Utilization
-          averageUtilization: 80
-```
-
-> El HPA requiere que `resources.requests` esté configurado en todos los contenedores — calcula la utilización como `actual / request`.
-
----
-
-## PodDisruptionBudget (PDB)
-
-Evita que caigan demasiados pods durante drenados de nodos o rolling updates:
-
-```yaml
-apiVersion: policy/v1
-kind: PodDisruptionBudget
-metadata:
-  name: my-app-pdb
-  namespace: my-namespace
-spec:
-  minAvailable: 2           # O bien usa maxUnavailable: 1
-  selector:
-    matchLabels:
-      app: my-app
-```
-
----
-
-## Namespaces y multi-tenencia
-
-```bash
-# Crear un namespace con cuotas de recursos
-kubectl create namespace my-namespace
-
-# Aplicar un ResourceQuota para limitar el consumo del namespace
-kubectl apply -f - <<EOF
-apiVersion: v1
-kind: ResourceQuota
-metadata:
-  name: my-namespace-quota
-  namespace: my-namespace
-spec:
-  hard:
-    requests.cpu: "4"
-    requests.memory: 4Gi
-    limits.cpu: "8"
-    limits.memory: 8Gi
-    pods: "20"
-EOF
-```
-
----
-
-## Jobs y CronJobs
-
-```yaml
-# Job puntual (migración de BD, procesamiento de datos)
-apiVersion: batch/v1
-kind: Job
-metadata:
-  name: db-migrate
-  namespace: my-namespace
-spec:
-  backoffLimit: 3          # Reintentar hasta 3 veces ante fallo
-  ttlSecondsAfterFinished: 3600   # Autoeliminarse después de 1h
-  template:
-    spec:
-      restartPolicy: OnFailure    # Nunca "Always" en Jobs
-      containers:
-        - name: migrate
-          image: ghcr.io/org/my-app:1.0.0
-          command: ["python", "manage.py", "migrate"]
-          resources:
-            requests:
-              cpu: "100m"
-              memory: "256Mi"
-```
-
-```yaml
-# CronJob
-apiVersion: batch/v1
-kind: CronJob
-metadata:
-  name: cleanup-job
-  namespace: my-namespace
-spec:
-  schedule: "0 2 * * *"         # 2am cada día
-  concurrencyPolicy: Forbid      # No ejecutar si el anterior sigue corriendo
-  successfulJobsHistoryLimit: 3
-  failedJobsHistoryLimit: 1
-  jobTemplate:
-    spec:
-      template:
-        spec:
-          restartPolicy: OnFailure
-          containers:
-            - name: cleanup
-              image: ghcr.io/org/cleanup:1.0.0
-              resources:
-                requests:
-                  cpu: "50m"
-                  memory: "64Mi"
-```
-
----
-
-## Chuleta de depuración con kubectl
-
-```bash
-# --- Estado de pods y logs ---
-kubectl get pods -n my-namespace
-kubectl get pods -n my-namespace -o wide          # Muestra la asignación de nodo
-kubectl describe pod <pod-name> -n my-namespace   # Detalles de eventos y estado
-kubectl logs <pod-name> -n my-namespace           # Logs actuales
-kubectl logs <pod-name> -n my-namespace --previous  # Logs del contenedor que crasheó
-kubectl logs <pod-name> -n my-namespace -c <container>  # Pod multi-contenedor
-
-# --- Ejecutar dentro de un contenedor en marcha ---
-kubectl exec -it <pod-name> -n my-namespace -- sh
-kubectl exec -it <pod-name> -n my-namespace -- bash
-
-# --- Comprobar el uso de recursos ---
-kubectl top pods -n my-namespace
-kubectl top nodes
-
-# --- Operaciones de Deployment ---
-kubectl rollout status deployment/my-app -n my-namespace
-kubectl rollout history deployment/my-app -n my-namespace
-kubectl rollout undo deployment/my-app -n my-namespace      # Rollback
-kubectl rollout undo deployment/my-app --to-revision=2 -n my-namespace
-
-# --- Escalar manualmente ---
-kubectl scale deployment my-app --replicas=5 -n my-namespace
-
-# --- Inspeccionar eventos (problemas a nivel de clúster) ---
-kubectl get events -n my-namespace --sort-by='.lastTimestamp'
-
-# --- Port-forward para depuración local ---
-kubectl port-forward pod/<pod-name> 8080:8080 -n my-namespace
-kubectl port-forward svc/my-app 8080:80 -n my-namespace
-
-# --- Dry-run para validar YAML ---
-kubectl apply -f deployment.yaml --dry-run=client
-kubectl apply -f deployment.yaml --dry-run=server   # Valida contra el clúster en vivo
-```
-
-### Diagnóstico de errores comunes
-
-```bash
-# CrashLoopBackOff: el contenedor no deja de crashear
-kubectl logs <pod-name> --previous -n my-namespace  # Revisar los logs del crash
-kubectl describe pod <pod-name> -n my-namespace     # Revisar el código de salida y OOMKilled
-
-# ImagePullBackOff: no se puede descargar la imagen
-kubectl describe pod <pod-name> -n my-namespace     # Revisar la sección Events
-# Causas: tag de imagen incorrecto, falta imagePullSecret, registro privado
-
-# Pod pendiente: no fue planificado
-kubectl describe pod <pod-name> -n my-namespace
-# Causas: recursos insuficientes, sin node selector coincidente, desajuste de taint/toleration
-
-# OOMKilled: sin memoria
-# Aumenta los limits de memoria, busca fugas de memoria
-kubectl describe pod <pod-name> -n my-namespace | grep -A5 "Last State"
-```
-
----
-
-## Antipatrones
-
-```yaml
-# MAL: usar el tag :latest — despliegues no deterministas
-image: myapp:latest
-
-# BIEN: fijar un tag inmutable específico (SHA o semver)
-image: ghcr.io/org/myapp:1.4.2
-# o
-image: ghcr.io/org/myapp@sha256:abc123...
-
-# ---
-
-# MAL: ejecutar como root
-securityContext: {}    # Por defecto es root
-
-# BIEN: no-root con UID explícito
-securityContext:
-  runAsNonRoot: true
-  runAsUser: 1001
-
-# ---
-
-# MAL: sin límites de recursos — un pod puede dejar sin recursos al nodo entero
-containers:
-  - name: app
-    image: myapp:1.0.0
-    # Sin resources definidos
-
-# BIEN: configura siempre requests y limits
-resources:
-  requests:
-    cpu: "100m"
-    memory: "128Mi"
-  limits:
-    cpu: "500m"
-    memory: "256Mi"
-
-# ---
-
-# MAL: guardar secretos en texto plano en ConfigMaps
-apiVersion: v1
-kind: ConfigMap
-data:
-  DB_PASSWORD: "mysecretpassword"   # NUNCA — usa un Secret o un gestor de secretos externo
-
-# ---
-
-# MAL: ClusterAdmin para service accounts de aplicaciones
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-roleRef:
-  kind: ClusterRole
-  name: cluster-admin    # Le da modo dios a tu app
-
-# ---
-
-# MAL: minAvailable: 0 en un PDB — anula su propósito
-spec:
-  minAvailable: 0
-
-# ---
-
-# MAL: restartPolicy: Always en un Job (provoca un bucle infinito de reinicios)
-spec:
-  restartPolicy: Always   # Usa OnFailure o Never en Jobs
-```
-
----
-
-## Lista de verificación de buenas prácticas
-
-### Seguridad
-- [ ] El contenedor se ejecuta como no-root (`runAsNonRoot: true`, `runAsUser` definido)
-- [ ] `readOnlyRootFilesystem: true` con `emptyDir` para las rutas escribibles
-- [ ] `allowPrivilegeEscalation: false`
-- [ ] Todas las capacidades eliminadas (`capabilities.drop: [ALL]`)
-- [ ] ServiceAccount dedicado por app, no `default`
-- [ ] `automountServiceAccountToken: false` salvo que sea necesario
-- [ ] El RBAC sigue el mínimo privilegio (usa `Role`, no `ClusterRole`, salvo que sea necesario)
-- [ ] Secretos gestionados con Sealed Secrets o External Secrets Operator
-
-### Confiabilidad
-- [ ] Los 3 tipos de probes configurados (startup + liveness + readiness)
-- [ ] Requests Y limits de recursos definidos en cada contenedor
-- [ ] `minReplicas: 2+` para cualquier carga de producción
-- [ ] PodDisruptionBudget definido para servicios con estado o críticos
-- [ ] Estrategia `RollingUpdate` con `maxUnavailable: 0`
-- [ ] HPA configurado para servicios de carga variable
-
-### Observabilidad
-- [ ] La app expone endpoints `/health` (liveness) y `/ready` (readiness)
-- [ ] Logging JSON estructurado (sin PII en los logs)
-- [ ] Etiquetas de recursos: `app`, `version`, `environment`
-
----
-
-## Skills relacionadas
-
-- `patrones-docker` — Dockerfiles multi-stage y seguridad de imágenes
-- `patrones-despliegue` — Pipelines de CI/CD, estrategia de rollback, endpoints de health check
-- `revision-seguridad` — Contexto más amplio de endurecimiento de seguridad
-- `flujo-git` — Integración GitOps con K8s (patrones ArgoCD / Flux)