Kubernetes: сетевой плагин не готов: cni config неинициализирован

@PLoic По этому вопросу нет добавьте подпись :
(1) упоминание сигнатуры: @kubernetes/sig-<team-name>-misc
например, @kubernetes/sig-api-machinery-* для машинного оборудования API
(2) указание метки вручную: /sig <label>
например, /sig scalability для сигнатуры / масштабируемости

_Примечание: метод (1) вызовет уведомление для команды. Вы можете найти список команд здесь и список ярлыков здесь _

/ area [kubeadm]

@PLoic вы получаете эту ошибку, потому что сеть CNI не определена в /etc/cni/net.d, и вы, очевидно, используете сетевой плагин CNI. Что-то должно записать файл конфигурации в этот каталог, чтобы сообщить драйверу CNI, как настроить сеть. Я не уверен, что / как kubeadm это делает, поэтому оставлю это @jbeda или другим специалистам по kubeadm.

xref: # 43567

@dcbw Привет, dcbw, среда такая же, как у @PLoic , но я получаю ту же ошибку

Кажется, он работает, удалив $KUBELET_NETWORK_ARGS в /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

удаление $ KUBELET_NETWORK_ARGS у меня не работает.

@PLoic тоже у меня не работает

@PLoic на шаге 3, какую сеть модулей вы установили? Существуют различные варианты, и устранение неполадок после этого зависит от конкретного случая.

@PLoic также, журналы kubelet были бы отличными

попробуйте применить этот плагин: kubectl apply --filename https://git.io/weave-kube-1.6
меня устраивает.

@PLoic @dcbw Я устанавливаю плагин flannel для k8s (1.7), все равно получаю ту же ошибку. Можете ли вы предложить решение?

14 июля 17:57:20 node2 kubelet: W0714 17: 57: 20.540849 17504 cni.go: 189] Невозможно обновить конфигурацию cni: сети не найдены в /etc/cni/net.d
14 июля 17:57:20 node2 kubelet: E0714 17: 57: 20.541001 17504 kubelet.go: 2136] Сеть времени выполнения контейнера не готова: NetworkReady = false, причина: NetworkPluginNotReady сообщение: docker : сетевой плагин не готов: cni config неинициализирован
14 июля, 17:57:23 node2 kubelet: I0714 17: 57: 23.032330 17504 kubelet.go: 1820] пропуск синхронизации подов - [Не удалось запустить ContainerManager версия systemd не поддерживает возможность запуска среза как временного модуля]

Извините за задержку, я использовал Weave, попробую обновить kubernetes до 1.7.1 и с новой версией weave

Я обновил все свои компоненты, и, похоже, все работает! :)

Можно ли закрыть эту проблему @PLoic ?

@cmluciano Да, думаю, можно закрыть эту проблему

Удаление $ KUBELET_NETWORK_ARGS в /etc/systemd/system/kubelet.service.d/10-kubeadm.conf работает для меня.
Спасибо @PLoic

Обратите внимание, что KUBELET_NETWORK_ARGS - это то, что сообщает kubelet, какой тип сетевого плагина следует ожидать. Если вы удалите его, kubelet не ожидает никакого плагина, и, следовательно, вы получите то, что дает вам базовая среда выполнения контейнера: обычно Docker «мостовая» сеть.

В некоторых случаях это нормально, особенно если у вас только одна машина. Это бесполезно, если вы действительно хотите использовать CNI.

Я вижу ту же ошибку с kubeadm, где она навсегда удаляется:

[apiclient] Created API client, waiting for the control plane to become ready

В "journalctl -r -u kubelet" я снова и снова вижу эти строки:
Aug 31 16:34:41 k8smaster1 kubelet[8876]: E0831 16:34:41.499982 8876 kubelet.go:2136] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized Aug 31 16:34:41 k8smaster1 kubelet[8876]: W0831 16:34:41.499746 8876 cni.go:189] Unable to update cni config: No networks found in /etc/cni/net.d

Детали версии:
`kubeadm version: & version.Info {Major:" 1 ", Minor:" 7 ", GitVersion:" v1.7.4 ", GitCommit:" 793658f2d7ca7f064d2bdf606519f9fe1229c381 ", GitTreeState:" clean ", BuildDate:" 30-08-17T08: "2017-08-17T08 : 51Z ", GoVersion:" go1.8.3 ", компилятор:" gc ", платформа:" linux / amd64 "}

Версия Kubectl: Версия клиента: version.Info {Major: "1", Minor: "7", GitVersion: "v1.7.4", GitCommit: "793658f2d7ca7f064d2bdf606519f9fe1229c381", GitTreeState: "clean", BuildDate: "2017-08-17T08 : 48: 23Z ", GoVersion:" go1.8.3 ", компилятор:" gc ", платформа:" linux / amd64 "}`

