Kubernetes 1.35 Timbernetes Release

Introduction: Growing Stronger, Branch by Branch

The Kubernetes project closes 2025 with version 1.35, codenamed "Timbernetes" (The World Tree Release), inspired by Yggdrasil from Norse mythology—the tree of life connecting multiple realms. This release delivers 60 enhancements across 17 stable, 19 beta, and 22 alpha features.

Released on December 17, 2025, approximately four months after Kubernetes 1.34 (Of Wind & Will), version 1.35 addresses critical production needs while pruning technical debt. The release focuses on zero-downtime operations, enhanced security, and AI/ML workload support—all while maintaining backward compatibility.

What's New

Release Statistics

• 60 total enhancements
  • 17 features graduated to Stable (GA)
  • 19 features promoted to Beta
  • 22 new Alpha features
• Release Team: Led by Drew Hagen with contributors from the global Kubernetes community
• Supported Until: Approximately December 2026 (based on the standard 1-year support window)

Release Theme: The World Tree

The "Timbernetes" theme reflects:

1. Deep Roots: Stable foundation maintained by global contributors
2. Strong Trunk: Core features reaching maturity (GA status)
3. Growing Branches: Beta and alpha features extending capabilities
4. Global Canopy: Community spanning enterprises, startups, and open-source contributors

As Drew Hagen, the 1.35 release lead, explained: "The project keeps growing into branches, and the product is rooting itself to be a very mature foundation for things like AI and edge going into the future."

Top 7 Features in 1.35

1. In-Place Pod Resource Updates (STABLE) ⭐

KEP: KEP-1287: In-Place Update of Pod Resources
Impact: Production game-changer

After 6 years in development (first proposed in 2019), you can now adjust CPU and memory resources without restarting Pods. This eliminates downtime for:

• AI/ML training jobs requiring dynamic resource scaling
• Stateful applications that can't tolerate restarts
• Edge computing workloads with complex dependencies

# In-place update → zero downtime
spec:
  containers:
  - name: app
    resources:
      requests:
        cpu: 200m  # Updated live via cgroups!

2. Pod Certificates for Workload Identity (BETA)

KEP: KEP-4317: Pod Certificates
Impact: Simplifies service mesh and zero-trust architectures

Native workload identity without external dependencies like cert-manager or SPIFFE/SPIRE. The kubelet now:

• Generates keys inside Pods
• Requests certificates via PodCertificateRequest
• Writes credential bundles to Pod filesystem
• Handles automated rotation

Use Cases:

• Pure mTLS flows without bearer tokens
• Service mesh identity without sidecars
• Compliance-friendly workload authentication

Limitation: Beta feature requires enabling PodCertificates feature gate.

3. Node Declared Features (ALPHA)

KEP: KEP-5328: Node Declared Features
Impact: Prevents scheduling failures due to feature mismatches

The Problem: When control planes enable new features but nodes lag (permitted by Kubernetes version skew policy), Pods requiring new features can land on incompatible older nodes.

The Solution: Nodes publish supported features via .status.declaredFeatures field. The scheduler and admission controllers validate compatibility before scheduling.

Example Scenario:

# Node reports its capabilities
apiVersion: v1
kind: Node
metadata:
  name: node-1
status:
  declaredFeatures:
  - name: "UserNamespaces"
    version: "1.35"
  - name: "InPlacePodVerticalScaling"
    version: "1.35"

4. Traffic Distribution: PreferSameNode (STABLE)

KEP: KEP-3015: PreferSameNode Traffic Distribution
Impact: Explicit control over traffic routing

The trafficDistribution field gets clearer semantics:

• PreferSameNode: Route to local endpoints first (new in 1.35)
• PreferSameZone: Route within availability zone (renamed from PreferClose)

Use Case: Latency-sensitive microservices requiring node-local communication.

apiVersion: v1
kind: Service
metadata:
  name: redis-cache
spec:
  trafficDistribution: PreferSameNode  # New option!
  selector:
    app: redis

5. Job API managedBy Field (STABLE)

