<p>kubeadm init застрял на "Первый узел зарегистрирован, но еще не готов"</p>

Точно то же самое происходит со мной в Ubuntu 16.04.02, как GCE, так и локальные установки VMWare, версия Docker 1.12.6, ядро ​​4.8.0-44-generic 47 ~ 16.04.1-Ubuntu SMP.

Журнал kubelet показывает предупреждение об отсутствии /etc/cni/net.d перед ошибкой, которую мы видим в отчете jimmycuadra:

Mar 29 04:43:25 instance-1 kubelet[6800]: W0329 04:43:25.763117    6800 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Mar 29 04:43:25 instance-1 kubelet[6800]: E0329 04:43:25.763515    6800 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Та же проблема на виртуальной машине Ubuntu AWS. Докер 1.12.5

root @ ip-10-43-0-20 : ~ # версия kubeadm
kubeadm version: version.Info {Major: "1", Minor: "6", GitVersion: "v1.6.0", GitCommit: "fff5156092b56e6bd60fff75aad4dc9de6b6ef37", GitTreeState: "clean", BuildDate: "2017-03-28T16 30Z ", GoVersion:" go1.7.5 "

корень @ ip-10-43-0-20 : ~ # uname -a
Linux ip-10-43-0-20 4.4.0-45-generic # 66-Ubuntu SMP среда, 19 октября, 14:12:37 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux

корень @ ip-10-43-0-20 : ~ # kubeadm init --config cfg.yaml
[kubeadm] ВНИМАНИЕ: kubeadm находится на стадии бета-тестирования, пожалуйста, не используйте его для производственных кластеров.
[init] Использование версии Kubernetes: v1.6.0
[init] Использование режима авторизации: RBAC
[init] ВНИМАНИЕ: для работы интеграции с облачным провайдером --cloud-provider должен быть установлен для всех кубелец в кластере.
(Для этого необходимо отредактировать /etc/systemd/system/kubelet.service.d/10-kubeadm.conf)
[предполетная] Проведение предполетных проверок
[предполетная] Запуск сервиса kubelet
[сертификаты] Сгенерированные сертификат CA и ключ.
[сертификаты] Сгенерированные сертификат и ключ сервера API.
[сертификаты] Сервер API, обслуживающий сертификат, подписан для имен DNS [ip-10-43-0-20 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] и IP-адресов [10.96.0.1 10.43.0.20 ]
[сертификаты] Сгенерированы сертификат клиента kubelet сервера API и ключ.
[сертификаты] Сгенерированные ключ подписи токена учетной записи службы и открытый ключ.
[сертификаты] Сгенерированные сертификат и ключ CA внешнего прокси.
[сертификаты] Сгенерированные клиентский сертификат и ключ внешнего прокси.
[сертификаты] Действующие сертификаты и ключи теперь находятся в "/ etc / kubernetes / pki"
[kubeconfig] Записал файл KubeConfig на диск: "/etc/kubernetes/admin.conf"
[kubeconfig] Записал файл KubeConfig на диск: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Записал файл KubeConfig на диск: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Записал файл KubeConfig на диск: "/etc/kubernetes/scheduler.conf"
[apiclient] Создан клиент API, ожидает готовности уровня управления
[apiclient] Все компоненты уровня управления исправны через 16,531681 секунды
[apiclient] Ожидает, пока хотя бы один узел зарегистрируется и станет готовым
[apiclient] Первый узел зарегистрирован, но еще не готов
[apiclient] Первый узел зарегистрирован, но еще не готов
[apiclient] Первый узел зарегистрирован, но еще не готов

++ та же проблема (Ubuntu 16.04.1)

То же самое и здесь, в Ubuntu 16.04

На CentOS 7 я понизил версию kubelet до 1.5.4 . Это решило проблему для меня. Кажется, что проверка готовности работает иначе в кубеле 1.6.0 .

Та же проблема с CentOS 7 на машине x64 с голым железом после обновления до k8s 1.6.0

Та же проблема в Ubuntu 16.04

Та же проблема в Ubuntu 16.04, ручной переход на более раннюю версию пакета kubelet решил проблему.

# apt install kubelet=1.5.6-00

@ctrlaltdel у меня не сработало.

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

@jbeda Знаете ли вы, когда эта проблема будет решена?

@kristiandrucker - нет - все еще выясняю, что происходит. Сначала необходимо устранить причину этого.

@jbeda Хорошо, но после того, как проблема будет решена, что

@kristiandrucker Это должно появиться в точечном выпуске k8s, если это проблема с kubelet.

Я подозреваю, что https://github.com/kubernetes/kubernetes/pull/43474 является основной причиной. Собираюсь сообщить об ошибке и связаться с людьми из сети.

@dcbw Ты здесь?

Похоже, проблема в том, что DaemonSet не запланирован для узлов, у которых есть условие Net stNetwork: true должен быть запланирован на узле Net workReady: false , а модуль ho

В качестве обходного пути добавление аннотации scheduler.alpha.kubernetes.io/critical-pod к вашему набору DaemonSet снова заставит вас работать?

@janetkuo @lukaszo можете ли вы

Кстати, в # sig-network продолжается обсуждение Slack.

Та же проблема CentOS 7 x64

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

CentOS Linux версии 7.3.1611 (Core)

Я пробовал это на одном узле с Ubuntu 16.04. Зависает с сообщением "еще не готов". Я также вручную создал фланелевый DaemonSet, но в моем случае он без проблем спланировал один модуль. Сам модуль демона вошел в CrashLoopBackOff с ошибкой: E0329 22:57:03.065651 1 main.go:127] Failed to create SubnetManager: error retrieving pod spec for 'kube-system/kube-flannel-ds-z3xgn': the server does not allow access to the requested resource (get pods kube-flannel-ds-z3xgn)

