<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
    <channel>
      <title>kaikai&#039;s wiki</title>
      <link>https://wiki.kaikai.site</link>
      <description>最近的10条笔记 on kaikai&#039;s wiki</description>
      <generator>Quartz -- quartz.jzhao.xyz</generator>
      <item>
    <title>log</title>
    <link>https://wiki.kaikai.site/log</link>
    <guid>https://wiki.kaikai.site/log</guid>
    <description><![CDATA[ 操作日志 只追加，不修改。格式：## [YYYY-MM-DD] 操作类型 | 标题 快速查看最近操作：grep &quot;^## \[&quot; wiki/log.md | tail -10 [2026-04-13] init | wiki 初始化 创建目录结构、CLAUDE.md 模式文件、index.md、overview.md。 [2026-04-13] ingest | LLM Wiki — Andrej Karpathy 触及页面：sources/llm-wiki、topics/llm-wiki-pattern、topics/knowledge-management、entiti... ]]></description>
    <pubDate>Tue, 26 May 2026 06:02:06 GMT</pubDate>
  </item><item>
    <title>CloudNativePG</title>
    <link>https://wiki.kaikai.site/entities/cloudnativepg</link>
    <guid>https://wiki.kaikai.site/entities/cloudnativepg</guid>
    <description><![CDATA[  CloudNativePG 对我来说最重要的定位，不是“把 PostgreSQL 放进 Kubernetes 的工具”，而是一个会持续调和 PostgreSQL 集群状态的 Operator。它让数据库更云原生，但也要求运维者更清楚地理解 PV/PVC、Service、WAL 和副本状态之间的边界。 我怎么理解它 CloudNativePG 管的是 PostgreSQL 集群的控制面：实例创建、primary/replica 角色、Service、证书、存储卷、failover 和副本重建。它的价值在于把很多原本靠人手维护的数据库运行细节变成 Kubernetes 资源状态。 但这次恢复经验... ]]></description>
    <pubDate>Tue, 26 May 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>Kubernetes</title>
    <link>https://wiki.kaikai.site/entities/kubernetes</link>
    <guid>https://wiki.kaikai.site/entities/kubernetes</guid>
    <description><![CDATA[  我越来越把 Kubernetes 看成一套”调度语义系统”，而不是一个单纯跑容器的平台。它真正难的地方，经常不是 YAML 能不能 apply，而是资源、调度、控制器和云基础设施之间的因果关系有没有被想清楚。 在这个 wiki 中的重要性 Kubernetes 目前在这份 wiki 里主要连接四条线。 第一条是 API 与资源定义。kubernetes-api-groups-and-schema-validation 让我把 apiVersion、core API、GVK 和编辑器 schema 假阳性拆开看，提醒我不要为了让工具安静而篡改 Kubernetes API 身份。 第二条是平台... ]]></description>
    <pubDate>Tue, 26 May 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>整体综述</title>
    <link>https://wiki.kaikai.site/overview</link>
    <guid>https://wiki.kaikai.site/overview</guid>
    <description><![CDATA[ 这份 wiki 越往后写，我越清楚它不是“资料仓库”，而更像一条不断长出来的思考主线。起点当然是 llm-wiki-pattern：Karpathy 提醒我，真正有复利的不是一次次对着原始资料发问，而是把理解编译进一个会持续演化的知识系统。 但写到今天，这个系统已经明显不只是在谈知识管理。我能看到几条越来越清晰的技术主线在彼此靠拢：一条是 agent 如何设计、分层与运行；一条是搜索如何在本地、可迁移的前提下扩展；另一条则是数据库系统如何把“查询意图”真正翻译成高性能的访问路径。下面这部分不是冷冰冰的目录，而更像我最近这段时间在反复咀嚼的几组问题。 核心主题 目前 wiki 围绕一个核心方法论... ]]></description>
    <pubDate>Tue, 26 May 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>ACK 云盘存储卷快照与恢复指南</title>
    <link>https://wiki.kaikai.site/sources/ack-disk-volume-snapshots</link>
    <guid>https://wiki.kaikai.site/sources/ack-disk-volume-snapshots</guid>
    <description><![CDATA[ 这篇文章解决的核心问题是：在 ACK 里如何为云盘存储卷做备份，以及备份之后如何恢复。它不是讲传统的手动快照操作，而是把 Kubernetes 的 VolumeSnapshot API 和阿里云 ECS 快照能力衔接起来的完整工作流。 Kubernetes 快照的三层抽象 文档用一张表把三个资源类型的关系说得很清楚： 资源类比谁创建命名空间VolumeSnapshotContentPV管理员无VolumeSnapshotPVC操作员有VolumeSnapshotClassStorageClass管理员无 这个类比帮我理解了一个之前模糊的点：VolumeSnapshotContent 是后端的快... ]]></description>
    <pubDate>Tue, 26 May 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>ACK 动态云盘存储卷使用指南</title>
    <link>https://wiki.kaikai.site/sources/ack-dynamic-disk-volumes</link>
    <guid>https://wiki.kaikai.site/sources/ack-dynamic-disk-volumes</guid>
    <description><![CDATA[ 如果说静态卷是”先有车再上牌”，动态卷就是”按需造车”。这篇文章讲的是 ACK 里如何通过 StorageClass 让 CSI 自动创建云盘、自动绑定、自动挂载，整个过程对应用开发者几乎透明。 StorageClass 才是真正的决策点 很多人把注意力放在 StatefulSet 的 volumeClaimTemplates 上，但真正的选型发生在 StorageClass。它决定了：创建什么类型的云盘、用哪种绑定策略、删 PVC 时是否同时删盘、支不支持在线扩容。 文档里最推荐的默认 StorageClass 是 alicloud-disk-topology-alltype，它的关键参数是... ]]></description>
    <pubDate>Tue, 26 May 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>ACK 静态云盘存储卷使用指南</title>
    <link>https://wiki.kaikai.site/sources/ack-static-disk-volume</link>
    <guid>https://wiki.kaikai.site/sources/ack-static-disk-volume</guid>
    <description><![CDATA[ 这篇文章解决的核心问题是：当云盘已经存在时，如何在 ACK 集群里把它正确注册给 Pod 使用。它的思路不是动态创建，而是”先注册、再绑定、后挂载”，也就是 Kubernetes 里常说的静态卷模式。 什么场景适合静态卷 不是所有人都需要动态卷。如果你手里已经有一块云盘，或者需要把一块已有的数据盘复用到新集群里，静态卷是最直接的路径。典型场景包括：数据库迁移时需要保留原有磁盘、测试环境需要反复挂载同一块盘、或者云厂商侧已经有明确的磁盘配额规划。 静态卷的本质是：你在 Kubernetes 外部管理云盘的生命周期，在集群内部只做”声明和绑定”。 创建 PV：不只是填云盘 ID 文档里最让我意外的... ]]></description>
    <pubDate>Tue, 26 May 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>CNPG 事故恢复与存储策略复盘</title>
    <link>https://wiki.kaikai.site/sources/cnpg-recovery-incident</link>
    <guid>https://wiki.kaikai.site/sources/cnpg-recovery-incident</guid>
    <description><![CDATA[  这次复盘真正教我的不是某条 kubectl 命令，而是有状态系统里最容易被低估的一件事：控制器可以自动重建 Pod，但它不能替我判断哪块盘才是权威数据。 事故主线 这次问题从 CloudNativePG 管理的 PostgreSQL 实例磁盘空间不足开始。数据库实例因为低磁盘空间拒绝启动，随后又叠加了集群对象被重建、旧主库云盘使用 Delete 回收策略、部分旧副本盘仍被 Retain 保存等多个状态。真正的恢复入口不是“让 Operator 再试一次”，而是先确认哪些 PV 还存在、哪些 PVC 已经失效、哪一份数据可以作为恢复候选。 我更愿意把这个过程拆成三层：第一层是保全证据，先给仍在... ]]></description>
    <pubDate>Tue, 26 May 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>CloudNativePG 恢复与持久化策略</title>
    <link>https://wiki.kaikai.site/topics/cloudnativepg-recovery</link>
    <guid>https://wiki.kaikai.site/topics/cloudnativepg-recovery</guid>
    <description><![CDATA[  我现在会把 CloudNativePG 这类数据库 Operator 理解成“会帮你调和资源状态的控制面”，而不是“替你判断数据权威性的保险箱”。事故恢复时最危险的错觉，就是看到 Pod 被重建、Cluster 变 Ready，就以为数据路径已经正确。 先判断权威数据，再让控制器动作 CNPG 的优势是能把 PostgreSQL 实例、Service、证书、replica、PVC 这些资源统一纳入调和。但当事故牵涉到 PVC 删除、PV 回收策略、旧副本盘、快照恢复和 Service selector 临时切换时，第一步不是让 Operator “自动修”，而是先回答：哪一份数据是完整的，哪... ]]></description>
    <pubDate>Tue, 26 May 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>Kubernetes 持久化存储：静态卷、动态卷与快照的选择框架</title>
    <link>https://wiki.kaikai.site/topics/kubernetes-persistent-storage</link>
    <guid>https://wiki.kaikai.site/topics/kubernetes-persistent-storage</guid>
    <description><![CDATA[  在 Kubernetes 里用存储，表面上是写 YAML，实际上是做一系列不可逆的选型决策：云盘类型、绑定策略、回收行为、备份方式，以及这些选择对应用生命周期和运维成本的长期影响。 这篇文章不是某一类存储的教程，而是把 ack-static-disk-volume、ack-dynamic-disk-volumes、ack-disk-volume-snapshots 和一次 cnpg-recovery-incident 放到同一个判断框架里，回答一个问题：什么时候该用静态卷，什么时候该用动态卷，快照又该什么时候介入。 静态卷 vs 动态卷：核心差异不在技术，在生命周期所有权 维度静态卷动态卷云... ]]></description>
    <pubDate>Tue, 26 May 2026 00:00:00 GMT</pubDate>
  </item>
    </channel>
  </rss>