G
А, ну хотя дефаулт гейтвей и без адреса может быть
Из тех что я видел cni дефолт на eth0 обычно
Size: a a a
2020 October 28
k
интересная штука, это конструктор аписерверов?
Не, это прокси-сервер наоборот
k
Обычно оно используется чтобы из аписервера в кластер достучаться или к etcd если они работают в другой сети за натом и хочется зашифровать подключение
k
См. konnectivity
KG
Это колхоз
Точнее? Что колхоз?
c
Точнее? Что колхоз?
Весь опенштфт колхоз по мне
KG
Весь опенштфт колхоз по мне
Ааа. Ну мне тоже многое не нравится, поэтому едем в EKS.
Но тем не менее вопрос остаётся открытым. Либо везде в образах переписывать юзера на номер. Либо делать что-то другое.
Прописывать в подах securityContext.
Admission Controller из опеншифта как-то нету в простом варианте.
Как вообще люди делают?
Но тем не менее вопрос остаётся открытым. Либо везде в образах переписывать юзера на номер. Либо делать что-то другое.
Прописывать в подах securityContext.
Admission Controller из опеншифта как-то нету в простом варианте.
Как вообще люди делают?
c
В шифте идёт привязка рандомного id к проекту при деплое
LB
Обычно оно используется чтобы из аписервера в кластер достучаться или к etcd если они работают в другой сети за натом и хочется зашифровать подключение
читаю https://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/ и не понимаю что это. это какая-то штука для перенаправления доступа? компоненты кластера знают об этой CRD и если там сказано "доступ к мастеру через этот сокет", то вместо хождения напрямую идут в сокет?
GG
Кто-нибудь пользуется pod security policy в кубе?
Openshift даёт магию в виде замены юзера на рандомного и нормально хаваются образы, где прописан юзер именной, например, USER kong.
В многих образах прописан такой именной юзер. Как это использовать для куба? Переписывать на номер?
Openshift даёт магию в виде замены юзера на рандомного и нормально хаваются образы, где прописан юзер именной, например, USER kong.
В многих образах прописан такой именной юзер. Как это использовать для куба? Переписывать на номер?
И в чем проблема в юзере
GG
Замена это хорошо, у тебя софт портабельный должен быть, иначе он некорректно написан
GG
читаю https://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/ и не понимаю что это. это какая-то штука для перенаправления доступа? компоненты кластера знают об этой CRD и если там сказано "доступ к мастеру через этот сокет", то вместо хождения напрямую идут в сокет?
Ну, это если у тебя кластер распилен как у квапса
GG
Отдельно куб мастера - и им как-то нужно ходить в вебхуки, которые в кластер задеплоены, а Воркер ноды отдельно
GG
Причём мастер может и не быть нодой самого кубернетса
KG
И в чем проблема в юзере
Если в образе указан USER kong, то куб не может его определить как nonroot.
Именные юзеры используются часто в opensource образах.
Меня интересует как так? Неужели все переписывают юзеров? Как поступают другие?
Именные юзеры используются часто в opensource образах.
Меня интересует как так? Неужели все переписывают юзеров? Как поступают другие?
k
читаю https://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/ и не понимаю что это. это какая-то штука для перенаправления доступа? компоненты кластера знают об этой CRD и если там сказано "доступ к мастеру через этот сокет", то вместо хождения напрямую идут в сокет?
https://youtu.be/FDdPProqE8g
Смотреть с 27 минуты
Смотреть с 27 минуты
МS
Короче, вы убедили меня, что я арго не хочу
Это как они тебя так убедили?
DS
Кто-нибудь пользуется pod security policy в кубе?
Openshift даёт магию в виде замены юзера на рандомного и нормально хаваются образы, где прописан юзер именной, например, USER kong.
В многих образах прописан такой именной юзер. Как это использовать для куба? Переписывать на номер?
Openshift даёт магию в виде замены юзера на рандомного и нормально хаваются образы, где прописан юзер именной, например, USER kong.
В многих образах прописан такой именной юзер. Как это использовать для куба? Переписывать на номер?
Я использую, там не рандомный, а минимальный id из диапозона. Например:
Если в спеке пода не указан будет uid юзера, то контейнер запустится от 4401 uid. А если в спеке пода uid указан, то ему разрешены только с 4401 по 4500
runAsUser:
rule: MustRunAs
ranges:
- max: 4500
min: 4401
Если в спеке пода не указан будет uid юзера, то контейнер запустится от 4401 uid. А если в спеке пода uid указан, то ему разрешены только с 4401 по 4500
МS
https://youtu.be/FDdPProqE8g
Смотреть с 27 минуты
Смотреть с 27 минуты
А у тебя в проде init куб - kubeadm?
KG
Я использую, там не рандомный, а минимальный id из диапозона. Например:
Если в спеке пода не указан будет uid юзера, то контейнер запустится от 4401 uid. А если в спеке пода uid указан, то ему разрешены только с 4401 по 4500
runAsUser:
rule: MustRunAs
ranges:
- max: 4500
min: 4401
Если в спеке пода не указан будет uid юзера, то контейнер запустится от 4401 uid. А если в спеке пода uid указан, то ему разрешены только с 4401 по 4500
Т.е. ты прописываешь securityContext для приложений и норм?
Спасибо.
Спасибо.