Еще попробую на Centos, но не думаю, что здесь виноват DaemonSet, здесь зависает kubeadm.

это ошибка разрешения rbac.

@jimmycuadra Я только что заметил, что вы запускаете его на Raspberry Pi с процессором

Для набора фланелевых демонов у вас есть:

nodeSelector:
beta.kubernetes.io/arch: amd64

but your node is labeled with: 

beta.kubernetes.io/arch=arm
`` ''

Таким образом, DaemonSet не может обедать модуль на этом узле, просто измените селектор узла, и он будет работать.
Вы все равно получите сообщение об ошибке с разрешением rbac, но, возможно, @mikedanese расскажет вам, как это исправить, потому что я этого не знаю.

Ах, спасибо @lukaszo! В этот раз я не следовал руководству по RPi (которое я использовал для k8s 1.5) и забыл об этом шаге. Я бы обнаружил это, когда в наборе демона возникла ошибка, но, как оказалось, я не зашел так далеко. :}

Я также вижу эту проблему, когда следую инструкциям, описанным здесь:
https://blog.hypriot.com/post/setup-kubernetes-raspberry-pi-cluster/

удалось заставить его работать после установки правильного фланелевого сетевого модуля.

Я думаю, что @jimmycuadra может заставить его работать с комментарием @lukaszo .

Когда появится сообщение [apiclient] First node has registered, but is not ready yet start flooding, сервер API Kubernetes будет запущен, поэтому вы можете:

curl -sSL https://rawgit.com/coreos/flannel/master/Documentation/kube-flannel.yml | kubectl create -f -

Для установки raspberry pi:

curl -sSL https://rawgit.com/coreos/flannel/master/Documentation/kube-flannel.yml | sed "s/amd64/arm/g" | kubectl create -f -

Тогда он закончится:

