/ cc @lukemarsden @luxas @mikedanese

Если мы полностью вернем # 43474, мы снова окажемся в ситуации, когда мы сломаем плагины CNI 0.2.0 (см. Https://github.com/kubernetes/kubernetes/issues/43014)

Стоит ли нам подумать о том, чтобы сделать что-то вроде https://github.com/kubernetes/kubernetes/pull/43284?

Также / cc @thockin

/ cc @ kubernetes / сиг-сети-ошибки

Ссылка: https://github.com/kubernetes/kubernetes/issues/43397#issuecomment -289978351

@jbeda Могу ли я получить журналы kubelet с --loglevel = 5?

@yujuhong - вы упомянули, что считаете, что это работает так, как задумано. Тем не менее, kubeadm зависел от этого поведения. Мы ввели критическое изменение в # 43474. Мы можем поговорить о правильном способе исправить это в 1.7, но пока нам нужно снова заставить kubeadm работать.

Обсуждение Slack продолжается - https://kubernetes.slack.com/archives/C09QYUH5W/p1490803144368246

Похоже, что DaemonSets все равно будет запланирован, даже если узел не готов. В данном случае kubeadm действительно слишком параноик.

Текущий план, который мы собираемся протестировать, состоит в том, чтобы kubeadm больше не ждал, пока главный узел будет готов, а вместо этого просто должен зарегистрировать его. Этого должно быть достаточно, чтобы позволить CNI DaemonSet настроить CNI.

@kensimon проверяет это.

@jbeda да, похоже, что контроллер DaemonSet по-прежнему будет ставить их в очередь в основном потому, что он полностью игнорирует сетевую связь. Мы действительно должны исправить это в более общем плане. Есть ли что-то немедленное, что можно сделать в kube, или все это на данный момент в kubeadm?

Я пытаюсь установить kubernetes с помощью kubeadm на Ubuntu 16.04. Есть ли быстрое решение для этого?

@jbeda, если у вас есть исправленная версия, с удовольствием ее протестирую ..

У меня kubeadm проходит мимо статуса NotReady узла, но созданное им фиктивное развертывание не работает из-за заражения node.alpha.kubernetes.io/notReady препятствующего его запуску. Добавление допусков, похоже, не помогает, я не совсем уверен, как действовать на этом этапе. Может ли кто-нибудь пролить свет на то, как развернуть модуль, допускающий заражение notReady ?

Я изучаю некоторые другие варианты, например, не отмечать узел как notReady, но не совсем ясно, что мы хотим сделать.

мы работали над этим, удалив KUBELET_NETWORK_ARGS из командной строки kubelet. после этого kubeadm init работал нормально, и мы смогли установить плагин canal cni.

@sbezverk, не

Можно подтвердить результаты @sbezverk (удачная находка :)), отрегулировав /etc/systemd/system/10-kubeadm.conf и удалив KUBELET_NETWORK_ARGS, чтобы запустить его на centos. Протестировано с плетением.

@overip нужно отредактировать /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

ExecStart = / usr / bin / kubelet $ KUBELET_KUBECONFIG_ARGS $ KUBELET_SYSTEM_PODS_ARGS $ KUBELET_NETWORK_ARGS $ KUBELET_DNS_ARGS $ KUBELET_AUTHZ_ARGS $ KUBELET_EXTRA

удалить $ KUBELET_NETWORK_ARGS

а затем перезапустите kubelet, после чего bebeadm init должен работать.

это то, что я сделал

kubeadm сбросить

удалить записи ENV из:

/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

перезагрузить сервисы systemd и kube

systemctl демон-перезагрузка
systemctl перезапустить kubelet.service

перезапустить init

kubeadm init

Все правильно, и пока мы на этом

Если вы видите это:
kubelet: ошибка: не удалось запустить Kubelet: не удалось создать kubelet: неправильная конфигурация: драйвер cgroup kubelet: «cgroupfs» отличается от драйвера cgroup docker: «systemd»

вам нужно отредактировать свой /etc/systemd/system/kubelet.service.d/10-kubeadm.conf и добавить флаг --cgroup-driver = "systemd"

и сделайте как указано выше

kuebadm сбросить
systemctl демон-перезагрузка
systemctl перезапустить kubelet.service
kubeadm init.

Я бы осторожно удалил --network-plugin=cni из флагов CLI kubelet, это заставляет kubelet использовать плагин no_op по умолчанию ... Я был бы удивлен, если бы в этом случае вообще работали бы общие плагины, такие как calico / weave (но опять же, мое понимание того, как работают эти плагины, немного ограничено.)

@kensimon hm, я не видел никаких проблем с моей настройкой, я развернул плагин canal cni, и он работал нормально ..

@sbezverk Хорошо ли работает кросс-хостовая сеть?

@resouer не может подтвердить, у меня 1.6.0 только как All-In-One.

@resouer @sbezverk Я

 [root@deploy-01 x86_64]# kubectl get nodes
 NAME        STATUS    AGE       VERSION
 deploy-01   Ready     51m       v1.6.0
 master-01   Ready     4m        v1.6.0

`` [ root @ deploy-01 x86_64] # kubectl get pods -n kube-system
НАЗВАНИЕ ГОТОВ СОСТОЯНИЕ ВОЗРАСТ ВОЗВРАЩАЕТСЯ
etcd-deploy-01 1/1 Бег 0 50 м
kube-apiserver-deploy-01 1/1 Бег 0 51 м
kube-controller-manager-deploy-01 1/1 Бег 0 50 м
kube-dns-3913472980-6plgh 3/3 Бег 0 51м
kube-proxy-mbvdh 1/1 Бег 0 4 мес.
kube-proxy-rmp36 1/1 Бег 0 51 м
kube-scheduler-deploy-01 1/1 Бег 0 50 м
kubernetes-dashboard-2396447444-fm8cz 1/1 Бег 0 24 м
weave-net-3t487 2/2 Бег 0 44м
weave-net-hhcqp 2/2 Бег 0 4м

`` ''

обходной путь работает, но фланель не работает ...

@stevenbower наихудший сценарий, вы можете вернуть этот параметр и перезапустить kubelet, когда закончите работу с kubeadm.

У меня есть трехузловой кластер с работающим weave . Не уверен, насколько стабильно это может быть с этим хаком, но все равно спасибо! : смайлик:

На боковом узле вы можете вернуть $ KUBELET_NETWORK_ARGS после того, как инициализация на главном узле пройдет. На самом деле я не удалял его на машине, к которой я присоединился, только cgroup-driver, иначе kubelet и docker не будут работать вместе.

Но вам не нужно сбрасывать kubeadm, просто измените /etc/systemd/system/kubelet.service.d/10-kubeadm.conf и выполните танец systemctl:

systemctl демон-перезагрузка
systemctl перезапустить kubelet.service

Тем из вас, кто отказывается от KUBELET_NETWORK_ARGS и сообщает, что это работает для вас:

Для меня у меня есть 2 кластера: в одном я применил патч из https://github.com/kubernetes/kubernetes/pull/43824 и позволил kubeadm нормально работать при инициализации, а второй - с удаленным KUBELET_NETWORK_ARGS. В кластере с удаленным KUBELET_NETWORK_ARGS любой трафик между модулями не работает.

В кластере с удаленным KUBELET_NETWORK_ARGS:

$ kubectl run nginx --image=nginx
deployment "nginx" created
$ kubectl expose deployment nginx --port 80
service "nginx" exposed
$ kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
If you don't see a command prompt, try pressing enter.
/ # wget nginx.default.svc.cluster.local
wget: bad address 'nginx.default.svc.cluster.local'

В кластере с обычным KUBELET_NETWORK_ARGS, но с исправленным kubeadm:

$ kubectl run nginx --image=nginx          
deployment "nginx" created
$ kubectl expose deployment nginx --port 80
service "nginx" exposed
$ kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
If you don't see a command prompt, try pressing enter.
/ # wget nginx.default.svc.cluster.local
Connecting to nginx.default.svc.cluster.local (10.109.159.41:80)
index.html           100% |********************************************************************************************|   612   0:00:00 ETA

Если вы один из тех, кто отключил KUBELET_NETWORK_ARGS, проверьте, работает ли вышеуказанное для вас.

Я предлагаю отказаться от проверки готовности узла и фиктивной проверки развертывания.
всего для 1.6 и переместите их на этап проверки для 1.7.

29 марта 2017 г. в 10:13 «Дэн Уильямс» [email protected] написал:

@jbeda https://github.com/jbeda да, похоже, DaemonSet
контроллер по-прежнему будет помещать их в очередь в основном потому, что он полностью игнорирует
сетевой связи. Мы действительно должны исправить это в более общем плане. Здесь
что-нибудь срочно сделать в kube или все это на данный момент в kubeadm?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290158416 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ABtFIUw8GIJVfHrecB3qpTLT8Q4AyLVjks5rqpFKgaJpZM4MtMRe
.

Кто-нибудь еще работает с Ubuntu 16.04? Я удалил KUBELET_NETWORK_ARGS из службы systemd и перезагрузил демон systemd . Я могу включить главный узел, но не могу присоединиться к узлу. Сбой с ошибкой The requested resource is unavailable

KUBELET_NETWORK_ARGS удален, любой трафик между модулями не работает.

Я не удивлюсь, поскольку KUBELET_NETWORK_ARGS сообщает kubelet, какой плагин использовать, где искать конфигурацию и двоичные файлы. Они вам НУЖНЫ.

Я рекомендую # 43835 (и вишневый выбор 1.6 # 43837) в качестве исправления, которое мы делаем для 1.6. Я протестировал оба, и они работают. Я поручил @jbeda и @luxas проверять, когда они просыпаются.

Оба этих пиара выглядят разумными. Но я думаю, нам следует вместо этого подумать о https://github.com/kubernetes/kubernetes/pull/43824 . Хотя это немного сложнее, он сохраняет этот путь кода, чтобы пользователи, которые предварительно настраивают CNI за пределами использования Daemonset (я делаю это в https://github.com/jbeda/kubeadm-gce-tf, хотя я не обновил его до 1.6) все еще ждем, пока узлы будут готовы.

В качестве бонуса, это @kensimon «s первый PR в Kubernetes и он вытащил остановки , чтобы проверить этот материал. Но, честно говоря, они оба работоспособны, и я действительно хочу, чтобы это было исправлено. :)

Извините, я пропустил https://github.com/kubernetes/kubernetes/pull/43824. Я также доволен любым из них, если они оба работают.

Я тоже доволен, если они оба тоже работают

@kensimon У меня работает, когда я отключаю KUBELET_NETWORK_ARGS во время kubadm init . Благодаря вашим инструкциям я смог это проверить.

Подтверждено, что @webwurst работает, когда вы отключаете KUBELET_NETWORK_ARGS во время kubadm init . Мне пришлось перезапустить kube-dns, чтобы он его поднял. Проверка от @kensimon работает,

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

Лучшее решение - патчи от @kensimon или @mikedanese.

@coeki как именно вы перезапустили kube-dns. Я попробовал kubectl delete pod kube-dns-3913472980-l771x --namespace=kube-system и теперь kube-dns остается в ожидании kube-system kube-dns-3913472980-7jrwm 0/3 Pending 0 4m
Он сделал точно так, как описано: удалите KUBELET_NETWORK_ARGS , sudo systemctl daemon-reload && sudo systemctl restart kubelet.service , kubeadm init , добавьте KUBELET_NETWORK_ARGS , снова sudo systemctl daemon-reload && sudo systemctl restart kubelet.service
Но тогда мой хозяин остается в NotReady . В describe я получаю

Conditions:
  Type          Status  LastHeartbeatTime           LastTransitionTime          Reason              Message
  ----          ------  -----------------           ------------------          ------              -------
...
KubeletNotReady         runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Я попробовал перезапустить kube-dns, как описано выше, но безуспешно. Любая идея? Я умираю от этого, пытаясь снова запустить наш кластер после неудачного обновления 1.6.0 :(

@patte Я просто delete pods kube-dns-3913472980-3ljfx -n kube-system И снова появляется kube-dns.

Вы после kubeadm init добавили KUBELET_NETWORK_ARGS , снова sudo systemctl daemon-reload && sudo systemctl restart kubelet.service установили сеть pod, например weave или calico? Добавьте это в первую очередь, вы сможете заставить его работать.

Я пробовал и тестировал centos7 и только что сделал это на ubuntu / xenial, так что должно работать.

Подведем итог тому, что я сделал:

удалить KUBELET_NETWORK_ARGS
sudo systemctl daemon-reload && sudo systemctl restart kubelet.service

kubeadm init --token=$TOKEN --apiserver-advertise-address=$(your apiserver ip address)

добавить KUBELET_NETWORK_ARGS раз
sudo systemctl daemon-reload && sudo systemctl restart kubelet.service

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

Присоединился к машине, как правило, нужно добавить статический маршрут к 10.96.0.0 (IP-адрес кластера), поскольку я нахожусь на бродяге.
Используйте с $ TOKEN, но этот шаг является дополнительным.

Потом:

delete pods kube-dns-3913472980-3ljfx -n kube-system

Ждать его

kubectl run nginx --image=nginx
kubectl expose deployment nginx --port 80
kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
/ # wget nginx.default.svc.cluster.local Connecting to nginx.default.svc.cluster.local (10.101.169.36:80) index.html 100% |***********************************************************************| 612 0:00:00 ETA

У меня работает, хотя это ужасный хак;)

