inqfen

Потсоны, подскажите, можно как-то сервис направить не на лейблы, а на под по имени?

Andrei

kubectl explain service.spec.selector Читать описание. Коротко: только если руками будешь менеджить endpoints И, собственно, нахрена создавать поды без лэйблов? За это сразу по рукам

Игорь

зачем руками, можно оператор написать :)

Andrei

Сначала пусть расскажет зачем ему поды без меток)

inqfen

kubectl explain service.spec.selector Читать описание. Коротко: только если руками будешь менеджить endpoints И, собственно, нахрена создавать поды без лэйблов? За это сразу по рукам

а кто сказал, что они без меток?

inqfen

Но я правда просто порты наружу выкинул

inqfen

Есть ingress подыб они соответственно daemonset на нодах

inqfen

2 пода, у обоих лейблы одинаковы

inqfen

Но метрики у каждого свои

Andrei

тааак, и?

inqfen

вот мне надо было у них порт 10254 отдельно у каждого пробросить

inqfen

потому что прометеус внешний

Andrei

А, видел мельком. Ок, а зачем? Почему не сделать локальный пром с retantion 1d и забирать метрики с него уже внешним?

inqfen

А, видел мельком. Ок, а зачем? Почему не сделать локальный пром с retantion 1d и забирать метрики с него уже внешним?

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

inqfen

У меня была таки мысль сделать федерацию, но я и без нее в итоге обошелся

Andrei

Даже если нет, в том кластере где пром, добавить сервис, добавить к нему руками endpoint ами по ингрессу и навесить метки для сборка метрик уже этим промом

inqfen

метрики cadvisor доступны через api, kube-state-metrics выставил через ingress, ingress метрики просто выкинул портом наружу

Andrei

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

Vadim

потому что прометеус внешний

внутренний прометеус на emptyDir + push нужных метрик во внешний прометеус?

inqfen

внутренний прометеус на emptyDir + push нужных метрик во внешний прометеус?

Метрики в итоге можно и без внутреннего забрать

inqfen

И без особого геморроя

Vadim

Метрики в итоге можно и без внутреннего забрать

можно, но если они потерялись то дебажить труднее

inqfen

В смысле потерялись? Доступ к ним?

Vadim

ну и светить всеми нодами на внешку тоже так себе идея

Andrei

Метрики в итоге можно и без внутреннего забрать

А чем лучше вывешивание 10-ка портов, нежели один пром?

inqfen

А чем лучше вывешивание 10-ка портов, нежели один пром?

одного порта

Vadim

В смысле потерялись? Доступ к ним?

а вот в этом и вопрос - что случилось, порт недоступен у пары нод или сам экспортер - сиди вот разбирайся

Andrei

одного порта

cadvisor доступны через api, kube-state-metrics выставил через ingress уже нет

inqfen

а вот в этом и вопрос - что случилось, порт недоступен у пары нод или сам экспортер - сиди вот разбирайся

ну как бы не сложнее чем если оператор или его часть приляжет

inqfen

cadvisor доступны через api, kube-state-metrics выставил через ingress уже нет

апи и так доступно, ингресс и так доступен

inqfen

вывесил только 10254

inqfen

ну и светить всеми нодами на внешку тоже так себе идея

все через sg закрыто, только для прома и админов, на ingress auth

Andrei

Решать и делать, конечно, Вам. Но делать изначально костыльное решение, имхо, плохой признак. Меня тут недавно в чате попинали за легаси в виде прокси между аппликухами и ингрессом, не поленился, за пол дня все выпилил к чертям и доволен)

inqfen

>делать изначально костыльное решение ну, я в нем тоже сомневаюсь, только вот не менее ли костыльно ставить оператор, со своими реакциями на события, сервисом прома, экспортерами etc для того, чтобы странички с кучкой текста передать

Andrei

но ты делаешь сложно, но привычно тебе

кстати, ты был прав, спасибо! это была просто лень, лень перепиливать легаси)

Andrei

>делать изначально костыльное решение ну, я в нем тоже сомневаюсь, только вот не менее ли костыльно ставить оператор, со своими реакциями на события, сервисом прома, экспортерами etc для того, чтобы странички с кучкой текста передать

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

Andrei

апи и так доступно, ингресс и так доступен

а в чем тогда проблема метрики ингресса так вывести через него же? костылить так по полной)

inqfen

а в чем тогда проблема метрики ингресса так вывести через него же? костылить так по полной)

а вот тут начинаем сначала - как сделать 2 сервиса на 2 пода с одинаковыми лейблами?)

Andrei

зайду с другой стороны, nginx там с hostnetwork?

inqfen

ага, стандартно

inqfen

А, понял про что ты, network=host

Andrei

Ну так у вас эти порты и так доступны по ip нод

inqfen

нет, там published ports

inqfen

Искаропки опубликованы только 80 и 443

Andrei

Ок, там nginx-ingress и над ним еще кто-то?

inqfen

ports: - containerPort: 80 hostPort: 80 ... и так далее

inqfen

Ок, там nginx-ingress и над ним еще кто-то?

