# Módulo 8: Entregable — Pulso listo para producción ## 1. Objetivo Un solo chart de Helm, dos perfiles. `values-dev.yaml` sigue siendo el laboratorio liviano del módulo 5: una réplica, sin PSA estricta, sin HPA, con un Secret que arma el propio chart para no tener que sellar nada mientras desarrollás. `values-prod.yaml` es el mismo chart con todo lo del módulo 6 encendido: `pulso` y `pulso-datos` en Pod Security `restricted`, RBAC y ServiceAccounts por componente, NetworkPolicies con deny por defecto, un HPA que escala por CPU real, un PDB que protege un `kubectl drain`, y la contraseña de la base llegando en dos Secrets sellados con Sealed Secrets — nunca en texto plano en el repo, ni en el StatefulSet, ni en los values. El criterio de este módulo no es "que levante": es que un `helm upgrade` no le corte un pedido a nadie, que un nodo drenado no te tire las dos réplicas de la api a la vez, y que nadie con acceso al repo pueda leer la contraseña de Postgres. ```mermaid flowchart LR dev["values-dev.yaml"] -.->|"--set nada extra"| chart["chart/pulso"] prod["values-prod.yaml"] -.->|"psa.enforce=restricted, hpa.enabled=true, secretoExistente=true"| chart chart --> nsPulso["Namespace pulso"] chart --> nsDatos["Namespace pulso-datos"] nsPulso --> gw["Gateway + HTTPRoute"] nsPulso --> api["Deployment api (HPA, PDB, NetworkPolicy)"] nsPulso --> worker["Deployment worker (HPA, NetworkPolicy)"] nsPulso --> web["Deployment web"] api --> nsDatos worker --> nsDatos ``` ## 2. Punto de partida Traés el chart completo del módulo 5 (`Chart.yaml`, `values.yaml`, `values-dev.yaml` y los 12 templates: api, worker, web, postgres, valkey, migrar, gateway, configmap, secret, namespace-datos, `_helpers.tpl` y `NOTES.txt`) y los manifests de seguridad del módulo 6 (`k8s/overlays/seguro/`: ServiceAccounts, RBAC, NetworkPolicies, PDB, HPA, cinco patches de `securityContext` con UID explícitos, y el Secret sellado con Sealed Secrets). El trabajo de este módulo es fusionar los dos: lo que el módulo 6 escribió como *patches* de Kustomize sobre manifests fijos, acá se vuelve parte del propio template de Helm, condicionado por `values`. `k8s/base/` y `k8s/overlays/dev/` quedan en tu repo como estaban (referencia de la versión con Kustomize); no hace falta tocarlos. ## 3. Criterios de aceptación - [ ] `helm install` con `values-prod.yaml` en un cluster nuevo termina `deployed`: ```bash kubectl create namespace pulso kubectl create namespace pulso-datos PGPASS="$(openssl rand -hex 24)" kubectl create secret generic pulso-secretos -n pulso \ --from-literal="DATABASE_URL=postgres://pulso:${PGPASS}@postgres.pulso-datos.svc:5432/pulso" \ --dry-run=client -o yaml \ | kubeseal --controller-namespace kube-system --controller-name sealed-secrets-controller \ --format yaml > sellado-pulso.yaml kubectl create secret generic postgres-secretos -n pulso-datos \ --from-literal="POSTGRES_PASSWORD=${PGPASS}" \ --dry-run=client -o yaml \ | kubeseal --controller-namespace kube-system --controller-name sealed-secrets-controller \ --format yaml > sellado-pulso-datos.yaml unset PGPASS kubectl apply -f sellado-pulso.yaml -f sellado-pulso-datos.yaml helm install pulso chart/pulso -f chart/pulso/values-prod.yaml \ -n pulso --wait=hookOnly --take-ownership --timeout 300s ``` Run real: `STATUS: deployed`, `REVISION: 1`, `Job migrar` → `Complete 1/1` en unos 30 a 40 s según la corrida. La sección 6 ("Errores comunes") explica por qué no lleva `--rollback-on-failure` acá. - [ ] El namespace `pulso` tiene `pod-security.kubernetes.io/enforce: restricted` y no hay eventos `FailedCreate`: ```bash kubectl get namespace pulso pulso-datos --show-labels kubectl -n pulso get events --field-selector reason=FailedCreate ``` Run real: las dos namespaces con `pod-security.kubernetes.io/enforce=restricted`; `FailedCreate en pulso: 0; en pulso-datos: 0`. - [ ] HPA probado con carga: réplicas antes y durante, con `kubectl get hpa`. `monitores.js` da de alta sus monitores contra `sitio-lento`, que en este chart viene apagado: primero se enciende con un upgrade, y recién después se lanza la carga. ```bash helm upgrade pulso chart/pulso -f chart/pulso/values-prod.yaml \ --set sitioLento.enabled=true -n pulso --wait --timeout 240s kubectl -n pulso rollout status deployment/sitio-lento --timeout=120s GW_IP="$(kubectl -n pulso get gateway pulso -o jsonpath='{.status.addresses[0].value}')" kubectl -n pulso get hpa k6 run -e BASE_URL="http://$GW_IP" -e N=80 -e INTERVALO=10 -e DELAY_MS=300 -e DURACION=5m \ carga/monitores.js & k6 run -e BASE_URL="http://$GW_IP" -e VUS=40 -e DURACION=5m carga/api.js & kubectl -n pulso get hpa -w ``` Run real — antes: `api cpu: /50% REPLICAS 2`, `worker cpu: /20% REPLICAS 1`. A los 20 s de carga los dos seguían en ``. A los 40 s: `api cpu: 397%/50% REPLICAS 4`, `worker cpu: 45%/20% REPLICAS 2`, con `api 4/4` y `worker 2/2` en `kubectl get deployment`. La corrida cortó la carga en ese mismo momento, apenas el worker pasó de 1 réplica: no midió la vuelta a las réplicas mínimas. En tu cluster, cortá k6 y dejá el `get hpa -w` abierto: este chart no configura `behavior.scaleDown`, así que corre la ventana de estabilización por defecto de Kubernetes (5 minutos) antes de que el HPA baje réplicas. - [ ] NetworkPolicies comprobadas: api sin salida a Internet, worker con salida, la base solo desde api, worker y el Job: Un `kubectl run` pelado no sirve acá: `pulso` está en `restricted` y rechazaría el Pod. Los Pods de prueba llevan el mismo `securityContext` que exige PSA, y el label que les hace heredar la NetworkPolicy del componente que imitan (`role`, no `app`, para no meterse como backend del Service): ```bash crear_pod_prueba() { # uso: crear_pod_prueba [label=valor] local nombre="$1" label="${2:-}" labels_yaml="" if [ -n "$label" ]; then labels_yaml=$' labels:\n'" ${label%%=*}: ${label#*=}" fi cat < [!NOTE] > Los archivos de abajo son los que corrieron en el runner de este curso, con una sola diferencia > que no cambia nada de lo que se aplica: `ghcr.io/coceresroman` → `ghcr.io/` en cada > imagen. `Chart.yaml`, `templates/configmap.yaml`, `templates/gateway.yaml`, > `templates/_helpers.tpl` y `templates/NOTES.txt` son **byte a byte los del módulo 5**, sin ningún > cambio: no se repiten acá. `k8s/base/`, `k8s/overlays/dev/` (Kustomize, módulo 4) y `carga/` > (`sondeo.js` del módulo 4; `monitores.js`/`api.js` del módulo 6) tampoco cambiaron: son las mismas > carpetas de siempre.

Solución completa