[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node is ready after 245.050597 seconds
[apiclient] Test deployment succeeded
[token] Using token: 4dc99e............
[apiconfig] Created RBAC rules
[addons] Created essential addon: kube-proxy
[addons] Created essential addon: kube-dns

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run (as a regular user):

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  http://kubernetes.io/docs/admin/addons/

You can now join any number of machines by running the following on each node
as root:

  kubeadm join --token 4dc99e........... 192.168.1.200:6443

У меня была такая же проблема, и я исправил ее следующим образом:
ты должен быть root

в 1.6.0 kubeadm вы должны удалить переменную окружения $ KUBELET_NETWORK_ARGS в системном файле: /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

затем перезапустите демонов

systemctl daemon-reload

kubeadm init

это займет немного времени ... после успеха

загрузите сетевое дополнение, которое хотите использовать: http://kubernetes.io/docs/admin/addons/

ситцевая ткань кажется лучшей, не уверен, но все еще испытываю для меня.

@thelastworm
Я просто пытался это сделать, но ничего не вышло.
Ubuntu 16.04.2 LTS, kubeadm 1.6.0
Я сделал следующие шаги:

1. отредактируйте /etc/systemd/system/kubelet.service.d/10-kubeadm.conf и удалите $ KUBELET_NETWORK_ARGS
2. kubeadm reset чтобы очистить предыдущую попытку запустить его
3. kubeadm init --token=<VALUE> --apiserver-advertise-address=<IP>

[ИЗМЕНИТЬ]
Это сработало после того, как @ srinat999 указал на необходимость запуска systemctl daemon-reload перед kubeadm init

Решение @jcorral сработало для меня с одним изменением развертывания фланели, поскольку незащищенный порт API больше не создается kubeadm .

curl -sSL https://rawgit.com/coreos/flannel/master/Documentation/kube-flannel.yml | \
kubectl --kubeconfig /etc/kubernetes/admin.conf create -f -

@MaximF Вы должны сделать systemctl daemon-reload после изменения файла conf. Работал у меня.

@jcorral У меня работает твое решение. Спасибо.

@MaximF, я просто добавляю командную строку демона перезапуска

kubeadm init завершается успешно, но когда я проверяю версию, получаю следующую ошибку:

Версия клиента: version.Info {Major: «1», Minor: «6», GitVersion: «v1.6.0», GitCommit: «fff5156092b56e6bd60fff75aad4dc9de6b6ef37», GitTreeState: «clean», BuildDate: «2017-03-28T16: 36: 33Z ", GoVersion:" go1.7.5 ", компилятор:" gc ", платформа:" linux / amd64 "}
В соединении с сервером localhost: 8080 было отказано - вы указали правильный хост или порт?

@haribole
Вы должны установить KUBECONFIG env var

Кто-нибудь заставил Flannel искать обходные пути, связанные с CNI? Я могу решить проблему "не готов", но когда я запускаю Flannel, я получаю следующее сообщение об ошибке:

Failed to create SubnetManager: error retrieving pod spec for 'kube-system/kube-flannel-ds-g5cbj': the server does not allow access to the requested resource (get pods kube-flannel-ds-g5cbj)

Статус Pods показывает "CrashLoopBackOff"

Вам нужно добавить роли rbac, чтобы разрешить flannel читать из API.

Вам нужно добавить роли rbac, чтобы разрешить flannel читать из API.

Если кому-то еще интересно, что это означает, похоже, вам нужно создать kube-flannel-rbac.yml прежде чем создавать фланель:

kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml
kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

Я думаю, поскольку основная проблема решена и соответствующий тикет закрыт , мы должны закрыть и эту :)

Просто для информации: теперь он работает у меня с обновленными пакетами под Ubuntu 16.04.

1.6.1 у меня работает! Спасибо всем, кто помог исправить это исправление!

Я успешно настроил свой кластер Kubernetes на centos-release-7-3.1611.el7.centos.x86_64, выполнив следующие шаги (я предполагаю, что Docker уже установлен):

1) (из /etc/yum.repo.d/kubernetes.repo) baseurl = http: //yum.kubernetes.io/repos/kubernetes-el7-x86_64-unstable
=> Чтобы использовать нестабильный репозиторий для последней версии Kubernetes 1.6.1
2) yum install -y kubelet kubeadm kubectl kubernetes-cni
3) (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) добавьте "--cgroup-driver = systemd" в конец последней строки.
=> Это потому, что Docker использует systemd для cgroup-driver, а kubelet использует cgroupfs для cgroup-driver.
4) systemctl включить kubelet && systemctl start kubelet
5) kubeadm init --pod-network-cidr 10.244.0.0/16
=> Если вы раньше добавляли --api-Advertise-addresses, вам нужно вместо этого использовать --apiserver-Advertise-address.
6) cp /etc/kubernetes/admin.conf $ HOME /
sudo chown $ (идентификатор -u): $ (идентификатор -g) $ HOME / admin.conf
экспорт KUBECONFIG = $ HOME / admin.conf
=> Без этого шага вы можете получить ошибку с помощью kubectl get
=> Я этого не делал с 1.5.2
7) kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml
=> 1.6.0 вводит управление доступом на основе ролей, поэтому вы должны добавить ClusterRole и ClusterRoleBinding перед созданием демона Flannel
8) kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
=> Создать демон Flannel
9) (на каждом подчиненном узле) kubeadm join --token (ваш токен) (ip) :( порт)
=> как показано в результате kubeadm init

