SAP把Cloud Foundry用户逼到第7步|sap|yaml|契约|显式标识

从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的配比需要你自己验算。