Извлечь образы из локального (небезопасного) реестра в кластер типа - PullRequest
0 голосов
/ 17 марта 2020

Я пытался использовать какой-то пользовательский локальный образ на своем кластере, следуя инструкциям на https://kind.sigs.k8s.io/docs/user/local-registry - т.е. применяя следующее containerdConfigPatches к моему cluster.cfg:

containerdConfigPatches:
- |-
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors."192.168.83.82:5000"]
    endpoint = ["http://192.168.83.82:5000"]

192.168.83.82:5000 - это IP-адрес виртуальной машины, на которой локальный (небезопасный) реестр работает рядом с типом кластера и его открытым портом.

После создания кластера я могу проверить настройки где применяется ко всем узлам:

docker exec kind-worker3 cat /etc/containerd/config.toml
# [...]
# Relevant sections:
# [...]
  [plugins."io.containerd.grpc.v1.cri"]
    [plugins."io.containerd.grpc.v1.cri".registry]
      [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."192.168.83.82:5000"]
          endpoint = ["http://192.168.83.82:5000"]

Однако при работе с модулями происходит сбой до ErrImagePull, и эти журналы событий:

Events:
  Type     Reason     Age                From                             Message
  ----     ------     ----               ----                             -------
  Normal   Scheduled  32s                default-scheduler                Successfully assigned default/test-6bc95ff8c5-g6g86 to kind-worker3
  Normal   Pulled     31s                kubelet, kind-worker3  Container image "docker.elastic.co/beats/filebeat-oss:6.4.2" already present on machine
  Normal   Created    31s                kubelet, kind-worker3  Created container test-log-agent
  Normal   Started    31s                kubelet, kind-worker3  Started container test-log-agent
  Normal   Pulling    16s (x2 over 31s)  kubelet, kind-worker3  Pulling image "192.168.83.82:5000/test/image:2.2.1"
  Warning  Failed     16s (x2 over 31s)  kubelet, kind-worker3  Failed to pull image "192.168.83.82:5000/test/image:2.2.1": rpc error: code = Unknown desc = failed to resolve image "192.168.83.82:5000/test/image:2.2.1": no available registry endpoint: failed to do request: Head https://192.168.83.82:5000/v2/test/image/manifests/2.2.1: http: server gave HTTP response to HTTPS client
  Warning  Failed     16s (x2 over 31s)  kubelet, kind-worker3  Error: ErrImagePull
  Normal   BackOff    3s (x3 over 30s)   kubelet, kind-worker3  Back-off pulling image "192.168.83.82:5000/test/image:2.2.1"
  Warning  Failed     3s (x3 over 30s)   kubelet, kind-worker3  Error: ImagePullBackOff

TL; DR: "http: сервер дал HTTP-ответ клиенту HTTPS "- который, как я думал, будет решен с помощью ConfigPatch выше (как это происходит, когда вы настраиваете docker daemon.json).

Также, в качестве альтернативы, попытался загрузить изображение с хоста на узлы кластера:

kind load docker-image 192.168.83.82:5000/test/image:2.2.1 --name="kind-cluster"

и проверил, что изображение было загружено на все узлы, перечислив их:

sysadmin@ubuntu:~/kind$ docker exec kind-worker3 crictl images
IMAGE                                TAG                 IMAGE ID            SIZE
192.168.83.82:5000/test/image        2.2.1               ba1601dfa9c48       822MB
docker.io/kindest/kindnetd           0.5.0               ef97cccdfdb50       83.6MB
k8s.gcr.io/coredns                   1.3.1               eb516548c180f       40.5MB
k8s.gcr.io/etcd                      3.3.10              2c4adeb21b4ff       258MB
k8s.gcr.io/kube-apiserver            v1.15.3             be321f2ded3f3       249MB
k8s.gcr.io/kube-controller-manager   v1.15.3             ac7d3fe5b34b7       200MB
k8s.gcr.io/kube-proxy                v1.15.3             d428039608992       97.3MB
k8s.gcr.io/kube-scheduler            v1.15.3             a44f53b10fee0       96.5MB
k8s.gcr.io/pause                     3.1                 da86e6ba6ca19       746kB

Надеясь, что изображение теперь будет читать из кэша изображений. Однако результат был точно таким же.

Есть подсказка, как подойти к этому? Есть что-то, что я мог упустить из виду?

1 Ответ

0 голосов
/ 25 марта 2020

Попробуйте после обновления daemon.josn следующим образом.

{
   "insecure-registries" : [
   "host.docker.internal:5000"
    ],
   "experimental" : true,
   "debug" : true
}
...