In-Tree到Out-of-Tree迁移体现设计正确性向现实兼容性的妥协

Kubernetes早期内置了大量In-Tree（代码写在Kubernetes代码树里）存储驱动， 这个策略在诞生初期是有意义的——能在云存储提供商发布官方驱动之前就把 支持能力加进来、减轻管理员维护负担，帮Kubernetes快速占领市场。但它的 代价随时间显现：驱动只能跟着Kubernetes大版本发布节奏更新，云存储提供商 被迫迁就Kubernetes的节奏；第三方存储代码混进Kubernetes二进制文件本身， 也带来可靠性和安全性隐患。从1.14版本起，Kubernetes启动In-Tree驱动向 Out-of-Tree（基于[[FlexVolume与CSI两代存储扩展机制的能力差距]]里的CSI 规范）的迁移，计划到1.²¹⁄₁.22版本（约2021年中）让AWS EBS、GCE PD、 vSphere等主要驱动全部改为Out-of-Tree实现。但这个”设计上无疑正确”的 迁移撞上了Kubernetes一贯坚持的原则——升级版本不应该让仍在大范围使用的 已有功能突然失效：原来用awsElasticBlockStore字段声明存储的Pod YAML，字面意义上应该要全部改写成CSI的driver: ebs.csi.aws.com写法才能 继续工作，这对存量用户是不可接受的破坏性变更。Kubernetes 1.17因此 又设计了CSIMigration方案，让Out-of-Tree驱动能自动伪装成In-Tree接口对 用户提供服务，用户的旧YAML完全不用改。这个案例是本章反复出现的 Kubernetes设计哲学的又一次印证：好设计要在多方利益之间权衡，很多时候 必须向现实妥协，而不能只追求理论最优方案。