Все вышеперечисленные шаги являются результатом объединения предложений из различных проблем, связанных с Kubernetes-1.6.0, особенно с kubeadm.

Надеюсь, это сэкономит ваше время.

@eastcirclek @Sliim Ты

@eastcirclek, это были именно те шаги, которые я только что выполнил, запросив также несколько форумов. Может быть, разница в часовых поясах? Спасибо всем, эта тема была действительно полезной.

У меня есть сервер Ubuntu 16.04 на AWS, и я выполнил шаги

1. отредактируйте /etc/systemd/system/kubelet.service.d/10-kubeadm.conf и удалите $ KUBELET_NETWORK_ARGS
2. kubeadm reset, чтобы очистить предыдущую попытку запустить его
3. kubeadm init --token =--apiserver-Advertise-address =

который, по-видимому, работал правильно, но затем, когда я пытаюсь установить Calico в качестве сетевого плагина, я получаю следующую ошибку
В соединении с сервером localhost: 8080 было отказано - вы указали правильный хост или порт?

Команда k8s работает над патчем?

Спасибо

@overip Я не думаю, что для этого требуется какой-либо патч ... Вам просто нужно указать правильный файл kubeconfig при использовании kubectl. kubeadm должен был записать его в /etc/kubernetes/admin.conf .

@jimmycuadra, не могли бы вы объяснить, как это сделать?

@overip В выводе kubeadm init есть инструкции:

To start using your cluster, you need to run (as a regular user):

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

Лично я предпочитаю копировать файл в $HOME/.kube/config , где kubectl будет искать его по умолчанию. Тогда вам не нужно устанавливать переменную окружения KUBECONFIG.

Если вы планируете использовать kubectl со своего локального компьютера, вы можете использовать scp (или даже просто скопировать и вставить содержимое), чтобы записать его в ~/.kube/config на вашем собственном компьютере.

Поищите "admin.conf" в этом выпуске GitHub для получения дополнительных сведений. Об этом упоминалось несколько раз.

@eastcirclek - выполнил шаги, но по какой-то причине узлы не могут правильно установить фланель.
(Примечание: на мастере все гладко.)