Я действительно удивлен, что сообщество разработчиков kubernetes не предоставило ETA для официального исправления. Я имею в виду, что это ужасная ошибка, которая должна быть легко обнаружена во время тестирования кода. Поскольку у него нет, по крайней мере, 1.6.1 следует выпускать как можно скорее вместе с исправлением, чтобы люди перестали взламывать свои кластеры и начали делать продуктивные вещи;). Я здесь не прав?

Всем привет,

На этой неделе я немного отвлекся, и это длинная нить, полная
kubeadm вещи, которые я не очень хорошо знаю. Может кто-нибудь резюмировать для меня? я
думаю, я понял суть ошибки, но каковы предлагаемые решения и
что делает их ужасными?

Вт, 30 марта 2017 г., 8:13, Сергей Безверхий < [email protected]

написал:

Я очень удивлен, что сообщество разработчиков kubernetes не
предоставил любое ETA для официального исправления. Я имею в виду, что это ужасная ошибка, которая
должны быть легко пойманы во время тестирования кода. Поскольку это не так, на
по крайней мере, 1.6.1 следует запустить как можно скорее вместе с исправлением, чтобы люди
прекратите взламывать свои кластеры и начните делать что-то продуктивное;). Я
здесь не так?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290442315 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AFVgVEoKuUf28VazmUApsnyfGhuAhZIqks5rq8aLgaJpZM4MtMRe
.

