M
19.02.2018
10:10:24
ребят подскажите, kube-proxy порт доступный из вне но этого порта нет в services и по этому порту можно перейти на /healthz
что это такое и как сконфигурировать или убрать
Айбелив
19.02.2018
10:12:53
M
19.02.2018
10:13:35
Айбелив
19.02.2018
10:14:27
да понятно, поэтому я и пытаюсь выяснить на каком языке лучше говорить. Потому что русский не совсем понятен.
Google
M
19.02.2018
10:14:41
я хорошо говорю по русски
Айбелив
19.02.2018
10:15:27
да я не спорю, но знаки препинания в сообщениях не повредят
66271
19.02.2018
10:19:22
Айбелив
19.02.2018
10:20:26
kube-proxy обычно имеет hostNetwork: true, вся конфигурация проходит на уровне аргументов
noname
19.02.2018
10:21:37
Айбелив
19.02.2018
10:22:22
noname
19.02.2018
10:22:54
так в чём вопрос-то?
nginx-ingress-icm LoadBalancer 10.101.147.36 <pending> 80:31603/TCP 48m
icm-ingress icm.test,auth.icm.test 192.168.131.245 80 2m
(192.168.131.245) в качестве внешнего айпи(хостоывый)
вопрос в том чтобы он слушал на 192.168.131.245 ip не 31604 порт а 80
Айбелив
19.02.2018
10:23:39
так ответили уже вроде
порты с 30000 выделяются для service NodePort. самый простой способ забиндить ingress-nginx на 80,443 - запустить его с hostnetwork
либо поменять сам range в kube-apiserver флажком --service-node-port-range
Google
noname
19.02.2018
10:28:25
все хзаработало. спасибо большое!
M
19.02.2018
10:30:01
Айбелив
19.02.2018
10:30:42
hostNetwork: true
не, с gke не сталкивался
у них какой-то свой kube-proxy, либо просто в 1.8.x так стало много всего
M
19.02.2018
10:33:48
вот такая штука возвращается
и без понятия где менять значение
Айбелив
19.02.2018
10:34:10
да я верю и даже уже ответил как убрать
M
19.02.2018
10:34:27
так мне не надо убрать я хочу поменять
Айбелив
19.02.2018
10:34:57
ребят подскажите, kube-proxy порт доступный из вне но этого порта нет в services и по этому порту можно перейти на /healthz
что это такое и как сконфигурировать или убрать
> что это такое и как сконфигурировать или убрать
» или убрать
можно форкнуть kube-proxy (думаю, что весь kubernetes придётся) и переконфигурировать как надо
M
19.02.2018
10:37:27
Айбелив
19.02.2018
10:39:44
Andrey
19.02.2018
10:41:25
Сергей
19.02.2018
10:42:05
Andrey
19.02.2018
10:42:44
Айбелив
19.02.2018
10:43:04
Andrey
19.02.2018
10:43:35
Google
Andrey
19.02.2018
10:44:18
Nick
19.02.2018
10:44:48
первые две строчки почитай
сам ингресс ничего не балансит, но он говорит как это делать нжинксу
Айбелив
19.02.2018
10:45:56
задача ингресса — принять внешний трафик и размазать внутри по ендпоинтам под
Andrey
19.02.2018
10:46:30
ясно же, про что спрашивают
про внешний по отношению к кластеру лоадбалансер
а не то, как оно внутри запросы между подами раскидывает
Nick
19.02.2018
10:48:47
дык что мешает его юзать как балансе?
nginx ж обычный
Andrey
19.02.2018
10:49:19
Да, суть вопроса была в том чтобы сверху все ноды накрыть балансером. Для доступа снаружи
Andrey
19.02.2018
10:49:48
Andrey
19.02.2018
10:49:49
Nick
19.02.2018
10:50:25
Andrey
19.02.2018
10:51:10
RTFM
Let Eat
19.02.2018
10:54:26
Evgenii
19.02.2018
10:54:53
Разобрался с секретом к eu.gcr.io, засунул его в нужный NS, привязал к дефолтному SA. Но всё равно контейнеры не тянутся оттуда. Локально всё тянется. Подскажите, как можно отладить такое?
Andrey
19.02.2018
10:55:13
RTFM
ткни плз носом где это описано, пойду читать)
Google
Let Eat
19.02.2018
10:55:27
M
19.02.2018
10:56:18
Andrey
19.02.2018
10:57:01
Айбелив
19.02.2018
10:57:35
в проде юзаешь?
Andrey
19.02.2018
10:57:38
Metallb в статусе альфы
Andrey
19.02.2018
10:57:47
Andrey
19.02.2018
10:57:56
но у меня не highload
Anton
19.02.2018
11:13:56
единственно что неудобно, что с vip размазать трафик по N машинам чуть сложновато.
хотя первый вопрос как то и без metallb решить можно
а вот несколько ip на один сервис, это интреснее (входящий трафик на N машин размазать)
Vladyslav
19.02.2018
11:41:37
W0219 11:40:11.455349 1 x509.go:172] x509: subject with cn=system:kube-scheduler is not in the allowed list: [front-proxy-client]
после деплоя с kubespray такое вылазит, кто сталкивался ?
Ivan
19.02.2018
11:43:40
все ж в доках есть
M
19.02.2018
11:53:02
Sergey
19.02.2018
11:55:12
глупый вопрос - как лучше организовать накатку миграций базы для приложений (ну и вообще куда пихать что-то что надо запустить непосредственно перед обновлением подов и строго в единственном эксземпляре?
Andrey
19.02.2018
11:55:35
Job
Можно через helm в post-* или pre-* хуке.
Google
Sergey
19.02.2018
11:57:38
c helm еще не разбирался... потому дополнительный вопрос - как разруливать когда нужно раскатывать контейнеры в определенном порядке?
ну допустим есть 4 пода, и мне надо сначала обновить один, потом что-то запустить, потом обновить остальные
Andrey
19.02.2018
11:58:09
Тоже страдаем с этим. С Helm единым пока никак.
Кстати, интересно опыт коллег послушать.
Vladyslav
19.02.2018
12:02:46
через init containers попробуйте
Andrey
19.02.2018
12:21:07
А еще мне интересен вот такой вопрос. Допустим, у меня на серваке с бд закончилось место, и я прифигарил раздел побольше. Есть правильный способ перенести туда hostpath pv, чтобы ничего не сломать?
Vladyslav
19.02.2018
12:22:12
базу в рдс держим
на метале - отдельная виртуалка
Andrey
19.02.2018
12:23:50
@gorilych и @anti_on ?
Andrey
19.02.2018
12:28:28
Sergey
19.02.2018
12:43:29
через init containers попробуйте
а если у меня 10 контейнеров стартуют? как ограничить что бы только один сначала отработал и если с ним все ок то только потом остальные запускать*?
Konstantin
19.02.2018
12:46:11
Vladyslav
19.02.2018
12:46:13
Sergey
19.02.2018
12:46:25
да
о миграциях
и уверен что сначала миграция а потом раскатить новую версию приложеньки на класстер
Konstantin
19.02.2018
12:47:28
Сделайте job'у для миграции, а из процесса раскатки приложения уберите это
Vladyslav
19.02.2018
12:47:29
отдельной джобой миграции накатывайте