Docker периодически отправляет сбой в закрытый реестр Docker на Kubernetes (Docker-рабочий стол) - PullRequest
Новая
       24

Docker периодически отправляет сбой в закрытый реестр Docker на Kubernetes (Docker-рабочий стол)

0 голосов
/ 16 февраля 2019

Я использую кластер kubernetes на рабочем столе (Mac).

В нем есть локальный реестр Docker.

Я могу запросить реестр без проблем черезAPI вызывает список тегов.

Раньше я мог выдвинуть изображение, но для этого потребовалось несколько попыток.

Я не могу сейчас выдвинуть новые изменения.Похоже, что он успешно проталкивается для слоев, но затем не подтверждает, что слой был передан, а затем повторяет попытку.

Репо называется localhost: 5000, и я правильно перенаправляю порт согласно инструкциям на https://blog.hasura.io/sharing-a-local-registry-for-minikube-37c7240d0615/

Я не использую ssl-сертификаты, так как они предназначены для разработки на локальном компьютере.

(Доказано, что переадресация портов работает в противном случае вызов API) 

e086a4af6e6b: Retrying in 1 second 
35c20f26d188: Layer already exists 
c3fe59dd9556: Pushing [========================>                          ]  169.3MB/351.5MB
6ed1a81ba5b6: Layer already exists 
a3483ce177ce: Retrying in 16 seconds 
ce6c8756685b: Layer already exists 
30339f20ced0: Retrying in 1 second 
0eb22bfb707d: Pushing [==================================================>]  45.18MB
a2ae92ffcd29: Waiting 
received unexpected HTTP status: 502 Bad Gateway

обходной путь (этого будет достаточно, но не идеально, так как приходится собирать каждый контейнер 

apiVersion: v1
kind: Pod
metadata:
  name: producer
  namespace: aetasa
spec:
  containers:
  - name: kafkaproducer
    image: localhost:5000/aetasa/cta-user-create-app
    imagePullPolicy: Never // this line uses the built container in docker
    ports:
        - containerPort: 5005

Журналы Kubectl для реестра 

10.1.0.1 - - [20/Feb/2019:19:18:03 +0000] "POST /v2/aetasa/cta-user-create-app/blobs/uploads/ HTTP/1.1" 202 0 "-" "docker/18.09.2 go/go1.10.6 git-commit/6247962 kernel/4.9.125-linuxkit os/linux arch/amd64 UpstreamClient(Docker-Client/18.09.2 \x5C(darwin\x5C))" "-"
2019/02/20 19:18:03 [warn] 12#12: *293 a client request body is buffered to a temporary file /var/cache/nginx/client_temp/0000000011, client: 10.1.0.1, server: localhost, request: "PATCH /v2/aetasa/cta-user-create-app/blobs/uploads/16ad0e41-9af3-48c8-bdbe-e19e2b478278?_state=qjngrtaLCTal-7-hLwL9mvkmhOTHu4xvOv12gxYfgPx7Ik5hbWUiOiJhZXRhc2EvY3RhLXVzZXItY3JlYXRlLWFwcCIsIlVVSUQiOiIxNmFkMGU0MS05YWYzLTQ4YzgtYmRiZS1lMTllMmI0NzgyNzgiLCJPZmZzZXQiOjAsIlN0YXJ0ZWRBdCI6IjIwMTktMDItMjBUMTk6MTg6MDMuMTU2ODYxNloifQ%3D%3D HTTP/1.1", host: "localhost:5000"
2019/02/20 19:18:03 [error] 12#12: *293 connect() failed (111: Connection refused) while connecting to upstream, client: 10.1.0.1, server: localhost, request: "PATCH /v2/aetasa/cta-user-create-app/blobs/uploads/16ad0e41-9af3-48c8-bdbe-e19e2b478278?_state=qjngrtaLCTal-7-hLwL9mvkmhOTHu4xvOv12gxYfgPx7Ik5hbWUiOiJhZXRhc2EvY3RhLXVzZXItY3JlYXRlLWFwcCIsIlVVSUQiOiIxNmFkMGU0MS05YWYzLTQ4YzgtYmRiZS1lMTllMmI0NzgyNzgiLCJPZmZzZXQiOjAsIlN0YXJ0ZWRBdCI6IjIwMTktMDItMjBUMTk6MTg6MDMuMTU2ODYxNloifQ%3D%3D HTTP/1.1", upstream: "http://10.104.68.90:5000/v2/aetasa/cta-user-create-app/blobs/uploads/16ad0e41-9af3-48c8-bdbe-e19e2b478278?_state=qjngrtaLCTal-7-hLwL9mvkmhOTHu4xvOv12gxYfgPx7Ik5hbWUiOiJhZXRhc2EvY3RhLXVzZXItY3JlYXRlLWFwcCIsIlVVSUQiOiIxNmFkMGU0MS05YWYzLTQ4YzgtYmRiZS1lMTllMmI0NzgyNzgiLCJPZmZzZXQiOjAsIlN0YXJ0ZWRBdCI6IjIwMTktMDItMjBUMTk6MTg6MDMuMTU2ODYxNloifQ%3D%3D", host: "localhost:5000"

Ответы [ 3 ]

0 голосов
/ 20 февраля 2019

Я сталкивался с этой проблемой довольно много раз и, к сожалению, не смог получить окончательного исправления.

Скорее всего, изображение должно быть повреждено в реестре.В качестве обходного пути, я предлагаю вам удалить изображение из реестра и сделать новый толчок.это будет работать, и последующие нажатия будут работать тоже.

Эта проблема должна быть связана с отсутствующими слоями изображения.иногда мы удаляем изображение с помощью параметра --force, в этом случае возможно, что некоторые из общих слоев могут быть удалены и повлиять на другие изображения, которые имеют общие удаленные слои.

0 голосов
/ 25 февраля 2019

Попробуйте настроить --max-concurrent-uploads=1 для вашего докер-клиента.Вы выдвигаете довольно большие слои (350 МБ), поэтому, вероятно, вы где-то ограничиваете некоторые ограничения (размеры запросов, тайм-ауты).Одна одновременная загрузка может помочь вам, но это только обходной путь.Реальным решением будет конфигурация (размеры буфера, таймауты, ...) реестра + обратный прокси-сервер перед реестром.

0 голосов
/ 19 февраля 2019

Это может быть проблема с дисковым пространством.Если вы храните образы докеров внутри Docker VM, вы можете довольно быстро заполнить дисковое пространство.

По умолчанию дисковое пространство Docker-desktop VM ограничено 64 гигабайтами.Вы можете увеличить его до 112 Гб на вкладке « Диск » в Docker Предпочтения .

...