Блог

Я попытался использовать KinD в качестве альтернативы Minikube для начальной загрузки кластера K8S на моем локальном компьютере.

Кластер создан успешно.

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

 $ kubectl run nginx --image=nginx
$ kubectl run hello --image=hello-world
  

Через несколько минут используйте get pods для получения статуса сбоя.

 $ kubectl get pods
NAME    READY   STATUS             RESTARTS   AGE
hello   0/1     ImagePullBackOff   0          11m
nginx   0/1     ImagePullBackOff   0          22m
  

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

 kubectl describe pods/nginx
Name:         nginx
Namespace:    default
Priority:     0
Node:         dev-control-plane/172.19.0.2
Start Time:   Sun, 30 Aug 2020 19:46:06  0800
Labels:       run=nginx
Annotations:  <none>
Status:       Pending
IP:           10.244.0.5
IPs:
  IP:  10.244.0.5
Containers:
  nginx:
    Container ID:
    Image:          nginx
    Image ID:
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       ErrImagePull
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-mgq96 (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  default-token-mgq96:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-mgq96
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                From                        Message
  ----     ------     ----               ----                        -------
  Normal   Scheduled  56m                default-scheduler           Successfully assigned default/nginx to dev-control-plane
  Normal   BackOff    40m                kubelet, dev-control-plane  Back-off pulling image "nginx"
  Warning  Failed     40m                kubelet, dev-control-plane  Error: ImagePullBackOff
  Warning  Failed     13m (x3 over 40m)  kubelet, dev-control-plane  Failed to pull image "nginx": rpc error: code = Unknown desc = failed to pull and unpack image "docker.io/library/nginx:latest": failed to copy: unexpected EOF
  Warning  Failed     13m (x3 over 40m)  kubelet, dev-control-plane  Error: ErrImagePull
  Normal   Pulling    13m (x4 over 56m)  kubelet, dev-control-plane  Pulling image "nginx"
  

Когда я вошел в контейнер kindest / node, но в нем нет docker. Не уверен, как работает KIND, изначально я понимаю, что он развертывает кластер K8S в контейнере Docker.

 $ docker ps
CONTAINER ID        IMAGE                  COMMAND                  CREATED             STATUS              PORTS                       NAMES
a644f8b61314        kindest/node:v1.19.0   "/usr/local/bin/entr…"   About an hour ago   Up About an hour    127.0.0.1:52301->6443/tcp   dev-control-plane

$ docker exec -it  a644f8b61314  /bin/bash
root@dev-control-plane:/# docker -v
bash: docker: command not found
  

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

Кстати, я использую последнюю бета-версию Docker Desktop в Windows 10.

Сначала извлеките изображение в вашей локальной системе с помощью docker pull nginx , а затем используйте приведенную ниже команду для загрузки этого изображения в кластер kind

 kind load docker-image nginx --name kind-cluster-name 
  

Kind использует containerd вместо docker в качестве среды выполнения, поэтому docker не установлен на узлах.

В качестве альтернативы вы можете использовать инструмент crictl для извлечения и проверки изображений внутри узла kind.

 crictl pull nginx
crictl images
  

Я столкнулся с той же проблемой, потому что я экспортировал http_proxy и https_proxy перед созданием кластера на локальный прокси (127.0.0.1), который недоступен в кластере. После отмены http (ов) _proxy и воссоздания кластера все работает нормально.

Поскольку другие ответы не помогли в моем случае: необходимо установить http(s)_proxy переменные среды перед запуском kind create cluster . Только настройка среды для docker соответственно. containerd здесь не помогает:

 export http_proxy=http://...
export https_proxy=http://...

kind create cluster --config ...