Kubeadm: apiserver не запускается, потому что livenessprobe слишком агрессивен

Похоже, что в настоящее время мы установили для InitialDelaySeconds и TimeoutSeconds значение 15 для модулей уровня управления, что также соответствует тому, что делает kube-up.sh . Я понимаю, что первоначальный запуск выполняется медленно, все изображения извлекаются одновременно, но после того, как все изображения были извлечены, сколько времени требуется вашему apiserver, чтобы ответить на проверки /healthz после запуска?

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

После запуска он может реагировать на проверки работоспособности за << 15 с - на самом деле это просто все дополнительные функции, которые apiserver выполняет между exec () и фактической готовностью к обслуживанию afaics.

о, и время извлечения докера не учитывается в афаиксах InitialDelaySeconds (хорошо). В других примерах с более крупными (общий ubuntu) изображениями по моему медленному сетевому каналу извлечение может занять много минут, но таймер initialDelaySeconds, похоже, не начинает отсчитывать, пока не завершится извлечение и не начнется запуск докера. (Я не смотрел соответствующий код - просто частый анекдотический опыт)

У меня та же проблема. На медленных машинах kubeadm сидит вечно. Использование v1.7.4

@anguslees и @koalalorenzo , можете ли вы подтвердить, что если вы вручную измените настройки зонда живучести (путем редактирования файлов манифеста в /etc/kubernetes/manifests/ ), это решит вашу проблему? Я также недавно видел случай в Slack, где у пользователя были те же симптомы, но, вероятно, он столкнулся с ограничениями памяти, потому что проблема исчезла, когда они перешли на тип хоста с большим объемом памяти.

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

Я также сталкиваюсь с этой проблемой при попытке использовать kubeadm в QEMU без аппаратной виртуализации (что является плохой идеей, потому что это очень медленно). Увеличение InitialDelaySeconds и TimeoutSeconds помогает; кластер тогда в конечном итоге поднимется.

@pipejakob Я могу подтвердить, что (на моем bananapi) запуск этого в другом терминале в нужной точке запуска kubeadm позволяет успешно выполнить все:

sed -i 's/initialDelaySeconds: [0-9]\+/initialDelaySeconds: 180/' /etc/kubernetes/manifests/kube-apiserver.yaml

(Я обычно также вручную docker kill старый контейнер apiserver с перезапуском цикла, я не уверен, что он автоматически очищается с помощью статических модулей)

@anguslees Отлично! Спасибо за подтверждение.

Я могу подтвердить, что у меня тоже была эта проблема, в моем случае на raspberry pi 3. Переход на 180 с исправил ее, однако я думаю, что также столкнулся с проблемой № 106, поскольку в моем случае она просто умерла с

1 сен 10:47:30 raspberrypi kubelet [6053]: W0901 10: 47: 30.020409 6053 kubelet.go: 1596] Удаление модуля зеркала "kube-apiserver-raspberrypi_kube-system (7c03df63-8efa-1
1e7-ae86-b827ebdd4b52) "потому что он устарел

Мне пришлось вручную HUP процесс kubelet, чтобы вернуть его к жизни.

Я также могу подтвердить, что у меня было это, и я хотел поблагодарить вас за то, что спасли меня. У меня есть Raspberry Pi 2B, и я застрял на этапе инициализации в течение последнего месяца. После запуска этого однострочника, когда он начал ждать плоскости управления, я продвинул его вперед.

Эта проблема все еще существует в kubeadm v1.8.0, и это еще хуже, потому что сама kubeadm теперь имеет тайм-аут в 1 минуту для большинства действий. Тайм-аут в 1 минуту, кажется, был выбран произвольно, и, к сожалению, а) не дает вам достаточно времени, чтобы вмешаться и отладить / решить проблему (например, sed hack выше), б) достаточно времени для запуска apiserver (~ 90-е годы для меня), даже когда initialDelaySeconds был продлен, и c) не может быть увеличен без взлома / восстановления kubeadm afaics.

Тайм-ауты нарушают в остальном правильную логику, особенно в сложных в конечном итоге согласованных системах - мы никогда не должны добавлять их «просто потому, что» :( Насколько я понимаю, kubeadm должен быть строительным блоком, от которого могут зависеть более крупные системы развертывания. Следовательно, я смело предлагаю удалить все тайм-ауты из самого kubeadm (различные фазы должны продолжать повторять попытки бесконечно) и полагаюсь на процесс более высокого уровня для добавления общего тайм-аута, если / когда это необходимо в этом контексте более высокого уровня. В простом / прямом случае использования это будет означать «повторять, пока пользователь не сдастся и не нажмет ^ c». Будет ли приемлем такой PR?

@anguslees Раньше у нас было поведение «ждать вечно»; но это было очень неоптимально для UX PoV, так что теперь у нас есть таймауты. Если хотите, мы можем увеличить некоторые из этих таймаутов.

Проблема в том, что использование kubeadm двоякое. У нас обоих есть пользователи, вводящие kubeadm в интерактивном режиме, которые хотят знать, происходит что-то или нет _и_ потребители более высокого уровня.

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

@anguslees Раньше у нас было поведение «ждать вечно»; но это было очень неоптимально для UX PoV, так что теперь у нас есть таймауты. Если хотите, мы можем увеличить некоторые из этих таймаутов.

Как насчет того, чтобы сделать их настраиваемыми? Имеет ли смысл иметь одну опцию, которой принадлежат все?

/ приоритет важно-скоро

Имеет ли смысл иметь одну опцию, которой принадлежат все?

Возможно, или какой-то "вес" умножить на все таймауты ... Иначе попадем в конфиг-ад с 20 разными типами таймаутов :)