Изменение в kubelet (# 43474) привело к тому, что kubelet начал правильно сообщать о том, что сеть не готова до инициализации плагина cni. Это нарушило порядок, от которого мы зависели, и вызвало тупик при инициализации мастера kubeadm. Мы не заметили этого, потому что тесты kubeadm e2e были прерваны за несколько дней до этого изменения.

Текущие предлагаемые исправления: # 43824 и # 43835.

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

В чт, 30 марта 2017 г., в 8:28, Майк Данезе [email protected]
написал:

Смена кубелета (# 43474
https://github.com/kubernetes/kubernetes/pull/43474 ) заставил kubelet
начать правильно сообщать о том, что сеть не готова до того, как плагин cni был
инициализирован. Это нарушило порядок, от которого мы зависели, и вызвало
тупик в инициализации мастера kubeadm. Мы не поймали это, потому что
Перед этим изменением тесты kubeadm e2e не работали в течение нескольких дней.

Текущие предлагаемые исправления: # 43824
https://github.com/kubernetes/kubernetes/pull/43824 и # 43835
https://github.com/kubernetes/kubernetes/pull/43835 .

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290447309 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AFVgVLzQLxeV6qp1Rw1fNALDDaf-Sktyks5rq8o2gaJpZM4MtMRe
.

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

+1, чтобы решить эту проблему сегодня, так как много усилий тратится на работу с залогом от обходного пути.

Не могу поверить, что никто на самом деле не пробовал kubeadm 1.6.0 до выпуска 1.6.0 ....

Кроме того, kubelet 1.5.6 + kubeadm 1.5.6 также не работает, /etc/systemd/system/kubelet.service.d/10-kubeadm.conf ссылается на /etc/kubernetes/pki/ca.crt, но kubeadm не генерирует ca.crt, хотя есть ca.pem.

В настоящее время в репозитории k8s apt остались только версии 1.6.0 и 1.5.6 ...

"выломан из коробки", слова узнали сегодня.

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

Согласитесь с Майком по этому поводу. # 43835 - это более простое изменение, и проверка (при необходимости) может быть выполнена на отдельном этапе.

@thockin нам действительно нужны более детальные условия и статус для сети, особенно с ho stNetwork: true. Узлы могут быть готовы для одних подов, но не для других.

Мы не можем использовать nodeNetworkUnavailable, потому что это характерно для облачных провайдеров. Вероятно, нам понадобится еще один или способ для планировщика разрешить ho stNetwork: true pod'ы на узлах с Net workReady: false или заставить работать taints для неготовых узлов. И рабочие тесты kubeadm e2e :(

Согласен. Я откладывал решение проблемы, потому что у меня не было хороших ответов,
но нам нужно получить это в 1.7

30 марта 2017 г., 10:02, Дэн Уильямс [email protected]
написал:

@thockin https://github.com/thockin нам действительно нужен более мелкозернистый
условия и статус для сети, особенно с ho stNetwork: true.
Узлы могут быть готовы для одних подов, но не для других.

Мы не можем использовать nodeNetworkUnavailable, потому что это характерно для облака
провайдеры. Вероятно, нам понадобится еще один или способ, чтобы планировщик
allow ho stNetwork: true pods на узлах с Net workReady: false или
портит работу для неготовых узлов.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290475480 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AFVgVAaO9c76_R8me9PDo96AQ1ZrplMxks5rq-A1gaJpZM4MtMRe
.

@thockin какое-нибудь предпочтительное решение? Мы можем либо заблокировать готовность узла и выяснить, кто использует IsNodeReady (), как мы уже сделали, либо мы можем добавить еще одно условие узла, а затем исправить для него неизвестно сколько бит кодовой базы в другом месте. Или, может быть, есть другой вариант.

Мы не можем использовать nodeNetworkUnavailable, потому что это характерно для облачных провайдеров. Вероятно, нам понадобится еще один или способ для планировщика разрешить ho stNetwork: true pod'ы на узлах с Net workReady: false или заставить работать taints для неготовых узлов.

Я думаю, что планировщик можно исправить так, чтобы он уважал недостатки и допуски, вместо того, чтобы полностью исключать все неготовые узлы.
Тем не менее, кому- то придется применить stNetwork: true pod'ам . Я не знаю, кто, но это не должен быть планировщик, так как обучение планировщика пониманию спецификации модуля кажется слишком сложным.

/ cc @davidopp @ dchen1107

Кроме того, для всех, кто пробовал патчи my или michael и зависает на приближающейся плоскости управления, кажется, что сборка kubeadm из master не работает, если он управляет кластером v1.6.0. , из-за того, что kubeadm пытается запустить kube-apiserver с недопустимыми аргументами:

unknown flag: --proxy-client-cert-file

Если вы хотите протестировать мои изменения или изменения Майкла на кластере v1.6.0, выберите их на основе v1.6.0 вместо того, чтобы пока строить поверх master.

@yujuhong планировщик уже автоматически применяет модулям (см. https://github.com/kubernetes/kubernetes/pull/41414), это похоже на достаточно похожий вариант использования

У меня нет четкого представления обо всех пороках и готовности к
сеть, на данный момент. Дэн, у тебя есть полчаса, чтобы написать
текущее состояние, так что мы можем начать дразнить его? Я думаю ты это знаешь
Лучший. Я чувствую, что у нас есть ряд мелких проблем, которые мы только что решили
одеяло покрыто до сих пор.

В чт, 30 марта 2017 г., в 10:22, Кен Саймон [email protected]
написал:

@yujuhong https://github.com/yujuhong уже планировщик
автоматически применяет допуски к модулям (см. №41414
https://github.com/kubernetes/kubernetes/pull/41414 ), это похоже на
достаточно похожий вариант использования

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290481017 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AFVgVMas2IP5X5YA0V5626UlGbaS98jtks5rq-TCgaJpZM4MtMRe
.

@thockin Я могу это сделать, где мне это положить?

есть пара связанных вопросов, можем ли мы переименовать одну из них, опубликовать
краткое изложение текущего состояния и что дальше?

30 марта 2017 г., в 10:50, Дэн Уильямс [email protected]
написал:

@thockin https://github.com/thockin Я могу это сделать, куда мне положить
Это?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290489157 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AFVgVCXJYk9J0QmjTqQA6PPVuhzMHlLZks5rq-t-gaJpZM4MtMRe
.

Есть ли у нас информация о том, когда это исправление будет перенесено в репозиторий CentOS?

В 1.6 по умолчанию ядро ​​Kubernetes не применяет никаких повреждений к узлам автоматически. Планировщик учитывает загрязнения, которые добавляются системами развертывания, такими как kubeadm, kops и т. Д., Или добавляются вручную пользователями (и соблюдает соответствующие допуски, добавленные к модулям).

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

В 1.6 вы можете включить альфа-функцию, которая заставляет ядро ​​Kubernetes (NodeController) добавлять пометку NoExecute всякий раз, когда есть NodeReady == "False" или NodeReady == "Unknown". Это приведет к тому, что поды, работающие на узле, будут вытеснены (если они не переносят заражение) и предотвратят планирование новых подов на узле (если они не переносят заражение).

Долгосрочный план состоит в том, чтобы переместить всю логику «того, как ядро ​​Kubernetes реагирует на условия узла в отношении планирования и исключения», на использование taints и допусков (например, # 42001). Но нас пока нет и не будет. Таким образом, в краткосрочной перспективе у модуля нет возможности «терпеть» NetworkUnavailable или любое другое условие узла, которое вы можете добавить.

Если я понимаю, что @davidopp сказал правильно, то это функция NodeReady, которая теперь возвращает true, false или unknown, отмечает список тем, что необходимо. Если он может вернуть список значений, которые не выполняются, вы можете проверить это.

В случае с kubeadm, если тогда NetworkUnavailable - единственный. kubeadm может вернуть истину. Это в том случае, если мы не хотим, чтобы подключаемый модуль network / cni передавался во время инициализации kubeadm.

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

Поправьте меня если я ошибаюсь ;)

Перехожу к этой теме, потому что я столкнулся с этой проблемой, и это меня раздражает:

Почему готовность сети не может стать проблемой, которую кубелет добавляет и удаляет в зависимости от состояния сети на узле?
Таким образом, узел может быть «готов» для всех модулей, которые допускают искажение готовности сети (сетевые приложения для модулей).

Что касается модулей сети хоста, контроллер допуска может вносить допуски в пометку готовности сети модулей.

Я думаю, что это согласуется с долгосрочным планом в комментарии Дэвидоппа.

Я думаю, что это согласуется с долгосрочным планом в комментарии Дэвидоппа.

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

Ack. Есть ли причина не переходить на taints в патче v1.6?

Код для автоматического добавления порчи на основе условий узла только что перешел в альфа-версию в 1.6. Он не готов, чтобы на него можно было положиться. (И в настоящее время он обрабатывает только состояние готовности узла, а не сеть).

Итак, если я правильно понимаю, на данный момент, поскольку https://github.com/kubernetes/features/issues/166 занимает больше времени, чтобы иметь возможность правильно испортить доступность сети, мы должны найти обходной путь. Если мы сможем как можно скорее опубликовать исправление для kubeadm, например # 43835, с комментарием, чтобы исправить это на https://github.com/kubernetes/features/issues/166 , многие люди будут счастливы.

@davidopp Я полагаю, вы хотели сказать " не полагаются ". Мне все еще не хватает связи между автоматическим условием заражения логики, о которой вы упомянули, с ошибкой публикации kubelet непосредственно для сетевых проблем.

Да, спасибо, это была опечатка, теперь исправлено

Да, вы могли бы заставить Kubelet добавить заражение. Возможно, не идеально, чтобы Kubelet добавлял загрязнения для некоторых условий узла, а NodeController добавлял их для других условий узла (последнее необходимо, потому что только мастер может обнаруживать недоступность узла), но это всего лишь аргумент программной инженерии, а не что-то фундаментальное. Мой план заключался в том, чтобы NodeController добавлял taints для всех состояний узла, но для этого нет строгих требований.

Ack. В этом случае с одним условием узла связано несколько атрибутов, которые контроллер узла может быть не в состоянии распознать.
@mikedanese Мне кажется kubeadm init приводящее к работающему узлу. Я надеюсь, что требование добавления фазы validation не связано с этой проблемой.
@dcbw @thockin @yujuhong какие-нибудь мысли об использовании taints для представления проблем с конфигурацией узлов в kubelet?

Обратите внимание, что если вы хотите, чтобы ваша новая помеха заменила текущую автоматическую фильтрацию узлов на NetworkUnavailable, вам нужно будет изменить функцию, о которой я упоминал ранее (т.е. удалить ее из набора условий, отфильтровывающих узел). Я не знаю, какие еще будут побочные эффекты, поскольку эта функция может использоваться не только в планировщике, но и в списках узлов.

Есть ли способ установить 1.5.6, который должен работать в Ubuntu? Если есть, не могли бы вы объяснить, как это сделать? Спасибо!

Обратите внимание, что если вы хотите, чтобы ваша новая помеха заменила текущую автоматическую фильтрацию узлов на NetworkUnavailable, вам нужно будет изменить функцию, о которой я упоминал ранее (т.е. удалить ее из набора условий, отфильтровывающих узел). Я не знаю, какие еще будут побочные эффекты, поскольку эта функция может использоваться не только в планировщике, но и в списках узлов.

@davidopp, нам нужно быть осторожными с NetworkUnavailable и NodeReady. Есть два отдельных условия, которые действительно следует устранить:

nodeNetworkUnavailable - это характерно для облачных маршрутов, и только контроллеры облачных маршрутов очищают это условие, когда облачные маршруты между узлами были настроены. Сетевые плагины, которые создают наложения или не выполняют маршрутизацию L3 между узлами, не хотят и не используют это условие. Это условие не добавляется ни одним сетевым плагином; он добавляется kubelet специально, когда GCE или AWS выбраны в качестве облачных провайдеров. Не влияет на NodeReady, так как это отдельное условие.

NodeReady - напрямую зависит от сетевых плагинов (например, CNI или kubenet или удаленных сред выполнения, таких как dockershim / CRI-O).

Следует рассмотреть три отдельных вопроса:

1. Облачные маршруты - если облачная инфраструктура и сетевой плагин требуют облачных маршрутов, то отсутствие облачных маршрутов (например, NodeNetworkUnavailable = true) должно блокировать планирование hostNetwork = false pods
2. Сетевые плагины - если плагин еще не готов, ему необходимо заблокировать планирование hostNetwork = false pods. Это отличается от NodeNetworkUnavailable, потому что плагин может не иметь прямого взаимодействия с контроллером маршрутов, поскольку он не зависит от облачных маршрутов. Например, kubenet можно использовать локально на узле, если у вас есть что-то еще (облачные маршруты, фланель и т. Д.), Настраивающие маршруты узлов.
3. hostNetwork = true pod'ы должны игнорировать все эти условия и быть запланированными, но при соблюдении любых других применимых условий (дисковое пространство и т. д.)

NodeReady слишком большой молоток. Я думаю, нам, вероятно, нужно дополнительное условие NetworkPluginReady для готовности сетевого плагина (отдельно от готовности облачных маршрутов!), А затем мы должны пронести его до мест, которые заботятся :( Или, действительно, новые портят, а не условия.

Еще одну работу я нашел.

Пока kubeadm продолжает печатать «[apiclient] Первый узел зарегистрирован, но еще не готов», я развернул kube-flannel.yml, который устанавливает flanneld. И это работало без изменения файлов конфигурации.

1) kubeadm init --pod-network-cidr = 10.244.0.0 / 16 и
2) cp /etc/kubernetes/admin.conf ~ / .kube / config
3) kubectl apply -f kube-flannel-rbac.yml (необходимо в kubeadm 1.6)
4) kubectl apply -f kube-flannel.yaml
Используйте kube-flannel.yaml в https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml

Я мог бы сделать главный узел "Готовым". Но kube-dns не смог передать сообщение,

Error syncing pod, skipping: failed to "CreatePodSandbox" for "kube-dns-2759646324-nppx6_kube-system(bd585951-15cb-11e7-95c3-1c98ec12245c)" with CreatePodSandboxError: "CreatePodSandbox for pod \"kube-dns-2759646324-nppx6_kube-system(bd585951-15cb-11e7-95c3-1c98ec12245c)\" failed: rpc error: code = 2 desc = NetworkPlugin cni failed to set up pod \"kube-dns-2759646324-nppx6_kube-system\" network: \"cni0\" already has an IP address different from 10.244.0.1/24"

После того, как я сменил сетевой плагин на weave-net, все заработало.

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

ПОЖАЛУЙСТА, ПРОВЕРЬТЕ ЗАПАТЧЕННЫЕ ДЕБЫ

У kubernetes-xenial-unstable теперь есть исправленная сборка 1.6.1-beta.0.5+d8a384c1c5e35d-00 которую мы с @pipejakob тестировали сегодня. Узлы остаются неготовыми до тех пор, пока не будет создана сеть контейнеров (например, путем применения конфигураций плетения / фланели). Пройден тест на соответствие. PTAL.

# cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial-unstable main
EOF

cc @luxas @jbeda

Это общее направление, которое портит может выразить почти все
условия могут, а значит лучше во всех отношениях?

Я согласен, нам нужен более подробный сигнал. Нам все еще нужно разобраться
взаимодействие между kubelet, сетевым драйвером, облачным контроллером и облачным провайдером
для разблокировки hostNetwork = false pods, но hostNetwork = true не должно быть
заблокирован.

В чт, 30 марта 2017 г., в 19:24, Дэн Уильямс [email protected]
написал:

Обратите внимание: если вы хотите, чтобы ваша новая помеха заменила текущую автоматическую
фильтрация узлов с помощью NetworkUnavailable, вам нужно будет изменить
функция, о которой я упоминал ранее (т.е. удалить ее из набора условий
которые отфильтровывают узел). Я не знаю, какие еще побочные эффекты могут
иметь, поскольку эта функция может использоваться в списках узлов, кроме
планировщик.

@davidopp https://github.com/davidopp нам нужно быть осторожными
NetworkUnavailable против NodeReady. Есть два разных условия, которые
действительно следует очистить:

nodeNetworkUnavailable - это характерно для облачных маршрутов и только для облачных
контроллеры маршрутов сбрасывают это условие, когда облачные маршруты между узлами имеют
был настроен. Сетевые плагины, которые создают наложения или не выполняют L3
маршрутизация между узлами не требует или не использует это условие. Это состояние
не добавляется ни одним сетевым плагином; он добавлен kubelet специально, когда
GCE или AWS выбраны в качестве облачных провайдеров. Не влияет на NodeReady, так как
это отдельное условие.

NodeReady - напрямую зависит от сетевых плагинов (например, CNI или kubenet
или удаленные среды выполнения, такие как dockershim / CRI-O).

Следует рассмотреть три отдельных вопроса:

1. Cloud Routes - если облачная инфраструктура и сетевой плагин
   требуются облачные маршруты, а затем отсутствие облачных маршрутов (например,
   NodeNetworkUnavailable = true) необходимо заблокировать планирование hostNetwork = false
   стручки
2. Сетевые плагины - если плагин еще не готов, необходимо
   блокировать планирование hostNetwork = false pods
3. hostNetwork = true pod'ы должны игнорировать все эти условия и быть
   запланировано, но при соблюдении любых других применимых условий (место на диске и т. д.)

NodeReady слишком большой молоток. Я думаю, мы, вероятно, хотим
дополнительное условие NetworkPluginReady для готовности сетевого плагина
(отдельно от готовности облачных маршрутов!)
через места, которые заботятся :(

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290597988 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AFVgVGIn0CpVkcHd2SVaoRsp2RJNEgXFks5rrGPqgaJpZM4MtMRe
.

Для тех, кто все еще пытается временное исправление, удалив строку конфигурации kubelet KUBELET_NETWORK_ARGS, @ jc1arke нашел более простой обходной путь - провести два сеанса с новым мастером и, ожидая готовности первого узла, применить конфигурацию узла сети во втором сессия:
Первая сессия после запуска kubeadmin init:

...
[apiclient] Created API client, waiting for the control plane to become ready
[apiclient] All control plane components are healthy after 24.820861 seconds
[apiclient] Waiting for at least one node to register and become ready
[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
...

Вторая сессия (с использованием Calico. Ваш выбор, конечно, может варьироваться):

root@kube-test-master-tantk:~# kubectl apply -f http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/kubeadm/calico.yaml
configmap "calico-config" created
daemonset "calico-etcd" created
service "calico-etcd" created
daemonset "calico-node" created
deployment "calico-policy-controller" created
job "configure-calico" created
root@kube-test-master-tantk:~#

Вернуться к первому сеансу:

...
[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 118.912515 seconds
[apiclient] Test deployment succeeded
[token] Using token: <to.ken>
[apiconfig] Created RBAC rules
...

Это общее направление, которое портит может выразить почти все
условия могут, а значит лучше во всех отношениях?

Довольно много. Вероятно, мы не сможем избавиться от каких-либо условий узла из-за проблем с обратной совместимостью, но мы можем избавиться от всей логики в главном устройстве, которая выполняет действия на их основе (например, блокирование планирования или удаление модулей). Помимо того, что поведение становится более очевидным (нет необходимости запоминать, какие условия блокируют планирование, какие вызывают выселение, как долго мы ждем выселения и т. Д.), Реакция на условия настраивается для каждого модуля.

Только что протестировал дебюты от @pipejakob , они работают нормально.

Проверено на ubuntu / xenial:

root<strong i="9">@kube1</strong>:/home/ubuntu# kubeadm version
kubeadm version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean", BuildDate:"2017-03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

Только что протестировал дебюты от @pipejakob , все еще
[apiclient] Created API client, waiting for the control plane to become ready

Я ждал минут пять, но ничего не изменилось.
И вчера он повторял
[apiclient] First node has registered, but is not ready yet

TTI думаете, что проблема все еще не решена?

Проверено на Ubuntu 16.04:
версия kubeadm: version.Info {Major: "1", Minor: "6+", GitVersion: "v1.6.1-beta.0.5 + d8a384c1c5e35d", GitCommit: "d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTree "2017", GitTree " -03-31T04: 20: 36Z ", GoVersion:" go1.7.5 ", компилятор:" gc ", платформа:" linux / amd64 "}

@ myqq0000 вы можете опубликовать версию, которую используете?

kubeadm version

@coeki О, я забыл об этом. Я только что отредактировал и разместил версию в своем предыдущем комментарии. :)

@mikedanese Планируете ли вы обновить

Просто попробовал 1.6.1-beta.0.5+d8a384c1c5e35d-00 ( 1.6.1-beta.0.5+48c6a53cf4ff7d-00 упомянутый в https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290616036, похоже, не существует).

Вроде нормально работает.
Не связано: обратите внимание, что если вы используете плетение, вам нужно применить https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml вместо https: / /git.io/weave-kube

@mausch Не могли бы вы рассказать мне, как получить эти дебы?

@ srinat999 https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290616036

У меня работают пропатченные

root@kube-test0:~# kubeadm version
kubeadm version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean", BuildDate:"2017-03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

@mausch Спасибо. У меня они тоже работают с провайдером weave network.

Есть ли шанс создать такое же исправление и для Centos? Наша система стробирования в основном использует centos для базы кластера кубернетов. Если у меня версия centos, я могу гарантировать прибл. 100 запусков kubeadm init в день в качестве тестирования.

Патченные дебюты @mikedanese у меня частично работают. kubeadm сообщает, что кластер готов, а сам узел - нет.

Узлы @ squall0gd должны быть готовы, когда применяется сеть pod, например, kubectl apply -f https://git.io/weave-kube-1.6

В моей тестовой среде (в vagrant, на машинах centos / 7) kubeadm просто зависает. Используя strace, я вижу, что он пытается подключиться к серверу kubelet на главном сервере и выполняет циклы повторных попыток FUTEX_WAIT, epoll_wait. Но от него не поступает однострочный выходной сигнал.

kubelet не запускается, что, видимо, и есть причина.
(Но я не вижу причин, по которым кублет не запускается ..)

Это проблема этого вопроса?

Я получаю двоичные файлы из репозитория http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 .
Я также пытаюсь обновить двоичные файлы с https://storage.googleapis.com/kubernetes-release/release/v1.6.0/bin/linux/amd64/ .

==> Где взять пропатченную версию kubeadm для тестирования? <==

Примечание: я нашел одну (заявленную) исправленную версию kubeadm, упомянутую в этом выпуске, по адресу https://github.com/kensimon/aws-quickstart/commit/9ae07f8d9de29c6cbca4624a61e78ab4fe69ebc4 (исправленная версия - это:

@ squall0gd Можете ли вы показать нам точное сообщение, которое вы видите? Исходя из того, что вы описываете, мне интересно, действительно ли вы взяли новый .debs или использовали более старые кешированные версии.

@thockin @davidopp, поэтому, согласно предложению Тима, я https: // github. com / kubernetes / kubernetes / issues / 43815 # issuecomment -290597988.

Вот что, по-видимому, работает у меня с репо unstable (тестировал только сам мастер):

"sudo apt-get update && sudo apt-get install -y apt-transport-https",
"echo 'deb http://apt.kubernetes.io/ kubernetes-xenial-unstable main' | sudo tee /etc/apt/sources.list.d/kubernetes.list",
"curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -",
"sudo apt-get update",
"sudo apt-get install -y docker.io",
"sudo apt-get install -y kubelet kubeadm kubectl kubernetes-cni",
"sudo service kubelet stop",
"sudo service kubelet start",
"sudo kubeadm init",
"sudo cp /etc/kubernetes/admin.conf $HOME/",
"sudo chown $(id -u):$(id -g) $HOME/admin.conf",
"export KUBECONFIG=$HOME/admin.conf",
"kubectl taint nodes --all dedicated-",
"kubectl apply -f https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml",

Это действительно выплевывает error: taint "dedicated:" not found в какой-то момент, но, похоже, продолжается, несмотря на это.

Разве мы не запускаем эти тесты на ветке 1.6?

Условия узла

kubeadm не выглядит так, как будто он протестирован в ветке выпуска:
https://k8s-testgrid.appspot.com/release-1.6-all

@ bgrant0607 очевидно, что тесты kubeadm e2e были отключены / не работали примерно неделю до выпуска 1.6, IIRC

Условия узла предназначены для предоставления людям дополнительной информации для понимания происходящего, например, причины, сообщения и времени перехода.

@ bgrant0607 предназначены ли они в первую очередь для информации о людях, или это просто

@dcbw Порчи предназначены для того, чтобы стать

https://github.com/kubernetes/kubernetes/pull/18263#issuecomment -169220144
https://github.com/kubernetes/kubernetes/issues/29178

Обратите внимание, что если мы собираемся добавить заражение к узлам, нам нужно учитывать

а) Обратная совместимость, как с основным заражением: https://github.com/kubernetes/kubernetes/pull/43537

б) Перекос версии. При обновлении кластеров до 1.6 кублеты будут иметь смешанные выпуски, а некоторые могут быть такими же старыми, как и 1.4.

Итак, чтобы резюмировать или когда я разбираю это:

на основе @dcbw

nodeNetworkUnavailable - это облачный провайдер, не связанный с банкоматом kubeadm, мы можем столкнуться с этим.

Но NodeReady, который является основной причиной возникновения цикла, требует более детальной детализации. Это то, чем @davidopp хочет быть заражением, основываясь на списке, в котором отмечены флажки, в отношении проверки / живучести, готовности CNI и т. Д.

хорошо, хотя вы могли бы возразить, почему бы не наклеить ярлык?

Но @dcbw вы нашли

Я знаю, я был частью того, что не совсем разбирался в проблеме и писал хаки для ее решения :)

Но в любом случае мы должны обсудить основы в другом месте, убедиться, что здесь размещено ETA на исправление, и двигаться дальше.

Не шустрый, но хорошо :)

