Kubernetes 1.34 “Of Wind & Will”: novedades clave y cómo probarlas

El 27 de agosto de 2025, la CNCF lanzó Kubernetes 1.34, con nombre en clave “Of Wind & Will”. Este release refleja el esfuerzo de la comunidad por equilibrar el empuje del cambio (el “viento”) con la voluntad de mantener una plataforma estable y segura.

Incluye 58 mejoras: 23 llegaron a GA, 22 a beta y 13 se presentan como alfa. Y lo mejor: no hay deprecaciones disruptivas.

En este artículo te resumo las novedades más destacadas y te muestro cómo probarlas tú mismo en un clúster de laboratorio.

1. Pod-level resources (Beta)

Manifiesto completo

apiVersion: v1
kind: Pod
metadata:
  name: pod-podlevel-resources
spec:
  resourceClaims: []   # requerido aunque no uses claims
  containers:
  - name: main
    image: busybox
    command: ["sleep", "3600"]
  - name: sidecar
    image: busybox
    command: ["sleep", "3600"]
  # ? Nueva parte: recursos a nivel de Pod
  resources:
    requests:
      cpu: "500m"
      memory: "512Mi"
    limits:
      cpu: "1"
      memory: "1Gi"

Ventaja: más simple de gestionar cuando hay sidecars; el Pod usa un pool de recursos en lugar de repartirlos manualmente.

2. Horizontal Pod Autoscaler con tolerancias (Beta)

Deployment base

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: demo
        image: k8s.gcr.io/hpa-example
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 200m

HPA con tolerancias configuradas

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: demo-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1        # ? Grupo del recurso que quieres escalar
    kind: Deployment           # ? Tipo de recurso 
    name: demo-app             # ? Nombre EXACTO del Deployment
  minReplicas: 1
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15
      selectPolicy: Max
      tolerance: 0.05   # ? Tolerancia al subir (5%)
    scaleDown:
      stabilizationWindowSeconds: 60
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60
      selectPolicy: Min
      tolerance: 0.20   # ? Tolerancia al bajar (20%)

Ventaja: más agresivo al escalar hacia arriba, más conservador al reducir réplicas.

3. podReplacementPolicy en Jobs (GA)

Job completo

apiVersion: batch/v1
kind: Job
metadata:
  name: job-demo
spec:
  completions: 3
  parallelism: 1
  backoffLimit: 6
  # ? Parte importante: nueva política en 1.34
  podReplacementPolicy: TerminatingOrFailed
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: worker
        image: busybox
        command: ["sh", "-c", "echo Procesando; sleep 10; exit 1"]

Valores admitidos en podReplacementPolicy:

Failed

• Kubernetes crea el reemplazo en cuanto un Pod falla.
• El nuevo Pod puede arrancar incluso aunque el anterior siga en estado Terminating.
• Es el comportamiento clásico antes de 1.34.

TerminatingOrFailed

• Kubernetes espera a que el Pod anterior esté en estado Failed o totalmente Terminated antes de crear el reemplazo.
• Evita tener Pods solapados consumiendo recursos a la vez.
• Es la opción más segura para evitar sobrecarga en Jobs pesados.

(implícito) → Si no defines podReplacementPolicy, Kubernetes usa el valor por defecto Failed, manteniendo compatibilidad hacia atrás.

Ventaja: evita solapamientos de Pods y sobrecargas innecesarias.

4. Trazas de kubelet y API Server con OpenTelemetry (GA)

Configuración (apiserver)

Añade al manifest de kube-apiserver.yaml:

- --tracing-config-file=/etc/kubernetes/tracing.yaml

tracing.yaml de ejemplo

apiVersion: apiserver.config.k8s.io/v1alpha1
kind: TracingConfiguration
samplingRatePerMillion: 1000000   # 100% de requests
endpoint: "otel-collector.default.svc:4317"

Ventaja: observabilidad nativa para depurar latencias y cuellos de botella.

5. Dynamic Resource Allocation (GA)

ResourceClass

apiVersion: resource.k8s.io/v1alpha3
kind: ResourceClass
metadata:
  name: nvidia-gpu
driverName: nvidia.com/gpu-driver

ResourceClaim

apiVersion: resource.k8s.io/v1alpha3
kind: ResourceClaim
metadata:
  name: gpu-claim
spec:
  resourceClassName: nvidia-gpu

Pod que consume el claim

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-gpu
spec:
  resourceClaims:
  - name: my-gpu
    resourceClaimName: gpu-claim
  containers:
  - name: app
    image: nvidia/cuda:12.2.0-base
    command: ["nvidia-smi"]
    resources:
      claims:
      - name: my-gpu

Ventaja: Kubernetes gestiona GPUs y hardware especial de forma estándar.

6. KYAML (Alpha)

• Subconjunto de YAML más estricto (evita ambigüedades).
• En 1.34 está en alpha y no usable con kubectl -o kyaml por defecto.

Ejemplo comparativo

YAML clásico (ambiguo):

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  labels:
    debug: on    # ¿boolean o string?
spec:
  containers:
  - name: busy
    image: busybox
    command: [sleep, 3600]

KYAML equivalente (estricto):

apiVersion: "v1"
kind: "Pod"
metadata:
  name: "test-pod"
  labels:
    debug: "on"   # explícitamente string
spec:
  containers:
  - name: "busy"
    image: "busybox"
    command:
    - "sleep"
    - "3600"

Ventaja: elimina ambigüedades en los manifiestos; lo que ves es exactamente lo que interpreta Kubernetes.

Conclusiones

Kubernetes 1.34 “Of Wind & Will” no rompe nada, pero introduce mejoras que marcan tendencia:

• GA: podReplacementPolicy, OpenTelemetry tracing, DRA.
• Beta: Pod-level resources, HPA tolerances.
• Alpha: KYAML, de momento experimental.

Mi consejo:

• Empieza a usar ya las de GA.
• Prueba en staging las de Beta.
• Ten en el radar KYAML para el futuro.