Поды ядра Kubernetes зависли в состоянии ожидания. Не могу запустить приборную панель

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

Я запускаю свой мастер, выполнив следующие команды:

> kubeadm reset 
> kubeadm init --apiserver-advertise-address=[MASTER_IP] > file.txt
> tail -2 file.txt > join.sh # I keep this file for later

> kubectl apply -f https://git.io/weave-kube/

> kubectl -n kube-system get pod
NAME                                READY   STATUS  RESTARTS    AGE
coredns-fb8b8dccf-kb2zq             0/1     Pending 0           2m46s
coredns-fb8b8dccf-nnc5n             0/1     Pending 0           2m46s
etcd-kubemaster                     1/1     Running 0           93s
kube-apiserver-kubemaster           1/1     Running 0           93s
kube-controller-manager-kubemaster  1/1     Running 0           113s
kube-proxy-lxhvs                    1/1     Running 0           2m46s
kube-scheduler-kubemaster           1/1     Running 0           93s

Здесь мы видим, что два модуля coredns навсегда застряли в состоянии ожидания, и когда я запускаю команду:

> kubectl -n kube-system describe pod coredns-fb8b8dccf-kb2zq

Я вижу в части событий следующее предупреждение:

Failed Scheduling : 0/1 nodes are available 1 node(s) had taints that the pod didn't tolerate.

Поскольку это предупреждение, а не ошибка, и это как новичок в Kubernetes, taints для меня мало что значит, я попытался подключить узел к мастеру (используя ранее сохраненную команду):

> cat join.sh
kubeadm join [MASTER_IP]:6443 --token [TOKEN] \
    --discovery-token-ca-cert-hash sha256:[ANOTHER_TOKEN]

> ssh [USER]@[WORKER_IP] 'bash' < join.sh

This node has joined the cluster.

На мастере проверяю, что нода подключена:

> kubectl get nodes 
NAME        STATUS      ROLES   AGE     VERSION
kubemaster  NotReady    master  13m     v1.14.1
kubeslave1  NotReady    <none>  31s     v1.14.1

И я проверяю свои стручки:

> kubectl -n kube-system get pod
NAME                                READY   STATUS              RESTARTS    AGE
coredns-fb8b8dccf-kb2zq             0/1     Pending             0           14m
coredns-fb8b8dccf-nnc5n             0/1     Pending             0           14m
etcd-kubemaster                     1/1     Running             0           13m
kube-apiserver-kubemaster           1/1     Running             0           13m
kube-controller-manager-kubemaster  1/1     Running             0           13m
kube-proxy-lxhvs                    1/1     Running             0           14m
kube-proxy-xllx4                    0/1     ContainerCreating   0           2m16s
kube-scheduler-kubemaster           1/1     Running             0           13m

Мы видим, что еще один модуль kube-proxy был создан и застрял в статусе ContainerCreating.

И когда я снова делаю описание:

kubectl -n kube-system describe pod kube-proxy-xllx4

Я вижу в части событий несколько одинаковых предупреждений:

Failed create pod sandbox : rpx error: code = Unknown desc = failed pulling image "k8s.gcr.io/pause:3.1": Get https://k8s.gcr.io/v1/_ping: dial tcp: lookup k8s.gcr.io on [::1]:53 read up [::1]43133->[::1]:53: read: connection refused

Вот мои репозитории:

docker image ls
REPOSITORY                          TAG     
k8s.gcr.io/kube-proxy               v1.14.1 
k8s.gcr.io/kube-apiserver           v1.14.1 
k8s.gcr.io/kube-controller-manager  v1.14.1 
k8s.gcr.io/kube-scheduler           v1.14.1 
k8s.gcr.io/coredns                  1.3.1   
k8s.gcr.io/etcd                     3.3.10  
k8s.gcr.io/pause                    3.1 

И так, для приборной части я попробовал запустить ее командой

> kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/aio/deploy/recommended/kubernetes-dashboard.yaml

Но модуль приборной панели застрял в состоянии ожидания.

kubectl -n kube-system get pod
NAME                                    READY   STATUS              RESTARTS    AGE
coredns-fb8b8dccf-kb2zq                 0/1     Pending             0           40m
coredns-fb8b8dccf-nnc5n                 0/1     Pending             0           40m
etcd-kubemaster                         1/1     Running             0           38m
kube-apiserver-kubemaster               1/1     Running             0           38m
kube-controller-manager-kubemaster      1/1     Running             0           39m
kube-proxy-lxhvs                        1/1     Running             0           40m
kube-proxy-xllx4                        0/1     ContainerCreating   0           27m
kube-scheduler-kubemaster               1/1     Running             0           38m
kubernetes-dashboard-5f7b999d65-qn8qn   1/1     Pending             0           8s

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

Я знаю, что просто разместил здесь много информации, но я новичок в k8s и совершенно не понимаю этого.

Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Kubernetes - это портативная, расширяемая платформа с открытым исходным кодом для управления контейнерными рабочими нагрузками и сервисами, которая...
3
0
5 221
3
Перейти к ответу Данный вопрос помечен как решенный