PS да @ bgrant0607 мы должны были проверить это больше
PS2 Если я вижу это не так, можете винить меня;)

@coeki Я бы также добавил запрос на

@ kfox1111 стробирование тоже проблема .... нам нужна лучшая стратегия в этом отношении :)

Зачем вообще удалять старые выпуски? Это может легко нарушить автоматизацию людей и предотвратить повторяющиеся установки.

Условия узла предназначены для предоставления людям дополнительной информации для понимания происходящего, например, причины, сообщения и времени перехода.

Согласовано. UX определенно является основной причиной, по которой мы, вероятно, не можем избавиться от состояний узлов. Однако я верю, что мы можем избавиться от всех видов использования условий узла в качестве триггера для основных действий (таких как выселение и планирование блокировки) и вместо этого использовать taints.

В долгосрочной перспективе (например, в долгосрочной перспективе v2 API) вполне возможно, что мы могли бы добавить причину и сообщение к загрязнениям, а затем избавиться от условий узла, но я на самом деле не думал об этом и определенно не предлагаю официально это делать. (У нас уже есть эквивалент времени перехода в одном направлении, а именно TimeAdded.)

@coeki нет, то, о чем я говорил, не имеет ничего общего с гейтингом. Gating не сможет найти все проблемы, если у вас нет ворот, которые проверяют все, что возможно когда-либо сделать. Операторы любят делать странные вещи в своей среде. :) Непомерно дорого тестировать все возможное.

Я прошу не удалять старую версию до тех пор, пока не будет выпущена новая версия, по крайней мере, через первый выпуск исправления ошибок. В этом примере 1.6.1. Как минимум. Еще лучше хранить больше старых версий. Это лучшая практика, позволяющая операторам продолжать работу, пока исправляются ошибки в новой версии.

@ kfox1111 , это то, что делает стробирование, а не то, что кажется хорошим, и отбрасывание старого доброго надежного способа, что произошло сейчас.

@davidopp Я согласен с тем, что ярлыки и порчи могут отличаться от взгляда на них, UX и механизмов через api, но сейчас они расплывчаты. То есть тоже я :)

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

Я хотел бы спросить еще раз: если я вижу, что "kubeadm init" просто висит без вывода (пытаюсь подключиться к серверу kubelet, который не запустился), страдаю ли я от этой проблемы? И если это так, то # 43835 - это для меня исправление?

Где теперь взять:

• либо более старые (до 1.6.0) версии kubeadm / kubectl / kubelet
• или исправленная версия kubeadm (включая # 43835 или любое другое исправление)?

Спасибо!

(примечание: исправленная версия kubeadm, указанная в упомянутом коммите выше, не работает для меня ...)

@obnoxxx попробуйте верхушку ветки release-1.6.

$ gsutil ls gs://kubernetes-release-dev/ci/v1.6.1-beta.0.12+018a96913f57f9

https://storage.googleapis.com/kubernetes-release-dev/ci/v1.6.1-beta.0.12+018a96913f57f9/bin/linux/amd64/kubeadm

@mikedanese спасибо! пытающийся...

Если вы запускаете kubeadm без установки пакета ОС, вам необходимо

$ cat <<EOF > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true"
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true"
Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin"
Environment="KUBELET_DNS_ARGS=--cluster-dns=10.96.0.10 --cluster-domain=cluster.local"
Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt"
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_EXTRA_ARGS
EOF
$ systemctl daemon-reload
$ systemctl restart kubelet

из https://github.com/kubernetes/release/blob/master/debian/xenial/kubeadm/channel/stable/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

@mikedanese спасибо. Я устанавливаю пакет os (из репозитория kube), а затем устанавливаю двоичные файлы с веб-адреса поверх двоичных файлов из rpms ...

версия 1.6.1-beta.0.12 у меня не работала:
kubeadm init по-прежнему зависает без каких-либо выходных данных. (пытаюсь подключиться к кубелету)

Не забывайте и о драйвере systemd, если centos.

системный драйвер?

https://github.com/kubernetes/release/issues/306

Господи, спасибо, так лучше! :-)

@pipejakob У меня сейчас нет доступа к этим журналам, но я проверил версию kubeadm, и это была та же версия, что и у @webwurst . Кроме того, я проверил возможные kubeadm версии с помощью apt-cache policy kubeadm . И запись была только одна - от kubernetes-xenial-unstable.
@mikedanese Я пробовал использовать фланель перед публикацией;)
РЕДАКТИРОВАТЬ: я перестроил всю платформу, и kubadm работает нормально: +1:

Ребят какой статус-кво по фиксу? он собирается в ближайшее время переместиться в стабильный репозиторий?

Дебы, пропатченные

Кто-нибудь может сказать мне, как собрать исправленную версию kubeadm для rhel (rpm)?

@mikedanese с исправленными

Главный узел находится в NotReady .

weave-net (weaveworks / weave-kube: 1.9.4 - https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml) находится в 1/2 CrashLoopBackOff :

FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "weave"

Пакет kube-dns находится в 0/3 Pending .

@ChipmunkV Вероятно, вам нужно настроить kube-proxy для работы в пользовательском пространстве. Это было проблемой и в 1.5.

command:
  - /usr/local/bin/kube-proxy
  - --kubeconfig=/var/lib/kube-proxy/kubeconfig.conf
  # add this line:
  - --proxy-mode=userspace

Как бы то ни было, у меня хорошо работает kubernetes-xenial-unstable .

@pstadler , спасибо @errordeveloper в чате, который указал, что у меня есть перекрывающиеся сети, я перенастроил переплетение IPALLOC_RANGE .

Спасибо @thenayr. Я мог вызвать мастер Kubernetes, но также мог подключить к нему одного воркера с помощью kubeadm join. Скоро опубликую больше обновлений

@mikedanese мне потребовалась ci-cross/latest.txt (а именно v1.7.0-alpha.0.1982+70684584beeb0c ), и это привело к появлению нового флага kube-apiserver (а именно --proxy-client-key-file в d8be13fee85075abfc087632b3dbc586a10897ad), который не работает ни с одним из последних тегов в gcr.io/google_containers/kube-apiserver-amd64 ...

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

@errordeveloper, мы пытаемся выпустить релиз, чтобы мы могли

Предыдущий выпуск 1.5.6 работал у меня на CentOs 7, но теперь я даже не могу откатиться, потому что единственная версия kubeadm в http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 - это сломанная версия 1.6. 0. Есть предложения, как получить kubeadm 1.5.6 RPM?

