SAP把Cloud Foundry用户逼到第7步

从Cloud Foundry迁移到Kyma的开发者，平均要在Dockerfile上卡3.7天——这是SAP社区2024年调研的中位数。不是技术难，是思维惯性：过去8年，Buildpack帮你屏蔽了所有容器细节，现在突然要亲手写多阶段构建、调JVM参数、配非root用户。

这篇来自SAP官方技术博客的实战记录，完整还原了一个Java微服务从源码到生产级Helm部署的全流程。作者没讲理论，只给能直接复制的配置。

第一阶段：Dockerfile的"权力交接"

Cloud Foundry的隐形契约是：你只管代码，平台管打包。Kyma把这份契约撕了。

作者给出的Dockerfile分两个阶段。构建阶段用Maven 3.9和Eclipse Temurin 17，把pom.xml和源码扔进去跑package；运行阶段切换到Alpine JRE，显式创建appgroup/appuser，最后用USER指令切到非特权身份。这是生产环境的底线要求，不是可选项。

内存调优从"平台代劳"变成"你自己算"。Cloud Foundry会根据配额自动设-Xmx，Kyma里你得在JAVA_OPTS里写死-XX:MaxRAMPercentage=75.0，同时让K8s的resources.limits.memory和它对齐。对不齐？Pod被OOMKilled时日志不会告诉你真相。

端口绑定同理。CF的$PORT是环境变量注入，Kyma里你在Dockerfile写死EXPOSE 8080，然后在Helm values里再声明一遍service.port。重复？这是显式契约的好处：排查时不用猜平台行为。

第二阶段：Helm不是"另一个YAML"

作者列出的Chart结构有8个模板文件，比Cloud Foundry的manifest.yml多了7倍行数，但控制能力不在一个量级。

service-instance.yaml和service-binding.yaml是SAP BTP特有的。它们调用BTP Operator，把XSUAA和HANA这类服务实例的创建和凭证注入，从CF的"绑定即环境变量"变成K8s原生的Secret挂载。凭证不再进VCAP_SERVICES那个巨型JSON，而是以文件形式挂在/var/bindings/下，或者可选地注入环境变量。

这个设计有代价：本地调试时，你得mock整个Secret结构。但收益是显式的——生产环境的凭证流转路径在YAML里一目了然，安全审计时不用翻平台黑盒。

apirule.yaml是Kyma的API Gateway规则，替代CF的routes。作者没展开，但注释暗示了关键差异：CF的路由是平台级共享域名，Kyma的APIRule让你控制独立主机名和OAuth scope。

第三阶段：HPA是"最后的保险"

values.yaml里的autoscaling段，作者设了minReplicas: 2到maxReplicas: 10，targetCPUUtilization: 70。这串数字背后是Cloud Foundry没有的能力：水平自动扩容。

CF的扩容是垂直的——加内存配额，或者多实例但得手动改manifest。Kyma的HPA（Horizontal Pod Autoscaler）基于CPU利用率实时决策，作者把阈值设在70%，留30%缓冲应对突发流量。

但这里有个陷阱：JVM的堆内存和容器内存limit是两个概念。如果JAVA_OPTS里设了75% MaxRAMPercentage，而K8s limit是1Gi，那么堆上限是768Mi。Pod实际RSS可能逼近1Gi，触发 eviction。作者没明说，但resources.limits.memory: 1Gi和JAVA_OPTS的配比需要你自己验算。

从CF迁移者的视角

作者列了一张对照表，把5个核心差异摊平。最刺痛的是第一行：Container那栏，CF写"Buildpack creates it for you"，Kyma写"You write the Dockerfile"。

这不是技术倒退，是责任转移。Cloud Foundry的Buildpack策略在2015年很先进——Heroku模式，开发者专注业务。但到2024年，标准化容器镜像成了更硬的通货：多云部署、安全扫描、供应链审计，都需要可复现的Dockerfile，而不是平台黑盒生成的层。

SAP押注Kyma（基于开源Kubernetes）而非升级CF，这个选择本身就在释放信号。作者作为内部技术布道者，没评论战略，只给迁移路径：先接受"多写YAML"的摩擦，再换取"可控一切"的自由。

完整的代码片段和目录结构在原文都有，包括那个容易踩坑的registry-secret配置——Kyma不会自动帮你创建镜像拉取凭证，得提前kubectl create secret。

如果你正在维护一个CF上的Java应用，迁移评估清单的第一项不是"技术可行性"，而是团队有没有人能写出一个通过安全扫描的Dockerfile。作者没说的潜台词是：这项技能在2024年的SAP生态里，已经从"加分项"变成"生存项"。

最后留个开放问题：你的团队里，现在是谁在维护那个生产环境的Dockerfile——是开发写完后扔给运维，还是已经有人专门对镜像安全负责？