<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Kubernetes on 知识铺的博客</title>
    <link>https://index.zshipu.com/geek001/tags/kubernetes/</link>
    <description>Recent content in Kubernetes on 知识铺的博客</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>zh-CN</language>
    <lastBuildDate>Thu, 03 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://index.zshipu.com/geek001/tags/kubernetes/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>PB级Hudi数据湖流水线：用队列等待时间取代偏移量延迟</title>
      <link>https://index.zshipu.com/geek001/post/20260903/PB%E7%BA%A7Hudi%E6%95%B0%E6%8D%AE%E6%B9%96%E6%B5%81%E6%B0%B4%E7%BA%BF%E7%94%A8%E9%98%9F%E5%88%97%E7%AD%89%E5%BE%85%E6%97%B6%E9%97%B4%E5%8F%96%E4%BB%A3%E5%81%8F%E7%A7%BB%E9%87%8F%E5%BB%B6%E8%BF%9F/</link>
      <pubDate>Thu, 03 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://index.zshipu.com/geek001/post/20260903/PB%E7%BA%A7Hudi%E6%95%B0%E6%8D%AE%E6%B9%96%E6%B5%81%E6%B0%B4%E7%BA%BF%E7%94%A8%E9%98%9F%E5%88%97%E7%AD%89%E5%BE%85%E6%97%B6%E9%97%B4%E5%8F%96%E4%BB%A3%E5%81%8F%E7%A7%BB%E9%87%8F%E5%BB%B6%E8%BF%9F/</guid>
      <description>偏移量延迟在PB级Hudi流水线中已失效 在PB级数据湖环境中，传统偏移量延迟指标已经无法准确反映真实队列等待时间。Hudi作为主流的开源数据湖表格式，在处理海量增量数据时，偏移量延迟原本用于衡量从Kafka等消息队列到Hudi表的端到端延迟。但当数据规模达到PB级别，每天处理数万</description>
    </item>
    <item>
      <title>2026 年生产级 Node.js &#43; Express 后端该如何分层与选型</title>
      <link>https://index.zshipu.com/geek001/post/20260902/2026-%E5%B9%B4%E7%94%9F%E4%BA%A7%E7%BA%A7-Node.js-Express-%E5%90%8E%E7%AB%AF%E8%AF%A5%E5%A6%82%E4%BD%95%E5%88%86%E5%B1%82%E4%B8%8E%E9%80%89%E5%9E%8B/</link>
      <pubDate>Wed, 02 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://index.zshipu.com/geek001/post/20260902/2026-%E5%B9%B4%E7%94%9F%E4%BA%A7%E7%BA%A7-Node.js-Express-%E5%90%8E%E7%AB%AF%E8%AF%A5%E5%A6%82%E4%BD%95%E5%88%86%E5%B1%82%E4%B8%8E%E9%80%89%E5%9E%8B/</guid>
      <description>大多数 Node.js 教程停留在 app.get(&amp;rsquo;/&amp;rsquo;, &amp;hellip;)。真正项目一落地，代码库达到 40 个文件，所有逻辑却挤在 800 行的 index.js 里。经过数十个生产后端评审后，真正让项目可维护的结构和关键决策就此展开。 真实的生产后端从来不是把路由堆在一起就能跑通。代码膨胀后，调试一次 bug 要翻三四个文件，改一个字段要全局搜索替换，</description>
    </item>
    <item>
      <title>JDK 27 与 JDK 28 已知信息汇总：特性、性能和升级路径</title>
      <link>https://index.zshipu.com/geek001/post/20260902/JDK-27-%E4%B8%8E-JDK-28-%E5%B7%B2%E7%9F%A5%E4%BF%A1%E6%81%AF%E6%B1%87%E6%80%BB%E7%89%B9%E6%80%A7%E6%80%A7%E8%83%BD%E5%92%8C%E5%8D%87%E7%BA%A7%E8%B7%AF%E5%BE%84/</link>
      <pubDate>Wed, 02 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://index.zshipu.com/geek001/post/20260902/JDK-27-%E4%B8%8E-JDK-28-%E5%B7%B2%E7%9F%A5%E4%BF%A1%E6%81%AF%E6%B1%87%E6%80%BB%E7%89%B9%E6%80%A7%E6%80%A7%E8%83%BD%E5%92%8C%E5%8D%87%E7%BA%A7%E8%B7%AF%E5%BE%84/</guid>
      <description>InfoQ 文章标题直接写明《关于 JDK 27 和 JDK 28，我们目前都知道些什么》，链接指向的正是对这两个版本已知信息的汇总。这篇报道没有等待正式 GA，而是提前把可公开讨论的内容整理出来，说明社区已经掌握部分确定线索。 目前 JDK 27 和 JDK 28 的正式发布日期尚未敲定，但 OpenJDK 社区的讨论已经产出若干可公开的 JEP 草案和提案</description>
    </item>
    <item>
      <title>JDK 27-RC1 发布，多项 JEP 针对微服务并发优化</title>
      <link>https://index.zshipu.com/geek001/post/20260902/JDK-27-RC1-%E5%8F%91%E5%B8%83%E5%A4%9A%E9%A1%B9-JEP-%E9%92%88%E5%AF%B9%E5%BE%AE%E6%9C%8D%E5%8A%A1%E5%B9%B6%E5%8F%91%E4%BC%98%E5%8C%96/</link>
      <pubDate>Wed, 02 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://index.zshipu.com/geek001/post/20260902/JDK-27-RC1-%E5%8F%91%E5%B8%83%E5%A4%9A%E9%A1%B9-JEP-%E9%92%88%E5%AF%B9%E5%BE%AE%E6%9C%8D%E5%8A%A1%E5%B9%B6%E5%8F%91%E4%BC%98%E5%8C%96/</guid>
      <description>JDK 27-RC1 包含哪些可立即落地的改动 JDK 27-RC1 已经发布。这意味着开发者可以立即下载测试版，在生产环境升级前验证兼容性。RC1 阶段通常已冻结大部分特性，重点修复 bug 并优化稳定性。国内团队常在 Spring Boot 或自家微服务框架上跑 JDK 17/21，此次升级能直接获得更好的虚拟线程支持和垃圾回收调优。 具体改动集中在几个</description>
    </item>
    <item>
      <title>Kubernetes不会修复破碎团队，只会把问题放大</title>
      <link>https://index.zshipu.com/geek001/post/20260902/Kubernetes%E4%B8%8D%E4%BC%9A%E4%BF%AE%E5%A4%8D%E7%A0%B4%E7%A2%8E%E5%9B%A2%E9%98%9F%E5%8F%AA%E4%BC%9A%E6%8A%8A%E9%97%AE%E9%A2%98%E6%94%BE%E5%A4%A7/</link>
      <pubDate>Wed, 02 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://index.zshipu.com/geek001/post/20260902/Kubernetes%E4%B8%8D%E4%BC%9A%E4%BF%AE%E5%A4%8D%E7%A0%B4%E7%A2%8E%E5%9B%A2%E9%98%9F%E5%8F%AA%E4%BC%9A%E6%8A%8A%E9%97%AE%E9%A2%98%E6%94%BE%E5%A4%A7/</guid>
      <description>项目团队宣称“用Kubernetes解决所有部署问题”，六个月后同样问题依旧，还多了一个没人完全理解的昂贵集群。工具本身没问题，暴露的是团队组织缺陷：Kubernetes不会修复破碎的团队，只会把问题放大。 许多中国企业引入Kubernetes时，都带着类似期待。运维痛点堆积多年，</description>
    </item>
    <item>
      <title>OVHcloud因AI内存挤压上调服务价格 非AI基础设施成本传导</title>
      <link>https://index.zshipu.com/geek001/post/20260902/OVHcloud%E5%9B%A0AI%E5%86%85%E5%AD%98%E6%8C%A4%E5%8E%8B%E4%B8%8A%E8%B0%83%E6%9C%8D%E5%8A%A1%E4%BB%B7%E6%A0%BC-%E9%9D%9EAI%E5%9F%BA%E7%A1%80%E8%AE%BE%E6%96%BD%E6%88%90%E6%9C%AC%E4%BC%A0%E5%AF%BC/</link>
      <pubDate>Wed, 02 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://index.zshipu.com/geek001/post/20260902/OVHcloud%E5%9B%A0AI%E5%86%85%E5%AD%98%E6%8C%A4%E5%8E%8B%E4%B8%8A%E8%B0%83%E6%9C%8D%E5%8A%A1%E4%BB%B7%E6%A0%BC-%E9%9D%9EAI%E5%9F%BA%E7%A1%80%E8%AE%BE%E6%96%BD%E6%88%90%E6%9C%AC%E4%BC%A0%E5%AF%BC/</guid>
      <description>OVHcloud 将上调服务价格，根源是 AI 内存需求推高了非 AI 基础设施成本。这家欧洲云厂商的决定，直接把算力资源挤压传导到普通用户身上，服务器与存储租赁费用即将上涨。 OVHcloud 涨价覆盖哪些服务及涨幅 OVHcloud 明确表示将提高部分云服务价格，主要涉及服务器租赁、存储服务以及相关基础设施托管产品。根据公开信息，此次调整</description>
    </item>
  </channel>
</rss>