Подробная информация об ОС:
Operating System: Red Hat Enterprise Linux Server 7.3 (Maipo) Kernel: Linux 3.10.0-514.el7.x86_64 Architecture: x86-64
Любая помощь очень ценится!

@ ashish-billore какого провайдера CNI вы установили?

Я получаю Unable to update cni config: No networks found in /etc/cni/net.d с недавним советом github по основной ветке - "v1.9.0-alpha.0.690+9aef242a4c1e42-dirty"

в Ubuntu 17.04

если я удалю эту строку из 10-kubelet.conf :
Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/ --cni-bin-dir=/opt/cni/bin""

запускается kubelet, затем я устанавливаю weave-net в качестве плагина pod-network, но модули kube-system никогда не запускаются (они остаются запланированными?).

kube-system   etcd-luboitvbox                      0/1       Pending   0          31m
kube-system   kube-apiserver-luboitvbox            0/1       Pending   0          31m
kube-system   kube-controller-manager-luboitvbox   0/1       Pending   0          31m
kube-system   kube-dns-1848271846-7mw9x            0/3       Pending   0          32m
kube-system   kube-proxy-k89jp                     0/1       Pending   0          32m
kube-system   kube-scheduler-luboitvbox            0/1       Pending   0          31m
kube-system   weave-net-v8888                      0/2       Pending   0          30m

То же самое и с фланелью.

Здравствуйте,

Для информации, у меня возникла эта проблема: Kubernetes представляет RBAC начиная с версии 1.6, нам нужно создать соответствующую учетную запись службы, правила RBAC и фланелевый демон, чтобы kubelet мог правильно взаимодействовать с сервером api.

Вам нужно запустить:

$ kubectl create -f https://raw.githubusercontent.com/coreos/flannel/v0.9.0/Documentation/kube-flannel.yml

Я надеюсь, что это помогает.

Привет, ребята, почему закрыли этот вопрос? Не похоже, что было решение?

Я вижу это при попытке установить кластер k8 с плагином weave CNI.

@vinayvenkat проблема была закрыта, потому что OP обновился, и проблема исчезла.

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

Если ваша проблема связана с Weave Net, вы можете получить более конкретный ответ на странице https://github.com/weaveworks/issues/new или в Slack сообщества Weave.

Я тоже столкнулся с той же проблемой. Но это не фатальная ошибка при установке k8s.
Проблемой может быть то, что вы используете kubelet cgroups, которые отличаются от cgroups docker, настраиваете как kubelet, так и docker, снова запускаете kubeadm, он может работать хорошо.
надеюсь помочь вам.

ОС (например, из / etc / os-release): CentOS 7

Если вы видите, что каталог /etc/cni/net.d на узле пуст, несмотря на то, что на нем запущен модуль Pod Network Provider, попробуйте setenforce 0 и удалите модуль Pod Network Provider. k8s перезапустит его и, надеюсь, теперь он сможет скопировать свой config.

не забудьте перезапустить кубелет ...
удаление $ KUBELET_NETWORK_ARGS в /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
systemctl включить kubelet && systemctl start kubelet
затем снова присоединиться к узлу
этот способ отлично работает для меня ~

Привет,

Если вы прокомментируете $ KUBELET_NETWORK_ARGS в /etc/systemd/system/kubelet.service.d/10-kubeadm.conf и перезапустите службу / сервер, или если вы сбросите kubeadm и снова подключитесь к / kubeadm init, чтобы воссоздать кластер
и снова присоединяемся к узлам,

модули будут в рабочем состоянии, но если вы опишете модуль kube-dns, вы увидите

Предупреждение Неработоспособный 1 м (x4 более 2 м) кубелет, мастер Ошибка проверки готовности: Get http://172.17.0.2 : 8081 / готовность: наберите tcp 172.17.0.2:8081: getsockopt: соединение отклонено

полный вывод, как показано ниже.