Возникла та же проблема при использовании обновления kubeadm на кластере raspberry pi 2. Обновление не выполнено из-за слишком большого тайм-аута. Изменение настроек зонда живучести в манифестах не помогает. Любые идеи?

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

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

Для исходных тайм-аутов manifest livenessProbe это буквально однострочный патч. К сожалению, исправления только livenessProbe уже недостаточно, поскольку заблуждение «отклонение от нормального == ошибка» распространилось дальше по всей кодовой базе kubeadm. Изменение культурного сознания трудно, поэтому тем временем у меня есть раздвоенная версия kubeadm здесь , если кто -то хочет просто установить на Raspberry Pi. (Сборка с помощью make cross WHAT=cmd/kubeadm KUBE_BUILD_PLATFORMS=linux/arm )

@anguslees У вас есть скомпилированная версия 1.9.4 вашего пропатченного kubeadm? У меня проблемы с компиляцией вашей исправленной версии.

Я удивлен, что у kubeadm нет такого поведения за флагом. Может быть, пиар уместен?

/ назначить @liztio

Итак, мы исправили две проблемы в 1.11, которые могли повлиять на это.

1. Предварительно загрузите образ etcd перед запуском.
2. Исправьте проверку состояния гонки при запуске.
   ...

Если это происходит только на Rasberry Pi - gear, то нам нужен какой-то способ определения наименьшего общего знаменателя.

Какую самую низкую целевую платформу мы планируем поддерживать?

Я думаю, что Raspberry Pi 2 - это самая низкая платформа, на которой вы хотели бы запускать Kubernetes. Мои тесты с QEMU без аппаратной поддержки слишком экзотичны, чтобы их принимать во внимание.

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

imo rasberry pi2 слишком стар для поддержки - http://socialcompare.com/en/comparison/raspberrypi-models-comparison , вышел в 2015 году.

>= 3 кажется более разумным имо.

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

Исправление заключается только в увеличении тайм-аута initialDelaySeconds . Текущие значения тайм-аута в kubeadm неправильно используются для «обеспечения» быстрого взаимодействия с пользователем, а не для обнаружения ошибок.

Изменить: И чтобы быть ясным, это только запуск, который занимает много времени - мой контрольный кластер отлично работает на 3xRPi2, как только я увеличиваю тайм-аут apiserver intialDelaySeconds (и другие тайм-ауты только для установки, используемые в самом kubeadm). Я не понимаю, почему мы до сих пор об этом говорим: /

У меня есть кластер ARM64 на 1.9.3 и он успешно обновился до 1.9.7, но возникла проблема с тайм-аутом для обновления с 1.9.7 до 1.10.2.

Я даже пробовал редактировать и перекомпилировать kubeadm, увеличивая таймауты (например, эти последние коммиты https://github.com/anguslees/kubernetes/commit/kubeadm-gusfork) с теми же результатами.

$ sudo kubeadm upgrade apply  v1.10.2 --force
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade/version] You have chosen to change the cluster version to "v1.10.2"
[upgrade/versions] Cluster version: v1.9.7
[upgrade/versions] kubeadm version: v1.10.2-dirty
[upgrade/version] Found 1 potential version compatibility errors but skipping since the --force flag is set:

   - Specified version to upgrade to "v1.10.2" is higher than the kubeadm version "v1.10.2-dirty". Upgrade kubeadm first using the tool you used to install kubeadm
[upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler]
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.2"...
Static pod: kube-apiserver-kubemaster1 hash: ed7578d5bf9314188dca798386bcfb0e
Static pod: kube-controller-manager-kubemaster1 hash: e0c3f578f1c547dcf9996e1d3390c10c
Static pod: kube-scheduler-kubemaster1 hash: 52e767858f52ac4aba448b1a113884ee
[upgrade/etcd] Upgrading to TLS for etcd
Static pod: etcd-kubemaster1 hash: 413224efa82e36533ce93e30bd18e3a8
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/etcd.yaml"
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing etcd/server certificate and key.
[certificates] Using the existing etcd/peer certificate and key.
[certificates] Using the existing etcd/healthcheck-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests190581659/etcd.yaml"
[upgrade/staticpods] Not waiting for pod-hash change for component "etcd"
[upgrade/etcd] Waiting for etcd to become available
[util/etcd] Waiting 30s for initial delay
[util/etcd] Attempting to get etcd status 1/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 2/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 3/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 4/10
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148"
[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-apiserver.yaml"
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-scheduler.yaml"
[upgrade/staticpods] The etcd manifest will be restored if component "kube-apiserver" fails to upgrade
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing apiserver-etcd-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests190581659/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/apply] FATAL: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: [timed out waiting for the condition]

Если используется kubeadm и запущен apiserver, мы можем попробовать измерить точки при первом запуске. Возможно, мы изменим конфигурацию на более позднем этапе для тайм-аутов, адаптированных к измерениям при первой инициализации. Кроме того, при просмотре журналов трудно обнаружить, что apiserver вылетает из-за проверки здоровья, мы можем, по крайней мере, получить лучший вход в систему, чтобы знать о проблеме. Мне потребовалось некоторое время, чтобы понять, что проблема была в датчике живучести. Я должен упомянуть, что я новичок, и, по крайней мере, было бы полезно упомянуть где-нибудь в сообщении об ошибке для kubeadm.