нет, он демонсетом развернут, не понял насчет над ним еще кто-то

Andrei

Трафик на него как попадает?

inqfen

lb -> ingress nodes

inqfen

на каждой ноде есть ингресс под соответственно

Andrei

А lb к нему ходит по внутреннему ip сервиса?)

inqfen

через igw в данном случае емнип да, внутренний маршрутизируется

inqfen

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

Andrei

Я так понял, aws?

inqfen

ага

inqfen

lb, смотрит на инстансы, на инстансах ингресс ноды, для 80 и 443 таргет группа

Andrei

В общем, я к чему: если он у вас в daemonset и вы хотите идти по этому шаткому пути, не вижу проблем задеплоить с хостовой сетью

inqfen

прометеус ходит на ноды напрямую

Andrei

Если делать нормально, то свой пром в каждый кластер

Andrei

Засим, пардоньте, ушел

G72K

прометеус ходит на ноды напрямую

Пусть внешний Прометей через аписервера ходит в поды и забирает метрики. Так точно можно, надо только ключ сервис аккаунта выдать

Alexander

Это я в курсе, зачем, говорю, копировать данные, когда проще сделать один билд приложения с кодом и запускать как я описывал

Ну в "нашей" схеме проще поэксперементировать со сменой версий php и nginx. И она более логичная, отражает старый доконтейнерный деплой php приложения(3 версионированных артифакта) на контейнеры.

UglyKoyote

Доброго времени суток.. А подскажите пожалуйста вот такой момент. Есть внешний кластер etcd 3х нодовый, есть кластер кубернетиса 3х нодовый. дружат друг с другом, работают по секурному (сертификаты и всё такое). Кластера стендовые, для набития руки/морды и прочих частей тела. Вчера наткнулся на ситуевину. Путем незапомненных манипуляций ноды воркеры были выведены из строя, попытки удалить их из кластера привели к "залипанию" нод в кластере. Ну я то не дурак, делаю ресет кубера с ключем force. Удаляю каталоги, как обычно, когда ставил кубер со встроенным etcd, разворачиваю кубер и бабах - конфиг подтянулся из внешнего etcd. А это 3 ноды в наличии, из них 2 ноды-воркера в ступоре. Пытался найти вразумительно как почистить данные кубера на удаленном кластере etcd, но видимо под конец рабочего дня уже голова не принимала информацию. Проблему решил координально, остановил etcd, почистил каталог ему с базой. Есть ли у кого под рукой ссылка на бэст практис - как правильно решать такую ситуацию? Предполагаю что изначально недостаточно корректно настроил кубер на работу с внешним etcd

inqfen

Пусть внешний Прометей через аписервера ходит в поды и забирает метрики. Так точно можно, надо только ключ сервис аккаунта выдать

Я для ингресса в апи это не нашёл, только для cadvisor

inqfen

Доброго времени суток.. А подскажите пожалуйста вот такой момент. Есть внешний кластер etcd 3х нодовый, есть кластер кубернетиса 3х нодовый. дружат друг с другом, работают по секурному (сертификаты и всё такое). Кластера стендовые, для набития руки/морды и прочих частей тела. Вчера наткнулся на ситуевину. Путем незапомненных манипуляций ноды воркеры были выведены из строя, попытки удалить их из кластера привели к "залипанию" нод в кластере. Ну я то не дурак, делаю ресет кубера с ключем force. Удаляю каталоги, как обычно, когда ставил кубер со встроенным etcd, разворачиваю кубер и бабах - конфиг подтянулся из внешнего etcd. А это 3 ноды в наличии, из них 2 ноды-воркера в ступоре. Пытался найти вразумительно как почистить данные кубера на удаленном кластере etcd, но видимо под конец рабочего дня уже голова не принимала информацию. Проблему решил координально, остановил etcd, почистил каталог ему с базой. Есть ли у кого под рукой ссылка на бэст практис - как правильно решать такую ситуацию? Предполагаю что изначально недостаточно корректно настроил кубер на работу с внешним etcd

Эм, ну а что не так с решением, которое ты использовал?

Alexander

Эм, ну а что не так с решением, которое ты использовал?

Ну вообще-то если воркеры выходят из строя, то не нужер переставлять Кубер )

inqfen

А, понял, ты про то как воркеры удалить

inqfen

Ну вообще если их удаление залило, то видимо ещё какие-то ресурсы были

inqfen

Ну и в интернетах есть гайды как из etcd руками воркер удалить

Alexander N.

Коллеги, поясните мне, почему k8s при создании PV записывает адрес того монитора (ceph-provisioner), с помощью которого был создан и в дальнейшей работе использует только его, абсолютно наплевав на то, что написано в storageClass'e?

UglyKoyote

Ну и в интернетах есть гайды как из etcd руками воркер удалить

а нет случаем под рукой ссылки? ну чисто так... на удачу)

inqfen

Не, под рукой нету

UglyKoyote

А, понял, ты про то как воркеры удалить

да

UglyKoyote

Не, под рукой нету

спасибо, буду на свежую голову сейчас искать

inqfen