у меня балансер трафик пускает на прамую на под его айпи и внтуренний порт

да пофиг

Вопрос в том, что под нагрузкой контракт - это беда

он не тюнится до бесконечности

второе

я не хочу что бы через ноды на которых нет физически пода ходил трафик

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

делать только одну точку входа тоже не очень красиво, что если она упадет? прикручивать вррп?

а в чем проблема?

вы явно не стлакивались с ппс и таблицей контракта

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

у меня на 5 нод полтора ляма ппс - это норма

можно на ты

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

если с этим упираться - то нафиг мне кубер

сейчас и так это именно так работает

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

и резервируются порты

мы хотим намного больше гибкости

но при этом не дрочить таблицу контракта

а что такое таблица контракта?

или это вы так называете conntrack?

ну та

оё

балансировщики вне куба?

да

их два

но при этом не дрочить таблицу контракта

а в чем боль? В том, что kube-proxy генерирует правила для NAT, которые потенциально медленно работают? И поэтому юзерспейс-балансировщик на го предположительно работает быстрее?

он раотает быстрее

это раз

а тесты проводили? Хинт: если у вас модуль ядра подгружен и нет правил, которые бросают трафик на NOTRACK, то ни разу он быстрее не работает. афаик kube-proxy умеет работать в режиме, в котором трафик через него не идет совсем.

ну да

быстрее только nginx stream

nginx stream + conntrack работает быстрее чем conntrack?

как балансировщик

трафик прет на прямую на айпи подов и их внутрение порты

минуя контракт ноды

еще раз: если модуль загружен, и в raw нет NOTRACK-правил, трафик хоть и идет напрямую, всё равно отмечается в conntrack.

алсоу, conntrack от connection tracking, а не от contract.

вы сомтрели как реализованно в правилах iptables все это поведение?

мне лично не понравилось

это мое мнение, я никому его не навязываю

афаик, там правила в prerouting/postrouting таблицах, которые откусывают весь трафик на пару ip:port. но признаться не смотрел давно, поэтому могу сильно путать. я зацепился только за то, что коннтрек работает медленнее, чем nginx. что звучит несколько невероятно без dpdk.

я мог где-то и напортачить, потому и говорю что у меня вышло

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

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

ну вот я так хочу)

я не хочу что бы трафик приходил на ноду А, она потом его форвадила на ту ноду, где есть этот под, если я могу сразу туда пустить трафик

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

апи их им правится

они вон дискавери для хезелькаста через апи сервис дискавери кубера сделали и радуются

Да, api сдравое, лучше чем у docker.

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

плюс, по факту, к докер уон не привязан

там чет изменится в строну rkt лично для тебя шибко ничего не поменяется

Готов пример с prometheus https://github.com/kayrus/prometheus-kubernetes

> подозреваю, что они осилили у себя сделать без дт даунтайм есть

Готов пример с prometheus https://github.com/kayrus/prometheus-kubernetes

круто, обязательно затестю... а ты в helm это все запихивать не планируешь?

а вот еще, гугль через gcloud ставит свой kubectl, и при переходе на 1.4.0 (его они кстати обновили позже чем кластер) стали иногда выпадать ошибки в рандомных местах: panic: sync: inconsistent mutex state goroutine 1 [running]: panic(0x1b43960, 0xc8201cbad0) /usr/local/go/src/runtime/panic.go:481 +0x3e6 sync.(*Mutex).Lock(0xc82001bc50) /usr/local/go/src/sync/mutex.go:75 +0x16d

загуглил что такое helm. минуты две втыкал что это такое. что такое chart. думал графики какие-то

пакетный менеджер чтоли?

угу, позиционируют как официальный

да вот хз... опять бинарники качать, разбираться

а тут вроде sh везде есть. везде заведется

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

надо посмотреть. но в первого взгляда никаких преимуществ не вижу

ну да, если для себя то лишний геморой с оформлением, а если для комьюнити с поддержкой то унификация установки и поддержки

ну лично у меня одна проблема была. поменять конфиг и применить его к prometheus. config volumes по дефолту обновляются раз в минуту. пришлось для этого обвязку на shell писать. helm в этом поможет?

ну поможет наверное кому-то другому если ты опишешь в темлейтах )

ну и забомбило у меня когда выяснилось, что "complete" примеров для прометея нет. везде кусками. и то некоторые куски были предназначены для старой версии, а в релизе оно не работает.

кстати, если я хочу чтобы у меня в кластере по расписанию выполнялась какая-то функция (например дергался хттп-роут) это по каким ключевым словам гуглить?

sheduler cron что-то типа этого

http://kubernetes.io/docs/user-guide/scheduled-jobs/ оно?

похоже

$ kubectl get scheduledjobs Unable to list "scheduledjobs": the server could not find the requested resource

похоже не судьба пока )

может надо создать для начала

хотя версия api v2alpha

нужно включать на k8s > 1.4

гугль не поддерживает: only supports API versions ["federation/v1beta1" "apps/v1alpha1" "batch/v1" "batch/v2alpha1" "rbac.authorization.k8s.io/v1alpha1" "storage.k8s.io/v1beta1" "extensions/v1beta1" "policy/v1alpha1" "v1" "authentication.k8s.io/v1beta1" "authorization.k8s.io/v1beta1" "autoscaling/v1" "certificates.k8s.io/v1alpha1" "componentconfig/v1alpha1"]