RaspberryPi 3 по-прежнему демонстрирует эту проблему, даже с предварительно извлеченными изображениями. Серверу API требуется 2-3 минуты, чтобы добраться до места, где он может обслуживать страницу ...

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

@carlosedp во время обновления я отключаю kubelet во время загрузки apiserver. Это своего рода хакерство, но оно предотвращает запуск проверки работоспособности до тех пор, пока не запустится apiserver.

Но, честно говоря, kubeadm upgrade и ARM просто не так хорошо работают вместе, по моему опыту ...

@brendandburns Работал отлично до 1.9. Я развернул свой кластер 1.8 с ним без сбоев, а затем дважды обновился до 1.9. Не знаю, что могло быть изменено в 1.10, чтобы вызвать эти проблемы.

Я видел, что время ожидания изменилось с 1,11 до 5 минут (https://github.com/kubernetes/kubernetes/pull/64988/files#diff-2056df5f0c3a4828b3f9a2510a7533c7L45). А с 1.11 пробовали?

Попробую этот хакер после того, как вернусь из отпуска. Спасибо за чаевые!

@brendandburns @carlosedp
да, попробуйте 1.11, чтобы убедиться, что увеличение тайм-аута является для вас решением.

/ cc @ kubernetes / sig-кластер-жизненный цикл-ошибки

Привет! Я тоже сталкиваюсь с этой проблемой.
Интересно, что мне удалось создать мастер кластера с нуля на моем Raspberry 3, но постоянно не получается на моем 3+.
В любом случае, версия, которую я сейчас использую (согласно пошаговой документации на https://blog.hypriot.com/post/setup-kubernetes-raspberry-pi-cluster/), является
kubeadm version: &version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:14:41Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/arm"}

Как и в случае с другими, контейнер apiserver в конце концов встанет, но не раньше, чем выйдет kubeadm, оставив меня в подвешенном состоянии, так как я слишком неопытен, чтобы брать его вручную.

Быстрое обновление: запущено
watch -n 1.0 "sed -i 's/initialDelaySeconds: [0-9]\+/initialDelaySeconds: 180/' /etc/kubernetes/manifests/kube-apiserver.yaml"
в отдельном терминале позволил моему кластеру встать.

@DJGummikuh
спасибо за тестирование 1.11.

Как и в случае с другими, контейнер apiserver в конце концов встанет, но не раньше, чем выйдет kubeadm, оставив меня в подвешенном состоянии, так как я слишком неопытен, чтобы брать его вручную.

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

Трудно сказать, примерно 1 минуту, но я не знаю, как это правильно измерить.

Кроме того, теперь, когда мой мастер работает, мне не удается добавить к нему узел, что кажется еще одной проблемой тайм-аута.
`[предполетная] проверка перед полетом
[ПРЕДУПРЕЖДЕНИЕ RequiredIPVSKernelModulesAvailable]: прокси-сервер IPVS не будет использоваться, поскольку не загружены следующие необходимые модули ядра: [ip_vs_rr ip_vs_wrr ip_vs_sh ip_vs] или нет встроенной поддержки ipvs ядра: карта [ip_vs_rr :__wr_vs}: {} ip_vs nf_conntrack_ipv4: {} ip_vs: {}]
Вы можете решить эту проблему следующими способами:

1. Запустите 'modprobe -', чтобы загрузить недостающие модули ядра;
   
   
   
   1. Обеспечьте отсутствующую встроенную поддержку ipvs ядра
   
   

I0708 19: 02: 20.256325 8667 kernel_validator.go: 81] Проверка версии ядра
I0708 19: 02: 20.256846 8667 kernel_validator.go: 96] Проверка конфигурации ядра
[ПРЕДУПРЕЖДЕНИЕ SystemVerification]: версия докера старше последней проверенной версии. Версия докера: 18.03.1-в. Максимально допустимая версия: 17.03
[обнаружение] Попытка подключиться к серверу API "192.168.2.2:6443"
[обнаружение] Создан клиент обнаружения информации о кластере, запрашивающий информацию с " https://192.168.2.2 : 6443"
[обнаружение] Повторный запрос информации с https://192.168.2.2 : 6443 для проверки TLS по закрепленному открытому ключу
[обнаружение] Информационная подпись и содержимое кластера действительны, сертификат TLS проверяется на закрепленные корни, будет использоваться сервер API "192.168.2.2:6443"
[обнаружение] Успешно установленное соединение с сервером API "192.168.2.2:6443"
[kubelet] Загрузка конфигурации для kubelet из ConfigMap "kubelet-config-1.11" в пространстве имен kube-system
[kubelet] Запись конфигурации kubelet в файл "/var/lib/kubelet/config.yaml"
[kubelet] Запись файла среды kubelet с флагами в файл "/var/lib/kubelet/kubeadm-flags.env"
[предполетная] Активация сервиса kubelet
[tlsbootstrap] Ожидание, пока кубелет выполнит загрузку TLS ...
[kubelet-check] Кажется, кубелет не работает или не исправен.
[kubelet-check] Кажется, кубелет не работает или не исправен.
[kubelet-check] Кажется, кубелет не работает или не исправен.
[kubelet-check] Кажется, кубелет не работает или не исправен.
[kubelet-check] Кажется, кубелет не работает или не исправен.
К сожалению, произошла ошибка:
истекло время ожидания условия

Эта ошибка, вероятно, вызвана:
- Кубелет не работает
- Кубелет неисправен из-за неправильной конфигурации узла (обязательные контрольные группы отключены)

Если вы используете систему с питанием от systemd, вы можете попытаться устранить ошибку с помощью следующих команд:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'
истекло время ожидания условия

За это время на моем узле не появляется ни одного контейнера докеров.

[ВНИМАНИЕ! Требуется IPVSKernelModulesAvailable]:

оффтоп, мы вот об этом и говорим:
https://github.com/kubernetes/kubeadm/issues/975

Кроме того, теперь, когда мой мастер работает, мне не удается добавить к нему узел, что кажется еще одной проблемой тайм-аута.
[kubelet-check] HTTP-вызов, равный 'curl -sSL http: // localhost : 10248 / healthz', завершился ошибкой: Get http: // localhost : 10248 / healthz: dial tcp [:: 1]: 10248: connect : В соединении отказано.

кубелет не запускался. лучше посмотрите логи кубелет.

- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'

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

Я думаю, что это используемые значения, поэтому, если вы сами создаете kubeadm, попробуйте поиграть с:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96
но имейте в виду, что это увеличит таймауты для всех компонентов плоскости управления.

Изменить: я, по-видимому, слишком глуп, чтобы правильно форматировать комментарии в Github :-(

Here are the log outputs of both systemctl status kubelet and journalctl -xeu kubelet. "No cloud provider specified is the only thing that springs to eye.

`root@djg-clusterpi3:/home/djgummikuh# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since Sun 2018-07-08 19:55:15 CEST; 2min 12s ago
     Docs: http://kubernetes.io/docs/
 Main PID: 9233 (kubelet)
   Memory: 14.4M
      CPU: 17.064s
   CGroup: /system.slice/kubelet.service
           └─9233 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-driver=cgroupfs --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --network-pl

Jul 08 19:55:15 djg-clusterpi3 systemd[1]: Started kubelet: The Kubernetes Node Agent.
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.665304    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.675950    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.676273    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.963686    9233 server.go:408] Version: v1.11.0
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964029    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964378    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.965040    9233 plugins.go:97] No cloud provider specified.