`chart/pulso/values.yaml`: ```yaml # Valores por defecto del chart, pensados como un entorno de laboratorio: sin PSA # estricta, sin HPA ni PDB, y con un Secret que arma el propio chart (no hace # falta sellar nada para levantar esto). values-dev.yaml y values-prod.yaml pisan # solo lo que cambia por entorno — el resto (ServiceAccounts, RBAC, # NetworkPolicies, securityContext con UID explícitos: módulo 6) viaja siempre, # en los dos entornos: no son "extras de producción", son la forma correcta de # escribir los manifests. # Segunda namespace de la arquitectura (módulo 2): la de los datos. No es la # namespace de la release (esa la crea `helm install --create-namespace` con el # nombre que le pasás en -n) — el chart la declara aparte porque Helm no crea sola # ninguna namespace que no sea la de la propia release. namespaceDatos: pulso-datos imagenes: pullPolicy: IfNotPresent api: repositorio: ghcr.io//pulso-alumno-app tag: "1.0.0" worker: repositorio: ghcr.io//pulso-alumno-app tag: "1.0.0" web: repositorio: ghcr.io//pulso-alumno-web tag: "1.0.0" api: replicas: 2 recursos: requests: cpu: 50m memory: 96Mi limits: cpu: 200m memory: 192Mi worker: replicas: 1 recursos: requests: cpu: 75m memory: 128Mi limits: cpu: 250m memory: 256Mi web: replicas: 1 recursos: requests: cpu: 25m memory: 32Mi limits: cpu: 100m memory: 64Mi postgres: usuario: pulso # Contraseña de laboratorio: solo se usa con secretoExistente: false. Con # secretoExistente: true no se lee (values-prod.yaml la deja vacía a propósito). password: pulso baseDatos: pulso storageClassName: standard storage: 1Gi recursos: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 512Mi valkey: imagen: valkey/valkey:9.1 recursos: requests: cpu: 50m memory: 64Mi limits: cpu: 200m memory: 128Mi config: logLevel: info workerConcurrencia: 5 migracion: backoffLimit: 1 ttlSecondsAfterFinished: 600 gateway: enabled: true gatewayClassName: cloud-provider-kind # Namespaces con Pod Security Admission: "" no exige nada (values-dev.yaml); # "restricted" (values-prod.yaml) las pone en pulso Y pulso-datos, con la misma # etiqueta en las dos namespaces del chart (namespace.yaml y namespace-datos.yaml). psa: enforce: "" # false: el Secret pulso-secretos lo arma el propio chart, con la contraseña de # postgres.password de este mismo values (útil para instalar rápido en dev), y # Postgres recibe esa misma contraseña como `value:` en su StatefulSet. true # (values-prod.yaml): los Secrets ya existen en el cluster porque los creó el # controller de Sealed Secrets a partir de dos SealedSecrets aplicados antes del # helm install (README-k8s.md) — pulso-secretos (DATABASE_URL) en la namespace # de la release y postgres-secretos (POSTGRES_PASSWORD) en namespaceDatos. El # chart deja de crear el primero (si lo hiciera pisaría con texto plano lo que # Sealed Secrets acaba de sellar), Postgres lee el segundo con un secretKeyRef, # y postgres.password deja de usarse: la contraseña real no pasa por ningún # values ni por --set. secretoExistente: false # autoscaling/v2 por CPU (módulo 6): sin esto, HPA queda en con # replicas fijas si worker no tiene requests, o simplemente no existe. Los # targets vienen de la carga real medida en el módulo 6: 50% para la api (carga # de lectura satura rápido su límite de 200m) y 20% para el worker (con la # tolerancia por defecto del 10%, un target de 50% no llegaba a disparar con la # carga real de monitores.js, que sostiene 37-52% de la request). hpa: enabled: false api: minReplicas: 2 maxReplicas: 4 targetCPUUtilizationPercentage: 50 worker: minReplicas: 1 maxReplicas: 4 targetCPUUtilizationPercentage: 20 # minAvailable: 1, nunca igual a las réplicas de arranque (bloquearía cualquier # drenado por completo; módulo 6, sección 4). Sin PDB en dev: con 1 sola # réplica de api, minAvailable:1 == réplicas equivaldría a bloquear cualquier # eviction del único Pod que hay. pdb: enabled: false minAvailable: 1 # El sitio lento no es un componente público de Pulso: solo existe para generar # la carga de CPU real que el HPA del worker necesita (worker lo chequea cada # pocos segundos vía carga/monitores.js). Deshabilitado por defecto: activalo # con --set sitioLento.enabled=true cuando quieras reproducir el escalado. sitioLento: enabled: false imagen: ghcr.io//pulso-alumno-app tag: "1.0.0" ``` `chart/pulso/values-dev.yaml`: ```yaml # Entorno dev: una sola réplica de api (no hace falta tolerar una caída mientras # desarrollás) y logs más verbosos. No pisa psa.enforce, hpa.enabled, pdb.enabled # ni secretoExistente: los defaults de values.yaml (sin PSA estricta, sin HPA, # sin PDB, Secret armado por el propio chart) YA son el perfil de dev que pide # el criterio de aceptación 8 ("sin HPA ni PSA estricta"). api: replicas: 1 config: logLevel: debug ``` `chart/pulso/values-prod.yaml`: ```yaml # Entorno de producción: PSA restricted # en pulso Y pulso-datos (módulo 6: postgres:18 y valkey/valkey:9.1 arrancan y # sirven bajo restricted con runAsUser explícito, sin necesidad de bajar a # baseline), HPA y PDB activos, y los Secrets llegan sellados — secretoExistente: # true asume que ya corriste kubeseal y aplicaste los dos SealedSecrets # resultantes (pulso-secretos en pulso, postgres-secretos en pulso-datos) ANTES # de este helm install (README-k8s.md, sección "Instalar en producción"). api: replicas: 2 config: logLevel: info psa: enforce: restricted secretoExistente: true # Vacía a propósito: en producción la contraseña no sale de ningún values, sale # de los dos Secrets sellados. Pisar acá el default de laboratorio de values.yaml # ("pulso") hace que, si algún template todavía leyera postgres.password en este # modo, el `required` corte el render en vez de instalar con la contraseña de # laboratorio. No la completes ni la pases con --set: quedaría en claro en el # Secret de release de Helm. postgres: password: "" hpa: enabled: true pdb: enabled: true ``` `chart/pulso/templates/namespace.yaml`: ```yaml # Namespace de la release, declarada por el propio chart (no solo por # `helm install --create-namespace`, que la crea pero sin ningún label). Helm # ordena los kinds al aplicar: Namespace queda primero en esa lista fija, así # que este label de PSA (cuando psa.enforce no está vacío) ya está puesto antes # de que se cree ningún Pod — necesario para que el criterio "sin FailedCreate" # se cumpla incluso en el primer install sobre un cluster nuevo. # # helm.sh/resource-policy: keep, mismo motivo que namespace-datos.yaml: sin # esto, un `helm uninstall` borraría la Namespace completa (con TODO lo de # adentro, en cascada) en vez de borrar cada recurso de a uno. Seguís # necesitando --create-namespace en el primer install: Helm exige que la # namespace de destino ya exista antes de crear nada, no la saca de su propia # lista de recursos a aplicar. apiVersion: v1 kind: Namespace metadata: name: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} {{- if .Values.psa.enforce }} pod-security.kubernetes.io/enforce: {{ .Values.psa.enforce }} pod-security.kubernetes.io/enforce-version: latest {{- end }} annotations: "helm.sh/resource-policy": keep ``` `chart/pulso/templates/namespace-datos.yaml`: ```yaml # helm.sh/resource-policy: keep protege SOLO este objeto (la Namespace), no lo que # vive adentro: Postgres (StatefulSet) y Valkey (Deployment) no tienen esta anotación, # así que un `helm uninstall` los borra igual (el módulo 5 lo prueba). A propósito no se # la pusimos a Postgres/Valkey: un recurso "keep" que se queda ahí, roto o desactualizado, # complica más el próximo `helm install` de lo que ayuda. # # Lo que de verdad sobrevive al ciclo completo es el PersistentVolumeClaim de Postgres: # no lo crea este chart (lo crea el controller de StatefulSet a partir de # volumeClaimTemplates, sin ownerReference hacia el StatefulSet — módulo 2, sección 8), # así que Helm nunca lo tiene en su lista de recursos a borrar. Esta anotación en la # Namespace es lo que hace falta para que ese PVC tenga dónde seguir viviendo: sin ella, # borrar la Namespace se lleva puesto TODO lo de adentro sin excepción, PVC incluido # (el borrado de una Namespace no respeta ownerReferences, es total). Con la Namespace # viva y el PVC vivo, reinstalar Postgres en la misma namespaceDatos reengancha el mismo # PVC (mismo nombre determinístico) y recupera los datos — el módulo 5 lo demuestra. # # El mismo psa.enforce de namespace.yaml se repite acá (módulo 6): postgres:18 y # valkey/valkey:9.1 arrancan y sirven bajo restricted con el runAsUser explícito # que llevan postgres.yaml y valkey.yaml, así que no hay motivo para dejar esta # namespace en un nivel más laxo que la de la aplicación. apiVersion: v1 kind: Namespace metadata: name: {{ .Values.namespaceDatos }} labels: {{- include "pulso.labels" . | nindent 4 }} {{- if .Values.psa.enforce }} pod-security.kubernetes.io/enforce: {{ .Values.psa.enforce }} pod-security.kubernetes.io/enforce-version: latest {{- end }} annotations: "helm.sh/resource-policy": keep ``` `chart/pulso/templates/secret.yaml`: ```yaml {{- if not .Values.secretoExistente }} # DATABASE_URL tiene la contraseña de Postgres adentro: por eso es Secret y no # ConfigMap. stringData es solo para escribir el manifest en texto plano; el # apiserver lo guarda codificado en base64 en el campo data (módulo 2, sección 3: # base64 no es cifrado). `required` corta el render con un mensaje claro si algún # values.yaml de un fork se olvida de fijar la contraseña, en vez de instalar con # un DATABASE_URL roto. # # Este template solo se renderiza con secretoExistente: false (el default, # values-dev.yaml). Con secretoExistente: true (values-prod.yaml) el chart NO # crea este Secret: ya existe en el cluster, creado por el controller de Sealed # Secrets a partir de los SealedSecrets aplicados ANTES del helm install # (README-k8s.md) — si este template igual lo creara, pisaría con texto plano lo # que Sealed Secrets acaba de sellar, y el Secret real (el sellado) nunca queda # en el repo, que es el punto entero del ejercicio: el Secret plano no está en # el repo. # # En ese modo tampoco sale de acá la contraseña del servidor: postgres.yaml # cambia el `value:` de POSTGRES_PASSWORD por un secretKeyRef al Secret # postgres-secretos de namespaceDatos, que llega sellado igual que este. Son dos # SealedSecrets (uno por namespace) con la misma contraseña adentro. apiVersion: v1 kind: Secret metadata: name: pulso-secretos namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} type: Opaque stringData: DATABASE_URL: postgres://{{ .Values.postgres.usuario }}:{{ required "postgres.password es obligatorio" .Values.postgres.password }}@postgres.{{ .Values.namespaceDatos }}.svc:5432/{{ .Values.postgres.baseDatos }} {{- end }} ``` `chart/pulso/templates/serviceaccounts.yaml`: ```yaml # Una ServiceAccount por componente (módulo 6), no la "default" del namespace, # compartida por cualquier Pod que no declare la suya: así un Role atado a una # sola de estas identidades no le da nada de más a los otros dos componentes. # Las tres llevan automountServiceAccountToken: false en su Deployment # (api.yaml/worker.yaml/web.yaml): ninguno de los tres necesita hablarle a la # API de Kubernetes desde adentro del proceso, así que ni siquiera montan el # token. Viajan siempre, en los dos entornos. apiVersion: v1 kind: ServiceAccount metadata: name: api namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} --- apiVersion: v1 kind: ServiceAccount metadata: name: worker namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} --- apiVersion: v1 kind: ServiceAccount metadata: name: web namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} ``` `chart/pulso/templates/rbac.yaml`: ```yaml # Role de solo lectura sobre Pods y Services del namespace de la release, atado # únicamente a la ServiceAccount "api" (módulo 6: pensado para una futura ruta # de diagnóstico propia, tipo "/api/estado-cluster"; hoy la api no la usa # todavía). worker y web no tienen ningún Role: pueden autenticarse contra la # API (si algo les montara el token) pero cualquier acción les da "Forbidden". apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: lector-pods namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} rules: - apiGroups: [""] resources: ["pods", "services"] verbs: ["get", "list", "watch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: api-lector-pods namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} subjects: - kind: ServiceAccount name: api namespace: {{ .Release.Namespace }} roleRef: kind: Role name: lector-pods apiGroup: rbac.authorization.k8s.io ``` `chart/pulso/templates/api.yaml`: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: api namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: {{- if not .Values.hpa.enabled }} # replicas fijo SOLO cuando no hay HPA (values-dev.yaml): con hpa.enabled: true # (values-prod.yaml), este campo se omite del todo — no se pone en 0 ni se # copia el valor que trae hpa.api.minReplicas. Si lo declarásemos igual, cada # helm upgrade/rollback reclamaría de nuevo ese campo con el número fijo de # values.yaml, peleándose con lo que el HPA ya decidió (los dos actores # reclaman el mismo campo del Deployment). Omitirlo dejar que Kubernetes # conserve el último valor que puso quien sea que lo haya tocado, HPA # incluido (sección 6, "Errores comunes"). replicas: {{ .Values.api.replicas }} {{- end }} # maxUnavailable: 0 fuerza a levantar el Pod nuevo (maxSurge) ANTES de bajar uno # viejo (módulo 4, sección 6): en ningún momento del rollout hay menos réplicas # Ready que réplicas declaradas. strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 maxSurge: 1 selector: matchLabels: app: api template: metadata: labels: app: api # "role" además de "app" (módulo 6): el Service api elige endpoints por # "app: api"; un pod de prueba de NetworkPolicy con ese mismo label se # metería como backend real y le robaría tráfico. "role" no lo usa # ningún Service, solo las NetworkPolicy de este chart. role: api annotations: # Sin esto, un `helm upgrade` que solo cambia pulso-config (LOG_LEVEL, # REDIS_URL) no mueve un pelo acá: envFrom lee la ConfigMap una vez, al # arrancar el contenedor, y Kubernetes no reinicia Pods porque cambió una # ConfigMap que no está montada como volumen. El checksum en la propia # spec del Pod sí cambia, y ESO es lo que dispara el rollout (módulo 5). checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} spec: enableServiceLinks: false serviceAccountName: api automountServiceAccountToken: false # runAsUser: 1000 explícito, no un adorno: la imagen de node declara # "USER node" (un nombre, no un UID numérico). Sin esto, el kubelet no # puede verificar estáticamente que ese usuario no sea root y rechaza el # Pod con "container has runAsNonRoot and image has non-numeric user # (node), cannot verify user is non-root" (módulo 6, mensaje real). 1000 # es el UID del usuario "node" en la imagen oficial de Node.js. Este # securityContext viaja siempre (no solo con psa.enforce: restricted): # es correcto igual en un namespace sin PSA estricta. securityContext: runAsNonRoot: true runAsUser: 1000 seccompProfile: type: RuntimeDefault containers: - name: api image: "{{ .Values.imagenes.api.repositorio }}:{{ required "imagenes.api.tag es obligatorio" .Values.imagenes.api.tag }}" imagePullPolicy: {{ .Values.imagenes.pullPolicy }} ports: - name: http containerPort: 3000 envFrom: - configMapRef: name: pulso-config env: - name: DATABASE_URL valueFrom: secretKeyRef: name: pulso-secretos key: DATABASE_URL startupProbe: httpGet: path: /healthz port: http periodSeconds: 2 failureThreshold: 30 readinessProbe: httpGet: path: /readyz port: http periodSeconds: 5 failureThreshold: 3 livenessProbe: httpGet: path: /healthz port: http periodSeconds: 10 failureThreshold: 3 lifecycle: preStop: sleep: seconds: 5 securityContext: allowPrivilegeEscalation: false capabilities: drop: ["ALL"] readOnlyRootFilesystem: true resources: {{- toYaml .Values.api.recursos | nindent 12 }} --- apiVersion: v1 kind: Service metadata: name: api namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: selector: app: api ports: - name: http port: 3000 targetPort: http ``` `chart/pulso/templates/worker.yaml`: ```yaml # Service worker-metricas, nunca "metricas": un Service llamado igual que la # variable que ya usa Pulso (METRICAS_PORT) le pisa el valor al contenedor si # enableServiceLinks no está en false (módulo 2, sección 4). apiVersion: apps/v1 kind: Deployment metadata: name: worker namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: {{- if not .Values.hpa.enabled }} # Mismo motivo que api.yaml: con el HPA activo, este campo se omite del todo # para no pelearse por él en cada helm upgrade/rollback. replicas: {{ .Values.worker.replicas }} {{- end }} selector: matchLabels: app: worker template: metadata: labels: app: worker role: worker annotations: checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} spec: enableServiceLinks: false serviceAccountName: worker automountServiceAccountToken: false # Mismo runAsUser: 1000 y misma razón que api.yaml (imagen node, USER no # numérico). securityContext: runAsNonRoot: true runAsUser: 1000 seccompProfile: type: RuntimeDefault # El apagado del worker drena los chequeos en curso durante hasta 25 s (README # de Pulso): 40 s da un colchón real sobre el default de 30 s. terminationGracePeriodSeconds: 40 containers: - name: worker image: "{{ .Values.imagenes.worker.repositorio }}:{{ required "imagenes.worker.tag es obligatorio" .Values.imagenes.worker.tag }}" imagePullPolicy: {{ .Values.imagenes.pullPolicy }} command: ["node", "dist/worker/principal.js"] ports: - name: metricas containerPort: 9464 envFrom: - configMapRef: name: pulso-config env: - name: DATABASE_URL valueFrom: secretKeyRef: name: pulso-secretos key: DATABASE_URL startupProbe: httpGet: path: /healthz port: metricas periodSeconds: 2 failureThreshold: 30 readinessProbe: httpGet: path: /readyz port: metricas periodSeconds: 5 failureThreshold: 3 livenessProbe: httpGet: path: /healthz port: metricas periodSeconds: 10 failureThreshold: 3 securityContext: allowPrivilegeEscalation: false capabilities: drop: ["ALL"] readOnlyRootFilesystem: true resources: {{- toYaml .Values.worker.recursos | nindent 12 }} --- apiVersion: v1 kind: Service metadata: name: worker-metricas namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: selector: app: worker ports: - name: metricas port: 9464 targetPort: metricas ``` `chart/pulso/templates/web.yaml`: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: web namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: replicas: {{ .Values.web.replicas }} selector: matchLabels: app: web template: metadata: labels: app: web spec: enableServiceLinks: false serviceAccountName: web automountServiceAccountToken: false # Sin runAsUser explícito: nginxinc/nginx-unprivileged declara "USER 101" # (numérico) en su propio Dockerfile, así que el kubelet lo puede # verificar sin ayuda (módulo 6) — a diferencia de la imagen de node. securityContext: runAsNonRoot: true seccompProfile: type: RuntimeDefault containers: - name: web image: "{{ .Values.imagenes.web.repositorio }}:{{ required "imagenes.web.tag es obligatorio" .Values.imagenes.web.tag }}" imagePullPolicy: {{ .Values.imagenes.pullPolicy }} env: - name: PULSO_API_URL value: http://api.{{ .Release.Namespace }}.svc:3000 ports: - name: http containerPort: 8080 readinessProbe: httpGet: path: / port: http periodSeconds: 5 failureThreshold: 3 livenessProbe: httpGet: path: / port: http periodSeconds: 10 failureThreshold: 3 lifecycle: preStop: sleep: seconds: 5 securityContext: allowPrivilegeEscalation: false capabilities: drop: ["ALL"] resources: {{- toYaml .Values.web.recursos | nindent 12 }} --- apiVersion: v1 kind: Service metadata: name: web namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: selector: app: web ports: - name: http port: 8080 targetPort: http ``` `chart/pulso/templates/postgres.yaml`: ```yaml # PVC vía volumeClaimTemplates, montado en /var/lib/postgresql (la imagen postgres:18 # declara VOLUME ahí, no en /var/lib/postgresql/data). La StorageClass "standard" de # kind es local-path-provisioner: WaitForFirstConsumer y reclaimPolicy Delete # (módulo 2, sección 8: borrar el PVC borra los datos de verdad). apiVersion: apps/v1 kind: StatefulSet metadata: name: postgres namespace: {{ .Values.namespaceDatos }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: serviceName: postgres replicas: 1 selector: matchLabels: app: postgres template: metadata: labels: app: postgres spec: enableServiceLinks: false # Sin serviceAccountName usa la "default" de la namespace; Postgres no le # habla a la API de Kubernetes, así que ni siquiera monta su token. automountServiceAccountToken: false # runAsUser: 999 (módulo 6, prueba real): la imagen oficial postgres:18 no # declara un USER no-root en su Dockerfile (arranca como root para el # chown inicial de PGDATA y recién ahí hace su propio drop de privilegios # con gosu), así que sin esto el kubelet la rechaza igual que a node # (mismo error, otra imagen). 999 es el UID del usuario "postgres" que la # propia imagen crea. Viaja siempre, no solo con psa.enforce: restricted. securityContext: runAsNonRoot: true runAsUser: 999 runAsGroup: 999 seccompProfile: type: RuntimeDefault containers: - name: postgres image: postgres:18 securityContext: allowPrivilegeEscalation: false capabilities: drop: ["ALL"] env: - name: POSTGRES_USER value: {{ .Values.postgres.usuario | quote }} # La contraseña del servidor sale de un lugar distinto según el entorno. # secretoExistente: false (dev): un `value:` en claro con # postgres.password, el mismo valor con el que secret.yaml arma el # DATABASE_URL. secretoExistente: true (prod): un secretKeyRef al # Secret postgres-secretos de ESTA namespace (namespaceDatos), que ya # existe porque llegó sellado antes del helm install (README-k8s.md). # Así la contraseña real no aparece ni en este StatefulSet ni en el # Secret de release de Helm, y postgres.password ni se lee (el # `required` queda en la rama de dev). Tiene que ser la MISMA # contraseña que viaja adentro del DATABASE_URL de pulso-secretos: # son dos Secrets porque un Pod solo puede leer Secrets de su propia # namespace. - name: POSTGRES_PASSWORD {{- if .Values.secretoExistente }} valueFrom: secretKeyRef: name: postgres-secretos key: POSTGRES_PASSWORD {{- else }} value: {{ required "postgres.password es obligatorio" .Values.postgres.password | quote }} {{- end }} - name: POSTGRES_DB value: {{ .Values.postgres.baseDatos | quote }} ports: - name: postgres containerPort: 5432 readinessProbe: exec: command: ["pg_isready", "-U", {{ .Values.postgres.usuario | quote }}, "-d", {{ .Values.postgres.baseDatos | quote }}] periodSeconds: 5 failureThreshold: 3 livenessProbe: exec: command: ["pg_isready", "-U", {{ .Values.postgres.usuario | quote }}, "-d", {{ .Values.postgres.baseDatos | quote }}] initialDelaySeconds: 15 periodSeconds: 10 failureThreshold: 5 resources: {{- toYaml .Values.postgres.recursos | nindent 12 }} volumeMounts: - name: datos mountPath: /var/lib/postgresql volumeClaimTemplates: - metadata: name: datos spec: accessModes: ["ReadWriteOnce"] storageClassName: {{ .Values.postgres.storageClassName }} resources: requests: storage: {{ .Values.postgres.storage }} --- apiVersion: v1 kind: Service metadata: name: postgres namespace: {{ .Values.namespaceDatos }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: selector: app: postgres ports: - port: 5432 targetPort: 5432 ``` `chart/pulso/templates/valkey.yaml`: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: valkey namespace: {{ .Values.namespaceDatos }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: replicas: 1 selector: matchLabels: app: valkey template: metadata: labels: app: valkey spec: enableServiceLinks: false # Mismo motivo que postgres.yaml: usa la ServiceAccount "default" y no # necesita su token. automountServiceAccountToken: false # Mismo runAsUser: 999 que postgres.yaml (módulo 6, misma prueba real): # UID del usuario que trae la imagen oficial valkey/valkey. securityContext: runAsNonRoot: true runAsUser: 999 runAsGroup: 999 seccompProfile: type: RuntimeDefault containers: - name: valkey image: {{ .Values.valkey.imagen }} securityContext: allowPrivilegeEscalation: false capabilities: drop: ["ALL"] ports: - name: valkey containerPort: 6379 readinessProbe: exec: command: ["valkey-cli", "ping"] periodSeconds: 5 failureThreshold: 3 livenessProbe: exec: command: ["valkey-cli", "ping"] initialDelaySeconds: 5 periodSeconds: 10 failureThreshold: 5 resources: {{- toYaml .Values.valkey.recursos | nindent 12 }} --- apiVersion: v1 kind: Service metadata: name: valkey namespace: {{ .Values.namespaceDatos }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: selector: app: valkey ports: - port: 6379 targetPort: 6379 ``` `chart/pulso/templates/migrar-job.yaml`: ```yaml # Hook post-install,pre-upgrade — OJO, no pre-install: el propio Postgres de este # chart (postgres.yaml) es un recurso NO-hook. La tabla de hooks de la documentación # oficial de Helm ("Chart Hooks") dice, para pre-install: "Executes after templates # are rendered, but before any resources are created in Kubernetes"; para # post-install: "Executes after all resources are loaded into Kubernetes". Con # pre-install, el initContainer de este Job esperaría para siempre un Postgres que # Helm todavía no creó: instalación colgada hasta el timeout. Con post-install, Helm # ya sometió Postgres (y api/worker/web) antes de correr este hook, así que el # pg_isready del initContainer tiene sentido. En upgrade sí es pre-upgrade: para # entonces Postgres ya existe de una instalación anterior, y correr las migraciones # ANTES de actualizar api/worker es lo que querés (que el código nuevo nunca vea un # esquema viejo). # # hook-delete-policy: before-hook-creation (sin hook-succeeded) deja el Job # Completed visible después de instalar, para poder mirarlo con kubectl; Helm lo # borra recién antes de crear el próximo (el de un upgrade posterior). Si en cambio # el Job termina Failed, se queda ahí para inspección con `kubectl logs` — y el # upgrade también lo borra antes de reintentar. before-hook-creation es además la # política por defecto de Helm; con otra política sola (por ejemplo hook-succeeded), # un Job fallido se queda y el reintento choca con que spec.template es inmutable. # # backoffLimit: 1 (un solo reintento: si falla dos veces algo está mal de verdad) y # ttlSecondsAfterFinished: 600 (el controlador de TTL lo borra 10 minutos después de # terminar, así no queda acumulando Jobs viejos entre upgrades). apiVersion: batch/v1 kind: Job metadata: name: migrar namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} annotations: "helm.sh/hook": post-install,pre-upgrade "helm.sh/hook-delete-policy": before-hook-creation spec: backoffLimit: {{ .Values.migracion.backoffLimit }} ttlSecondsAfterFinished: {{ .Values.migracion.ttlSecondsAfterFinished }} template: spec: restartPolicy: Never enableServiceLinks: false # El Job corre con la ServiceAccount "default": migrar solo le habla a # Postgres, nunca a la API de Kubernetes, así que no monta el token. automountServiceAccountToken: false # Dos containers, dos imágenes, dos UID numéricos distintos (módulo 6): # "esperar-postgres" corre la imagen postgres:18 (UID 999, igual que el # propio Postgres) solo para hacer pg_isready en loop; "migrar" corre la # imagen de node (UID 1000, igual que la api). El securityContext a nivel # Pod no alcanza porque cada container necesita un runAsUser distinto: se # pisa a nivel container. securityContext: runAsNonRoot: true seccompProfile: type: RuntimeDefault initContainers: - name: esperar-postgres image: postgres:18 command: - sh - -c - until pg_isready -h postgres.{{ .Values.namespaceDatos }}.svc -p 5432 -U {{ .Values.postgres.usuario }}; do sleep 2; done securityContext: runAsUser: 999 allowPrivilegeEscalation: false capabilities: drop: ["ALL"] containers: - name: migrar image: "{{ .Values.imagenes.api.repositorio }}:{{ required "imagenes.api.tag es obligatorio" .Values.imagenes.api.tag }}" imagePullPolicy: {{ .Values.imagenes.pullPolicy }} command: ["node", "dist/migrar.js"] envFrom: - configMapRef: name: pulso-config env: - name: DATABASE_URL valueFrom: secretKeyRef: name: pulso-secretos key: DATABASE_URL securityContext: runAsUser: 1000 allowPrivilegeEscalation: false capabilities: drop: ["ALL"] readOnlyRootFilesystem: true resources: requests: cpu: 50m memory: 96Mi limits: cpu: 200m memory: 192Mi ``` `chart/pulso/templates/networkpolicies.yaml`: ```yaml # Deny por defecto en el namespace de la release: ningún Pod acepta ni inicia # una conexión que no esté permitida explícitamente por otra NetworkPolicy de # más abajo (todas se suman; no se pisan). Sin la regla de DNS de al lado, esta # sola ya corta la resolución de nombres de todo el namespace (módulo 6). # Viajan siempre, en los dos entornos: kindnet aplica NetworkPolicy por # defecto y esto es correcto sin importar si el namespace está en restricted. apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-por-defecto namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: podSelector: {} policyTypes: ["Ingress", "Egress"] --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: permitir-dns namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: podSelector: {} policyTypes: ["Egress"] egress: - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system ports: - protocol: UDP port: 53 - protocol: TCP port: 53 --- # La api no tiene ninguna razón para salir a Internet: solo le habla a Postgres # y a Valkey, los dos en namespaceDatos. El puerto de entrada (3000) queda # abierto a cualquier origen porque quien le manda tráfico es el Gateway # (fuera del cluster, vía cloud-provider-kind) o el propio web — no hay una # forma simple de acotar el ingreso del Gateway a un podSelector. # # El podSelector usa "role" (api.yaml/worker.yaml agregan ese label al Pod), # no "app": el Service api elige sus endpoints por "app: api", y un Pod de # prueba de esta NetworkPolicy con ese mismo label se metería como backend # real del Service y le robaría tráfico. apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: api namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: podSelector: matchLabels: role: api policyTypes: ["Ingress", "Egress"] ingress: - from: - ipBlock: cidr: 0.0.0.0/0 ports: - protocol: TCP port: 3000 egress: - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: {{ .Values.namespaceDatos }} ports: - protocol: TCP port: 5432 - protocol: TCP port: 6379 --- # worker sí sale a Internet a propósito: revisar sitios de terceros es su # trabajo. Lo único que se restringe es que no reciba tráfico entrante de # nadie (nadie le pega directo, ni el Gateway ni otro Pod: solo lo consume el # kubelet para las probes de :9464). apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: worker namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: podSelector: matchLabels: role: worker policyTypes: ["Egress"] egress: - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: {{ .Values.namespaceDatos }} ports: - protocol: TCP port: 5432 - protocol: TCP port: 6379 - {} # sin "to": cualquier destino — los sitios que monitorea son arbitrarios --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: migrar namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: podSelector: matchLabels: job-name: migrar policyTypes: ["Egress"] egress: - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: {{ .Values.namespaceDatos }} ports: - protocol: TCP port: 5432 --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: web namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: podSelector: matchLabels: app: web policyTypes: ["Ingress", "Egress"] ingress: - from: - ipBlock: cidr: 0.0.0.0/0 ports: - protocol: TCP port: 8080 egress: - to: - podSelector: matchLabels: role: api ports: - protocol: TCP port: 3000 --- # Deny por defecto en namespaceDatos: Postgres y Valkey no aceptan ni inician # nada que no esté permitido más abajo. apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-por-defecto namespace: {{ .Values.namespaceDatos }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: podSelector: {} policyTypes: ["Ingress", "Egress"] --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: permitir-dns namespace: {{ .Values.namespaceDatos }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: podSelector: {} policyTypes: ["Egress"] egress: - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system ports: - protocol: UDP port: 53 - protocol: TCP port: 53 --- # Postgres solo acepta conexiones de quien de verdad le habla: api, worker (los # dos con su propio Pool) y el Job migrar, todos en el namespace de la release. # Un Pod cualquiera sin ninguno de esos labels no matchea ninguna regla de # "from" y se cae por timeout. apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: postgres namespace: {{ .Values.namespaceDatos }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: podSelector: matchLabels: app: postgres policyTypes: ["Ingress"] ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: {{ .Release.Namespace }} podSelector: matchExpressions: - key: role operator: In values: ["api", "worker"] - namespaceSelector: matchLabels: kubernetes.io/metadata.name: {{ .Release.Namespace }} podSelector: matchLabels: job-name: migrar ports: - protocol: TCP port: 5432 --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: valkey namespace: {{ .Values.namespaceDatos }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: podSelector: matchLabels: app: valkey policyTypes: ["Ingress"] ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: {{ .Release.Namespace }} podSelector: matchExpressions: - key: role operator: In values: ["api", "worker"] ports: - protocol: TCP port: 6379 ``` `chart/pulso/templates/pdb.yaml`: ```yaml {{- if .Values.pdb.enabled }} # minAvailable de values.pdb.minAvailable (default 1), nunca igual a las # réplicas de arranque de la api (módulo 6: eso bloquearía cualquier drenado # por completo). Con 2 réplicas (values-prod.yaml) y minAvailable: 1, un drain # puede bajar UNA réplica sin que el PDB proteste; recién al intentar la # segunda, que dejaría 0 disponibles, el PDB corta la eviction. Gateado por # pdb.enabled porque con 1 réplica (values-dev.yaml) minAvailable == réplicas # bloquearía cualquier eviction del único Pod que hay. apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: api namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: minAvailable: {{ .Values.pdb.minAvailable }} selector: matchLabels: app: api {{- end }} ``` `chart/pulso/templates/hpa.yaml`: ```yaml {{- if .Values.hpa.enabled }} # Los dos HPA escalan por CPU (autoscaling/v2) contra el % de la request del # container (sin requests, TARGETS queda en y el HPA nunca decide # nada — api.yaml/worker.yaml siempre las declaran). worker arranca en su # único replica y sube con la carga de monitores contra el sitio lento # (carga/monitores.js); api ya corre en varias réplicas y sube con la carga de # lectura (carga/api.js). # # worker en 20%, no 50% (módulo 6, medido): en un runner de 2 vCPU compartidas # con todo el resto del cluster, la carga real de monitores.js sostuvo el # worker entre 37% y 52% de su request (75m) durante 5 minutos, pero el HPA # por defecto solo actúa si el uso supera el target en más del 10% # (--horizontal-pod-autoscaler-tolerance): contra un target de 50% hacía falta # pasar ~55% de forma sostenida, y el pico de 52% no alcanzó — REPLICAS quedó # en 1 toda la corrida. Con 20% (umbral real ~22% con la tolerancia) la misma # carga escala sin este ajuste. Gateado por hpa.enabled: sin HPA en dev # (values-dev.yaml), un replicas fijo no compite contra un controller que # también quiere decidir el número de réplicas. apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: worker namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: worker minReplicas: {{ .Values.hpa.worker.minReplicas }} maxReplicas: {{ .Values.hpa.worker.maxReplicas }} metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: {{ .Values.hpa.worker.targetCPUUtilizationPercentage }} behavior: scaleUp: stabilizationWindowSeconds: 0 policies: - type: Pods value: 2 periodSeconds: 15 --- apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: api namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: api minReplicas: {{ .Values.hpa.api.minReplicas }} maxReplicas: {{ .Values.hpa.api.maxReplicas }} metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: {{ .Values.hpa.api.targetCPUUtilizationPercentage }} behavior: scaleUp: stabilizationWindowSeconds: 0 policies: - type: Pods value: 2 periodSeconds: 15 {{- end }} ``` `chart/pulso/templates/sitio-lento.yaml`: ```yaml {{- if .Values.sitioLento.enabled }} # El mismo sitio-lento del ejercicio del módulo 2 (módulo 6, con el # securityContext que exige un namespace restricted): no es un componente # público de Pulso, solo genera la carga de CPU real que necesita el HPA del # worker. carga/monitores.js le da de alta N monitores al worker contra # /lento, que responde después de un delay fijo — eso es lo que le sube el uso # de CPU al worker, no el propio k6. apiVersion: apps/v1 kind: Deployment metadata: name: sitio-lento namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: replicas: 1 selector: matchLabels: app: sitio-lento template: metadata: labels: app: sitio-lento spec: enableServiceLinks: false # ServiceAccount "default", sin token montado: no le habla a la API. automountServiceAccountToken: false # runAsUser: 1000, no solo runAsNonRoot: la imagen de node declara "USER # node" (nombre, no UID numérico) y sin esto el kubelet rechaza el Pod. securityContext: runAsNonRoot: true runAsUser: 1000 seccompProfile: type: RuntimeDefault containers: - name: sitio-lento image: "{{ .Values.sitioLento.imagen }}:{{ .Values.sitioLento.tag }}" imagePullPolicy: {{ .Values.imagenes.pullPolicy }} command: ["node", "dist/sitio-lento/servidor.js"] env: - name: PORT value: "3001" ports: - name: http containerPort: 3001 securityContext: allowPrivilegeEscalation: false capabilities: drop: ["ALL"] readOnlyRootFilesystem: true readinessProbe: httpGet: path: /healthz port: http periodSeconds: 5 failureThreshold: 3 livenessProbe: httpGet: path: /healthz port: http periodSeconds: 10 failureThreshold: 3 resources: requests: cpu: 25m memory: 64Mi limits: cpu: 200m memory: 128Mi --- apiVersion: v1 kind: Service metadata: name: sitio-lento namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: selector: app: sitio-lento ports: - name: http port: 3001 targetPort: http --- # NetworkPolicy propia: sitio-lento solo acepta del worker (que es quien lo # chequea). Se elige por "role", igual que el resto de las NetworkPolicies del # chart (worker.yaml le pone role: worker al Pod). apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: sitio-lento namespace: {{ .Release.Namespace }} labels: {{- include "pulso.labels" . | nindent 4 }} spec: podSelector: matchLabels: app: sitio-lento policyTypes: ["Ingress"] ingress: - from: - podSelector: matchLabels: role: worker ports: - protocol: TCP port: 3001 {{- end }} ``` `README-k8s.md`: ````markdown # Pulso, listo para producción Un solo chart de Helm (`chart/pulso/`) con dos perfiles: `values-dev.yaml` (laboratorio, sin PSA estricta ni HPA) y `values-prod.yaml` (PSA `restricted`, HPA, PDB, Secrets sellados). `k8s/base/` y `k8s/overlays/dev/` quedan como referencia de la versión con Kustomize del módulo 4, **sin** el endurecimiento del módulo 6: no tienen `securityContext`, NetworkPolicies, PSA ni ServiceAccounts propias, y su `secret.yaml` es un placeholder de laboratorio en texto plano. Sirven para comparar con el chart, no para desplegar: para producción usá el chart. ## Instalar en desarrollo Un solo comando: el chart arma su propio Secret con la contraseña de laboratorio de `values.yaml` (`postgres.password`), y Postgres recibe esa misma contraseña. ```bash helm install pulso chart/pulso -f chart/pulso/values-dev.yaml \ --set namespaceDatos=pulso-dev-datos \ -n pulso-dev --create-namespace --wait=hookOnly --timeout 240s ``` `--set namespaceDatos=pulso-dev-datos`: el chart declara dos Namespaces, la de la release (`-n`) y la de los datos, que por defecto se llama `pulso-datos`. Si en el mismo cluster ya está (o estuvo) la release de producción, esa Namespace `pulso-datos` ya existe y es de la otra release: sin este `--set`, el install de dev corta por ownership de la Namespace, y si no cortara terminaría compartiendo namespace de datos con producción. Con su propio nombre, dev no toca nada de prod. `--wait=hookOnly` (no `--wait` a secas): el hook de migraciones (`post-install,pre-upgrade`) corre recién después de que Postgres, api, worker y web ya existen como recursos — con la estrategia `watcher` de `--wait` normal, Helm esperaría a que api/worker estén `Ready` ANTES de correr ese hook, y nunca lo van a estar sin que las migraciones hayan corrido (deadlock, ver "Errores comunes" en la lección del módulo 5). `kubectl rollout status` confirma la convergencia real después: ```bash kubectl -n pulso-dev-datos rollout status statefulset/postgres --timeout=180s kubectl -n pulso-dev rollout status deployment/api --timeout=180s kubectl -n pulso-dev rollout status deployment/worker --timeout=180s kubectl -n pulso-dev rollout status deployment/web --timeout=180s ``` ## Instalar en producción A diferencia de dev, los Secrets **no** los arma el chart (`values-prod.yaml` fija `secretoExistente: true`): tienen que existir ANTES del `helm install`, sellados con Sealed Secrets. Son dos, con la misma contraseña adentro, porque un Pod solo puede leer Secrets de su propia namespace y un `SealedSecret` queda atado a su namespace y su nombre: | Secret | Namespace | Clave | Quién lo lee | |---|---|---|---| | `pulso-secretos` | `pulso` | `DATABASE_URL` | api, worker y el Job `migrar` | | `postgres-secretos` | `pulso-datos` | `POSTGRES_PASSWORD` | el StatefulSet `postgres` (por `secretKeyRef`) | Con `secretoExistente: true` el chart no lee `postgres.password` (`values-prod.yaml` la deja vacía): la contraseña real no pasa por ningún values ni por `--set`, así que no queda en claro ni en el StatefulSet ni en el Secret de release que guarda Helm. 1. Instalar el controller de Sealed Secrets (una vez por cluster): ```bash kubectl apply -f https://github.com/bitnami/sealed-secrets/releases/download/v0.40.0/controller.yaml kubectl -n kube-system rollout status deployment/sealed-secrets-controller --timeout=120s ``` 2. Crear a mano las dos namespaces del chart (Sealed Secrets necesita que existan para poder aplicar cada `SealedSecret` ahí; el `helm install` del paso 4 las "adopta" con `--take-ownership`): ```bash kubectl create namespace pulso kubectl create namespace pulso-datos ``` 3. Generar la contraseña, sellar los dos Secrets y aplicar el resultado. El Secret plano nunca toca el disco: `kubectl create secret --dry-run=client` lo arma en memoria y se lo pasa a `kubeseal` por un pipe. No hay ningún archivo con la contraseña para editar, y por lo tanto ninguno que se pueda commitear por error. ```bash PGPASS="$(openssl rand -hex 24)" kubectl create secret generic pulso-secretos -n pulso \ --from-literal="DATABASE_URL=postgres://pulso:${PGPASS}@postgres.pulso-datos.svc:5432/pulso" \ --dry-run=client -o yaml \ | kubeseal --controller-namespace kube-system --controller-name sealed-secrets-controller \ --format yaml > sellado-pulso.yaml kubectl create secret generic postgres-secretos -n pulso-datos \ --from-literal="POSTGRES_PASSWORD=${PGPASS}" \ --dry-run=client -o yaml \ | kubeseal --controller-namespace kube-system --controller-name sealed-secrets-controller \ --format yaml > sellado-pulso-datos.yaml unset PGPASS kubectl apply -f sellado-pulso.yaml -f sellado-pulso-datos.yaml kubectl -n pulso get secret pulso-secretos # lo crea el controller, no vos kubectl -n pulso-datos get secret postgres-secretos # ídem ``` - `sellado-pulso.yaml` y `sellado-pulso-datos.yaml` **sí se commitean**: adentro solo hay texto cifrado que únicamente el controller de este cluster puede abrir. Son la fuente de verdad de los Secrets. - `openssl rand -hex 24` da 48 caracteres hexadecimales: la contraseña viaja adentro de una URL (`DATABASE_URL`) y el hex no necesita escaparse. Si elegís otra, que no tenga `@`, `:`, `/` ni `%`, o codificala para URL en el `DATABASE_URL` (y sin codificar en `POSTGRES_PASSWORD`). - El `-n` de `kubectl create secret` no es decorativo: `kubeseal` toma de ahí la namespace, que queda como parte de lo cifrado. Un `SealedSecret` sellado para `pulso` no se abre en `pulso-datos`. - Si querés guardar la contraseña fuera del cluster, que sea en un gestor de contraseñas, no en un archivo del repo. Si no, siempre podés leerla del Secret con `kubectl` (con permisos). 4. Instalar el chart: ```bash helm install pulso chart/pulso -f chart/pulso/values-prod.yaml \ -n pulso --wait=hookOnly --take-ownership --timeout 300s ``` `--take-ownership`: sin esto, `helm install` corta porque las Namespaces `pulso` y `pulso-datos` del paso 2 (el chart declara las dos) no tienen las anotaciones de propiedad que Helm exige para adoptar un recurso preexistente (mensaje real, sección "Errores comunes" de la lección). **Sin `--rollback-on-failure` acá**: combinado con `--wait=hookOnly`, Helm 4.3.0 fuerza la estrategia `watcher` internamente (`pkg/action/install.go`: `if i.WaitStrategy == kube.HookOnlyStrategy && i.RollbackOnFailure { ... = kube.StatusWatcherStrategy }`) — y `watcher` espera a que api/worker estén `Ready` ANTES de correr el hook de migraciones, que es justo lo que los deja `Ready`. Deadlock garantizado en el primer install (confirmado corriendo esta lección). `--rollback-on-failure` sí sirve, y sin trampa, en un `helm upgrade` posterior (ver más abajo): ahí Postgres ya está migrado. 5. Confirmar: ```bash kubectl get namespace pulso pulso-datos --show-labels # pod-security.kubernetes.io/enforce=restricted kubectl -n pulso get hpa kubectl -n pulso get pdb # La contraseña no está en el StatefulSet: POSTGRES_PASSWORD es un secretKeyRef kubectl -n pulso-datos get statefulset postgres \ -o jsonpath='{.spec.template.spec.containers[0].env[?(@.name=="POSTGRES_PASSWORD")]}' ``` ## Actualizar en producción ```bash helm upgrade pulso chart/pulso -f chart/pulso/values-prod.yaml \ --set imagenes.api.tag= --rollback-on-failure -n pulso --wait --timeout 240s ``` `--wait` a secas (no `hookOnly`) porque en un upgrade Postgres ya existe de una instalación anterior: el hook `pre-upgrade` no tiene que esperar nada que todavía no exista. Si algo sale mal: ```bash helm rollback pulso -n pulso --wait --timeout 240s ``` (sin número de revisión: vuelve a la anterior). ## Erratas conocidas (ver "Errores comunes" del módulo 8) - `values-prod.yaml` pisa solo lo que declara: si tu fork agrega una clave nueva a `values.yaml` sin ponerla también en `values-prod.yaml`, producción hereda el default de laboratorio. - Con `hpa.enabled: true`, los Deployments de api y worker NO declaran `replicas` (el chart lo omite a propósito): si lo agregás a mano en un `--set`, vas a pelearte con lo que decide el HPA en cada `helm upgrade`. - La NetworkPolicy `postgres`/`valkey` de `pulso-datos` solo deja pasar a los Pods con label `role` en `api`/`worker` o `job-name: migrar`: un componente nuevo que hable con la base necesita alguno de esos labels, o una regla nueva. - Un `SealedSecret` está cifrado con la clave **pública** del controller de Sealed Secrets de UN cluster específico, y solo la clave privada de ese controller (que nunca sale del cluster) lo desella: el mismo YAML sellado no sirve para otro cluster (hay que volver a sellar contra el controller de destino). - Los dos Secrets sellados tienen que llevar la MISMA contraseña. Si `pulso-secretos` y `postgres-secretos` no coinciden, Postgres arranca bien y el Job `migrar` falla con `password authentication failed`. - `POSTGRES_PASSWORD` solo se usa la primera vez, cuando la imagen inicializa un directorio de datos vacío. Con el PVC `datos-postgres-0` ya creado, volver a sellar con otra contraseña NO cambia la del servidor: primero `ALTER USER pulso PASSWORD '...'` adentro de Postgres, después los dos `SealedSecret` nuevos y un `kubectl rollout restart` de api y worker. - Con `secretoExistente: true` no pases `--set postgres.password=...`: el chart no la usa y el valor quedaría en claro en el Secret de release de Helm (`helm get values`). ````

