Fabric8 Kubernetes Client在AWS EKS上文件上传问题的分析与解决

问题背景

在使用Fabric8 Kubernetes Client的CopyOrReadable#upload方法时，开发者在AWS EKS集群上遇到了文件上传失败的问题。具体表现为上传的tar文件虽然成功创建在目标容器中，但文件内容为空，方法返回false。这个问题在极少数情况下能正常工作，但大多数情况下都会失败。

问题现象

当尝试上传文件时，系统日志显示文件大小验证失败：

i.f.k.c.d.i.uploadable.PodUpload upload file size validation failed, expected 3584, but was 0

在目标容器中检查文件时，发现文件确实为空：

-rw-r--r--    1 root     root             0 Jul 29 19:52 fabric8-00000000-0000-0000-0000-000000000019.tar

问题分析

通过深入调查，发现使用kubectl直接执行类似命令也会出现相同问题：

echo "test" | kubectl exec -i -n default aws-eks-run-python-9nwmi -c init-files -- sh -c "cat - > /working-dir/test"

对比官方Kubernetes客户端的实现方式，发现他们采用了不同的处理策略：

cat test.tar | kubectl exec -i -n default aws-eks-run-python-9nwmi -c init-files -- sh -c "tar -xmf - -C /working-dir"

进一步研究发现，问题的根源可能与使用cat命令通过exec管道传输stdin时的可靠性有关。在某些环境下，连接可能在cat命令有机会捕获EOF之前就被关闭，导致stdin输入流没有正确关闭。

解决方案

经过多次实验，发现一个有效的解决方案是在cat命令后添加一个额外的命令，例如echo $?或sleep 0。例如：

cat ./3150193551304389127.py.tar | kubectl exec -i -n default aws-eks-run-python-9xdmb -c init-files -- sh -c "cat - > /working-dir/3150193551304389127.py.tar && echo $?"

虽然这个解决方案看起来有些奇怪，但它确实能够稳定地解决问题。推测原因可能是额外的命令给了系统足够的时间来正确处理输入流，确保文件内容被完整写入。

技术实现

在Fabric8 Kubernetes Client中，这个问题通过修改上传逻辑得到了解决。新的实现确保了文件上传的可靠性，同时保持了与现有API的兼容性。解决方案的核心是在文件上传命令后添加一个简单的状态检查命令，确保上传过程完整执行。

环境说明

这个问题主要出现在以下环境中：

• AWS EKS Kubernetes版本：1.30
• AMI版本：1.30.0-20240703
• 节点实例类型：m5.large
• Java版本：21

总结

这个问题展示了在分布式系统中文件传输可能遇到的微妙问题。通过深入分析和实验性验证，找到了一个简单而有效的解决方案。这个案例也提醒开发者，在处理文件上传和流传输时，需要考虑网络环境和命令执行的时序因素，确保数据传输的完整性和可靠性。