Действительно жаль. Похоже, что старые версии полностью удалены. :-(

Мои результаты таковы на centos 7:

• Мне не удалось заставить kubadm init дать мне вообще какой-либо результат, даже с пропатченным последним kubeadm, без каких-либо действий с kubectl.
• Мне удалось запустить kubectl с помощью инструкций @coeki , а затем kubeadm даже прошел. Но после этого у меня ничего не работает. kubectl говорит

The connection to the server localhost:8080 was refused - did you specify the right host or port?

Любой намек на то, что происходит?

@obnoxxx по умолчанию apiserver не слушает 8080, он слушает безопасный порт 6443, вы можете проверить с помощью netstat -tunlp.
Вам нужно скопировать admin.conf из / etc / kubernetes в $ HOME / .kube / config
убедитесь, что вы изменили права доступа к файлу в вашем $ HOME / .kube /, после этого ваш kubectl должен иметь возможность правильно связываться с apiserver. HTH. Сергей

@apsinha Знаете ли вы об этой ветке? Было бы неплохо, если бы некоторые разработчики продукта следили за мной, поскольку я думаю, что в будущем мы сделаем несколько важных выводов.

С верхней части моей головы:

• 1.6.0 никогда не проходил автоматическое тестирование: https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290809481
• Бинарные файлы / пакеты для более старых версий были удалены, поэтому люди не могут безопасно откатиться; сломал любую автоматизацию установки, которая предполагала, что они по-прежнему доступны: https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290861903
• Нет публичного объявления (которое я видел) о том, что это не работает
• Нет графика исправления (я разработчик, поэтому я знаю, насколько неприятен вопрос «когда это будет исправлено?», Но, тем не менее, люди спросят об этом, так что хорошо, по крайней мере, предложить примерный период времени)
• Пользователи, продолжающие присоединяться к разговору, не понимают, что происходит, обходные пути и график исправлений.
• Множество технических дискуссий среди участников, многие из которых касаются долгосрочной стратегии, объединены в одном потоке, когда пользователи пытаются выяснить, что происходит, и как справиться с непосредственной проблемой.

Никакого неуважения ко всем великим людям, которые делают Kubernetes тем, чем он является. Я просто надеюсь, что в будущем появятся некоторые «поучительные моменты», поскольку это выглядит плохо с точки зрения общественного восприятия Kubernetes как надежного / стабильного. (Конечно, kubeadm является альфа / бета-версией, но он все еще хорошо заметен.)

Я собрал kubeadm-1.5.6 с помощью kubernetes / release.rpm только для того, чтобы обнаружить (к моему ужасу), что

# rpm -Uvh kubectl-1.5.6-0.x86_64.rpm kubeadm-1.5.6-0.x86_64.rpm 
error: Failed dependencies:
        kubectl >= 1.6.0 is needed by kubeadm-1.5.6-0.x86_64
        kubelet >= 1.6.0 is needed by kubeadm-1.5.6-0.x86_64

@bostone, вам нужно настроить .spec здесь .

@sbezverk спасибо за подсказку! Сейчас лучше ...

Это любопытно:

• Я не помню, чтобы копирование admin.conf было необходимо мне в более ранних версиях.
• Раньше я пробовал использовать kubectl -s localhost:6443 но этого было недостаточно.

В любом случае, теперь я могу продолжить. Спасибо еще раз

Версия 1.6.1 находится в процессе выпуска. Это будет делать EOD.

Некоторые примечания:

1. Проблема с удалением старых пакетов отслеживалась здесь: https://github.com/kubernetes/release/issues/234. Из-за некоторого дурацкого управления версиями kubeadm и того, как эти вещи отсортированы по алфавиту, по-видимому, было невозможно сохранить версию kubeadm 1.5.x в репозитории. ( @bostone там тоже
2. Тестирование kubeadm e2e по отслеживаемым PR здесь: https://github.com/kubernetes/kubeadm/issues/190
3. Что касается публичного объявления - я написал в твиттере, но вряд ли это официально. Непонятно, какие каналы подходят для подобных критических проблем.

Все это хорошие вопросы, которые стоит поднять в личку. @pipejakob любезно вызвался провести вскрытие.

@obnoxxx Требование скопировать / выбрать admin.conf было необходимо раньше, потому что с 1.5 у нас был сервер API, открывающий незащищенный порт. Мы изменили это в 1.6. Теперь вы должны использовать безопасные учетные данные для доступа к серверу API (см. Https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#kubeadm-2)

@mikedanese, это здорово, спасибо!
Просто для пустышки - каков будет эффект от этой версии 1.6.1 в отношении этой проблемы?
Будет ли kubelet запускаться без изменения /etc/systemd/system/kubelet.service.d/10-kubeadm.conf ( обходной путь

@jbeda спасибо за объяснение!

@jbeda Я думаю, что путаница возникает из-за того, что официальный установочный документ kubadm устанавливает репозиторий YUM на http://yum.kubernetes.io/repos/kubernetes-el7-x86_64. В этом репо есть только kubeadm-1.6.0

И снова, к моему разочарованию, сборка 1.5.6 об / мин и установка закончились той же самой проблемой. Запуск kubeadm init висит на той же строке:

# kubeadm init
Running pre-flight checks
<master/tokens> generated token: "5076be.38581a71134596d0"
<master/pki> generated Certificate Authority key and certificate:
Issuer: CN=kubernetes | Subject: CN=kubernetes | CA: true
Not before: 2017-04-03 21:28:18 +0000 UTC Not After: 2027-04-01 21:28:18 +0000 UTC
Public: /etc/kubernetes/pki/ca-pub.pem
Private: /etc/kubernetes/pki/ca-key.pem
Cert: /etc/kubernetes/pki/ca.pem
<master/pki> generated API Server key and certificate:
Issuer: CN=kubernetes | Subject: CN=kube-apiserver | CA: false
Not before: 2017-04-03 21:28:18 +0000 UTC Not After: 2018-04-03 21:28:18 +0000 UTC
Alternate Names: [10.25.47.21 10.96.0.1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local]
Public: /etc/kubernetes/pki/apiserver-pub.pem
Private: /etc/kubernetes/pki/apiserver-key.pem
Cert: /etc/kubernetes/pki/apiserver.pem
<master/pki> generated Service Account Signing keys:
Public: /etc/kubernetes/pki/sa-pub.pem
Private: /etc/kubernetes/pki/sa-key.pem
<master/pki> created keys and certificates in "/etc/kubernetes/pki"
<util/kubeconfig> created "/etc/kubernetes/kubelet.conf"
<util/kubeconfig> created "/etc/kubernetes/admin.conf"
<master/apiclient> created API client configuration
<master/apiclient> created API client, waiting for the control plane to become ready

Думаю, я просто дождусь релиза 1.6.1 и надеюсь ...

1.6.1 отсутствует.

@mikedanese Вы тестировали kubeadm перед закрытием этой ошибки? Прямо сейчас я смотрю на [apiclient] Created API client, waiting for the control plane to become ready уже 10 минут. На CentOS 7 с новой установкой 1.6.1

@bostone , возможно, вы

Попробуйте отредактировать /etc/systemd/system/kubelet.service.d/10-kubeadm.conf и добавить --cgroup-driver=systemd

Не забудьте запустить systemctl daemon-reload; systemctl restart kubelet

@gtirloni с нашим предложением я добрался до конца kubeadm init однако любая попытка запустить kubectl приводит к этой ошибке: The connection to the server localhost:8080 was refused - did you specify the right host or port? Я не уверен, где и как это изменить или какой порт является правильным. эта точка?

Не уверен, связано ли это, но вот что я вижу при запуске systemctl status kubelet :
Статус systemctl kubelet -l
● kubelet.service - kubelet: агент узла Kubernetes.
Загружено: загружено (/etc/systemd/system/kubelet.service; включено; предустановка поставщика: отключено)
Падение: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf
Активен: активен (работает) с понедельника 2017-04-03 17:31:07 PDT; 11мин назад
Документы: http://kubernetes.io/docs/
Основной PID: 10382 (кубелет)
CGroup: /system.slice/kubelet.service
├─10382 / usr / bin / kubelet --kubeconfig = / etc / kubernetes / kubelet.conf --require-kubeconfig = true --pod-manifest-path = / etc / kubernetes / manifestests --allow-privileged = true - -network-plugin = cni --cni-conf-dir = / etc / cni / net.d --cni-bin-dir = / opt / cni / bin --cluster-dns = 10.96.0.10 --cluster-domain = cluster.local --authorization-mode = Webhook --client-ca-file = / etc / kubernetes / pki / ca.crt --cgroup-driver = systemd
└─10436 journalctl -k -f

03 апреля, 17:41:56 sdl02269 kubelet [10382]: W0403 17: 41: 56.645299 10382 cni.go: 157] Невозможно обновить конфигурацию cni: сети не найдены в /etc/cni/net.d
03 апр, 17:41:56 sdl02269 kubelet [10382]: E0403 17: 41: 56.645407 10382 kubelet.go: 2067] Сеть времени выполнения контейнера не готова: NetworkReady = false причина: NetworkPluginNotReady сообщение: docker : сетевой плагин не готов: cni config неинициализированный

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

@bostone, может быть, вы пропустили эти шаги после kubeadm init ?

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

Вам также необходимо выполнить шаг 3, описанный здесь . Кажется, это связано с ошибкой конфигурации cni, которую вы получаете.

Также смотрю на [apiclient] Created API client, ожидая готовности уровня управления в течение 10 минут уже с Ubuntu 16.04 и новой установкой 1.6.1

@pingthings Я бы порекомендовал присоединиться к Slack Kubernetes и каналу kubeadm . Мы можем помочь вам отладить там.

Я успешно настроил свой кластер 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.

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

Кажется, это не решено (Ubuntu LTS, kubeadm 1.6.1).

Во-первых, я также столкнулся с зависанием kubeadm на «Созданном клиенте API, ожидании готовности уровня управления» при использовании флага --apiserver-advertise-address . Журналы журнала говорят:

let.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Apr 04 12:27:04 xxx kubelet[57592]: E0404 12:27:04.352780   57592 eviction_manager.go:214] eviction manager: unexpected err: failed GetNode: node 'xxx' not found
Apr 04 12:27:05 xxx kubelet[57592]: E0404 12:27:05.326799   57592 kubelet_node_status.go:101] Unable to register node "xxx" with API server: Post https://x.x.x.x:6443/api/v1/nodes: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.745674   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://x.x.x.x:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dxxx&resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.746759   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://x.x.x.x:6443/api/v1/nodes?fieldSelector=metadata.name%3Dxxx&resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.747749   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://x.x.x.x:6443/api/v1/services?resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeou

Если я не предоставлю этот флаг, kubeadm пройдет успешно, но даже тогда я получаю следующую ошибку при запуске kubelet:

Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Kubelet отказывается правильно запускаться, и я никак не могу подключиться к кластеру с kubectl

Кажется, версии 1.5.x kubeadm были удалены не только из репозитория centos, но и из Ubuntu LTS: https://packages.cloud.google.com/apt/dists/kubernetes-xenial/main/binary-amd64/Packages It затрудняет переход на более раннюю версию и фактически нарушает обратную совместимость

@bostone

Вы выяснили зависание при «ожидании готовности плоскости управления»? Я вижу то же самое после всех изменений в 1.6.1.

@gtirloni @srzjulio добавление этих шагов после kubeadm init не помогло. Это привело к изменению службы kubelet с failed на active (running) но у меня все еще есть сообщение The connection to the server localhost:8080 was refused - did you specify the right host or port? . И если я смотрю на прослушивание сервисов, я нигде не вижу 8080. Я вижу, что kubelet прослушивает эти порты:

kubelet    6397  root   12u  IPv6 611842      0t0  TCP *:4194 (LISTEN)
kubelet    6397  root   15u  IPv4 611175      0t0  TCP sdl02269.labs.teradata.com:49597->sdl02269.labs.teradata.com:sun-sr-https (ESTABLISHED)
kubelet    6397  root   16u  IPv4 611890      0t0  TCP localhost:10248 (LISTEN)
kubelet    6397  root   18u  IPv6 611893      0t0  TCP *:10250 (LISTEN)
kubelet    6397  root   19u  IPv6 611895      0t0  TCP *:10255 (LISTEN)

Значит, есть какая-то неправильная (измененная?) Настройка, которая неверно указывает на 8080?

@bostone вам нужен не порт kubelet, это kube-apiserver, он должен прослушивать порт 6443.

@sbezverk Я не входит ни в одну инструкцию). Что мне нужно сделать, чтобы переключиться с 8080 на 6443?

@bostone, если вы ничего не изменяли в манифесте apiserver, по умолчанию он будет прослушивать порт 6443. Вам просто нужно скопировать /etc/kubernetes/admin.conf в $ HOME / .kube / config, изменить права доступа к файлу конфигурации, и все будет готово.

@sbezverk BTW - Я выполняю все шаги установки как root, но эти 3 строки инструкций из вывода kubeadm init предлагают использовать пользователя sudo. Какая рекомендация по этому поводу? Следует ли запускать все шаги установки как sudo?

Хорошо, я проделал все шаги с нуля и, кажется, лучше. Вот шаги, которые у меня сработали до сих пор, и я работаю с правами root на CentOS 7.

# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
        https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
# setenforce 0
# yum install -y docker kubelet kubeadm kubectl kubernetes-cni
# vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

Добавьте -cgroup-driver=systemd в 10-kubeadm.conf и сохраните

# systemctl enable docker && systemctl start docker
# systemctl enable kubelet && systemctl start kubelet
# sysctl -w net.bridge.bridge-nf-call-iptables=1
# systemctl stop firewalld; systemctl disable firewalld
# kubeadm init
# cp /etc/kubernetes/admin.conf $HOME/
# chown $(id -u):$(id -g) $HOME/admin.conf
# export KUBECONFIG=$HOME/admin.conf
# kubectl apply -f https://git.io/weave-kube

На этом этапе я могу запустить kubectl get nodes и увидеть свой главный узел в списке.
Повторите все шаги для миньона, кроме kubeadm init и вместо этого запустив kubeadm join --token a21234.c7abc2f82e2219fd 12.34.567.89:6443 сгенерированный kubeadm init
Этот шаг завершен, и я вижу узлы мастера и миньона (ов).

А теперь - проблема:

# kubectl get nodes
NAME       STATUS     AGE       VERSION
abc02918   NotReady   42m       v1.6.1
abc04576   NotReady   29m       v1.6.1

# kubectl describe node abc02918
Events:
  FirstSeen LastSeen    Count   From            SubObjectPath   Type        Reason          Message
  --------- --------    -----   ----            -------------   --------    ------          -------
  43m       43m     1   kubelet, sdl02918           Normal      Starting        Starting kubelet.
  43m       43m     1   kubelet, sdl02918           Warning     ImageGCFailed       unable to find data for container /
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasSufficientDisk   Node sdl02918 status is now: NodeHasSufficientDisk
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasSufficientMemory Node sdl02918 status is now: NodeHasSufficientMemory
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasNoDiskPressure   Node sdl02918 status is now: NodeHasNoDiskPressure
  42m       42m     1   kube-proxy, sdl02918            Normal      Starting        Starting kube-proxy.

Похоже, что узлы так и не будут готовы. Какие-либо предложения?

Я полагаю, ваше переплетение не развертывается должным образом, потому что вы используете
файл yaml до версии 1.6.

Попробуйте "kubectl apply -f https://git.io/weave-kube-1.6 "

Во вторник, 4 апреля 2017 г., в 12:24 Бо Стоун [email protected] написал:

Хорошо, я проделал все шаги с нуля и, кажется, лучше. Здесь
шаги, которые сработали для меня до сих пор, и я работаю как root.

кошка <

[кубернетес]
name = Kubernetes
baseurl = http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
включен = 1
gpgcheck = 1
repo_gpgcheck = 1
gpgkey = https://packages.cloud.google.com/yum/doc/yum-key.gpg http://yum.kubernetes.io/repos/kubernetes-el7-x86_64enabled=1gpgcheck=1repo_gpgcheck=1gpgkey=https:/ /packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

setenforce 0

yum install -y docker kubelet kubeadm kubectl kubernetes-cni

vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

Добавьте -cgroup-driver = systemd в 10-kubeadm.conf и сохраните

systemctl включить докер && systemctl запустить докер

systemctl включить kubelet && systemctl start kubelet

sysctl -w net.bridge.bridge-nf-call-iptables = 1

systemctl stop firewalld; systemctl отключить firewalld

kubeadm init

cp /etc/kubernetes/admin.conf $ HOME /

chown $ (идентификатор -u): $ (идентификатор -g) $ HOME / admin.conf

экспорт KUBECONFIG = $ HOME / admin.conf

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

На этом этапе я могу запустить kubectl get nodes и увидеть свой главный узел в
список.
Повторите все шаги для миньона, кроме, конечно, запуска kubeadm join.
--token a21234.c7abc2f82e2219fd 12.34.567.89:6443, сгенерированный kubeadm
в этом
Этот шаг завершен, и я вижу узлы мастера и миньона (ов).

А теперь - проблема:

kubectl получить узлы

ИМЯ СТАТУС ВОЗРАСТ ВЕРСИЯ
abc02918 NotReady 42m v1.6.1
abc04576 NotReady 29m v1.6.1

kubectl описать узел abc02918

События:
FirstSeen LastSeen Count из сообщения о причине типа SubObjectPath
--------- -------- ----- ---- ------------- -------- --- --- -------
43м 43м 1 кубелет, sdl02918 Нормальный пуск Стартовый кубелет.
43m 43m 1 кубелет, sdl02918 Предупреждение ImageGCFailed не удалось найти данные для контейнера /
43m 43m 29 kubelet, sdl02918 Нормальный NodeHasSufficientDisk Статус узла sdl02918 теперь: NodeHasSufficientDisk
43m 43m 29 kubelet, sdl02918 Normal NodeHasSufficientMemory Статус узла sdl02918 теперь: NodeHasSufficientMemory
43m 43m 29 kubelet, sdl02918 Normal NodeHasNoDiskPressure Статус узла sdl02918 теперь: NodeHasNoDiskPressure
42м 42м 1 kube-proxy, sdl02918 Нормальный запуск Запуск kube-proxy.

