Java基础、中级、高级、架构面试资料
    你的位置：业余草 > 业余杂谈 > 苦等6年，K8s 1.35正式GA发布，支持原地扩缩容，Java启动提速70%！

    苦等6年，K8s 1.35正式GA发布，支持原地扩缩容，Java启动提速70%！

    业余杂谈 herman 26浏览
    公告：“业余草”微信公众号提供免费CSDN下载服务(只下Java资源)，关注业余草微信公众号，添加作者微信：xttblog2，发送下载链接帮助你免费下载！
    本博客日IP超过2000，PV 3000 左右，急需赞助商。
    极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
    受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
    所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
    视频教程免费领
    腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云

    不知道大家最近有没有注意到 CNCF 发布的重磅消息，Kubernetes 1.35 正式发布，代号为“Timbernetes”。

    这个 GA 的版本包含 60 项增强功能，其中 22 项为 Alpha 特性，19 项晋升为 Beta，17 项达到通用可用或稳定状态，同时还包含若干弃用和移除内容。

    这其中，最让我兴奋的是，Pod 原地扩缩容特性。要知道这个特性经历了 6 年打磨，现在 K8S 1.35 终于将 Pod 原地扩缩容（In-Place Pod Resize）推至正式版本了。这一革命性特性将彻底改变我们管理应用资源的方式，尤其是对 Java 开发者来说，意味着再也不用为 JVM 启动时的资源浪费而头疼了！

    所以，接下来，我们就一起来了解、学习和解读一下这个新特性吧。

    Kubernetes 1.35 核心亮点

    2025 年 12 月，Kubernetes 社区正式发布 v1.35 版本。虽然这个版本包含多项改进，但最引人注目的无疑是In-Place Pod Resize特性从 Beta 毕业到 Stable（GA）状态。

    这意味着什么？简单来说：你可以在不重启 Pod 的情况下，动态调整容器的 CPU 和内存资源！

    彻底告别过去“一改配置就要重启”的痛苦时代，K8S 终于实现了真正的“热扩容”能力。

    接下来，我们重点就放在 In-Place Pod Resize 详解上吧。先来了解一下什么是原地扩缩容？

    原地扩缩容

    在过去，一旦 Pod 创建成功，resources.requests 和 resources.limits 就变成了“铁律”，任何修改都逃不过“删 Pod → 重建”的命运。对于 Stateful 应用、实时服务或有状态批处理任务，这种中断简直就是噩梦。

    而现在的In-Place Pod Resize特性的核心突破在于无需重启即可完成资源的再分配。

    # 旧方式：修改资源 = 必须重启 Pod
kubectl patch pod my-app --patch '{"spec":{"containers":[{"name":"app","resources":{"requests":{"cpu":"2"}}}]}}'
# 结果：Pod 被终止，新 Pod 调度启动（中断服务）

