слеш в конце строки работает как обычно

запустил bash. результат не изменился.

коллеги, добрый день) может странный вопрос, кто-то юзает в проде okd4 с реально большой нагрузкой?

извините за ответный странный вопрос, а реально большой это сколько?

Мммм ну у нас юзается с нагрузкой если в пользователях где-то 200к +. Ну и система не сайтики

В телеметрии есть окд кластеры на 140+ и 70+ нод. Не знаю правда насколько они загружены

Правильно понимаю что статические ip которые необходимо указать при бутстрапе кластера шифта через IPI - это временная тема? Потом перевешиваются DNS api/ingress на внешние балансиры?

Коллеги, привет.
А как-то можно гарантировать, чтобы при новом деплойменте ничего не наследовалось?
У нас сейчас авария была из-за того, что когда-то давно в деплойменте руками пропатчили ресурс, добавив nodeName и это правило по какой-то причине не конфликтует с указанным рядом affinity.podAntiAffinity.
Знаю и другое проявление этого наследования, которое тоже приводит к проблеме: все подцепленные руками Secret/ConfigMap ресурсы - тоже наследуются при последующих деплойментах.

У нас деплой идёт через oc apply -f resources.yaml, где в файле собрано описание всех ресурсов в структуре

kind: Template
objects:
  - kind: DeploymentConfig
  ...
...

Всем привет! Куда копать если с мастера пытаюсь сделать телнет ip сервиса порт сервиса и получаю no route to host?

Соответственно, поды тоже не могут достучаться до него

В голову kube-dns (СoreDNS) наверно, iptables.

Посмотреть соответствующие Endpoints, в них IP адреса подов, которые соответствуют сервису. Если там нет IP адресов, значит pod не отработали liveness и readiness пробы и т.д.

попробовать сходить telnet напрямую на pod на нужный порт, убедиться что там все работает

Запустил oc adm diagnostic, у меня там много проблем походу с сеткой.. хотя ставил по документации

а так - вот хороший наглядный гайд по поиску проблем https://learnk8s.io/troubleshooting-deployments.

Всем привет.
Коллеги, подскажите куда смотреть, что не так. Пытаюсь установить okd4, подготовил балансировщик, на бутстрап ноду установил coreos через сгенерированный openshift-install игнишен

Запускаю и вываливаюсь с очень невнятным сообщением:
[root@okd4 html]# openshift-install --dir=/opt/okd4 wait-for bootstrap-complete --log-level=debug                                                                                                  
DEBUG OpenShift Installer 4.7.0-0.okd-2021-05-22-050008                                                                    
DEBUG Built from commit ba1a5fc61dd3be134a24fa6d89ae24012a93385a                                                  
INFO Waiting up to 20m0s for the Kubernetes API at https://api.okd4.mydomain.ru:6443...              
INFO API v1.20.0-1073+df9c8387b2dc23-dirty up                                                                              
INFO Waiting up to 30m0s for bootstrapping to complete...                                                          
W0531 12:01:26.055387  111721 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

на бустрап-ноде вижу следующее:
[core@localhost ~]$ sudo crictl ps -a

STATE               NAME                             ATTEMPT            
Running             kube-controller-manager          8                  
Running             kube-apiserver-insecure-readyz   1                  
Running             kube-apiserver                   3                  
Exited              setup                            1                  
Running             cluster-policy-controller        3                  
Exited              kube-controller-manager          7                  
Running             cluster-version-operator         3                  
Running             kube-scheduler                   3                  
Exited              cluster-version-operator         2                  
Exited              cluster-policy-controller        2                  
Exited              kube-scheduler                   2                  
Running             cloud-credential-operator        1                  
Exited              kube-apiserver-insecure-readyz   0                  
Exited              kube-apiserver                   2                  
Exited              cloud-credential-operator        0                  
Running             machine-config-server            0                  
Exited              machine-config-controller        0                  
Running             etcd                             0

что ему не нравится?

Должны ли быть при этом уже запущены мастер-ноды?

да