Ошибку точную покажете ?

таки покажите ошибку тогда

я полагаю, не хватает прав на выполнение неких действий, тогда вам нужно выполнить RBAC инструкции гитлаба (если есть, наверное, должны быть)

ip-172-31-27-112 NotReady master 20m v1.15.0

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

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

"message": "pods is forbidden: User \"system:anonymous\" cannot list resource \"pods\" in API group \"\" in the namespace \"default\"",

ну вот, значит все работает

Отключил флаг --dynamic-config-dir - кубелет заработал. Почистил директорию с динамик конфигами, вернул флаг - работает. Конфигмапы не менял. Фига ли оно такое стабильное..

1.14?

в каком поле сертификата?

При добавлении кластера в gitlab

>всего лиш разработчик >самоподписанные сертификаты >проблемы с SSL сертификатом похоже открылся новый хостинг для биткоин майнеров

Я c SLL сертификатами плотно не работал, прошу прощения за нубство)

я не хотел никого обидеть, сорри если прозвучало грубо. Лучше сразу почитать про LetsEncrypt если кубернетес светит в публичную сеть с таким сертификатом

я не хотел никого обидеть, сорри если прозвучало грубо. Лучше сразу почитать про LetsEncrypt если кубернетес светит в публичную сеть с таким сертификатом

можно поподробнее про возможную атаку, пожалуйста?

кроме того без вообще никакого CA довольно трудно "перегенерить всё", потому что нет возможности получить достоверный список что именно было сгенерено

https://kubernetes.io/docs/tasks/administer-cluster/sysctl-cluster/#enabling-unsafe-sysctls

Создал podsecuritypolicy, в деплойменте указал securityContext: sysctls: - name: net.core.somaxconn value: "1024" все равно пишет not whitelisted

kubelet --allowed-unsafe-sysctls ... ?

перешли бы уже на человеческий kubevirt, не?

Покурил немного доку KubeVirt и вот что я выяснил: Сторадж: Можно использовать несколько типов драйверов, среди них: lun - внешний lun configmap - конфигмап пакуется и маунтится как iso hostDisk - устройство на хосте containerDisk - образ вкомпиленный в docker имадж dataVolume - тот самый PV из Kubernetes (включется отдельно в featureGates) и как я понял виртуалка не будет использовать его напрямую, а будет хранить файл диска на приаттаченном волуме https://kubevirt.io/user-guide/docs/latest/creating-virtual-machines/disks-and-volumes.html Примечательно, что Live-Migration требует стораджа с поддержкой ReadWriteMany https://kubevirt.io/user-guide/docs/latest/administration/live-migration.html#condition-and-migration-method Сеть: Текущий вариант: интерфейс контейнера добавляется в бридж и туда же добавляется интерфейс виртуалки затем виртуалка получает адрес с помощью DHCP. DHCP при этом запускается для каждой виртуалки свой и настраивает ровно одну виртуалку в поде. Таким образом получается что внутри каждого пода будет libvirt, виртуалка, бридж и SingleClientDHCPServer, который отдаёт виртуалке айпишник и роуты Решение интересное но насколько оно надёжное - непонятно. Ещё как я понял есть возможность использовать Multus с OpenVSwitch CNI, но инфы как именно это работает я что-то не нашёл (может быть плохо искал?) https://kubevirt.io/2018/KubeVirt-Network-Deep-Dive.html

Покурил немного доку KubeVirt и вот что я выяснил: Сторадж: Можно использовать несколько типов драйверов, среди них: lun - внешний lun configmap - конфигмап пакуется и маунтится как iso hostDisk - устройство на хосте containerDisk - образ вкомпиленный в docker имадж dataVolume - тот самый PV из Kubernetes (включется отдельно в featureGates) и как я понял виртуалка не будет использовать его напрямую, а будет хранить файл диска на приаттаченном волуме https://kubevirt.io/user-guide/docs/latest/creating-virtual-machines/disks-and-volumes.html Примечательно, что Live-Migration требует стораджа с поддержкой ReadWriteMany https://kubevirt.io/user-guide/docs/latest/administration/live-migration.html#condition-and-migration-method Сеть: Текущий вариант: интерфейс контейнера добавляется в бридж и туда же добавляется интерфейс виртуалки затем виртуалка получает адрес с помощью DHCP. DHCP при этом запускается для каждой виртуалки свой и настраивает ровно одну виртуалку в поде. Таким образом получается что внутри каждого пода будет libvirt, виртуалка, бридж и SingleClientDHCPServer, который отдаёт виртуалке айпишник и роуты Решение интересное но насколько оно надёжное - непонятно. Ещё как я понял есть возможность использовать Multus с OpenVSwitch CNI, но инфы как именно это работает я что-то не нашёл (может быть плохо искал?) https://kubevirt.io/2018/KubeVirt-Network-Deep-Dive.html

Если будут какие-то вопросы,то пишите, я постараюсь задать

немношко тут

спроси что мейлрушники думают про реализацию Cluster API

Чего в мыло не пришёл?)

В плане?

у них есть имплементация автоскейлера, но он реагирует только на метрики. А я хочу машины прям вот манифестами описывать, а не кликать там

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

хех, Cluster API для AWS и vSphere уже в 4.1 есть. Но я хочу чтобы мейлрушники осознали что им это тоже нужно :)

для берметала же тоже вроде, не?

хех, Cluster API для AWS и vSphere уже в 4.1 есть. Но я хочу чтобы мейлрушники осознали что им это тоже нужно :)

*trigger warning: SOAP, CPAN, XML*

а что там по репликам и количеству нод?

а, еще и в кубере, сорян, я так не извращался :D

не очнеь понимаю как на managed k8s это сделать

@kvaps ты смотришь?)