События:
Тип Причина Возраст из сообщения
---- ------ ---- ---- -------
Обычный Запланированный 10-метровый планировщик по умолчанию Успешно назначен мастер kube-dns-6f4fd4bdf-qxmzn
Нормальный SuccessfulMountVolume 10 м кубелет, мастер MountVolume.SetUp успешно завершен для тома "kube-dns-token-47fpd"
Нормальный SuccessfulMountVolume 10m kubelet, главный MountVolume.SetUp успешно завершен для тома "kube-dns-config"
Обычный вытягивающий кубелет 10м, мастер вытягивающий изображение "gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.7"
Нормальный Вытащил 10м кубелет, мастер Вытащил изображение "gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.7"
Нормально Создан 10-метровый кубелет, мастер Создан контейнер
Нормальный Запущенный 10м кубелет, мастер Запущенный контейнер
Обычный вытягивающий кубелет 10м, мастер вытягивающий изображение "gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64:1.14.7"
Нормально Вытащил 10м кубелет, мастер Удачно вытащил изображение "gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64:1.14.7"
Нормально Создан 10-метровый кубелет, мастер Создан контейнер
Нормальный Запущенный 10м кубелет, мастер Запущенный контейнер
Обычное вытягивание 10м кубелет, мастер вытягивает изображение "gcr.io/google_containers/k8s-dns-sidecar-amd64:1.14.7"
Нормальный Вытащил 10м кубелет, мастер Вытащил изображение "gcr.io/google_containers/k8s-dns-sidecar-amd64:1.14.7"
Нормально Создан 10-метровый кубелет, мастер Создан контейнер
Нормальный Запущенный 10м кубелет, мастер Запущенный контейнер
Нормальный SuccessfulMountVolume 2 м кубелет, мастер MountVolume.SetUp успешно завершен для тома "kube-dns-token-47fpd"
Нормальный SuccessfulMountVolume 2 м кубелет, мастер MountVolume.SetUp успешно завершен для тома "kube-dns-config"
Нормальный SandboxChanged 2m kubelet, основная песочница Pod изменена, она будет убита и создана заново.
Нормальный Вытащенный 2-метровый кубелет, основной образ контейнера "gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.7" уже присутствует на машине
Нормально Создан 2м кубелет, мастер Создан контейнер
Нормальный Запущенный 2м кубелет, Мастер Запущенный контейнер
Нормально Создан 2м кубелет, мастер Создан контейнер
Нормальный Вытащенный 2-метровый кубелет, основной образ контейнера "gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64:1.14.7" уже присутствует на компьютере
Нормальный Запущенный 2м кубелет, Мастер Запущенный контейнер
Нормальный Вытащенный 2-метровый кубелет, главный образ контейнера "gcr.io/google_containers/k8s-dns-sidecar-amd64:1.14.7" уже присутствует на машине
Нормально Создан 2м кубелет, мастер Создан контейнер
Нормальный Запущенный 2м кубелет, мастер Запущенный контейнер
Предупреждение Неработоспособный 1 м (x4 более 2 м) кубелет, мастер Ошибка проверки готовности: Get http://172.17.0.2 : 8081 / готовность: набрать tcp 172.17.0.2:8081: getsockopt: соединение отклонено

docker @ master : ~ $ kubectl получить поды --namespace = kube-system
ИМЯ ГОТОВ СОСТОЯНИЕ ВОЗРАСТ
etcd-master 1/1 Бег 1 14м
kube-apiserver-master 1/1 Бег 1 14м
kube-controller-manager-master 1/1 Бег 1 14м
kube-dns-6f4fd4bdf-qxmzn 3/3 Бег 3 15м
kube-proxy-d54fk 1/1 Бег 1 15м
kube-scheduler-master 1/1 Бег 1 14м

Никто еще не упомянул SELinux. Я получил эту ошибку при запуске kubeadm join на машине Centos 7 с SELinux в принудительном режиме. Установка setenforce 0 и повторный запуск kubeadm устранили мою проблему.

@jdanekrh https://github.com/kubernetes/kubernetes/issues/48798#issuecomment -359193792

Спасибо, что setenforce 0 работал у меня.

1. $ KUBELET_NETWORK_ARGS вынуть ， проблему не решить
2. усилие 0
3. systemctl остановить firewalld
4.docker cgroups drivers: systemd与 Environment = "KUBELET_CGROUP_ARGS = - cgroup-driver = systemd"
соответствие
но вы знаете, что проблема все еще существует.