## 6. Errores comunes - **`values-prod.yaml` que no pisa lo que creés.** `values-prod.yaml` solo declara las claves que cambian; todo lo demás lo hereda de `values.yaml`. Si agregás una clave nueva a `values.yaml` (por ejemplo, un límite de memoria más generoso) y te olvidás de reflejarla también en `values-prod.yaml` cuando el entorno de producción la necesita distinta, producción termina corriendo con el valor pensado para laboratorio — sin ningún error, sin ningún aviso. - **HPA y `replicas` fijo peleándose.** Ya lo viste en la sección 4.3: con `hpa.enabled: true`, si `api.yaml`/`worker.yaml` siguieran declarando `replicas:` con un número fijo, cada `helm upgrade`/`rollback` competiría con el HPA por ese mismo campo. La solución de este chart (omitir el campo del todo cuando hay HPA) es la forma general de evitarlo; no es exclusiva de Pulso. - **NetworkPolicy que deja afuera al Job de migraciones.** Es fácil escribir la política de ingreso de Postgres pensando solo en `api` y `worker` y olvidarse del Job: sus Pods llevan el label automático `job-name: migrar` (no `app`), así que una regla que solo mira `role in [api, worker]` lo deja afuera. Una NetworkPolicy se aplica al Pod entero, no a cada container: el Job vive en `pulso` y Postgres en `pulso-datos`, así que el corte ya le pega al `initContainer` `esperar-postgres`, antes de que la migración arranque. El síntoma esperable es un Pod `migrar` clavado en `Init:0/1`, con `pg_isready` reintentando contra un Postgres que está sano pero no le contesta, hasta que vence el `--timeout` del install. La NetworkPolicy `postgres` de este chart incluye explícitamente `job-name: migrar` como tercer `from` (sección 4.4; el criterio de NetworkPolicies de la sección 3 lo prueba: un pod con ese label sí llega). - **SealedSecret sellado para otro cluster.** Un `SealedSecret` está cifrado con la clave **pública** del controller de Sealed Secrets de un cluster específico, y solo la clave privada de ese mismo controller lo desella (módulo 6); ese mismo YAML aplicado en otro cluster (otro `kind create cluster`, un cluster de verdad distinto) no lo puede desencriptar nadie — `kubeseal` tiene que volver a correr contra el controller de destino. Migrar un clúster sin re-sellar es la causa más común de "el Secret nunca aparece" en el mundo real. - **Las dos contraseñas selladas no coinciden.** `pulso-secretos` y `postgres-secretos` se sellan por separado y nada comprueba que lleven la misma contraseña. Si difieren, Postgres arranca bien y el que falla es el Job `migrar`, con el `password authentication failed` de la Rotura 2 del módulo 7. Por eso el flujo usa una sola variable (`PGPASS`) para los dos comandos. - **Re-sellar con otra contraseña sobre un PVC que ya tiene datos.** La imagen de Postgres solo usa `POSTGRES_PASSWORD` cuando inicializa un directorio de datos vacío. Con el PVC `datos-postgres-0` ya creado, sellar de nuevo con otra contraseña no cambia la del servidor: primero un `ALTER USER pulso PASSWORD '...'` adentro de Postgres, después los dos `SealedSecret` nuevos y un `kubectl rollout restart` de api y worker. - **`--set postgres.password=...` en producción.** Con `secretoExistente: true` el chart no usa ese valor, pero Helm lo guarda igual: quedaría en claro en el Secret de release, a un `helm get values` de distancia. - **Namespace preexistente, sin las anotaciones de Helm (error real de una corrida).** El flujo de producción crea a mano las namespaces `pulso` y `pulso-datos` para que Sealed Secrets tenga dónde aplicar cada `SealedSecret` antes del `helm install`, y el chart declara las dos. Sin ningún flag extra, ese `helm install` corta en la primera que encuentra; con `pulso`, el mensaje es: ```text Error: INSTALLATION FAILED: unable to continue with install: Namespace "pulso" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "pulso"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "pulso" ``` Helm exige que un recurso preexistente tenga sus propias anotaciones de propiedad para "adoptarlo" — sin eso, se niega a arriesgarse a pisar algo que gestiona otra cosa. `--take-ownership` (confirmado en `helm install --help` de la v4.3.0: "install will ignore the check for helm annotations and take ownership of the existing resources") es la salida correcta, no un bypass de emergencia. - **`--rollback-on-failure` en el primer install, con un hook post-install (error real de una corrida).** El chart usa un hook `post-install,pre-upgrade` para las migraciones (heredado del módulo 5): con `--wait=hookOnly`, Helm espera solo al hook, dejando que api/worker se pongan `Ready` después, ya migrados. Agregar `--rollback-on-failure` a ese mismo install revienta esa lógica — confirmado contra el código fuente real de Helm 4.3.0 (`pkg/action/install.go`): ```go if i.WaitStrategy == kube.HookOnlyStrategy && i.RollbackOnFailure { i.WaitStrategy = kube.StatusWatcherStrategy } ``` Apenas `--rollback-on-failure` está activo, Helm **ignora** el `--wait=hookOnly` que pediste y fuerza la estrategia `watcher`, que sí espera a que `api`/`worker` estén `Ready` — antes de correr el hook que los migra. Deadlock hasta el timeout, seguido de un rollback automático que en un install nuevo es directamente un uninstall (visto en una corrida real: `resource Deployment/pulso/api not ready. status: InProgress, message: Available: 0/2`, `context deadline exceeded`, release desinstalada, ningún Job `migrar` llegó siquiera a crearse). La solución de este módulo: `--rollback-on-failure` no va en el primer install; sí funciona, sin ninguna trampa, en el `helm upgrade` sin cortes de los criterios de la sección 3 — ahí Postgres ya está migrado de instalaciones anteriores, así que la estrategia `watcher` no tiene nada que esperar. ## 7. Checkpoint del curso ```quiz titulo: Checkpoint — Curso 4, módulos 1 a 8 modo: examen preguntas: - tipo: opcion-multiple enunciado: >- En el módulo 1, un Pod de la api sin Postgres ni Valkey arriba terminó en CrashLoopBackOff, no en un Pod vivo respondiendo 503 en /readyz. ¿Por qué? opciones: - "listarMonitores(db) corre antes de app.listen; si falla, el proceso sale con process.exit(1) sin llegar a escuchar ningún puerto" - "Kubernetes mata cualquier Pod que tarde más de 30 segundos en arrancar, tenga o no probes configuradas, y lo vuelve a crear" - "/readyz devuelve siempre 503 mientras corre la startupProbe, y el kubelet toma ese 503 como un contenedor caído y lo reinicia" correcta: "listarMonitores(db) corre antes de app.listen; si falla, el proceso sale con process.exit(1) sin llegar a escuchar ningún puerto" explicacion: El diseño fail-fast de Pulso corta el arranque antes de escuchar, así que nunca hay un servidor vivo que pueda responder /readyz; el 503 solo se ve si la base se cae DESPUÉS de que la api ya está arriba. - tipo: opcion-multiple enunciado: "¿Por qué el Service del worker se llama worker-metricas y nunca metricas?" opciones: - "enableServiceLinks inyecta _PORT por cada Service del namespace; un Service metricas pisaría la variable METRICAS_PORT que ya usa el worker" - "Kubernetes rechaza los nombres de Service de menos de 10 caracteres, y metricas tiene 8: el prefijo worker- lo lleva al largo mínimo" - "metricas es un nombre reservado por el apiserver para el Service de metrics-server, y crear otro igual falla en cualquier namespace" correcta: "enableServiceLinks inyecta _PORT por cada Service del namespace; un Service metricas pisaría la variable METRICAS_PORT que ya usa el worker" explicacion: El riesgo existe apenas alguien cree un Service llamado metricas en el namespace, sin que nadie lo relacione con el worker. - tipo: opcion-multiple enunciado: >- Un Pod con una imagen mínima, sin shell ni herramientas de red, no arranca. El módulo 3 lo diagnostica igual. ¿Con qué herramienta, GA desde Kubernetes 1.25? opciones: - "kubectl debug, que agrega al Pod que falla un contenedor efímero con su propia imagen (con shell), sin rearmar la imagen original" - "kubectl exec --force, que ignora el entrypoint de la imagen y abre una shell que provee el kubelet del nodo donde corre el Pod" - "kubectl patch --debug, que reemplaza en caliente el contenedor que falla por otro con shell, conservando sus volúmenes y su red" correcta: "kubectl debug, que agrega al Pod que falla un contenedor efímero con su propia imagen (con shell), sin rearmar la imagen original" explicacion: Los contenedores efímeros comparten namespaces con el Pod (red, a veces procesos) sin modificar el spec original ni reconstruir nada. - tipo: opcion-multiple enunciado: >- api.yaml (módulo 4) fija maxUnavailable:0 y maxSurge:1. Con 2 réplicas, ¿qué es lo que impide directamente que el rollout deje menos de 2 Pods disponibles en algún momento? opciones: - "maxUnavailable:0 obliga a que el Pod nuevo (que crea maxSurge:1) pase su readinessProbe antes de bajar cualquier Pod viejo" - "El preStop de 5 s, que retrasa el SIGTERM real y así mantiene al Pod viejo contando como disponible durante todo el rollout" - "La startupProbe, que reinicia el Pod nuevo si tarda de más y por eso no deja que el Deployment avance con un Pod lento" correcta: "maxUnavailable:0 obliga a que el Pod nuevo (que crea maxSurge:1) pase su readinessProbe antes de bajar cualquier Pod viejo" explicacion: El preStop tapa la ventana de milisegundos del EndpointSlice y la startupProbe solo decide cuándo reiniciar un Pod que no arranca; el piso de disponibilidad durante todo el rollout lo fija la estrategia. - tipo: opcion-multiple enunciado: >- El Job migrar de este chart usa el hook post-install,pre-upgrade, no pre-install. ¿Por qué pre-install hubiera colgado el primer install? opciones: - "pre-install corre antes de que Helm cree cualquier recurso normal: el initContainer del Job esperaría con pg_isready un Postgres que todavía no existe" - "Helm 4 ignora los hooks pre-install en el primer install de una release y recién los corre a partir del primer upgrade, así que el Job nunca se crearía" - "Helm no permite hooks pre-install en charts con más de un Deployment, y corta el install con un error de validación antes de aplicar nada" correcta: "pre-install corre antes de que Helm cree cualquier recurso normal: el initContainer del Job esperaría con pg_isready un Postgres que todavía no existe" explicacion: "post-install corre después de que todos los recursos normales (Postgres incluido) ya están cargados en Kubernetes, así que el pg_isready del Job tiene sentido." - tipo: opcion-multiple enunciado: >- La Namespace pulso-datos lleva la anotación helm.sh/resource-policy: keep. Un helm uninstall de la release borra igual a Postgres y Valkey (sin esa anotación). ¿Qué protege entonces la anotación, si no evita que la base se caiga? opciones: - "Protege solo el objeto Namespace: así el PVC de Postgres, que creó el controller del StatefulSet y Helm no gestiona, no cae en un borrado en cascada" - "Impide que se cree cualquier Pod nuevo en esa namespace después del uninstall, para que nadie pise los datos hasta la próxima instalación" - "Deja a Postgres y Valkey en estado Terminating sin borrarse nunca, con lo que sus datos siguen accesibles hasta que alguien quite la anotación" correcta: "Protege solo el objeto Namespace: así el PVC de Postgres, que creó el controller del StatefulSet y Helm no gestiona, no cae en un borrado en cascada" explicacion: El módulo 5 lo comprobó con un uninstall + reinstall real. Lo que preserva los datos es el PersistentVolumeClaim, que Helm nunca gestionó; pero borrar la Namespace se lo hubiera llevado puesto igual, sin excepción, y por eso la anotación va en la Namespace. - tipo: respuesta-multiple enunciado: "¿Cuáles de estas afirmaciones sobre Pod Security restricted (módulo 6) son ciertas?" opciones: - "Con runAsNonRoot: true y una imagen que declara un USER no numérico (como node), el kubelet rechaza el Pod: no puede verificar estáticamente que ese usuario no sea root sin un runAsUser explícito" - postgres:18 y valkey/valkey:9.1 arrancan bajo restricted con un runAsUser explícito, sin necesitar un nivel más laxo como baseline - Todo Pod bajo restricted necesita automáticamente su propio ServiceAccount con RBAC asignado correctas: - "Con runAsNonRoot: true y una imagen que declara un USER no numérico (como node), el kubelet rechaza el Pod: no puede verificar estáticamente que ese usuario no sea root sin un runAsUser explícito" - postgres:18 y valkey/valkey:9.1 arrancan bajo restricted con un runAsUser explícito, sin necesitar un nivel más laxo como baseline explicacion: PSA no exige ServiceAccounts ni RBAC — son buenas prácticas aparte; sí exige runAsNonRoot, seccompProfile RuntimeDefault, capabilities drop ALL y allowPrivilegeEscalation false. - tipo: ordenar enunciado: >- Ordená el método de diagnóstico del módulo 7 frente a un objeto de Kubernetes que no converge, de la señal más superficial a la más profunda. pasos: - "helm status / helm history (¿qué revisión quedó activa, y con qué resultado?)" - "kubectl get events --sort-by=.lastTimestamp (¿qué pasó, en orden?)" - "kubectl describe (Events al final, con el mensaje completo)" - "condiciones del objeto (Ready, Programmed, Available, según el tipo)" - "kubectl logs (o logs --previous), el detalle que solo tiene el propio proceso" explicacion: Cada paso agrega una capa de detalle sobre el anterior; saltar directo a logs sin mirar events o describe suele hacerte reproducir a mano lo que Kubernetes ya registró. - tipo: opcion-multiple enunciado: >- El install de valores de producción de este módulo usa --wait=hookOnly, sin --rollback-on-failure, en un cluster nuevo. ¿Por qué agregar --rollback-on-failure ahí hubiera colgado el install? opciones: - "Helm 4.3.0 fuerza la estrategia watcher cuando --rollback-on-failure está activo e ignora --wait=hookOnly: espera api/worker Ready antes de correr el hook que los migra" - "--rollback-on-failure exige que el chart tenga un hook pre-install donde guardar el estado previo, y este chart solo declara post-install y pre-upgrade" - "--wait=hookOnly y --rollback-on-failure abren cada uno su propio watch contra el apiserver, y los dos watches se bloquean entre sí hasta el timeout" correcta: "Helm 4.3.0 fuerza la estrategia watcher cuando --rollback-on-failure está activo e ignora --wait=hookOnly: espera api/worker Ready antes de correr el hook que los migra" explicacion: Sin migrar, api y worker nunca llegan a Ready, así que watcher espera hasta el timeout. Confirmado contra pkg/action/install.go de Helm 4.3.0 y contra una corrida real de este módulo que terminó desinstalada por el timeout. - tipo: emparejar enunciado: Uní cada pieza del chart de este módulo con el problema que resuelve. pares: - - "replicas: omitido en api.yaml/worker.yaml cuando hpa.enabled: true" - "Evita que cada helm upgrade le pelee al HPA el campo spec.replicas, que el HPA cambia por su cuenta vía el subrecurso scale" - - "helm.sh/resource-policy: keep en namespace-datos.yaml" - "Evita que un helm uninstall borre la Namespace pulso-datos completa en cascada, llevándose puesto el PVC de Postgres que Helm nunca gestionó" - - "Label role (no app) en las NetworkPolicy de api/worker" - "Deja que un Pod de prueba herede la política real del componente sin volverse, por compartir el label app, un endpoint más del Service" - - "--take-ownership en el helm install de producción" - "Permite adoptar las Namespaces pulso y pulso-datos creadas a mano (para que Sealed Secrets tuviera dónde aplicar cada SealedSecret antes del install), que no tienen las anotaciones de propiedad que Helm exige" distractores: - "secretoExistente: true, que hace que el chart arme su propio Secret con la contraseña de values.yaml" explicacion: El distractor describe lo contrario de secretoExistente:true — ese value hace que el chart NO arme el Secret, porque ya existe. - tipo: caso escenario: >- Salida real de este módulo, tres momentos de la misma corrida: kubectl get hpa antes de lanzar la carga, y kubectl top pods seguido de kubectl get hpa a los 20 y a los 40 segundos (k6 con 80 monitores contra sitio-lento y 40 VUs de lectura contra /api/estado, los dos en paralelo). La request de CPU de la api es 50m y su límite 200m: lenguaje: text codigo: | antes: NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE api Deployment/api cpu: /50% 2 4 2 54s worker Deployment/worker cpu: /20% 1 4 1 54s 20s: NAME CPU(cores) MEMORY(bytes) api-7bb8fc8d9d-9n9dn 32m 35Mi api-7bb8fc8d9d-wwmhz 192m 58Mi sitio-lento-5597bbcdc-wddqf 7m 20Mi web-5569b59f58-mhnhv 1m 3Mi worker-6554cd79ff-sphhz 21m 48Mi NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE api Deployment/api cpu: /50% 2 4 2 74s worker Deployment/worker cpu: /20% 1 4 1 74s 40s: NAME CPU(cores) MEMORY(bytes) api-7bb8fc8d9d-9n9dn 198m 54Mi api-7bb8fc8d9d-wwmhz 199m 59Mi sitio-lento-5597bbcdc-wddqf 5m 20Mi web-5569b59f58-mhnhv 1m 3Mi worker-6554cd79ff-sphhz 34m 50Mi NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE api Deployment/api cpu: 397%/50% 2 4 4 94s worker Deployment/worker cpu: 45%/20% 1 4 2 94s preguntas: - tipo: opcion-multiple enunciado: "¿Por qué api llegó a 397% de su request de CPU mientras worker escaló con apenas 45% contra un target de 20%?" opciones: - "Cada HPA compara contra su propio target: 40 VUs llevan la api a su límite de 200m, cuatro veces su request de 50m; al worker le alcanza 45% porque su target es 20%" - "Los dos HPA comparten el mismo target de 50%: worker todavía no llegó a esa marca, y sus 2 réplicas salen de minReplicas y no de un escalado por CPU" - "api escaló más porque tiene más réplicas mínimas (minReplicas 2): el HPA multiplica el porcentaje medido por la cantidad de réplicas de arranque" correcta: "Cada HPA compara contra su propio target: 40 VUs llevan la api a su límite de 200m, cuatro veces su request de 50m; al worker le alcanza 45% porque su target es 20%" explicacion: "El porcentaje es uso sobre request: 198m y 199m contra 50m dan 397%. El target de worker es deliberadamente bajo (20%, no el 50% típico) porque la carga medida en el módulo 6 nunca sostenía más de ~50% de su request. minReplicas solo fija el piso de réplicas, no influye en el porcentaje." - tipo: opcion-multiple enunciado: "A los 20 segundos kubectl top pods ya mostraba consumo (192m en un Pod de api, 21m en el worker), pero los dos HPA seguían en . ¿Qué explicación es compatible con esa salida?" opciones: - "El HPA no lee kubectl top: calcula en su propio ciclo y descarta muestras de Pods recién iniciados o no Ready, así que puede seguir en con metrics-server ya respondiendo" - "metrics-server todavía no había hecho ningún scraping de esos Pods: sin una sola muestra de CPU disponible, ni kubectl top ni el HPA tienen nada que mostrar" - "Kubernetes oculta el porcentaje de CPU del HPA durante los primeros 30 segundos de carga de cualquier Deployment, y recién después lo publica en TARGETS" correcta: "El HPA no lee kubectl top: calcula en su propio ciclo y descarta muestras de Pods recién iniciados o no Ready, así que puede seguir en con metrics-server ya respondiendo" explicacion: "kubectl top sale de la misma Metrics API que consulta el HPA: si top ya muestra números, metrics-server tiene muestras, y eso descarta la explicación del scraping. La salida no dice cuál de los descartes del HPA se aplicó en esta corrida; lo que enseña es que significa que el HPA todavía no pudo calcular, no que el uso sea 0%." - tipo: caso escenario: >- Log real de este módulo (recortado al Pod que queda bloqueado), kubectl drain sobre el único nodo con el Deployment api recién bajado a mano de 4 a 2 réplicas y el PDB api (minAvailable: 1, ALLOWED DISRUPTIONS 1) vigente. El drain ya había evictado otros tres Pods de api y el resto del cluster: lenguaje: text codigo: | evicting pod pulso/api-7bb8fc8d9d-4v45n error when evicting pods/"api-7bb8fc8d9d-4v45n" -n "pulso" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget. (se repite hasta el timeout) error: unable to drain node "pulso-control-plane" due to error: [... global timeout reached: 30s] preguntas: - tipo: opcion-multiple enunciado: "El drain pudo evictar otros Pods de api sin problema, y recién se bloqueó en el último. ¿Por qué no se bloqueó de entrada?" opciones: - "Con minAvailable: 1 y 2 réplicas el PDB permite 1 disrupción voluntaria: la primera eviction deja 1 réplica disponible; la segunda dejaría 0, y ahí corta" - "El PDB recién empieza a proteger después de la primera eviction: la primera de cada Deployment pasa siempre, y desde la segunda se aplica minAvailable" - "Kubernetes garantiza al menos una eviction por Deployment en cada drain, sin importar el PDB, para que un nodo nunca quede imposible de vaciar" correcta: "Con minAvailable: 1 y 2 réplicas el PDB permite 1 disrupción voluntaria: la primera eviction deja 1 réplica disponible; la segunda dejaría 0, y ahí corta" explicacion: "ALLOWED DISRUPTIONS en kubectl get pdb refleja justo esa cuenta: con 2 réplicas y minAvailable 1, empieza en 1. Que en el log salgan tres Pods de api evictados y no uno es compatible con esa cuenta: el Deployment venía de bajar de 4 a 2, y un Pod que ya se está apagando no cuenta como disponible para el PDB, así que evictarlo no gasta presupuesto." - tipo: opcion-multiple enunciado: "Si minAvailable hubiera sido igual a las réplicas (2, en vez de 1), ¿qué hubiera pasado con el drain?" opciones: - "ALLOWED DISRUPTIONS hubiera sido 0 desde el arranque: ni la primera eviction de api hubiera podido proceder, y el drain se bloqueaba de entrada" - "No hay diferencia: el PDB solo mira la última réplica que queda en el nodo, así que el drain se hubiera bloqueado en el mismo Pod y momento" - "Kubernetes hubiera ignorado un PDB imposible de cumplir y evictado las dos réplicas igual, dejando un Warning en los eventos del namespace" correcta: "ALLOWED DISRUPTIONS hubiera sido 0 desde el arranque: ni la primera eviction de api hubiera podido proceder, y el drain se bloqueaba de entrada" explicacion: minAvailable == réplicas es el error clásico de un PDB mal calibrado (módulo 6) — bloquea CUALQUIER drenado, no solo el que dejaría el servicio caído. - tipo: caso escenario: >- Mensaje real de este módulo, un helm install pulso -f values-prod.yaml sin --take-ownership sobre una namespace pulso creada a mano con kubectl create namespace (para que Sealed Secrets tuviera dónde aplicar cada SealedSecret antes del install): lenguaje: text codigo: | Error: INSTALLATION FAILED: unable to continue with install: Namespace "pulso" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "pulso"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "pulso" preguntas: - tipo: opcion-multiple enunciado: "¿Por qué Helm rechazó instalar sobre una namespace que existía de antes, en vez de simplemente agregarle sus labels y seguir?" opciones: - "Helm exige que un recurso preexistente ya tenga sus anotaciones de propiedad para adoptarlo: prefiere cortar con un error antes que pisar algo que gestiona otra cosa" - "kubectl create namespace y helm install usan versiones distintas de la API de Namespace, y un objeto creado con una no se puede leer desde la otra" - "La Namespace pulso ya tenía el label de PSA restricted, y Helm se niega a instalar sobre cualquier namespace que ya traiga ese label puesto por otro" correcta: "Helm exige que un recurso preexistente ya tenga sus anotaciones de propiedad para adoptarlo: prefiere cortar con un error antes que pisar algo que gestiona otra cosa" explicacion: Es una protección general de Helm, no algo específico de Namespace ni de este chart — aplica a cualquier recurso que el chart declare y que ya exista sin las anotaciones de Helm. - tipo: opcion-multiple enunciado: "¿Qué flag de helm install resuelve esto, sin tener que borrar y recrear la namespace?" opciones: - "--take-ownership: le dice a Helm que ignore la falta de anotaciones y adopte el recurso preexistente igual" - "--force-replace: reemplaza el recurso preexistente por uno nuevo, con las anotaciones de Helm" - "--skip-schema-validation: desactiva la validación que rechazaba la namespace" correcta: "--take-ownership: le dice a Helm que ignore la falta de anotaciones y adopte el recurso preexistente igual" explicacion: "--force-replace resuelve un problema distinto (reemplazar un recurso incompatible); --skip-schema-validation es sobre JSON Schema de values, no sobre ownership de recursos existentes." ``` ## 8. Próximo curso Terminaste la ruta de Kubernetes con un chart real: dos entornos, seguro por defecto, que escala solo y se actualiza sin cortes. El próximo curso de la ruta DevOps es **Terraform y AWS** (tag `inicio-terraform-aws`): en vez de `kubectl apply`/`helm install` contra un cluster que ya existe, vas a describir la infraestructura misma — el cluster, la red, la base de datos — como código, con un state que hay que cuidar. El curso de **Observabilidad y GitOps** (tag `inicio-observabilidad-gitops`) también arranca desde el chart que dejaste acá: métricas y trazas más allá de `kubectl top`, y un cluster que se sincroniza solo contra tu repo en vez de recibir un `helm upgrade` manual. Podés hacer cualquiera de los dos primero.

Kubernetes

Contenido del curso:

Cursos previos