我在aws（acc和prod）上的coreos上运行了两个kubernetes集群，并且两者都设置了一个自定义注册表，其中包含nginx ssl（购买了wildcart证书，检查好了）终止到v1 + v2后端，所有都在运行精细。不知何故，我现在有一个问题，一个特定的构建不会上传。另一张图片上传得很好...一次又一次我看到了同样的行为。
我构建的两个图像是WEB（虚拟大小约为390 MB）和API（虚拟大小约为420 MB）。导致异常的一个是WEB图像，它只是略大，所以我认为没有问题。
再次，al运行良好，直到这个特定的图像出现。我创建了不同大小的新版本，但它不会上传。其他图像上传后很好，进入同一个存储库，这使得这个案例如此有趣（让我疯了;）。 我不相信这是aws ssl elb设置的问题，因为我在nginx容器中进行ssl终止，并且所有其他服务在同一架构中运行良好。
针对未来有关为什么需要v1后端的问题： 需要容纳wercker，它（仍）发布到v1后端。注册表然后将流量重定向到v2后端，在那里存储图像。
注册表的日志（显示的v1和v2）显示以下输出（并按此顺序）：
PUT / v1 / repositories / web / 01 / Apr / 2016：09：47：41 +0000 DEBUG：args = {＆＃39; namespace＆＃39;：＆＃39; library＆＃39;，＆＃39 ;存储库＆＃39;：u＆＃39; xxxxx＆＃39;}
POST / v2 / xxxxx / blobs / uploads /
时间=＆＃34; 2016-04-01T10：07：31Z＆＃34; level = info msg =＆＃34;响应完成＆＃34; go.version = go1.5.3 http.request.host = xxxxx http.request.id = f3f5b5c0-44ce-4d1b-9f41-7cf9b06e6c3d http.request.method = POST http.request.remoteaddr = 172.22.90.1 http.request.uri =＆＃34; / V2 / XXXXX /斑点/上传/＆＃34; http.request.useragent =＆＃34; docker / 1.9.1 go / go1.4.3 git-commit / 9894698 kernel / 4.3.6-coreos os / linux arch / amd64＆＃34; http.response.duration = 196.065061ms http.response.status = 202 http.response.written = 0 instance.id = 741a8348-2a62-4b49-8f78-99f102bf7593 version = v2.3.1
PATCH / v2 / REPO / blobs / uploads / 30bbaca1-3c4a-4766-a59e-8dd6fc1ebc25 [...]
时间=＆＃34; 2016-04-01T09：49：42Z＆＃34; level = error msg =＆＃34;客户端已断开连接 在blob PATCH＆＃34; go.version = go1.5.3 http.request.host = xxxxx http.request.id = 05dd5386-e797-4122-be43-4d2c564b28be http.request.method = PATCH http.request.remoteaddr = 172.22.90.1 http.request.uri =＆＃34; / V2 / XXXXX /斑点/上传/ 30bbaca1-3c4a-4766-a59e-8dd6fc1ebc25 _STATE = E_ajSTSwyO48bb-dO9hmnXaPXxTH9Bc2PdB2BMaFki97Ik5hbWUiOiJqdW5nby13ZWIiLCJVVUlEIjoiMzBiYmFjYTEtM2M0YS00NzY2LWE1OWUtOGRkNmZjMWViYzI1IiwiT2Zmc2V0IjowLCJTdGFydGVkQXQiOiIyMDE2LTA0LTAxVDA5OjQ3OjU5LjM4NDEzNjkyOVoifQ％3D％3D＆＃34;
docker客户端似乎没有从注册表收到终止信号（或类似的东西），使其永久上传第一层并最终超时。没有任何标记，并且上传被清除。
编辑：我已成功使用1.10.1 docker-cli手动推送图像，所以问题必须是wercker docker-cli;（