KEP: KEP-4368: Job Managed By Mechanism
Impact: Clean delegation for multi-cluster job orchestration

Allows external controllers (like Kueue's MultiKueue) to handle Job status synchronization across clusters.

How It Works:

1. Management cluster creates Job
2. Worker cluster mirrors and executes Job
3. Status updates propagate back
4. Built-in Job controller doesn't interfere (delegated via managedBy)

Example:

apiVersion: batch/v1
kind: Job
metadata:
  name: ml-training-job
spec:
  managedBy: "kueue.x-k8s.io/multikueue"  # External controller
  template:
    spec:
      containers:
      - name: trainer
        image: ml-trainer:v2

Deprecations and Removals: Spring Cleaning

Kubernetes 1.35 removes technical debt to enable future innovation:

❌ IPVS Proxy Mode Deprecated

Migration Target: nftables-based kube-proxy
Timeline: Deprecation in 1.35, removal likely in 1.37+

Reason: IPVS (IP Virtual Server) is being replaced by nftables, the modern Linux packet filtering framework offering:

• Better performance
• Unified interface for filtering, NAT, and load balancing
• Active kernel development

Action Required: Test service mesh and network policies with nftables mode before migration deadline.

❌ cgroups v1 Support Deprecated

Migration Target: cgroups v2
Impact: Required for in-place Pod resource updates

Most modern distributions (RHEL 9+, Ubuntu 22.04+) use cgroups v2 by default. Older environments need OS upgrades.

Who Should Care About Kubernetes 1.35?

🎯 Platform Engineers

• In-place resource updates eliminate maintenance windows
• Node declared features prevent scheduling failures
• Traffic distribution provides fine-grained control

🎯 ML/AI Teams

• Dynamic vertical scaling for training jobs
• Gang scheduling (alpha) for distributed workloads (KEP-4671)
• Resource flexibility without restarts

🎯 Security Teams

• Pod certificates enable zero-trust architectures
• Constrained impersonation (alpha) prevents node spoofing (KEP-5284)
• Native mTLS without external certificate management

🎯 Edge Computing

• In-place updates for constrained environments
• OCI artifact volumes for read-only data (KEP-4639)
• Resource efficiency improvements

Upgrade Considerations

Pre-Upgrade Checklist

1. Review official deprecations
2. Verify cgroups v2 availability on nodes
3. Test nftables kube-proxy mode in staging
4. Check feature gates for beta features you want to enable
5. Review version skew policy

Recommended Upgrade Path

1.33 → 1.34 → 1.35

Do not skip versions to maintain supportability.

Testing Strategy

1. Upgrade one control plane node
2. Verify API server health
3. Upgrade remaining control plane nodes
4. Drain and upgrade worker nodes (rolling update)
5. Validate workload behavior

Table 1: Top 5 Production-Critical Stable Features

Table 2: Complete List of 17 Stable (GA) Features in Kubernetes 1.35

Table 3: Notable Beta Features in Kubernetes 1.35

Resources and Links

Official Documentation

• Kubernetes v1.35 Release Announcement
• Kubernetes 1.35 CHANGELOG
• Kubernetes Enhancement Proposals (KEPs)

Key KEPs Referenced

• KEP-1287: In-Place Update of Pod Resources (Stable)
• KEP-4317: Pod Certificates (Beta)
• KEP-5328: Node Declared Features (Alpha)
• KEP-3015: Traffic Distribution (Stable)
• KEP-4368: Job Managed By (Stable)

Community

• Kubernetes Slack
• SIG Release Mailing List
• Kubernetes Enhancement Tracking Board

Conclusion

Kubernetes 1.35 "Timbernetes" delivers on production-grade, zero-downtime operations while advancing AI/ML and edge computing capabilities. The graduation of in-place Pod resource updates alone justifies the upgrade for many production environments.

As the project matures, we see a shift from adding features to stabilizing existing capabilities and removing technical debt. The deprecation of IPVS and cgroups v1 reflects this maturity—Kubernetes is confident enough to prune old branches to strengthen the trunk.

Next up: Take the quiz!