Как отладить приложение kubectl для kube-flannel.yml?

Буквально сегодня вечером я использовал kubespray, чтобы подготовить бродячий кластер на CoreOS, используя фланель (vxlan ), и я также был озадачен тем, как фланель может быть подом внутри Kubernetes.

Оказывается, , как видно здесь, что они используют flannel-cni изображение от для записи файлов CNI с помощью фланелевой коляски и креплений для томов hostDir; он выводит cni-conf.json (который настраивает CNI на использование фланели), а затем net-conf.json (который настраивает подсеть и серверную часть, используемые фланелью).

Я надеюсь, что синтаксис усов jinja2 не запутывает ответ, но мне было очень интересно посмотреть, как ребята из Kubernetes решили сделать это «по-настоящему» для сравнения и сравнения с примером DaemonSet, приведенным в README flannel-cni. Я предполагаю, что это длинный способ сказать: попробуйте дескрипторы в README flannel-cni, а затем, если это не сработает, посмотрите, отличаются ли они чем-то от заведомо работающей установки kubespray

update: в качестве конкретного примера обратите внимание, что yaml с документацией не включает _ 4_, и если ваша настройка Vagrant использует как NAT, так и" private_network ", то это, вероятно, означает, что фланель привязана к eth0 (NAT) а не eth1 с более статическим IP. Я видел это предостережение, упомянутое в документации, но не могу сразу вспомнить, где его цитировать.

обновление 2

Есть ли способ узнать, почему эта команда не работает? Могу ли я получить журналы откуда угодно?

Почти всегда можно получить доступ к журналам модуля (даже к статически определенному, например kube-controller-manager-coreos1) одним и тем же способом: kubectl --namespace=kube-system logs kube-controller-manager-coreos1, а в случае CrashLoopBackOff добавление -p для "-p" предыдущее покажет журналы из наиболее недавний сбой (но только на несколько секунд, а не на неопределенный срок), и иногда kubectl --namespace=kube-system describe pod kube-controller-manager-coreos1 будет отображать полезную информацию либо в разделе «События» внизу, либо в блоке «Статус» вверху, если он был прекращен по причине

В случае очень серьезного сбоя, например, когда apiserver не запускается (и, таким образом, kubectl logs ничего не будет делать), затем отправьте ssh-соединение на узел и используйте смесь journalctl -u kubelet.service --no-pager --lines=150 и docker logs ${the_sha_or_name}, чтобы попытаться увидеть любой текст ошибки. . В последнем случае вам почти наверняка понадобится docker ps -a, чтобы найти sha или имя завершенного контейнера, но то же самое «только на несколько секунд» также применимо, поскольку мертвые контейнеры будут удалены через некоторое время.

В случае с бродягой можно подключиться к виртуальной машине по ssh одним из нескольких способов:

• vagrant ssh coreos1
• vagrant ssh-config > ssh-config && ssh -F ssh-config coreos1
• или если у него есть адрес "частной_сети", например 192.168.99.101 или другой, то обычно вы можете ssh -i ~/.vagrant.d/insecure_private_key [email protected], но один из первых двух почти всегда более удобен