# 新方式：直接调整，无需重启
kubectl patch pod my-app --subresource=resize --patch '{"spec":{"containers":[{"name":"app","resources":{"requests":{"cpu":"2"}}}]}}'
# 结果：容器资源配置实时更新，业务零中断！

    工作原理揭秘

    要完成不用重启就能实现原地扩缩容，Kubernetes 1.35 引入了两个关键概念。

    1. Desired Resources（期望资源）：spec.containers[*].resources 现在代表“你想要的目标”，CPU 和内存字段完全可变
    2. Actual Resources（实际资源）：status.containerStatuses[*].resources 显示“当前生效的配置”

    当你通过 resize 子资源提交变更后。

    • Kubelet 接收到调整请求
    • 调用容器运行时（如 containerd）修改 cgroup 限制
    • 容器进程立即在新资源边界内运行
    • 无需重启容器，业务无感知！

    做个运维或使用过 k8s 的应该知道这个功能有多香。因为它有不少使用场景，下面我们简单展开说说。

    五大核心使用场景

    根据官方博客和社区实践，这个特性解锁了以下革命性场景。

    游戏服务器的弹性伸缩

    在线游戏玩家数量波动巨大。白天需要 8 核 CPU 支撑高峰，深夜玩家寥寥，可缩减至 2 核。现在无需重启游戏服务器进程，即可平滑调整资源。

    预热 Worker 的智能调度

    机器学习训练集群中，预加载数据的 Worker 在空闲时可压缩资源，任务到达瞬间扩容。资源利用率提升 40% 以上不再是梦。

    JIT 编译的启动加速

    这正是 Java 开发者的福音！Java 程序启动阶段需要大量 CPU 进行类加载和即时编译，启动完成后需求骤降。现在可以为启动阶段分配 4 核，30 秒后自动降至 1 核，既保证快速启动又节省成本。

    动态负载适应

    Web 服务在促销活动期间 CPU 飙升，活动结束立即回缩。配合 VPA（Vertical Pod Autoscaler），实现秒级响应的垂直自动扩缩容。

    内存限制的精细化控制

    v1.35 新特性支持降低内存 limits。虽然有一定风险（需要确保当前使用量低于新限制），但为内存优化提供了更大灵活性。

    对 Java 开发者的超级利好

    作为 Java 开发者，这个特性简直是量身定制！让我们看看这其中的具体优势。

    痛点迎刃而解

    过去存在的一些问题。

    • JVM 启动慢：类加载、JIT 编译需要大量 CPU，但启动后需求下降
    • 资源浪费：为启动峰值预留的资源，在运行时被闲置
    • 优化困难：无法区分“启动资源”和“运行资源”，只能一刀切
    • 在云原生时代，Java 启动慢总是被诟病

    现在多出了一些新的解决方案。

    # 示例：Java 应用的智能资源分配
apiVersion: v1
kind: Pod
metadata:
  name: java-app
  annotations:
    # 使用 VPA 的 CPU Startup Boost 功能
    vpa.kubernetes.io/startup-cpu-boost: "true"
spec:
  containers:
  - name: java-app
    image: my-java-app:1.0
    resources:
      requests:
        cpu: "500m"      # 正常运行需求
        memory: "1Gi"
      limits:
        cpu: "1"         # 正常运行上限
        memory: "2Gi"
    env:
    - name: JAVA_OPTS
      value: "-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0"

    CPU Startup Boost

    CPU Startup Boost，这可是启动加速的黑科技。

    目前，社区正在推进的AEP-7862提案（Vertical Pod Autoscaler CPU Startup Boost）完美配合 In-Place Resize。

    • 启动阶段：自动将 CPU 提升至 4 核，JVM 以火箭速度完成预热
    • 预设时间后（如 60 秒）：平滑降至正常运行配置（如 1 核）
    • 全程无中断：业务在容器内持续运行，只是资源配置动态变化

    实测效果。

    • Spring Boot 应用启动时间缩短50%-70%
    • 资源成本降低30%-50%（按实际使用量计费）
    • 再也不用担心 OOMKilled 或 CPU 饥饿！

    但也需要注意，一些线程池、资源池等，启动时按 CPU 个数计算，缩小资源后，对应的资源池等可能不会跟着缩减。现在是虚拟线程时代了，也是时候抛弃一些平台线程池了。

    实战

    下面，我们看一个 Java 应用启动优化完整方案。

    前提条件

    • Kubernetes 集群版本 ≥ 1.35
    • VPA 组件已部署（支持 In-Place Resize 的版本）
    • 节点内核支持 cgroup v2（推荐）

    方案一：使用 VPA 自动模式（推荐）

    步骤 1，部署 VPA。

    # 安装支持 In-Place Resize 的 VPA
kubectl apply -f https://github.com/kubernetes/autoscaler/releases/download/vertical-pod-autoscaler-1.4.0/vpa-v1.4.0.yaml

    步骤 2，配置 StartupCPU Boost。

    apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: java-app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: java-app
  updatePolicy:
    updateMode: "InPlaceOrRecreate"  # Beta 版本已支持
  resourcePolicy:
    containerPolicies:
    - containerName: java-app
      startupCpuBoost:
        enabled: true
        boostDuration: "60s"          # 提升持续 60 秒
        minCpu: "4"                   # 启动时最小 CPU
        targetCpu: "8"                # 启动时目标 CPU

    接下来，就是观察效果了。

    # 查看 Pod 资源变化