Jul 08 19:55:15 djg-clusterpi3 systemd[1]: Started kubelet: The Kubernetes Node Agent.
-- Subject: Unit kubelet.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit kubelet.service has finished starting up.
-- 
-- The start-up result is done.
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.665304    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.675950    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.676273    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.963686    9233 server.go:408] Version: v1.11.0
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964029    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964378    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.965040    9233 plugins.go:97] No cloud provider specified.`

Пожалуйста, помните, что в этих журналах ошибок нет.

Да, но я считаю, что это часть проблемы. Я нигде не могу найти ни одной убедительной строки [ERROR]. Вот что меня так сильно расстраивает :-)

В любом случае, спасибо за форматирование моего беспорядка :-D

Итак, что было бы хорошим следующим шагом?

Итак, что было бы хорошим следующим шагом?

как упоминалось ранее:

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

Я думаю, что это используемые значения, поэтому, если вы сами создаете kubeadm, попробуйте поиграть с:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96
но имейте в виду, что это увеличит таймауты для всех компонентов плоскости управления.

oof Сам kubeadm не собираю, тащу через apt с apt.kubernetes.io. У меня нет ничего, что отдаленно напоминало бы конвейер сборки для go на любой из моих машин (никогда еще не возился с этим). Я надеялся, что при присоединении к кластеру можно будет изменить аналогичный файл, как это было при его создании, однако, похоже, эти значения жестко запрограммированы в utils.go: - |

вы можете попробовать это решение, но оно непростое:
https://github.com/kubernetes/kubeadm/issues/413#issuecomment -402916173

проблема в том, что это требует изменения конфигурации, и я не думаю, что это может быть включено в выпуск 1.11.X (но мы можем попробовать). это также необходимо обсудить в первую очередь.

Это то, что я уже делал в комментарии, где я сказал вам, что мастер работает (это то, что делала моя команда watch -n 1.0). Что происходит сейчас, так это то, что kubeadm join не работает, и, насколько я могу судить, kubeadm join не помещает файлы yaml, которые я могу где-либо исправить: - /

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

это используемые значения, поэтому, если вы сами создаете kubeadm, попробуйте поиграть с:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96

Итак, я отмечаю, что тайм-аут InitialDelaySeconds здесь составляет _ еще_ 15 секунд через год, и я не понимаю, почему он не был увеличен до чего-то, что действительно представляет реальность. Этот отчет об ошибке вообще служит какой-либо цели? Я изначально не предлагал PR просто изменить это число сам, потому что я чувствовал, что кто-то уже из внутреннего круга kubeadm может сделать это и объединиться за несколько минут, но я рад сделать это, если "отсутствие PR" единственная причина, по которой мы не продвинулись вперед.

Я чувствую, что все пытаются придумать причины, чтобы объявить исходный отчет об ошибке недействительным (возможно, нам не следует поддерживать rPi2, возможно, мы должны сделать начальную задержку настраиваемой, возможно, мы должны предварительно вытащить изображения или какое-либо другое несвязанное изменение, возможно, быстрый непрозрачный сбой тайм-аута - лучший UX, чем более медленный успех), вместо того, чтобы просто увеличивать время ожидания initialDelay, чтобы отразить фактическое значение initialDelay, которое явно демонстрируют наши двоичные файлы, а затем переходить к чему-то еще, что действительно заслуживает обсуждения.

Итак, я отмечаю, что тайм-аут InitialDelaySeconds здесь все еще составляет 15 секунд через год, и я не понимаю, почему он не был увеличен до чего-то, что действительно представляет реальность. Этот отчет об ошибке вообще служит какой-либо цели? Я изначально не предлагал PR просто изменить это число сам, потому что я чувствовал, что кто-то уже из внутреннего круга kubeadm может сделать это и объединиться за несколько минут, но я рад сделать это, если "отсутствие PR" единственная причина, по которой мы не продвинулись вперед.

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

Я чувствую, что все пытаются придумать причины, чтобы объявить исходный отчет об ошибке недействительным (возможно, нам не следует поддерживать rPi2, возможно, мы должны сделать начальную задержку настраиваемой, возможно, мы должны предварительно вытащить изображения или какое-либо другое несвязанное изменение, возможно, быстрый непрозрачный сбой тайм-аута - лучший UX, чем более медленный успех), вместо того, чтобы просто увеличивать время ожидания initialDelay, чтобы отразить фактическое значение initialDelay, которое явно демонстрируют наши двоичные файлы, а затем переходить к чему-то еще, что действительно заслуживает обсуждения.

да, варианты уже обсуждались в этой ветке. это вопрос выбора правильного варианта и реализации.

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

Причина в том, что в большинстве случаев использования, которые я могу придумать, на самом деле не волнует, выполняется ли конкретный шаг за X секунд или нет, поскольку все, о чем заботятся в распределенной системе, - это конечная согласованность (спулинг другого узла на всякий случай дешевле чем возиться с настройками).

Однако в качестве промежуточного решения было бы достаточно фактически прочитать настройки тайм-аута для kubeadm join из файла конфигурации, как это делает материал kubeadm init, чтобы наш хак с заменой тайм-аута в полете сработал. Это взлом, не думайте иначе, но ужасный взлом все же лучше, чем полное отсутствие обходного пути.

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

@anguslees @DJGummikuh мы говорили об этом на недавней встрече SIG.

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

заметки:

• некоторые из наших людей имеют большой опыт и говорят, что это пахнет гонкой, которая тормозит запуск apiserver. это не должно занять так много времени. это могло быть дело ARM против GOLANG.
• Я спросил у SIG API Machinery, но не получил ответа на предложенные значения зонда живучести и подозревают ли они здесь другой тип проблемы.
• мы согласились с тем, что раскрытие параметра конфигурации, переменной среды или параметра командной строки - плохая идея для kubeadm . Причина в том, что мы не хотим раскрывать пользователям параметры, которые могут иметь совершенно произвольное значение.
• никто из команды никогда не видел такой проблемы на медленных машинах (например, медленных виртуальных машинах), что означает, что это могло быть связано с RPi, и весь аргумент о том, что это происходит из-за «медленного» оборудования, неверен.
• взгляните на это: https://github.com/kubernetes/kubernetes/issues/64357 пользователь вообще не сообщает о проблеме проверки живучести. любая идея, почему это?
• Кто-нибудь видел проблему на чем-то вроде https://www.scaleway.com/ , согласно теории в этой ветке, это тоже должно произойти там?
• В заключение мы обсудили, что жесткое кодирование больших значений тайм-аута / задержки не будет иметь большого значения для kubeadm, поэтому, если кто-то хочет отправить PR для этого, продолжайте. ( @anguslees )

взгляните на это: kubernetes / kubernetes # 64357 пользователь вообще не сообщает о проблеме проверки работоспособности. любая идея, почему это?

Нет, сейчас это даже не кажется воспроизводимым на моем оборудовании. Поскольку токен для присоединения узлов истек, я подумал «какого черта» и kubeadm сбросил мой мастер кластера и попытался повторно инициализировать его (с запущенным обходным путем) - теперь даже с этим обходным путем я больше не могу подтянуть мастер на моем Raspberry Pi 3+. Я даже увеличил настроенный таймаут со 180 до 300 секунд без разницы. Так что мне нравится идея, что это состояние гонки.
Тем не менее, я приветствую ваше предложение увеличить время ожидания запроса на вытягивание. Не сильно повредит и даст пи (который ЯВЛЯЕТСЯ медленным оборудованием, я думаю, мы все можем согласиться с этим :-)) немного больше передышки.

связанная проблема с ARM64 в apiserver:
https://github.com/kubernetes/kubernetes/issues/64649

Провел еще несколько исследований с моим (все еще не работает :-() Pi Cluster на выходных.

Я переустановил один из моих узлов, так как подозревал, что обновление с Pi 2 до Pi 3+ без переустановки ОС может вызвать некоторые проблемы. Это не тот случай, проблема та же самая с новенькой ОС.
Кроме того, я постарался скомпилировать кубернеты с увеличенными таймаутами и протестировал их. Да и никакого результата это не дало.
Мне удалось запустить мастер (с моим обходным путем для исправления файлов конфигурации), но присоединение к кластеру со вторым узлом просто никогда не удается.

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

Кто-нибудь готов принять вызов? ^^

это действительно проблема вне кубеадм ...

люди, работающие с api, не просмотрели мой запрос комментариев по проблеме, поэтому, если билет уже не зарегистрирован для этого, кто-то должен зарегистрировать его в репозитории kubernetes/kubernetes и отметить /sig api-machinery .

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

для начала можно включить --v 4 для kubelet в файле drop-in systemd, который сообщит регистратору GLOG включить высокую детализацию.
то же самое можно сделать и для компонентов плоскости управления из конфигурации kubeadm:
https://kubernetes.io/docs/setup/independent/control-plane-flags/

Это решило проблему в моем кластере Raspberry Pi 3: https://github.com/kubernetes/kubernetes/pull/66264

@joejulian nice Мне удалось это исправить, и теперь мой кластер также загорается. НАКОНЕЦ, после нескольких недель агонии! Спасибо :-)

@joejulian, спасибо за расследование!
потенциальное исправление можно найти на https://github.com/kubernetes/kubernetes/pull/66264

закрывается до дальнейшего уведомления.

/Закрыть

есть ли способ передать такие настройки в файле инициализации kubeadm? может в apiServerExtraArgs ? Больно наблюдать за файлами, чтобы исправить их, что довольно сложно автоматизировать.

Нет. Возможно, стоит добавить эту функцию.

В более поздних обновлениях было добавлено еще больше вещей для проверки, и увеличенного тайм-аута, предоставленного моим PR, уже было недостаточно. Я отказался от управления тайм-аутом. Решением для меня было использование сертификатов ecdsa.

Кроме того, службы контроллера, включая etcd, теперь занимают больше оперативной памяти, чем у Raspberry Pi, поэтому вместо того, чтобы удвоить количество узлов для размещения плоскости управления, я обновился до Rock64s.

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

Я только что пытался выполнить установку на Raspberry Pi 3+ и могу подтвердить, что установка действительно не удалась. Приведенный выше трюк с «часами» на kube-apiserver.yaml, похоже, работает стабильно ... но только если я изменю initialDelaySeconds на 360. Предлагаемое значение 180 кажется незначительным на моих машинах.

Когда все становится слишком просто, kubeadm жалуется, что версия Docker (18.09) не поддерживается. Быстрый возврат к 18.06 устранил проблему.

в kubeadm 1.13 мы добавляем флаг конфигурации в ClusterConfig-> ApiServer, который может контролировать тайм-аут сервера api.
https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1
timeoutForControlPlane

флаг конфигурации в разделе ClusterConfig-> ApiServer, который может контролировать тайм-аут сервера api.

При поиске в базе кода TimeoutForControlPlane я думаю, что по умолчанию это 4 минуты, и используется только для задержки, используемой самим kubeadm, чтобы дождаться, пока apiserver станет здоровым. В частности, он _не_ изменяет apiserver livenessprobe, используемый самим kubelet. Это верно?

Не думаю, что я встречал контраргумент где-либо в дискуссии по этому поводу. Есть ли причина, по которой мы _ не_ просто увеличиваем livenessProbe initialDelaySeconds и переходим к другой проблеме?

Кроме того: насколько я могу судить по быстрому чтению, TimeoutForControlPlane также не учитывает другие причины, не связанные с отказом, для увеличения задержки запуска apiserver, такие как перегрузка при извлечении нескольких изображений или дополнительный тайм-аут + цикл повтора. итераций, пока все сходится во время начальной установки (тайм-аут + повторные попытки - это шаблон проектирования k8s ... и это иногда случается в загруженной системе, что вполне ожидаемо и нормально). Лично мне кажется, что 4 минуты - это слишком долго для нетерпеливых интерактивных пользователей, ожидающих быстрого сбоя, и слишком мало для процесса установки в загруженной / медленной / автоматизированной системе, которая готова дольше ждать ожидаемого успеха. Как это было достигнуто, можем ли мы по умолчанию использовать 5 минут? Можем ли мы продолжать попытки до SIGINT? Почему мы устанавливаем искусственный дедлайн для настенных часов внутри компании, а не унаследовали его от среды звонков?

Afaics TimeoutForControlPlane просто выставляет произвольный фатальный внутренний крайний срок в качестве параметра, где единственный предполагаемый UX - просто увеличить параметр до тех пор, пока крайний срок никогда не будет достигнут. В качестве альтернативы, мы могли бы просто _не_ навязывать этот произвольный фатальный внутренний крайний срок ...

Это отличный момент, и я полностью согласен.

В частности, он не изменяет apiserver livenessprobe, используемый самим kubelet. Это верно?

да, пока нет планов доработать датчики живучести от kubeadm.

эта проблема rpi была квалифицирована на собрании sig-cluster-lifecyle как «что-то, чего не должно происходить», «похоже на состояние гонки в kubelet», «почему это происходит только на rpi, а не на других более медленных устройствах». Признаюсь, я сам не тестировал медленные устройства.

т.е. было соглашение, что увеличение этого значения:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L97
не является хорошим исправлением и кажется обходным путем для другой ошибки.

Как это было достигнуто, можем ли мы по умолчанию использовать 5 минут?

тайм-аут составлял 30 минут до 4 минут, потому что он учитывал вытягивание изображений до 1.11.
Если у вас есть мнение о 4 и 5 минутах, хорошо очерченный PR с сильными сторонами по этому вопросу может помочь в 1.14.

эта проблема rpi была квалифицирована на собрании sig-cluster-lifecyle как «что-то, чего не должно происходить», «похоже на состояние гонки в kubelet», «почему это происходит только на rpi, а не на других более медленных устройствах».

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

Если подойти к этому с другой стороны, если мы знаем, что у нас есть проблема в другом месте в kubernetes с обходным путем, который можно использовать в kubeadm - это роль kubeadm в том, чтобы «держать линию» в отношении чистоты и производить заведомо нарушенный результат? Похоже, что это противоречит цели создания инструмента, который, как мы ожидаем, люди будут использовать для реальных развертываний. До сих пор мне не удавалось использовать kubeadm в своем кластере без исправления для увеличения таймаутов (несмотря на то, что я сообщал об этом с исправлениями более года назад), что меня огорчает.

(Приношу извинения за то, что позволил части моего разочарования по поводу этой проблемы просочиться в мой тон)

если у вас есть мнение по поводу 4 минут против 5

Вздох. Я пытался обосновать _no_ тайм-аут в kubeadm, но мне еще предстоит найти способ убедительно сформулировать это предложение (см., Например, эту и другие неудачные попытки в этом выпуске) :(

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

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

Если подойти к этому с другой стороны, если мы знаем, что у нас есть проблема в другом месте в kubernetes с обходным путем, который можно использовать в kubeadm - это роль kubeadm в том, чтобы «держать линию» в отношении чистоты и производить заведомо нарушенный результат? Похоже, что это противоречит цели создания инструмента, который, как мы ожидаем, люди будут использовать для реальных развертываний.

столкновение с конечным пользователем - это цель kubeadm, это правда.
но опять же, это всего лишь отчет для rpis, и фактическая ошибка должна быть передана на sig-api-machinery (сервер api) и sig-node (kubelet) и, возможно, воспроизведена вне kubeadm.

До сих пор мне не удавалось использовать kubeadm в своем кластере без исправления для увеличения таймаутов (несмотря на то, что я сообщал об этом с исправлениями более года назад), что меня огорчает.

вам не нужно исправлять kubeadm, вместо этого вы можете исправлять файлы манифеста.
kubeadm 1.13 переводит фазы инициализации в команды верхнего уровня - например, kubeadm init phase [phase-name]
фазы присутствуют в основном потому, что пользователи хотят настраивать управление тем, как создается узел плоскости управления.

если вы сделаете kubeadm init --help он покажет вам, в каком порядке выполняются фазы.

чтобы вы могли разбить команду kubeadm init на соответствующие фазы, вы используете настраиваемые манифесты для компонентов плоскости управления и пропускаете фазу control-plane . есть еще --skip-phases сейчас.

вы уже можете сделать это в 1.11 и 1.12, но это не так просто.

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

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

С другой стороны, я как специалист по эксплуатации боюсь каскадных отказов в ситуациях перегрузки, особенно самого apiserver. Afaics, тайм-аут livenessprobe должен срабатывать только тогда, когда что-то явно провалилось , а не только когда он отклоняется от чьего-то представления о «нормальном». Afaics, мы _ должны_ иметь очень удобную настройку livenessprobe, даже на нашем самом быстром оборудовании. Мой маленький rpi просто более легко демонстрирует этот сбой перегрузки, но он также применим к более крупным серверам в более крупных сценариях перегрузки / DoS. Нет никаких преимуществ в использовании небольшого значения initialDelaySeconds . По умолчанию livenessprobe kubeadm излишне агрессивен на всех платформах.

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

добавление опции конфигурации kubeadm на данный момент маловероятно.

Я пытаюсь объяснить, что это уже можно сделать с помощью 3 команд в 1.13:

sudo kubeadm reset -f
sudo kubeadm init phase control-plane all --config=testkubeadm.yaml
sudo sed -i 's/initialDelaySeconds: 15/initialDelaySeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml
sudo kubeadm init --skip-phases=control-plane --ignore-preflight-errors=all --config=testkubeadm.yaml

Мне не нужна опция, я пытаюсь сказать, что текущее фиксированное значение (15) следует изменить на другое фиксированное значение (360 было предложено выше).

.. Но я не хочу затягивать это дальше. Понятно, что было принято решение придерживаться текущего значения, поэтому я откажусь от него побежденным. Спасибо тебе за твое терпение :)

@ neolit123, эта комбинация выглядит великолепно - намного проще, чем то, что я задокументировал - нужно дождаться набора уровня управления, а затем быстро запустить sed в другом терминале. https://github.com/alexellis/k8s-on-raspbian/blob/master/GUIDE.md

Я протестирую инструкции и посмотрю, чтобы обновить руководство.

@ neolit123 это то, что я получил, используя конфигурацию выше на RPi3 B +

[certs] apiserver serving cert is signed for DNS names [rnode-1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.0.110 192.168.0.26 192.168.0.26]
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xaa7204]

goroutine 1 [running]:
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.validateKubeConfig(0xfa93f2, 0xf, 0xfb3d32, 0x17, 0x4032210, 0x68f, 0x7bc)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:236 +0x120
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.createKubeConfigFileIfNotExists(0xfa93f2, 0xf, 0xfb3d32, 0x17, 0x4032210, 0x0, 0xf7978)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:257 +0x90
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.createKubeConfigFiles(0xfa93f2, 0xf, 0x3ec65a0, 0x3f71c60, 0x1, 0x1, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:120 +0xf4
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.CreateKubeConfigFile(0xfb3d32, 0x17, 0xfa93f2, 0xf, 0x3ec65a0, 0x1f7a701, 0xb9772c)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:93 +0xe8
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases.runKubeConfigFile.func1(0xf66a80, 0x4208280, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/kubeconfig.go:155 +0x168
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).Run.func1(0x3cc2d80, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:235 +0x160
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).visitAll(0x3ec9270, 0x3f71d68, 0x4208280, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:416 +0x5c
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).Run(0x3ec9270, 0x24, 0x416bdb4)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:208 +0xc8
k8s.io/kubernetes/cmd/kubeadm/app/cmd.NewCmdInit.func1(0x3e97b80, 0x3e900e0, 0x0, 0x3)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/init.go:141 +0xfc
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).execute(0x3e97b80, 0x3e3ff80, 0x3, 0x4, 0x3e97b80, 0x3e3ff80)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:760 +0x20c
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x3e96140, 0x3e97b80, 0x3e96780, 0x3d82100)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:846 +0x210
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).Execute(0x3e96140, 0x3c8c0c8, 0x116d958)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:794 +0x1c
k8s.io/kubernetes/cmd/kubeadm/app.Run(0x3c9c030, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/kubeadm.go:48 +0x1b0
main.main()
    _output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/kubeadm.go:29 +0x20

kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:36:44Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/arm"}

В kubeadm-config.yaml - 192.168.0.26 - это LB, указывающий на 192.168.0.110

apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: stable
apiServer:
  certSANs:
  - "192.168.0.26"
controlPlaneEndpoint: "192.168.0.26:6443"

Я получаю то же самое даже без внешнего IP-адреса config / lb.

Алекс

Некоторое время я подталкивал людей к использованию kubeadm, даже школы, желающие запускать его на своих кластерах Pi. Хотя я понимаю, что не хочу усложнять кодовую базу, я думаю, что для вашей пользовательской базы, вероятно, будет хорошо поддерживать работу на этих маленьких устройствах. это позволяет молодым людям «надрать» шины Kubernetes на дешевом оборудовании, которое иначе не могло бы быть. Приведенный выше обходной путь, хотя и действителен, для этого варианта использования намного сложнее.

А как насчет компромисса? Вместо того, чтобы делать его настраиваемым, добавьте простую эвристику, которая говорит, что если не x86_64, установить тайм-аут по умолчанию выше?

[kubeconfig] Написание файла kubeconfig "admin.conf"
[kubeconfig] Создание файла kubeconfig "kubelet.conf"
паника: ошибка времени выполнения: недопустимый адрес памяти или разыменование нулевого указателя
[сигнал SIGSEGV: код нарушения сегментации = 0x1 адрес = 0x8 pc = 0xaa7204]

странно, admin.conf генерируется машиной и должен содержать допустимый тип Config с полем current-context указывающим на контекст.

паника исходит от этой строки:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go#L236

Я вижу ту же ошибку, что и: point_up: выше, со следующим:

modify_kube_apiserver_config(){
  sed -i 's/failureThreshold: [0-9]/failureThreshold: 15/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 120/g' /etc/kubernetes/manifests/kube-apiserver.yaml
}
kubeadm init phase control-plane all --config=$${KUBEADM_CONFIG_FILE} && \
modify_kube_apiserver_config && \
kubeadm init \
--skip-phases=control-plane \
--ignore-preflight-errors=all \
--config=$${KUBEADM_CONFIG_FILE} \
--v 4

Следующий сценарий действительно решает эту проблему при использовании kubeadm версий 1.12, 1.13 ( большую часть времени).

modify_kube_apiserver_config(){
  while [[ ! -e /etc/kubernetes/manifests/kube-apiserver.yaml ]]; do
    sleep 0.5s;
  done && \
  sed -i 's/failureThreshold: [0-9]/failureThreshold: 18/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 240/g' /etc/kubernetes/manifests/kube-apiserver.yaml
}

# ref https://github.com/kubernetes/kubeadm/issues/413 (initialDelaySeconds is too eager)
if [[ ${var.arch} == "arm" ]]; then modify_kube_apiserver_config & fi

kubeadm init \
  --config=$${KUBEADM_CONFIG_FILE} \
  --v ${var.kubeadm_verbosity}

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

Поэтому я перенес скрипт на python (который по умолчанию установлен в Raspbian, поэтому нет необходимости в дополнительных зависимостях), на случай, если кому-то интересно:

import os
import time
import threading

filepath = '/etc/kubernetes/manifests/kube-apiserver.yaml'

def replace_defaults():
    print('Thread start looking for the file')
    while not os.path.isfile(filepath):
        time.sleep(1) #wait one second
    print('\033[94m -----------> FILE FOUND: replacing defaults \033[0m')
    os.system("""sed -i 's/failureThreshold: [0-9]/failureThreshold: 18/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")
    os.system("""sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")
    os.system("""sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 240/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")

t = threading.Thread(target=replace_defaults)
t.start()
os.system("kubeadm init")

Чтобы запустить его: sudo python however_you_name_the_file.py
Спасибо, что указали мне решение, @stephenmoloney и @ neolit123 !

Привет! этот вопрос очень помог

Я нашел интересный способ решить эту проблему с помощью kustomize

mkdir /tmp/kustom

cat > /tmp/kustom/kustomization.yaml <<EOF
patchesJson6902:
- target:
    version: v1
    kind: Pod
    name: kube-apiserver
    namespace: kube-system
  path: patch.yaml
EOF

cat > /tmp/kustom/patch.yaml <<EOF
- op: replace
  path: /spec/containers/0/livenessProbe/initialDelaySeconds
  value: 30
- op: replace
  path: /spec/containers/0/livenessProbe/timeoutSeconds
  value: 30
EOF

sudo kubeadm init --config config.yaml -k /tmp/kustom