то есть при правильном раскладе я стартую бутстрап-ноду, потом три мастера через какое-то время, и потом два воркера?

Есть ли какие-то таймауты между этими запусками?

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

ну как я понял:
INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443...
INFO API v1.21.0 up
INFO Waiting up to 30m0s for bootstrapping to complete...
INFO It is now safe to remove the bootstrap resources
The command succeeds when the Kubernetes API server signals that it has been bootstrapped on the control plane machines.

After bootstrap process is complete, remove the bootstrap machine from the load balancer.

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

только вот заветное INFO It is now safe to remove the bootstrap resources пока не получается получить

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

Вадим, а по поводу таймаутов подскажите? То есть насколько критично, что я запустил уже бустрап-ноду, а мастера допустим лишь минут через 15?

есть только два таймаута:
* этап бутстрапа должен завершиться за 30 минут
* после этого финальная установка должна завершится за 20 минут

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

На под ходит, на сервис не ходит.. дуристика какая-то

Понял, спасибо!

Endpoints что говорят?

Все равно не проходит инсталляция bootstrap:
INFO API v1.20.0-1073+df9c8387b2dc23-dirty up
INFO Waiting up to 30m0s for bootstrapping to complete...
W0531 15:42:03.085847  189286 reflector.go:424] k8s.io/client-go/tools/watch/informerwatcher.go:146: watch of *v1.ConfigMap ended with: very short watch: k8s.io/client-go/tools/watch/informerwatcher.go:146: Unexpected watch close - watch lasted less than a second and no items received
INFO Use the following commands to gather logs from the cluster
INFO openshift-install gather bootstrap --help
FATAL failed to wait for bootstrapping to complete: timed out waiting for the condition

Сделал openshift-install gather bootstrap --dir=/opt/okd4 --bootstrap 192.168.xx.20 --master 192.168.xx.10

В gather.log:
Gathering bootstrap systemd summary ...
Gathering bootstrap failed systemd unit status ...
Gathering bootstrap journals ...
Gathering bootstrap containers ...
Gathering rendered assets...
Gathering cluster resources ...
Waiting for logs ...

Gather remote logs
Collecting info from 192.168.xx.10
lost connection
ssh: connect to host 192.168.xx.10 port 22: Connection refused

почему refused -непонятно

понятно почему refused - ключ не установился или машина вообще не загрузилась

Так как гарантировать, что доставка k8s-ресурсов до кубера пройдёт только по тому, что в файле, без наследования чего-либо от текущих соответствующих k8s-ресурсов в кластере?

машина жива, на ключ грешу, но не могу понять почему, вроде все по ману

Имя генерировать новое может?

Чтоб на существующий ресурс не применялось

Ssh-agent проверь

У нас конфиги завязаны на имена, очень не хочется...
+ Это же значит rollingUpdate работать не будет.

Чет не приходит мне в голову как это гарантировать и защититься на 100% от шаловливых ручек. Дифф смотреть после можно, и если там что-нибудь неожиданное, то как минимум можно будет увидеть.