我在aws（acc和prod）的coreos上运行两个kubernetes集群，并且在两者上都设置了一个带有nginx ssl的自定义注册表（购买了通配符证书，检查好了）终止到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 = {'namespace': 'library', 'repository': u'xxxxx'}
发布 /v2/xxxxx/blob/上传/
time="2016-04-01T10:07:31Z" level=info msg="response completed" 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="/v2/xxxxx/blobs/uploads/" http.request.useragent="docker/1.9.1 go/go1. 4.3 git-commit/9894698 kernel/4.3.6-coreos os/linux arch/amd64" http.response.duration=196.065061ms http.response.status=202 http.response.written=0 instance.id=741a8348-2a62- 4b49-8f78-99f102bf7593 版本=v2.3.1
补丁 /v2/REPO/blob/uploads/30bbaca1-3c4a-4766-a59e-8dd6fc1ebc25 [...]
time="2016-04-01T09:49:42Z" level=error msg="client disconnected during blob PATCH" 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="/v2/xxxxx/blobs/uploads/30bbaca1-3c4a-4766-a59e-8dd6fc1ebc25?_state=E_ajSTSwyO48bb- dO9hmnXaPXxTH9Bc2PdB2BMaFki97Ik5hbWUiOiJqdW5nby13ZWIiLCJVVUlEIjoiMzBiYmFjYTEtM2M0YS00NzY2LWE1OWUtOGRkNmZjMWViYzI1IiwiT2Zmc2V0IjowLCJTdGFydGVkQXQiOiIyMDE2LTA0LTAxVDA5OjQ3OjU5LjM4NDEzNjkyOVoifQ%3D%3D"
docker 客户端似乎没有收到来自注册表的终止信号（或类似的东西），使其永远上传第一层并最终超时。没有任何东西被标记，并且上传被清除。
编辑：我已经使用 1.10.1 docker-cli 成功地手动推送了图像，所以问题一定是 wercker docker-cli ;(