Похоже, что узлы так и не будут готовы. Какие-либо предложения?

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-291571437 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAeJQ6OFBV3s6OHmfOkUdwqQsJ1sjg23ks5rsnzMgaJpZM4MtMRe
.

Используя CentOS и версию kubeadm 1.6.1-1, и следуя описанным выше шагам, я получаю немного другое поведение: кластер сообщается как готовый, но затем я застреваю на этом сообщении:

[apiclient] Temporarily unable to list nodes (will retry)

Но в логах все еще та же ошибка:

Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: E0404 13:30:30.491150  108575 pod_workers.go:182] Error syncing pod 2193220cb6f65d66c0d8762189232e64 ("kube-apiserver-csc-q-docker-1.colinx.com_kube-system(2193220cb6f65d66c0d8762189232e64)"), skipping: failed to "StartContainer" for "kube-apiserver" with CrashLoopBackOff: "Back-off 20s restarting failed container=kube-apiserver pod=kube-apiserver-csc-q-docker-1.colinx.com_kube-system(2193220cb6f65d66c0d8762189232e64)"
Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: W0404 13:30:30.524051  108575 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: E0404 13:30:30.524243  108575 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

@sjenning Вот и все! Мне все еще нужно развернуть несколько изображений, чтобы убедиться, что все работает, но я вижу все узлы со статусом Ready ! Всем спасибо, ребята (пока :)

@bostone Я следовал тому же рецепту, что и вы, но получил другие результаты - я не прошел kubeadm init. Какую версию докера вы используете? возможно, в этом разница в моем случае?

@dcowden Это то, что yum выбирает в моей системе Docker version 1.12.6, build 96d83a5/1.12.6 . Также мне помогло перепроверить все виртуальные машины, которые я использовал, вместо того, чтобы пытаться исправить мои предыдущие установки.

@bostone спасибо. Я перейду на эту версию, чтобы посмотреть, смогу ли я получить рабочую настройку. в моей системе самая последняя - странная версия 17.03.1.ce (очевидно, самая последняя лучшая)

Не уверен, что это вообще полезно, но у меня есть доступный сценарий, который
выполняет все шаги для CentOS 7

https://github.com/sjenning/kubeadm-playbook

YMMV, но, по крайней мере, документирует процесс. Я также делаю несколько вещей, например
переключить докер на использование ведения журнала json-файлов и хранилища оверлеев.

Может быть полезным в качестве справки, даже если вы на самом деле не запускаете playbook.

Во вторник, 4 апреля 2017 г., в 12:55, Дэйв Кауден [email protected]
написал:

@bostone https://github.com/bostone спасибо. я понизлюсь до этого
версию, чтобы увидеть, смогу ли я получить рабочую настройку. в моей системе последняя
странная версия 17.03.1.ce (очевидно, последняя лучшая)

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-291580822 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAeJQ7CUA4vxhF3T7nMc9wRu47rbWe-Kks5rsoQmgaJpZM4MtMRe
.

@sjenning Спасибо! это очень полезно!

Хорошо, вот одна сложность. после запуска kubeadm reset на мастере и миньоне и перезапуска служб docker и kubelet kubeadm init снова зависает на Created API client, waiting for the control plane to become ready . Может кто-нибудь предоставить полные инструкции по сбросу kubeadm?
@sjenning вы пытались перезапустить свой playbook после того, как вы его запустили изначально?

@bostone в моем случае перемещение /var/lib/etcd/ помогло .

@autostatic каталог был пуст, и его переименование не помогло. @sjenning у вас зависает playbook, я создал для вас билет

Кто-нибудь пробовал запустить дашборд на v1.6.1? Я получаю сообщение об ошибке, в котором говорится следующее:

`Запрещено (403)

Пользователь « system: serviceaccount: kube- system: default » не может отображать пространства имен в области кластера. (получить пространства имен)
`

Полагаю, мне нужно настроить больше RBAC, как вам нужно для работы с Flannel?

@srzjulio Можете ли вы подать новый выпуск по этому поводу? Я предполагаю, что это то, над чем SIG Auth и команда Dashboard должны работать вместе. Вероятно, это простое изменение YAML.

@srzjulio, вам нужно обновить правила RBAC, мы использовали их, чтобы начать работу:

apiVersion: rbac.authorization.k8s.io/v1alpha1
вид: ClusterRoleBinding
метаданные:
имя: кластер-админ
roleRef:
apiGroup: rbac.authorization.k8s.io
вид: ClusterRole
имя: кластер-админ
предметы:

• вид: Группа
  имя: система: мастера
• вид: Группа
  имя: система: аутентифицирован
• вид: Группа
  имя: система: не аутентифицировано

Будьте осторожны - привязка, которую имеет

kind: Group
name: system:unauthenticated

Это особенно плохо. Это означает, что любой, кто может связаться с вашим сервером API, даже без каких-либо учетных данных, может запускать произвольные команды.

@jbeda соответствует поведению, которое мы имели с 1.5.6 прямо из коробки. Это дает людям возможность просматривать и постепенно корректировать конфигурацию безопасности, вместо того, чтобы ничего делать с новыми правилами безопасности.

Собственно, сделать system: unauthenticated админ кластера намного хуже, чем 1.5.6

Если вы не хотите авторизации, используйте авторизатор AlwaysAllow.

Если вы хотите разрешить все, пока вы проводите аудит, используйте комбинацию RBAC, AlwaysAllow.

Это отключит анонимные запросы, регистрирует отказы RBAC в журнале сервера API, но по-прежнему разрешает всем аутентифицированным запросам делать все, что они хотят.

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

Опять же, извините, нажмите Enter слишком рано, но пока дела обстоят:

1 - выпуск 1.6.0 вызывает проблемы
2 - не все исправлено
3 - переход на RBAC (на мой взгляд, хорошо), но это проблема, почему? см. пункт 4
4 - Об этом не очень хорошо рассказали, и не так много документов / блогов или чего-то еще, чтобы это объяснить
5 - Я преклоняюсь перед всеми людьми, пытающимися спасти, но нам нужен лучший способ сделать это

https://kubernetes.io/docs/admin/authorization/rbac/#service -account-permissions - хорошее руководство по наиболее или менее детализированным вариантам открытия разрешений.

добавление " --cgroup-driver = systemd " в кублет вызывает новую проблему в Centos / RHEL 7.3 (полностью обновленная - также известная как docker 1.10.3):

Apr 12 14:23:25 machine01 kubelet[3026]: W0412 14:23:25.542322    3026 docker_service.go:196] No cgroup driver is set in Docker
Apr 12 14:23:25 machine01 kubelet[3026]: W0412 14:23:25.542343    3026 docker_service.go:197] Falling back to use the default driver: "cgroupfs"
Apr 12 14:23:25 machine01 kubelet[3026]: error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"

в то время как мы можем ясно видеть, что native.cgroupdriver = systemd установлен в

 ps -ef|grep -i docker
root      4365     1  3 14:30 ?        00:00:33 /usr/bin/docker-current daemon --authorization-plugin=rhel-push-plugin --exec-opt native.cgroupdriver=systemd --selinux-enabled --log-driver=journald --insecure-registry 172.30.0.0/16 --storage-driver devicemapper --storage-opt dm.fs=xfs --storage-opt dm.thinpooldev=/dev/mapper/vg.docker--pool --storage-opt dm.use_deferred_removal=true --storage-opt dm.use_deferred_deletion=true

@ReSearchITEng, почему докер не обновляется до 1.12.6? Прекрасно работает с этой версией.

@sbezverk : Я только что обновился до 1.12.5, и теперь он работает! Большое спасибо!

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

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

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

@sjenning @ReSearchITEng
Привет, у меня есть vagrant + ansible playbook [0], очень похожий на то, что вы создали, но я все еще не могу заставить его работать, хотя для меня он не работает при настройке сети. Я пробовал использовать ситцевую ткань, ткань и фланель, и все три оказались неудачными (хотя и с разными симптомами).