20 мая 20:10:45 k8s kubelet: I0520 20: 10: 45.244383 17638 kubelet.go: 1794] пропуск синхронизации подов - [время выполнения контейнера не работает]
20 мая 20:10:45 k8s kubelet: E0520 20: 10: 45.920981 17638 refctor.go: 205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:460: не удалось добавить в список * v1.Node: получить https: //192.168.18.90 : 6443 / api / v1 / nodes? FieldSelector = metadata.name% 3Dk8s.master.com & limit = 500 & resourceVersion = 0: набрать tcp 192.168.18.90:6443: getsockopt: в соединении отказано
20 мая 20:10:45 k8s kubelet: E0520 20: 10: 45.924021 17638 refctor.go: 205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:451: Не удалось добавить в список * v1.Service: Получить https: //192.168.18.90 : 6443 / api / v1 / services? Limit = 500 & resourceVersion = 0: набрать tcp 192.168.18.90:6443: getsockopt: соединение отклонено
20 мая 20:10:45 k8s kubelet: E0520 20: 10: 45.935594 17638 refctor.go: 205] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:47: Не удалось перечислить * v1.Pod: Get https://192.168.18.90 : 6443 / api / v1 / pods? fieldSelector = spec.nodeName% 3Dk8s.master.com & limit = 500 & resourceVersion = 0: наберите tcp 192.168.18.90:6443: getsockopt: в соединении отказано

23 мая, 10:19:45 arch kubelet [13585]: E0523 10: 19: 45.909458 13585 kubelet.go: 2095] Сеть времени выполнения контейнера не готова: NetworkReady = false, причина: NetworkPluginNotReady сообщение: docker : сетевой плагин не готов: cni config неинициализированный
23 мая 10:19:46 arch kubelet [13585]: E0523 10: 19: 46.002646 13585 helpers.go: 468] PercpuUsage имел 0 процессоров, но фактическое число - 8; игнорирование лишних процессоров

`sudo kubectl получить узел

ИМЯ СТАТУС РОЛИ ВОЗРАСТНАЯ ВЕРСИЯ
127.0.0.1 NotReady23ч v1.8.13`

Просто столкнулся с этим, и, похоже, из-за того, что файл фактически пуст, вот вывод контейнера install-cni :

$ k logs canal-25rct install-cni -n kube-system
ls: /calico-secrets: No such file or directory
Wrote Calico CNI binaries to /host/opt/cni/bin
CNI plugin version: v3.1.2
/host/secondary-bin-dir is non-writeable, skipping
CNI config: {
Created CNI config 10-calico.conflist
Done configuring CNI.  Sleep=true

И в /etc/cni/net.d/10-calico.conflist :

$ cat /etc/cni/net.d/10-calico.conflist 
{

Когда я пытаюсь выполнить оболочку в контейнере (может быть, это должен быть initContainer ?), Я получаю следующее:

$ k exec -it canal-25rct -c install-cni -n kube-system -- /bin/bash
Error: Malformed environment entry: "  "name": "k8s-pod-network",
": Success
command terminated with exit code 45

Это странно, потому что версия скрипта не изменилась, и единственное, что я недавно изменил, - это переключение на rkt для запуска контейнеров. Кроме того, это есть в Container Linux (CoreOS), если это вообще помогает.

Привет, ребята из K8s!

У меня много раз возникала одна и та же проблема. Например, во время инициализации K8s что-то пошло не так, и мне пришлось использовать kubeadm reset и снова инициализировать K8s. После запуска команды инициализации я получил в журнале kubelet эту ошибку:

Jun 01 10:13:40 vncub0626 kubelet[18861]: I0601 10:13:40.665823   18861 kubelet.go:2102] Container runtime status: Runtime Conditions: RuntimeReady=true reason: message:, NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Jun 01 10:13:40 vncub0626 kubelet[18861]: E0601 10:13:40.665874   18861 kubelet.go:2105] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

... Я был зол от этого сообщения об ошибке - ничего не помогло. Итак, я сказал себе - сначала была запущена инициализация, но не повторная инициализация. Таким образом, это не было вызвано этой строкой в ​​конфигурации Kubelet: KUBELET_NETWORK_ARGS и я не согласен с ее комментарием. Итак, я снова и снова читаю журнал kubelet ... и, наконец, я заметил в журнале следующее сообщение об ошибке:

Jun 01 10:13:29 vncub0626 kubelet[18861]: E0601 10:13:29.376339   18861 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:465: Failed to list *v1.Service: Get https://10.96.22.11:6443/api/v1/services?limit=500&resourceVersion=0: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")

Эта ошибка была вызвана неправильным файлом ~/.kube/config в домашнем каталоге после предыдущей инициализации. После его удаления я снова запускаю инициализацию ... и вуаля ... инициализация успешно завершена. :]

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

@waldauf ты прав !!! здорово!!!

Выполнить команду Follow работает хорошо

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.10.0/Documentation/kube-flannel.yml