kubectl describe pod java-app-xxx

# 关注 Events 中的 Resize 事件
# Normal  InPlacePodResized  Successfully resized Pod java-app-xxx

    方案二：手动控制

    这个方案适合手动控制的场景，适合定制化场景。Java 应用启动时需要 4 核，启动后降为 1 核。

    # 1. 创建 Pod（启动配置）
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: java-app-manual
spec:
  containers:
  - name: java-app
    image: openjdk:17-jre
    command: ["java", "-jar", "/app/myapp.jar"]
    resources:
      requests:
        cpu: "4"          # 启动时高配置
        memory: "2Gi"
      limits:
        cpu: "4"
        memory: "2Gi"
EOF

# 2. 等待应用启动完成（通过健康检查或日志判断）
kubectl wait --for=condition=Ready pod/java-app-manual --timeout=300s

# 3. 关键操作：执行原地缩容
kubectl patch pod java-app-manual --subresource=resize --patch '{"spec":{"containers":[{"name":"java-app","resources":{"requests":{"cpu":"1"},"limits":{"cpu":"1"}}}]}}'

# 4. 验证调整
kubectl get pod java-app-manual -o yaml | grep -A 5 status:

    方案三：Application Controller 自动化

    编写自定义 Operator，监听应用启动事件，自动触发缩容。

    // 伪代码示例
public class StartupOptimizer {
    public void onApplicationReadyEvent() {
        // 应用启动完成后调用 K8s API
        k8sClient.pods().withName("my-pod")
            .resize(new ResourceRequirementsBuilder()
                .addToRequests("cpu", new Quantity("1"))
                .addToLimits("cpu", new Quantity("1"))
                .build());
    }
}

    最佳实践与注意事项

    一般来说，推荐的做法如下。

    1. 始终设置 requests 和 limits：确保 QoS 等级明确
    2. 配合 VPA 使用：利用 InPlaceOrRecreate 模式实现智能化
    3. 监控 Resize 事件：建立告警机制，跟踪资源调整
    4. 测试你的应用：验证应用在资源变化下的稳定性
    5. 使用 CPU Startup Boost：Java 应用启动优化的黄金搭档

    但也需要避免注意以下事项。

    1. 不要过度依赖内存缩容：降低内存限制可能导致 OOMKill，务必确保使用量低于新限制
    2. 避免频繁震荡：设置合理的调整阈值，防止资源抖动
    3. 注意运行时限制：Java 目前不支持内存热调整（需重启），但 CPU 完全支持
    4. 不兼容场景：Swap、static CPU Manager、static Memory Manager 目前仍不支持

    总结与展望

    Kubernetes 1.35 的 In-Place Pod Resize GA 标志着云原生资源管理进入精细化、动态化的新纪元。对 Java 开发者而言。

    • 启动速度可能不再是瓶颈：通过 CPU Startup Boost，JVM 启动时间大幅缩短
    • 成本效益最大化：精准匹配应用生命周期资源需求
    • 运维负担减轻：告别为”峰值”预留资源的浪费模式

    对于接下来的一些新特性未来依然可期。

    • VPA 的 InPlace 模式即将 GA
    • Java 运行时内存热调整已在 OpenJDK 社区讨论（JDK-8359211）
    • 与 Ray、Agent-sandbox 等项目深度集成

    以上，对于有动态所扩容的可以升级试一试，期待大家都有好的体验。

    参考资料

    • 官方文档：调整容器资源https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/
    • VPA In-Place 更新提案 AEP-4016https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler/enhancements/4016-in-place-updates-support
    • CPU Startup Boost 提案 AEP-7862https://github.com/kubernetes/autoscaler/pull/7863
    • https://bugs.openjdk.org/browse/JDK-8359211

    业余草公众号

    最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！

    本文原文出处：业余草： » 苦等6年，K8s 1.35正式GA发布，支持原地扩缩容，Java启动提速70%！

    相关文章推荐