Я использую эти версии:
[ vagrant @ master ~] $ docker --version
Докер версии 1.12.6, сборка 3a094bd / 1.12.6
[ vagrant @ master ~] $ kubelet --version
Kubernetes v1.6.1
[ vagrant @ master ~] версия $ kubeadm
версия kubeadm: version.Info {Major: «1», Minor: «6», GitVersion: «v1.6.1», GitCommit: «b0b7a323cc5a4a2019b2e9520c21c7830b7f708e», GitTreeState: «clean», BuildDate: «33-04-03T20» 27Z ", GoVersion:" go1.7.5 ", компилятор:" gc ", платформа:" linux / amd64 "}

ошибки:

[vagrant<strong i="19">@master</strong> ~]$ kubectl get all --all-namespaces
NAMESPACE     NAME                                           READY     STATUS             RESTARTS   AGE
kube-system   po/calico-etcd-gvrhd                           1/1       Running            0          47m
kube-system   po/calico-node-7jvs8                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-node-7ljpn                           2/2       Running            0          47m
kube-system   po/calico-node-w15z3                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-node-zq3zx                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-policy-controller-1777954159-13x01   1/1       Running            0          47m
kube-system   po/etcd-master                                 1/1       Running            0          46m
kube-system   po/kube-apiserver-master                       1/1       Running            0          46m
kube-system   po/kube-controller-manager-master              1/1       Running            0          46m
kube-system   po/kube-dns-3913472980-16m01                   3/3       Running            0          47m
kube-system   po/kube-proxy-70bmf                            1/1       Running            0          45m
kube-system   po/kube-proxy-9642h                            1/1       Running            0          45m
kube-system   po/kube-proxy-jhtvm                            1/1       Running            0          45m
kube-system   po/kube-proxy-nb7q5                            1/1       Running            0          47m
kube-system   po/kube-scheduler-master                       1/1       Running            0          46m

NAMESPACE     NAME              CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
default       svc/kubernetes    10.96.0.1       <none>        443/TCP         47m
kube-system   svc/calico-etcd   10.96.232.136   <none>        6666/TCP        47m
kube-system   svc/kube-dns      10.96.0.10      <none>        53/UDP,53/TCP   47m

NAMESPACE     NAME                              DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kube-system   deploy/calico-policy-controller   1         1         1            1           47m
kube-system   deploy/kube-dns                   1         1         1            1           47m

NAMESPACE     NAME                                     DESIRED   CURRENT   READY     AGE
kube-system   rs/calico-policy-controller-1777954159   1         1         1         47m
kube-system   rs/kube-dns-3913472980                   1         1         1         47m

[vagrant<strong i="5">@master</strong> ~]$ kubectl -n kube-system describe po/calico-node-zq3zx
Name:       calico-node-zq3zx
Namespace:  kube-system
Node:       node1/192.168.10.101
Start Time: Wed, 26 Apr 2017 19:37:35 +0000
Labels:     k8s-app=calico-node
        pod-template-generation=1
Annotations:    kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"DaemonSet","namespace":"kube-system","name":"calico-node","uid":"844cd287-2ab7-11e7-b184-5254008815b6","ap...
        scheduler.alpha.kubernetes.io/critical-pod=
Status:     Running
IP:     192.168.10.101
Controllers:    DaemonSet/calico-node
Containers:
  calico-node:
    Container ID:   docker://ca00b0a73a073a2d2e39cb0cc315b8366eaa20e2e479002dd16134b0d1e94f0b
    Image:      quay.io/calico/node:v1.1.3
    Image ID:       docker-pullable://quay.io/calico/node<strong i="6">@sha256</strong>:8e62eee18612a6ac7bcae90afaba0ed95265baba7bf3c0ab632b7b40ddfaf603
    Port:       
    State:      Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Mon, 01 Jan 0001 00:00:00 +0000
      Finished:     Wed, 26 Apr 2017 20:21:09 +0000
    Ready:      False
    Restart Count:  12
    Requests:
      cpu:  250m
    Environment:
      ETCD_ENDPOINTS:               <set to the key 'etcd_endpoints' of config map 'calico-config'> Optional: false
      CALICO_NETWORKING_BACKEND:        <set to the key 'calico_backend' of config map 'calico-config'> Optional: false
      CALICO_DISABLE_FILE_LOGGING:      true
      FELIX_DEFAULTENDPOINTTOHOSTACTION:    ACCEPT
      CALICO_IPV4POOL_CIDR:         192.168.0.0/16
      CALICO_IPV4POOL_IPIP:         always
      FELIX_IPV6SUPPORT:            false
      FELIX_LOGSEVERITYSCREEN:          info
      IP:                   
    Mounts:
      /lib/modules from lib-modules (ro)
      /var/run/calico from var-run-calico (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from calico-cni-plugin-token-5wnmg (ro)
  install-cni:
    Container ID:   docker://442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
    Image:      quay.io/calico/cni:v1.7.0
    Image ID:       docker-pullable://quay.io/calico/cni<strong i="7">@sha256</strong>:3612ffb0bff609d65311b45f4bae57fa80a05d25e1580ceb83ba4162e2ceef9f
    Port:       
    Command:
      /install-cni.sh
    State:      Running
      Started:      Wed, 26 Apr 2017 19:38:29 +0000
    Ready:      True
    Restart Count:  0
    Environment:
      ETCD_ENDPOINTS:       <set to the key 'etcd_endpoints' of config map 'calico-config'>     Optional: false
      CNI_NETWORK_CONFIG:   <set to the key 'cni_network_config' of config map 'calico-config'> Optional: false
    Mounts:
      /host/etc/cni/net.d from cni-net-dir (rw)
      /host/opt/cni/bin from cni-bin-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from calico-cni-plugin-token-5wnmg (ro)
Conditions:
  Type      Status
  Initialized   True 
  Ready     False 
  PodScheduled  True 
Volumes:
  lib-modules:
    Type:   HostPath (bare host directory volume)
    Path:   /lib/modules
  var-run-calico:
    Type:   HostPath (bare host directory volume)
    Path:   /var/run/calico
  cni-bin-dir:
    Type:   HostPath (bare host directory volume)
    Path:   /opt/cni/bin
  cni-net-dir:
    Type:   HostPath (bare host directory volume)
    Path:   /etc/cni/net.d
  calico-cni-plugin-token-5wnmg:
    Type:   Secret (a volume populated by a Secret)
    SecretName: calico-cni-plugin-token-5wnmg
    Optional:   false
QoS Class:  Burstable
Node-Selectors: <none>
Tolerations:    CriticalAddonsOnly=:Exists
        node-role.kubernetes.io/master=:NoSchedule
        node.alpha.kubernetes.io/notReady=:Exists:NoExecute for 300s
        node.alpha.kubernetes.io/unreachable=:Exists:NoExecute for 300s
Events:
  FirstSeen LastSeen    Count   From        SubObjectPath           Type        Reason      Message
  --------- --------    -----   ----        -------------           --------    ------      -------
  46m       46m     1   kubelet, node1  spec.containers{calico-node}    Normal      Pulling     pulling image "quay.io/calico/node:v1.1.3"
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Pulled      Successfully pulled image "quay.io/calico/node:v1.1.3"
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Created     Created container with id e035a82202b2c8490e879cb9647773158ff05def6c60b31a001e23e6d288a977
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Started     Started container with id e035a82202b2c8490e879cb9647773158ff05def6c60b31a001e23e6d288a977
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Pulling     pulling image "quay.io/calico/cni:v1.7.0"
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Pulled      Successfully pulled image "quay.io/calico/cni:v1.7.0"
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Created     Created container with id 442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Started     Started container with id 442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
  44m       44m     1   kubelet, node1  spec.containers{calico-node}    Normal      Created     Created container with id 163a9073070aa52ce7ee98c798ffe130a581e4fdbbc503540ed5d3b79651c549
  44m       44m     1   kubelet, node1  spec.containers{calico-node}    Normal      Started     Started container with id 163a9073070aa52ce7ee98c798ffe130a581e4fdbbc503540ed5d3b79651c549
  44m       44m     1   kubelet, node1                  Warning     FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 10s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  44m   44m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 07453d944dfb9a4ebae57c83158e4b51f8870bcab94b4f706239f6c0b93bb62d
  44m   44m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 07453d944dfb9a4ebae57c83158e4b51f8870bcab94b4f706239f6c0b93bb62d
  43m   43m 2   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 20s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  43m   43m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 00f363848c16ff66743d54b87948133a87a97bfd32fbde2338622904d0990601
  43m   43m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 00f363848c16ff66743d54b87948133a87a97bfd32fbde2338622904d0990601
  42m   42m 3   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 40s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  41m   41m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id a5aad1f1a57a361fafcaa2ee6aba244bf19925f56c5b46771cfd45e5e7fd884e
  41m   41m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id a5aad1f1a57a361fafcaa2ee6aba244bf19925f56c5b46771cfd45e5e7fd884e
  41m   40m 6   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 1m20s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  40m   40m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 520ee97fe986fd726a0347cab6de5b2a8fba91f73df2d601e8b7625531ed2117
  40m   40m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 520ee97fe986fd726a0347cab6de5b2a8fba91f73df2d601e8b7625531ed2117
  39m   36m 12  kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 2m40s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  36m   36m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 90be4da6fd2e8c111c3e2a91256d60656db80316c1497c29c4155b8f009f241f
  36m   36m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 90be4da6fd2e8c111c3e2a91256d60656db80316c1497c29c4155b8f009f241f
  31m   31m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id bf0d93f45d5ffa2d2c42487851f80048757da5c767491f673bfecfa37fe76e48
  31m   31m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id bf0d93f45d5ffa2d2c42487851f80048757da5c767491f673bfecfa37fe76e48
  44m   3m  12  kubelet, node1  spec.containers{calico-node}    Normal  Pulled      Container image "quay.io/calico/node:v1.1.3" already present on machine
  25m   3m  5   kubelet, node1  spec.containers{calico-node}    Normal  Started     (events with common reason combined)
  25m   3m  5   kubelet, node1  spec.containers{calico-node}    Normal  Created     (events with common reason combined)
  36m   15s 149 kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  44m   15s 173 kubelet, node1  spec.containers{calico-node}    Warning BackOff Back-off restarting failed container

Это похоже на ключевую информацию, но я не знаю, как это исправить:

[vagrant<strong i="6">@master</strong> ~]$ kubectl -n kube-system logs calico-node-zq3zx calico-node
Skipping datastore connection test
time="2017-04-26T20:20:39Z" level=info msg="NODENAME environment not specified - check HOSTNAME" 
time="2017-04-26T20:20:39Z" level=info msg="Loading config from environment" 
ERROR: Unable to access datastore to query node configuration
Terminating
time="2017-04-26T20:21:09Z" level=info msg="Unhandled error: client: etcd cluster is unavailable or misconfigured; error #0: client: endpoint http://10.96.232.136:6666 exceeded header timeout
" 
time="2017-04-26T20:21:09Z" level=info msg="Unable to query node configuration" Name=node1 error="client: etcd cluster is unavailable or misconfigured; error #0: client: endpoint http://10.96.232.136:6666 exceeded header timeout
" 
Calico node failed to start

Любая помощь будет принята с благодарностью ...

[0] - https://github.com/thiagodasilva/kubernetes-swift/tree/master/roles

Я не мог определить, что с тобой не так.
Я настоятельно рекомендую вам попробовать создать отдельную установку, используя playbooks здесь: https://github.com/ReSearchITEng/kubeadm-playbook, и попытаться увидеть, в чем разница.
PS: мои последние тесты были с 1.6.2, как kube *, так и изображениями, и кажется, что все в порядке.

@kelseyhightower

@ReSearchITEng, извините, я забыл сообщить об этом, но в конце концов я заставил его работать, мои файлы vagrant + ansible находятся здесь: https://github.com/thiagodasilva/kubernetes-swift

У меня тоже возникла та же проблема, но я просто копирую конфигурацию cni на главном узле в соответствующее место рабочего узла, после чего все в порядке.

systemctl status kubelet.service -l

● kubelet.service - kubelet: агент узла Kubernetes.
Загружено: загружено (/etc/systemd/system/kubelet.service; включено; предустановка поставщика: отключено)
Падение: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf
Активен: активен (работает) с Вт 2017-06-06 10:42:00 CST; 18мин назад
Документы: http://kubernetes.io/docs/
Основной PID: 4414 (кубелет)
Память: 43,0 МБ
CGroup: /system.slice/kubelet.service
├─4414 / usr / bin / kubelet --kubeconfig = / etc / kubernetes / kubelet.conf --require-kubeconfig = true --pod-manifest-path = / etc / kubernetes / manifest --network-plugin = cni - -cni-conf-dir = / etc / cni / net.d --cni-bin-dir = / opt / cni / bin --cluster-dns = 10.96.0.10 --cluster-domain = cluster.local --authorizatio -ca-файл = / etc / kubernetes / pki / ca.crt --cgroup-driver = cgroupfs
└─4493 journalctl -k -f

06 июня, 10:59:46 contiv1.com kubelet [4414]: W0606 10: 59: 46.215827 4414 cni.go: 157] Невозможно обновить конфигурацию cni: сети не найдены в /etc/cni/net.d
06 июня, 10:59:46 contiv1.com kubelet [4414]: E0606 10: 59: 46.215972 4414 kubelet.go: 2067] Сеть времени выполнения контейнера не готова: NetworkReady = false ready message: docker : сетевой плагин не готов: cni config неинициализированный
06 июня, 10:59:51 contiv1.com kubelet [4414]: W0606 10: 59: 51.216843 4414 cni.go: 157] Невозможно обновить конфигурацию cni: сети не найдены в /etc/cni/net.d
06 июня, 10:59:51 contiv1.com kubelet [4414]: E0606 10: 59: 51.216942 4414 kubelet.go: 2067] Сеть времени выполнения контейнера не готова: NetworkReady = false ready message: docker : сетевой плагин не готов: cni config неинициализированный
06 июня, 10:59:56 contiv1.com kubelet [4414]: W0606 10: 59: 56.217923 4414 cni.go: 157] Невозможно обновить конфигурацию cni: сети не найдены в /etc/cni/net.d
06 июня, 10:59:56 contiv1.com kubelet [4414]: E0606 10: 59: 56.218113 4414 kubelet.go: 2067] Сеть времени выполнения контейнера не готова: NetworkReady = false ready message: docker : сетевой плагин не готов: cni config неинициализированный
06 июня, 11:00:01 contiv1.com kubelet [4414]: W0606 11: 00: 01.219251 4414 cni.go: 157] Невозможно обновить конфигурацию cni: сети не найдены в /etc/cni/net.d
06 июня, 11:00:01 contiv1.com kubelet [4414]: E0606 11: 00: 01.219382 4414 kubelet.go: 2067] Сеть времени выполнения контейнера не готова: NetworkReady = false ready message: docker : сетевой плагин не готов: cni config неинициализированный
06 июня, 11:00:06 contiv1.com kubelet [4414]: W0606 11: 00: 06.220396 4414 cni.go: 157] Невозможно обновить конфигурацию cni: сети не найдены в /etc/cni/net.d
06 июня, 11:00:06 contiv1.com kubelet [4414]: E0606 11: 00: 06.220575 4414 kubelet.go: 2067] Сеть времени выполнения контейнера не готова: NetworkReady = false ready message: docker : сетевой плагин не готов: cni config неинициализированный

Статус всех узлов:
[ root @ swarm net.d] # kubectl получить узел
ИМЯ СТАТУС ВОЗРАСТ ВЕРСИЯ
contiv1.com Готово 1ч v1.6.4
contiv2.com Готово 1ч v1.6.4
swarm.com Готов 1ч v1.6.4

Есть какое-нибудь решение по этому поводу? Я не смог этого сделать даже после того, как попробовал все упомянутые разрешения.

Поскольку я новичок в настройке Kubernetes, я очень запутался. Я пробовал следовать https://medium.com/@SystemMining/setup -kubenetes-cluster-on-ubuntu-16-04-with-kubeadm-336f4061d929, которые используют weave-kube для сети, но я также застрял с той же проблемой . Любой способ решить эту проблему?
Ready False Mon, 12 Jun 2017 16:55:16 +0200 Mon, 12 Jun 2017 12:22:45 +0200 KubeletNotReady runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Почему это все еще проблема? Ubuntu 16.04 / CentOS 7.3 с последними обновлениями с использованием официальных репозиториев k8s с 1.6.4 и следуя инструкциям, описанным здесь: https://kubernetes.io/docs/setup/independent/install-kubeadm/
Jun 13 09:57:21 tme-lnx1-centos kubelet: W0613 09:57:21.871413 10321 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Jun 13 09:57:21 tme-lnx1-centos kubelet: E0613 09:57:21.871788 10321 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

@drajen Нет, это коснулось только v1.6.0_ . Ожидается, что kubelet не найдет сеть, поскольку вы ее не установили. Например, просто запустите

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

установить Weave Net, и эти проблемы исчезнут. Вы можете установить Flannel, Calico, Canal или любую другую сеть CNI, если хотите.

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

@drajen Я думаю, что суть @luxas в том, что это неправильное место, чтобы спрашивать о настройке.
Различные руководства по настройке помогут вам преодолеть этот момент - типичный недостающий шаг в старых руководствах, который Luxas услужливо упоминает, поскольку вам необходимо применить конфигурацию сети, прежде чем все начнет работать должным образом.

Да, это может быть неочевидно, и мы сожалеем об этом, но у нас также не может быть одного имени поставщика.

Пообщался с @drajen в Slack, и проблема была связана с cgroup, kubelet был нездоровым и не мог создавать какие-либо поды, отсюда и проблема.

Спасибо @luxas за https://github.com/kubernetes/kubeadm/issues/302