Apr 13 22:31:11 node2 kubelet[22893]: I0413 22:31:11.666206   22893 kuberuntime_manager.go:458] Container {Name:install-cni Image:quay.io/coreos/flannel:v0.7.0-amd64 Command:[/bin/sh -c set -e -x; cp -f /etc/kube-flannel/cni-conf.json /etc/cni/net.d/10-flannel.conf; while true; do sleep 3600; done] Args:[] WorkingDir: Ports:[] EnvFrom:[] Env:[] Resources:{Limits:map[] Requests:map[]} VolumeMounts:[{Name:cni ReadOnly:false MountPath:/etc/cni/net.d SubPath:} {Name:flannel-cfg ReadOnly:false MountPath:/etc/kube-flannel/ SubPath:} {Name:flannel-token-g65nf ReadOnly:true MountPath:/var/run/secrets/kubernetes.io/serviceaccount SubPath:}] LivenessProbe:nil ReadinessProbe:nil Lifecycle:nil TerminationMessagePath:/dev/termination-log TerminationMessagePolicy:File ImagePullPolicy:IfNotPresent SecurityContext:nil Stdin:false StdinOnce:false TTY:false} is dead, but RestartPolicy says that we should restart it.
Apr 13 22:31:11 node2 kubelet[22893]: I0413 22:31:11.666280   22893 kuberuntime_manager.go:742] checking backoff for container "install-cni" in pod "kube-flannel-ds-3smf7_kube-system(2e6ad0f9-207f-11e7-8f34-0050569120ff)"
Apr 13 22:31:12 node2 kubelet[22893]: I0413 22:31:12.846325   22893 operation_generator.go:597] MountVolume.SetUp succeeded for volume "kubernetes.io/configmap/2e6ad0f9-207f-11e7-8f34-0050569120ff-flannel-cfg" (spec.Name: "flannel-cfg") pod "2e6ad0f9-207f-11e7-8f34-0050569120ff" (UID: "2e6ad0f9-207f-11e7-8f34-0050569120ff").
Apr 13 22:31:12 node2 kubelet[22893]: I0413 22:31:12.846373   22893 operation_generator.go:597] MountVolume.SetUp succeeded for volume "kubernetes.io/secret/2e6ad0f9-207f-11e7-8f34-0050569120ff-flannel-token-g65nf" (spec.Name: "flannel-token-g65nf") pod "2e6ad0f9-207f-11e7-8f34-0050569120ff" (UID: "2e6ad0f9-207f-11e7-8f34-0050569120ff").

Просто поделитесь моим методом обхода. Во-первых, требуется $ KUBELET_NETWORK_ARGS, иначе CNI не будет включен / настроен. Удаление и последующее восстановление $ KUBELET_NETWORK_ARGS кажется слишком сложным.
Когда kubeadm init показывает «[apiclient] Первый узел зарегистрирован, но еще не готов», кластер k8s фактически готов обслуживать запрос. В то время пользователь мог просто перейти к шагу 3/4 https://kubernetes.io/docs/getting-started-guides/kubeadm/ следующим образом.

To start using your cluster, you need to run (as a regular user):

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:  http://kubernetes.io/docs/admin/addons/

Когда пользователь устанавливает podnetwork, убедитесь, что сервисному аккаунту политики podnetwork предоставлено достаточно прав. Возьмем, к примеру, фланель. Я просто привязываю роль администратора кластера к служебной учетной записи flannel следующим образом. Это может быть не идеально, и вы могли бы определить конкретную роль для фланелевого сервисного аккаунта. Кстати, когда пользователь развертывает другую дополнительную службу, такую ​​как панель инструментов, также требуется предоставить достаточно разрешений для связанной учетной записи службы.

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: flannel:daemonset
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: flannel
  namespace:  kube-system

После того, как сервер podnetwork будет готов, kubeadm init покажет, что узел готов, и пользователь может продолжить выполнение инструкций.

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

Уже есть https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml

Спасибо всем за помощь.
Наконец-то полностью рабочий k8s 1.6.1 с фланелью. Все теперь в доступных плейбуках.
Проверено на Centos / RHEL. Началась подготовка и для Debian на основе (например, Ubuntu), но может потребоваться некоторая доработка.

https://github.com/ReSearchITEng/kubeadm-playbook/blob/master/README.md

PS: работа на основе sjenning / kubeadm-playbook - Большое спасибо @sjenning

Приготовление для присоединения к кластеру:
[обнаружение] Создан клиент обнаружения информации о кластере, запрашивающий информацию с " https://10.100.2.158 : 6443"
[обнаружение] Не удалось запросить информацию о кластере, попытаюсь снова: [configmaps "cluster-info" запрещен: пользователь " system: anonymous " не может получить configmaps в пространстве имен "kube-public"]
[обнаружение] Не удалось запросить информацию о кластере, попытаюсь снова: [configmaps "cluster-info" запрещен: пользователь " system: anonymous " не может получить configmaps в пространстве имен "kube-public"]

Я запустил узел как SelfHosting.