версия kubeadm v1.10.3

Удаление $ KUBELET_NETWORK_ARGS в /etc/systemd/system/kubelet.service.d/10-kubeadm.conf работает для меня.

Повторяем для видимости:

Обратите внимание, что KUBELET_NETWORK_ARGS - это то, что сообщает kubelet, какой тип сетевого плагина следует ожидать. Если вы удалите его, kubelet не ожидает никакого плагина, и, следовательно, вы получите то, что дает вам базовая среда выполнения контейнера: обычно Docker «мостовая» сеть.

В некоторых случаях это нормально, особенно если у вас только одна машина. Это бесполезно, если вы действительно хотите использовать CNI.

@waldauf спасибо , это работает

Это случилось со мной, когда мой плагин фланели не был установлен правильно.

Сегодня я следил за этим руководством (https://www.techrepublic.com/article/how-to-install-a-kubernetes-cluster-on-centos-7/) и пропустил конфигурацию cgroupfs в "/ etc / systemd /system/kubelet.service.d/10-kubeadm.conf ". Как только я исправил, это работало как шарм

https://github.com/kubernetes/kubernetes/issues/48798#issuecomment -395965665

@ChinaSilence Вы можете объяснить, почему мы должны использовать фланель? Разве без фланели не обойтись?

flannel 0.10.0 и kubernetes 1.12.0 как-то не могут работать вместе. что-то не так с kubernetes 1.12.0, поэтому я понизил kubernetes до 1.11.3, и все работает нормально.

Надеюсь, что Kubernetes скоро исправит эту проблему.

@ bilalx20 могу это подтвердить - фланель у меня тоже сломалась в 1.12.
что вы можете сделать, это попробовать плетение или каллико, они работают.

У меня эта проблема на моем Ubuntu 16.04 с k8s 1.12.

Перейдите на 1.11.0, и все будет в порядке.

У меня эта проблема на CentOS 7.5 с k8s 1.12

Удаление cni plugin conf из /var/lib/kubelet/kubeadm-flags.env отлично работает

flanneld требует исправления для k8s 1.12.
Используйте этот PR (до утверждения):
kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
это известная проблема: https://github.com/coreos/flannel/issues/1044

Я столкнулся с проблемой, описанной @ReSearchITEng в 1.12.1. Его / ее решение сработало для меня.
РЕДАКТИРОВАТЬ: поцарапайте это, один из узлов по-прежнему показывает ту же проблему после kubeadm join
EDIT2: несвязанная проблема, оказывается, на этом узле графического процессора отсутствовала среда выполнения nvidia-container. Диагностируется с помощью journalctl -xeu kubelet на неисправном узле

TL; DR: решение работает

Подтверждая, что решение от @ReSearchITEng работает, у меня нет моего главного узла в рабочем состоянии, а фланель работает.

На всякий случай кто-нибудь погуглиет. У меня была та же проблема, в моем случае процесс cloud-init установил для параметра NM_CONTROLLED в / etc / sysconfig / network-scripts / ifcfg- {interface-name} значение no.
Для этого параметра необходимо установить значение yes, чтобы NetworkManager создал необходимый файл resolv.conf для модулей sdn.

Мне не удалось применить манифесты плетения, следовательно, сетевой плагин не был инициализирован.
Примечание для себя: прочтите все руководство по установке Weave, прежде чем искать ответы в другом месте: +1:

flanneld требует исправления для k8s 1.12.
Используйте этот PR (до утверждения):
kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
это известная проблема: coreos / flannel # 1044

Дополнительно:
Я думаю, что эта проблема вызвана kuberadm first init coredns, но не init flannel, поэтому он выдает «сетевой плагин не готов: cni config неинициализирован».
Решение:

1. Установить фланель на kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
2. Сбросить модуль coredns
   kubectl delete coredns-xx-xx
3. Затем запустите kubectl get pods чтобы проверить, работает ли он.

если вы видите эту ошибку, «cni0» уже имеет IP-адрес, отличный от 10.244.1.1/24 ».
следовать этому:

ifconfig  cni0 down
brctl delbr cni0
ip link delete flannel.1

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

root<strong i="28">@master</strong>:/home/moonx/yaml# kubectl logs coredns-86c58d9df4-x6m9w -n=kube-system
.:53
2019-01-22T08:19:38.255Z [INFO] CoreDNS-1.2.6
2019-01-22T08:19:38.255Z [INFO] linux/amd64, go1.11.2, 756749c
CoreDNS-1.2.6
linux/amd64, go1.11.2, 756749c
 [INFO] plugin/reload: Running configuration MD5 = f65c4821c8a9b7b5eb30fa4fbc167769
 [FATAL] plugin/loop: Forwarding loop detected in "." zone. Exiting. See https://coredns.io/plugins/loop#troubleshooting. Probe query: "HINFO 1599094102175870692.6819166615156126341.".

Затем вы можете увидеть файл «/etc/resolv.conf» на отказавшем узле, если сервер имен - localhost, произойдет возврат по петле. Измените на:

#nameserver 127.0.1.1
nameserver 8.8.8.8

вы добавляете --network-plugin = cni в конфигурацию запуска kueblet
в моей системе:
1. vim /etc/systemd/system/kubelet.service
2. удалить --network-plugin = cni
3. перезапустите kubelet （systemctl daemon-reload; systemctl перезапустить кубелет）

Пожалуйста, сделайте 3 шага в вашей системе, возможно, ваша установка отличается от моей, пожалуйста, сделайте это так

@mdzddl вы удалили --network-plugin = cni, потому что kubelet жалуется на cni? Не так уж и умно. Не рекомендуется удалять сетевой плагин по умолчанию.

flanneld требует исправления для k8s 1.12.
Используйте этот PR (до утверждения):
kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
это известная проблема: coreos / flannel # 1044

Работает на меня !

@mdzddl вы удалили --network-plugin = cni, потому что kubelet жалуется на cni? Не так уж и умно. Не рекомендуется удалять сетевой плагин по умолчанию.

Тогда какое решение

flanneld требует исправления для k8s 1.12.
Используйте этот PR (до утверждения):
kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
это известная проблема: coreos / flannel # 1044

Дополнительно:
Я думаю, что эта проблема вызвана kuberadm first init coredns, но не init flannel, поэтому он выдает «сетевой плагин не готов: cni config неинициализирован».
Решение:

1. Установить фланель на kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
2. Сбросить модуль coredns
   kubectl delete coredns-xx-xx
3. Затем запустите kubectl get pods чтобы проверить, работает ли он.

если вы видите эту ошибку, «cni0» уже имеет IP-адрес, отличный от 10.244.1.1/24 ».
следовать этому:

ifconfig  cni0 down
brctl delbr cni0
ip link delete flannel.1

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

root<strong i="29">@master</strong>:/home/moonx/yaml# kubectl logs coredns-86c58d9df4-x6m9w -n=kube-system
.:53
2019-01-22T08:19:38.255Z [INFO] CoreDNS-1.2.6
2019-01-22T08:19:38.255Z [INFO] linux/amd64, go1.11.2, 756749c
CoreDNS-1.2.6
linux/amd64, go1.11.2, 756749c
 [INFO] plugin/reload: Running configuration MD5 = f65c4821c8a9b7b5eb30fa4fbc167769
 [FATAL] plugin/loop: Forwarding loop detected in "." zone. Exiting. See https://coredns.io/plugins/loop#troubleshooting. Probe query: "HINFO 1599094102175870692.6819166615156126341.".

Затем вы можете увидеть файл «/etc/resolv.conf» на отказавшем узле, если сервер имен - localhost, произойдет возврат по петле. Измените на:

#nameserver 127.0.1.1
nameserver 8.8.8.8

kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
clusterrole.rbac.authorization.k8s.io/flannel создан
clusterrolebinding.rbac.authorization.k8s.io/flannel создан
serviceaccount / flannel создан
configmap / kube-flannel-cfg создан
невозможно распознать " https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml ": нет совпадений для вида "DaemonSet" в версии "extensions / v1beta1"
невозможно распознать " https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml ": нет совпадений для вида "DaemonSet" в версии "extensions / v1beta1"
невозможно распознать " https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml ": нет совпадений для вида "DaemonSet" в версии "extensions / v1beta1"
невозможно распознать " https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml ": нет совпадений для вида "DaemonSet" в версии "extensions / v1beta1"
невозможно распознать " https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml ": нет совпадений для вида "DaemonSet" в версии "extensions / v1beta1"

Выдает ошибку, как указано выше

flannel не обновил свой манифест в соответствии с последними изменениями в k8s 1.16.
попробуйте другой плагин CNI, например Calico или WeaveNet.

... или исправьте манифесты фланели, чтобы использовать apps/v1 вместо extensions/v1beta1

У меня эта проблема на Ubuntu 16.04 с k8s 1.16 (я запускаю ubuntu на vagrant)

Удаление конфигурации плагина cni из /var/lib/kubelet/kubeadm-flags.env отлично работает

flannel не обновил свой манифест в соответствии с последними изменениями в k8s 1.16.
попробуйте другой плагин CNI, например Calico или WeaveNet.
...
... или исправьте манифесты фланели, чтобы использовать apps / v1 вместо extension / v1beta1

Это было исправлено некоторое время назад, но ссылки в документации Kubernetes по-прежнему указывают на более старую версию, которая не работает (https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster- kubeadm / имеет https://raw.githubusercontent.com/coreos/flannel/2140ac876ef134e0ed5af15c65e414cf26827915/Documentation/kube-flannel.yml). Использование «master» вместо этого работает, а также устраняет другую проблему (отсутствующая версия в конфигурации CNI).

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/

использует https://raw.githubusercontent.com/coreos/flannel/2140ac876ef134e0ed5af15c65e414cf26827915/Documentation/kube-flannel.yml

который должен включать исправления как cniVersion, так и apps / v1.

Вот что я увидел: эта ошибка возникает, когда у вас еще не запущена flannel, но вы запускаете kublet только с манифестами apiserver, scheduler и controller-manager - ПОКА У ВАС ЕСТЬ ЭТА СТРОКА в 10-kubeadm.conf - "Environment =" KUBELET_NETWORK_ARGS = - network-plugin = cni --cni-conf-dir = / etc / cni / net.d --cni-bin-dir = / opt / cni / bin --node-ip = 192.168.8.11 "

Прокомментируйте это и запустите кубелет.
Затем появляются основные модули kube-system.
Затем установите kube-proxy
Затем установите фланель
* Затем раскомментируйте строку выше и перезапустите кубелет *
Установите core-dns / kube-dns

Привет,
Я пытаюсь установить версию 1.16.0 Я использую подключение Kuberouter и получаю те же ошибки

Сеть времени выполнения контейнера не готова: NetworkReady = false, причина: NetworkPluginNotReady, сообщение: docker : сетевой плагин не готов: cni config неинициализирован

Привет,
Я пытаюсь установить версию 1.16.0 Я использую подключение Kuberouter и получаю те же ошибки

Сеть времени выполнения контейнера не готова: NetworkReady = false, причина: NetworkPluginNotReady, сообщение: docker : сетевой плагин не готов: cni config неинициализирован

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

это новая свежая установка версии 1.16.0 на Amazon.
Я использую этот AMI - k8s-1.16-debian-stretch-amd64-hvm-ebs-2020-01-17
uname -a
Linux ip-172-28-125-218 4.9.0-11-amd64 # 1 SMP Debian 4.9.189-3 + deb9u2 (2019-11-11) x86_64 GNU / Linux

если я установлю 1.15.0, никаких проблем не возникнет.

это то, что я вижу в системном журнале главных узлов.

12 марта 05:26:22 ip-172-28-125-218 kubeletÄ3656Å: E0312 05: 26: 22.761009 3656 kubelet.go: 2187Å Сеть времени выполнения контейнера не готова: NetworkReady = false причина: NetworkPluginNotReady сообщение: docker : сетевой плагин не работает готово: cni config неинициализирован
12 марта 05:26:25 ip-172-28-125-218 dockerÄ3570Å: I0312 05: 26: 25.713681 3619 dns.go: 47Å DNSView без изменений: 5
12 марта 05:26:25 ip-172-28-125-218 kubeletÄ3656Å: W0312 05: 26: 25.883857 3656 cni.go: 202Å Ошибка проверки конфигурации CNI и äkubernetes false Ä0xc0009d8260Å Ä123 34 99 110 105 86 101 114 115 105 111 110 34 58 34 34 44 34 110 97 109 101 34 58 34 107 117 98 101 114 110 101 116 101 115 34 44 34 112 108 117 103 105 110 115 34 58 91 123 34 98 114 105100103101 34 58 34 107 117 117 98101 45 98114105100103101 34 44 34 105112 97109 34 58123 34 115117 98110101116 34 58 34 49 48 48 46 57 54 46 48 46 48 47 50 52 34 44 34116121112101 34 58 34 104 111 115 116 45 108 111 99 97 108 34 125 44 34 105 115 68 101 102 97 117 108 116 71 97 116 101 119 97 121 34 58 116 114 117 101 44 34 110 97 109 101 34 58 34 107 117 98 101 114 110 101 116 101 115 34 44 34 116 121 112 101 34 58 34 98 114 105 100 103 101 34 125 93 125Åå: Äplugin bridge не поддерживает версию конфигурации "" Å
12 марта 05:26:25 ip-172-28-125-218 kubeletÄ3656Å: W0312 05: 26: 25.883925 3656 cni.go: 237Å Невозможно обновить конфигурацию cni: в /etc/cni/net.d/ не найдено действительных сетей
12 марта 05:26:27 ip-172-28-125-218 kubeletÄ3656Å: E0312 05: 26: 27.762309 3656 kubelet.go: 2187Å Сеть времени выполнения контейнера не готова: NetworkReady = false причина: NetworkPluginNotReady сообщение: docker : сетевой плагин не работает готово: cni config неинициализирован
12 марта 05:26:30 ip-172-28-125-218 dockerÄ3570Å: I0312 05: 26: 30.713906 3619 dns.go: 47Å DNSView без изменений: 5
12 марта 05:26:30 ip-172-28-125-218 kubeletÄ3656Å: W0312 05: 26: 30.886362 3656 cni.go: 202Å Ошибка проверки конфигурации CNI и äkubernetes false Ä0xc0008fc000Å Ä123 34 99 110 105 86 101 114 115 105 111 110 34 58 34 34 44 34 110 97 109 101 34 58 34 107 117 98 101 114 110 101 116 101 115 34 44 34 112 108 117 103 105 110 115 34 58 91 123 34 98 114 105100103 101 34 58 34 107 117 117 98101 45 98114105100103101 34 44 34 105112 97109 34 58 123 34 115117 98110101116 34 58 34 49 48 48 46 57 54 46 48 46 48 47 50 52 34 44 34116121112101 34 58 34 104 111 115 116 45 108 111 99 97 108 34 125 44 34 105 115 68 101 102 97 117 108 116 71 97 116 101 119 97 121 34 58 116 114 117 101 44 34 110 97 109 101 34 58 34 107 117 98 101 114 110 101 116 101 115 34 44 34 116 121 112 101 34 58 34 98 114 105 100 103 101 34 125 93 125Åå: Äplugin bridge не поддерживает версию конфигурации "" Å
12 марта 05:26:30 ip-172-28-125-218 kubeletÄ3656Å: W0312 05: 26: 30.886428 3656 cni.go: 237Å Невозможно обновить конфигурацию cni: в /etc/cni/net.d/ не найдено действительных сетей

Удаление конфигурации плагина cni из /var/lib/kubelet/kubeadm-flags.env также работает на CentOS 7.6 с k8s 1.16.8

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

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

Спасибо @ikramuallah , это сработало для 1.18, дело в том, что это не сработало напрямую, потому что один из фланелевых контейнеров не мог быть вытащен, так как один из причальных сайтов выбрасывал 500. Итак, я предлагаю после применения YAML проверить, все ли появились фланелевые капсулы и отладили это. Проблема со ссылками, которую я поднял для справки, во фланеле. coreos / фланель # 1294

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

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

благодаря!

пожалуйста, ничего не меняйте. Просто запустите эту команду. Ошибка исчезнет.
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

благодаря!

Извините, я не могу перейти по ссылке. Что-то не так ?

Ссылка @juxuny в порядке, возможно, временные проблемы с подключением к сети?

Пожалуйста, помогите мне
Для kube-proxy-windows-xhxzw статус модуля - ContainerCreating. Когда я описываю модули, он выдает предупреждение как

Предупреждение NetworkNotReady 3m27s (x4964 более 168м) kubelet, сеть casts1 не готова: сеть времени выполнения не готова: NetworkReady = false причина: NetworkPluginNotReady сообщение: docker : сетевой плагин не готов: cni config неинициализирован

Все остальные модули находятся в рабочем состоянии. кроме kube-proxy-windows

Я создал среду kubernetes, как показано ниже:
Готовность к главному узлу V1.19.0 ОС RHEL 7
Рабочий узел NotReady V1.19.0 Windows Server 2019
Я пытаюсь присоединить рабочий узел Windows к главному узлу

Я использую фланелевую сеть. Я пробовал следующие решения:
1.kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

1. Измените cniVersion 10-flannel.confglist с "0.3.1" на "0.2.0"
   10-flannel.confglist уже был там.

Пожалуйста, дайте мне знать точную проблему

В моем случае, когда я являюсь мастером init kubernetes, у меня была эта проблема. После удаления всех данных в etcd процесс инициализации прошел успешно
На всех узлах etcd:
systemctl stop etcd
rm -rf / var / lib / etcd / *
systemctl daemon-reload && systemctl включить etcd && systemctl start