Все еще сталкиваюсь с этим в Arch на 1.7, есть ли где-нибудь быстрое исправление?

Редактировать:

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

сделали свое дело, похоже, нам просто нужно было запустить CNI

По крайней мере, для CentOS / RHEL, убедитесь, что вы обновили /etc/systemd/system/kubelet.service.d/10-kubeadm.conf и добавили флаг --cgroup-driver = "systemd"

Если вы переустановите снова на том же компьютере, это будет полный правильный сброс:
https://github.com/ReSearchITEng/kubeadm-playbook/blob/master/reset.yml
(это необходимо, особенно если вы используете фланель)
Если вы хотите сделать все в одном, вы можете использовать весь проект: https://github.com/ReSearchITEng/kubeadm-playbook/

Я столкнулся с этой проблемой, и абсолютно ничего из того, что я прочитал выше, не сработало. Итак, я попробовал еще раз с гораздо более контролируемой настройкой, переключившись с Ubuntu на последнюю версию CoreOS, перейдя на более раннюю версию k8s для начала, и в целом очень внимательно относился ко всем, что было установлено в каждой виртуальной машине. Я НЕ использую kubeadm, а вместо него комбинацию vagrant и ansible.

(почему? потому что я понятия не имел, что происходит в kubeadm, и полагал, что таким образом я, по крайней мере, получу контроль и смогу обойти любые чрезмерные предполетные проверки, не говоря уже о том, что у меня было больше контроля автоматизации в целом, а также не беспокоиться о предупреждении о необходимости-не-применять-альфа-программное обеспечение в производстве.)

Когда я попробовал эту настройку с более старой (1.4.3) версией k8s, этот подход оказался золотым. Затем я попытался перейти на версию 1.71. Еще раз, я все еще сталкиваюсь с этой проблемой, несмотря на то, что вообще не использую kubeadm.

Я подтвердил, что использую calico на каждом из моих узлов, включая Мастера и трех потенциальных Рабочих. ВСЕ мои узлы сообщают как NotReady, поэтому я не совсем уверен, как я могу применить Weave (или что-то еще), чтобы заставить его работать.

Все это просто кажется цыпленком / яйцом ... не может выделить модуль, потому что сеть не работает, но требуется, чтобы сеть была запущена для создания сети в /etc/cni/net.d, чтобы иметь возможность выделять модули. И снова все это работало несколько часов назад с k8s 1.4.3. Я очень расстроен!

Буду признателен за любые идеи, которые мог бы дать кто-нибудь.

Сноски:

На мастере: journalctl -r -u kubelet дает мне

24 июля, 00:48:16 rogue-kube-master-01 kubelet-wrapper [7647]: E0724 00: 48: 16.592274 7647 kubelet.go: 2136] Сеть времени выполнения контейнера не готова: NetworkReady = false, причина: NetworkPluginNotReady, сообщение: docker : сетевой плагин нет
24 июля, 00:48:16 rogue-kube-master-01 kubelet-wrapper [7647]: W0724 00: 48: 16.590588 7647 cni.go: 189] Невозможно обновить конфигурацию cni: сети не найдены в / etc / cni / net .d

докер пс | grep calico

(усечено для удобства чтения)
cde ... quay.io/calico/ leader-elector @ sha256 : ... "/run.sh --election = c" 8 часов назад Up 8 часов
f72 ... calico / kube-policy-controller @ sha256 : ... "/ dist / controller" 8 часов назад Up 8 часов
c47 ... gcr.io/google_containers/pause-amd64:3.0 "/ pause" 8 часов назад Вверх 8 часов

Нет /etc/cni/net.d

Из моего ящика kubectl:
kubectl получить узлы
10.0.0.111 NotReady, SchedulingDisabled 8h v1.7.1 + coreos.0
10.0.0.121 NotReady 8h v1.7.1 + coreos.0
10.0.0.122 NotReady 8h v1.7.1 + coreos.0
10.0.0.123 NotReady 8h v1.7.1 + coreos.0

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

Ничего НЕ исправлял и на самом деле, кажется, только создал больше проблем.

bill @ rogue : ~ / vagrant_rogue / rogue-cluster $ kubectl apply -f https://git.io/weave-kube-1.6
сервисаккаунт "сотка-сеть" создан
кластеррообвязка "плетение-сетка" создана
демонсет "weave-net" создан
Ошибка сервера (Запрещено): clusterroles.rbac.authorization.k8s.io "weave-net" запрещено: попытка предоставить дополнительные привилегии: [PolicyRule {Resources: ["pods"], APIGroups: [""], глаголы: ["get"]} PolicyRule {ресурсы: ["pods"], APIGroups: [""], Verbs: ["list"]} PolicyRule {Resources: ["pods"], APIGroups: [""], Verbs: ["смотреть"]} Правило политики {ресурсы: ["пространства имен"], APIGroups: [""], глаголы: ["get"]} правило политики {ресурсы: ["пространства имен"], APIGroups: [""], глаголы: ["список"]} Правило политики {ресурсы: ["пространства имен"], APIGroups: [""], глаголы: ["смотреть"]} правило политики {ресурсы: ["узлы"], APIGroups: [""], глаголы: ["get"]} Правило политики {ресурсы: ["узлы"], APIGroups: [""], глаголы: ["список"]} правило политики {ресурсы: ["узлы"], APIGroups: [""], глаголы: ["смотреть"]} Правило политики {ресурсы: ["сетевые политики"], APIGroups: ["расширения"], глаголы: ["получить"]} Правило политики {ресурсы: ["сетевые политики"], APIGroups: ["расширения"], Глаголы: ["list"]} PolicyRule {Ресурсы: ["networkpolicies"], APIGroups: ["extensions"], Глаголы: ["watch"]}] user = & {kube-admin [system: a аутентифицировано] карта []} ownerrules = [] ruleResolutionErrors = []

bill @ rogue : ~ / vagrant_rogue / rogue-cluster $ kubectl get pods --namespace = kube-system
НАЗВАНИЕ ГОТОВ СОСТОЯНИЕ ВОЗРАСТ ВОЗВРАЩАЕТСЯ
kube-apiserver-10.0.0.111 1/1 Работает 1 8ч
kube-controller-manager-10.0.0.111 1/1 Выполняется 1 8 часов
kube-dns-v20-fcl01 0/3 В ожидании 0 8ч
kube-proxy-10.0.0.111 1/1 Выполняется 1 8 часов
kube-proxy-10.0.0.121 1/1 Выполняется 1 8 часов
kube-proxy-10.0.0.122 1/1 Выполняется 1 8 часов
kube-proxy-10.0.0.123 1/1 Выполняется 1 8 часов
kube-scheduler-10.0.0.111 1/1 Выполняется 1 8 часов
kubernetes-dashboard-v1.4.1-29zzk 0/1 В ожидании 0 8ч
weave-net-2lplj 1/2 CrashLoopBackOff 3 3м
weave-net-2nbgd 1/2 CrashLoopBackOff 3 3 мес.
weave-net-fdr1v 2/2 Бег 0 3м
weave-net-jzv50 1/2 CrashLoopBackOff 3 3 мес.

Более глубокое исследование ошибок плетения показывает, что они либо (а) не могут подключиться к apiserver, либо (б) в случае с пометкой «Выполняется» он жалуется, что не может подключиться к самому себе.

@billmilligan Имея аналогичные проблемы, DNS перестает работать через несколько минут после запуска контейнера

@Paxa @billmilligan Если вы хотите получить помощь, не комментируйте этот вопрос. Вместо этого откройте новые в репозитории kubeadm с запросом достаточной информации.

@luxas С уважением, я должен задаться вопросом, новая ли это проблема. Поскольку при настройке k8s без kubeadm я получаю тот же результат, что и все остальные с kubeadm, похоже, это устраняет kubeadm как источник проблемы. Может, стоит переименовать этот выпуск соответственно?

@billmilligan с уважением, так как проблема связана с kubeadm, и вы можете воспроизвести его без kubeadm, то это неправильное место для его хранения? Я думаю, что эта ветка решила проблему с kubeadm. Это новая проблема. Думаю, в качестве нового выпуска ему будет уделено больше внимания. Поскольку люди в этой ветке думают, что она уже решена, и игнорируют ее.

Я использую kubeadm, и эта проблема была решена, начиная с версии 1.6.1. С тех пор я развернул утерянные k8s, так что я действительно думаю, что у вас есть отдельная проблема.

@ kfox1111 Спасибо за отзыв. Я запишу новую проблему, но количество людей, которые, кажется, все еще сталкиваются с ней где-то еще в 1.7.x, все еще заставляет меня задуматься.

TL; DR;

Сообщение об ошибке

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

НЕ обязательно плохо.

Это сообщение об ошибке сообщает вам, что вам необходимо подключить сторонний поставщик реализации спецификации CNI .

Что такое CNI и как интегрируется с Kubernetes?

CNI расшифровывается как Container Network Interface и определяет спецификацию, которую kubelet использует для создания сети для кластера. На этой странице вы найдете дополнительную информацию о том, как Kubernetes использует спецификацию CNI для создания сети для кластера.

Kubernetes не заботится о том, как создается сеть, если она соответствует спецификации CNI.

kubelet отвечает за подключение новых модулей к сети (например, может быть оверлейной сетью).
kubelet читает каталог конфигурации (часто /etc/cni/net.d ) для использования в сетях CNI.
Когда создается новый Pod, кубелет считывает файлы в каталоге конфигурации, exec отправляет в двоичный файл CNI, указанный в файле конфигурации (двоичный файл часто находится в /opt/cni/bin ). Бинарный файл, который будет выполняться, принадлежит и установлен третьей стороной (например, Weave, Flannel, Calico и т. Д.).

kubeadm - это универсальный инструмент для раскрутки кластеров Kubernetes, который не знает, какое сетевое решение вам нужно, и не поддерживает никого конкретного. После запуска kubeadm init нет ни двоичного файла CNI, ни конфигурации . Это означает, что kubeadm init НЕДОСТАТОЧНО для запуска и запуска полностью рабочего кластера.

Это означает, что после kubeadm init в журналах kubelet будет сказано

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

это очень ожидаемо. Если бы это было не так, мы бы предпочли конкретного сетевого провайдера.

Итак, как мне «исправить» эту ошибку?
Следующим шагом в руководстве по началу работы с kubeadm является «Установка сети Pod».
Это означает, что kubectl apply манифест от предпочтительного сетевого провайдера CNI.

DaemonSet скопирует двоичные файлы CNI, необходимые для /opt/cni/bin и необходимую конфигурацию в /etc/cni/net.d/ . Также он будет запускать фактический демон, который устанавливает сеть между узлами (например, путем написания правил iptables).

После установки провайдера CNI kubelet заметит, что «у меня есть информация, как настроить сеть», и будет использовать стороннюю конфигурацию и двоичные файлы.

И когда сеть настраивается сторонним провайдером (вызывая его с помощью kubelet), узел помечает себя как Ready .

Как эта проблема связана с kubeadm?

В конце цикла v1.6 был объединен PR, который изменил способ сообщения kubelet статуса Ready/NotReady . В более ранних выпусках kubelet всегда сообщал о статусе Ready , независимо от того, была настроена сеть CNI или нет. На самом деле это было неправильно и было изменено с учетом статуса сети CNI. То есть NotReady при неинициализации CNI и Ready при инициализации.

kubeadm в v1.6.0 ошибочно ожидал, пока главный узел будет в состоянии Ready прежде чем продолжить выполнение остальных задач kubeadm init . Когда поведение kubelet изменилось на сообщение NotReady при неинициализации CNI, kubeadm будет вечно ждать, пока узел получит Ready .

ЭТО ОЖИДАЕТ НЕПРАВИЛЬНОЕ ПОНЯТИЕ НА СТОРОНЕ KUBEADM.

Однако мы быстро исправили регресс в версии 1.6.1 и выпустили ее через несколько дней после версии 1.6.0.

Пожалуйста, прочтите ретроспективу для получения дополнительной информации об этом и о том, почему v1.6.0 может быть выпущена с этим недостатком.

Итак, что делать, если вы думаете, что видите эту проблему в kubeadm v1.6.1 +?

Ну, я правда думаю, что нет. Эта проблема возникает, когда kubeadm init заходит в тупик.
Ни пользователи, ни сопровождающие не видели этого в версии 1.6.1 +.

То , что вы видите , хотя это

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

после каждого kubeadm init во всех версиях выше v1.6, но это НЕ ПЛОХО

В любом случае, если вы видите что-то неожиданное с kubeadm, открывайте новый выпуск.

Пожалуйста, не комментируйте эту проблему больше. Вместо этого откройте новый.

@billmilligan Итак, вам нужно всего лишь kubectl apply манифест провайдера CNI, чтобы ваш кластер заработал, я думаю

Я в значительной степени резюмирую сказанное выше, но, надеюсь, более четко и подробно.
Если у вас есть вопросы о том, как работает CNI, обратитесь к обычным каналам поддержки, таким как StackOverflow, проблема или Slack.

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