Ответы 3

На самом деле это противоположность глубокой или серьезной проблеме. Это тривиальная проблема. Всегда вы видите модуль, застрявший в состоянии Pending, это означает, что планировщику трудно запланировать модуль; в основном потому, что на узле недостаточно ресурсов.

В вашем случае это taint, у которого есть узел, а у вашего модуля нет допуска. Что вам нужно сделать, так это описать узел и получить taint:

kubectl describe node | grep -i taints

Примечание: у вас может быть более одной порчи. Так что вы можете сделать kubectl describe no NODE, так как с помощью grep вы увидите только один taint.

Как только вы получите порчу, это будет что-то вроде hello=world:NoSchedule; что означает key=value:effect, вам нужно будет добавить раздел toleration в свой Deployment. Это пример Deployment, чтобы вы могли увидеть, как это должно выглядеть:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 10
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        ports:
        - containerPort: 80
          name: http
      tolerations:
      - effect: NoExecute       #NoSchedule, PreferNoSchedule
        key: node
        operator: Equal
        value: not-ready
        tolerationSeconds: 3600

Как видите, в yaml есть раздел допуска. Таким образом, если бы у меня был узел с node=not-ready:NoExecute taint, ни один модуль не смог бы быть запланирован на этом узле, если бы не было этого допуска.

Также вы можете удалить taint, если вам это не нужно. Чтобы удалить taint, вы должны описать узел, получить key загрязнения и сделать:

kubectl taint node NODE key-

Надеюсь, это имеет смысл. Просто добавьте этот раздел в свое развертывание, и все заработает.

Спасибо за Ваш ответ ! На моем узле kubemaster обнаружены следующие дефекты: node.kubernetes.io/not-ready:NoExecute, node-role.kubernetes.io/master:NoSchedule, node.kubernetes.io/not-ready:NoSchedule. Я не понимаю, что я только выполнил команду kubeadm init --apiserver-advertise-address=[MASTER_IP]. На данный момент у меня нет файла YAML. Нужно ли создавать новый файл развертывания?

Nakeuh 10.04.2019 13:15

Да, эти порчи имеют смысл. Это делается для того, чтобы ни один под не запускался на главном узле (если он не предназначен) и никакие поды не должны работать на узле с определенными проблемами (не готовый узел). Просто добавьте допуски, как объяснено, к вашим развертываниям (например, core-dns), и все должно работать. P.S. ваша проблема не имеет ничего общего с сетевыми плагинами. По крайней мере тот, который вы описываете.

suren 10.04.2019 15:34

Ну, на самом деле дело в том, что мой coredns застрял в ожидании с предупреждением о недопустимых заражениях, и как только я правильно запустил сетевой плагин, статус coredns переходит в «Выполняется». Я не знаю, имеет ли это смысл, но это то, что произошло.

Nakeuh 10.04.2019 16:01

Это не имеет для меня никакого смысла. Если только ваш узел не был испорчен как not-ready из-за того, что плагин не был установлен. В этом случае заражение будет удалено, как только узел будет готов. Если вы бежите kubectl describe node NODE, у вас все еще есть порчи?

suren 10.04.2019 16:20

Теперь у меня есть только порча node-role.kubernetes.io/master:NoSchedule

Nakeuh 10.04.2019 16:28

Это имеет смысл для меня. Узел был динамически испорчен.

suren 10.04.2019 16:37
Ответ принят как подходящий

Я столкнулся с проблемой, когда модули coredns застряли в режиме ожидания при настройке собственного кластера; который я разрешаю, добавляя сеть pod.

Похоже, что из-за того, что Network Addon не установлен, узлы испорчены как not-ready. Установка аддона удалит загрязнения, и модули смогут планировать. В моем случае добавление фланель решило проблему.

Обновлено: об этом есть примечание в официальном Документация k8s - Создание кластера с помощью kubeadm:

The network must be deployed before any applications. Also, CoreDNS will not start up before a network is installed. kubeadm only supports Container Network Interface (CNI) based networks (and does not support kubenet).

Разве не для этого предназначен kubectl apply -f https://git.io/weave-kube/?

Nakeuh 10.04.2019 13:19

Я заменил предыдущую команду на kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')", и теперь в моих модулях появляется weave-net. И с тех пор мои стручки coredns волшебным образом начали работать (как вы сказали :))

Nakeuh 10.04.2019 14:07

это зависит от того, как вы собираетесь «установить» свой pod-network. Рад, что был полезен

Ivan Aracki 10.04.2019 14:25

Настройте сетевой инструмент фланели.

Запуск команд:

$ sysctl net.bridge.bridge-nf-call-iptables=1
$ kubectl apply -f 

https://raw.githubusercontent.com/coreos/flannel/62e44c867a2846fefb68bd5f178daf4da3095ccb/Documentation/kube-flannel.yml

Другие вопросы по теме