ок, попробую накинуть оперативы

спасибо 🙏

Коллеги привет! У кого то был опыт установки кластера OKD через AWS какой нибудь?

это типа когда кластер сам создается без предварительного создание машин

@vrutkovs
Добрый день!

На версии okd 4.7.0-0.okd-2021-06-19-191547 пропала возможность использования driver контейнеров. Так как selinux блокирует insmod модулей из priveleged контейнера.

insmod drbd.ko
insmod: ERROR: could not insert module drbd.ko: Permission denied

Изменение контекста тоже не помогает:

chcon -t modules_object_t drbd.ko
ls -Z drbd.ko
unconfined_u:object_r:modules_object_t:s0 drbd.ko

С самого хоста работает.
На версии okd 4.7.0-0.okd-2021-04-24-103438 тоже работает.

Это баг или фича? Заводить тикет?

Лог:

worker-1 audit[109560]: AVC avc:  denied  { module_load } for  pid=109560 comm="insmod" path="/tmp/drbd.ko" dev="tmpfs" ino=6248 scontext=system_u:system_r:spc_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=system permissive=0
Jun 23 15:01:11 worker-1 kernel: audit: type=1400 audit(1624460471.557:725): avc:  denied  { module_load } for  pid=109560 comm="insmod" path="/tmp/drbd.ko" dev="tmpfs" ino=6248 scontext=system_u:system_r:spc_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=system permissive=0
Jun 23 15:01:11 worker-1 audit[109560]: SYSCALL arch=c000003e syscall=313 success=no exit=-13 a0=3 a1=5652517dca2a a2=0 a3=3 items=0 ppid=108768 pid=109560 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="insmod" exe="/usr/bin/kmod" subj=system_u:system_r:spc_t:s0 key=(null)
Jun 23 15:01:11 worker-1 kernel: audit: type=1300 audit(1624460471.557:725): arch=c000003e syscall=313 success=no exit=-13 a0=3 a1=5652517dca2a a2=0 a3=3 items=0 ppid=108768 pid=109560 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="insmod" exe="/usr/bin/kmod" subj=system_u:system_r:spc_t:s0 key=(null)
Jun 23 15:01:11 worker-1 kernel: audit: type=1327 audit(1624460471.557:725): proctitle=696E736D6F6400647262642E6B6F
Jun 23 15:01:11 worker-1 audit: PROCTITLE proctitle=696E736D6F6400647262642E6B6F

стоит внести баг - и сразу в федору, на selinux-policies

ок, спасибо

у меня так же было когда скорости диска на мастер нодах не хватало. Посмотри в Monitoring dashboard Total Leader Elections Per Day. должна быть на нуле. если скорости диска при записи данных не хватает etcd запускает перевыборы. в след за этим перезапускаются api поды так как не успевают в таймаут liveness зонда и каскадом перезапускаются все остальные. поставь на мастера отдельные ssd диски и проблема уйдет

когда ты запускаешь билд, нагружаешь диск. к моменту когда билд собран auth поды перезапускаются.

это прямо настолько неожиданно и далеко от хостов, что готов поверить)

>Total Leader Elections Per Day. должна быть на нуле

в идеале - да, каждый etcd leader election - это капец всем коннектам. Раз в день еще терпимо, но если раз в несколько часов - это совсем плохо

В моем случае я делал маленький 3 узловой кластер без отдельных worker нод. Билд делался на одном из мастеров. Во втором случае я ставил ocp4 в виртуалках kvm на спаренном в raid0 хосту виртуализации. и файлы дисков виртуалок и мастеров и рабочих узлов складывал тупо в этот raid0 диск. Думал что скорости хватит ан нет

ну тогда не мой случай

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

по опыту опенстек + шпиндельные диски = проблемы с etcd

даже на пустых кластерах

посмотри ивенты в openshift-authentication

а есть ли у каких либо подов растущий счетчик количества рестартов?