Можно ли как-то решить эту проблему сейчас? https://github.com/kubernetes/features/issues/536

Всем привет! Кто эзал для деплоя эластика вот этот helm чарт? https://github.com/kubernetes/charts/tree/master/incubator/elasticsearch

хз насколько это известно, но я сюда всё же поделюсь: The reason why we have such a high limit is that we want to keep the tail latencies down. Kubernetes uses 100ms period in the CFQ scheduler. Due to this, if limit is set e.g. 100m, after container has used it's 10ms, it will need to wait for the next slot before it can do any work again. In worst case this can mean that there's 180ms pause in the request. And if we are very unlucky, that 10ms was used by GC and we need to wait another up to 90ms. There's open issue in kubernetes/kubernetes#51135 regarding this and someone finally made patch for it recently, but I don't think it will before 1.1, likely even 1.12.

https://github.com/kubernetes/kubernetes/issues/51135 вот ссылка

да. я уже посмотрел If k8s users want to continue to consume CPU Quota (at their own risk), it's their choice and for that reason I'll no longer stall configuring CPU Quota Period.

А что значит k8s юзает 100мс период? Ну возьми его на каждой ноде поменяй

Откуда вообще 100мс, что-то не верится что кублет при первом запуске или ещё когда лезет cfs конфигурировать - это же не его парафия

А что значит k8s юзает 100мс период? Ну возьми его на каждой ноде поменяй

Там в коде захардкожено

Как конкретно оно используется внутри - хз

В коде чего?

Линукса?

Кубелета вроде

Не спрашивай, во внутренности я не вникал

Глянь ссылки по ссылке сам

Я там как-то не нашёл про это по ссылке

Но если кублет лезет менять настройки CFS на нодах то за такое надо по рукам давать

Не по ссылке, а по ссылкам которые по ссылке можно найти

Но если кублет лезет менять настройки CFS на нодах то за такое надо по рукам давать

Он ещё и на своп вроде ругался, например

Подскажите пожалуйста. Kube-proxy работает одинаково с deployment и statefullset?

Эээ что?

Statefullset тоже надо экспозить через сервис

Но если кублет лезет менять настройки CFS на нодах то за такое надо по рукам давать

CFS? Логично, что не нашёл -- такого и правда нет по ссылке.

А прокси он же траффик роутит на сервис

CFS? Логично, что не нашёл -- такого и правда нет по ссылке.

Стоп так там про i/o шедулинг а не cfs?

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

Надеюсь там про cfs, иначе вообще как-то ничего непонятно

Ну на deployment он может проксировать трафик между всеми подами, которые находятся за сервисом. А в statefullset он работает по той же схеме?

Сервис роутит траффик на все поды которые матчатся по указанному в нем match labels

Он вообще не в курсе про деплоймент и тд

Сервис роутит траффик на все поды которые матчатся по указанному в нем match labels

спасибо понял!

И даже можно вручную менять в сервисе endpoints (айпишники подов)

ребят, нужна помощь\совет, чот в отчаянии. Кто собирает образы в Gitlab(другие CI возможно также ведут себя). Как в одной ветке ссылаться на артефакт\образ из другой, чтобы не пересобирать образ для каждой ветки? Прям велосипедить начинаю, явно не туда иду

https://gitlab.com/gitlab-org/gitlab-ce/issues/37157 < - same story

Звучит очень странно, зачем такое надо? Если чтобы переюзать кеш докера то пулл образа из ветки мастер, stable или какой нужно и потом —cache-from этот локальный образ

Звучит очень странно, зачем такое надо? Если чтобы переюзать кеш докера то пулл образа из ветки мастер, stable или какой нужно и потом —cache-from этот локальный образ

вопрос не в кеше\цпу\времени сборки, а чистоте релиза. Если образ будет пересобираться после релиза\слияния - то это уже другой образ и его надо опять по всем тестам гонять

Use cases As a developer, when my code is build in dev to create an artifact I want my subsequent environments (qa,stage,prod,etc) to refer to that artifact and use it for deployment instead of creating a new one. либо я не той дорогой пошёл, либо я что-то упускаю в реализации

Konstantin если говорим о image, то почему бы не пушить в registry?

Собственно, это и есть дефолтный путь работы с пайплайнами

Konstantin если говорим о image, то почему бы не пушить в registry?

Да, он пушится в виде image:SHA

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

Собственно - как вы собираете, релизите?)

Если я правильн опонимаю вопрос. То вероятно использовать внешнее хранилище. Redis например: Ветка -> tag Но я не знаю зачем такое надо

Если я правильн опонимаю вопрос. То вероятно использовать внешнее хранилище. Redis например: Ветка -> tag Но я не знаю зачем такое надо

Да, возможно я не туда забрел, вот и ищу концы, совет

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

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

Это всё таски в пределах одной ветки? Но их же несколько

В каждой билдить?

Все зависит от задачи. Если идет мерж в ветку develop (ну или как вы ее назовете), то там еще и в staging выкатка. В master - сразу на прод

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

После слияния веток хеш коммита не меняется. Если вы мерджите со сквошем или ещё откуда берётся мердж коммит - откуда уверенность что артефакт из этой ветки выйдет такой же как в той что замерджили?

После слияния веток хеш коммита не меняется. Если вы мерджите со сквошем или ещё откуда берётся мердж коммит - откуда уверенность что артефакт из этой ветки выйдет такой же как в той что замерджили?

Ну вот в этом моменте я тоже призадумался, но мерж не пройдёт пока все коммиты не пройдут тесты, как я понимаю. У меня одна ветка рабочая и из неё мерж dev>master

А если тесты пока идут в destination ветку промерджит кто-то другую ветку?

Почему может вылазить Failed to pull image "someusername/someimage:dev-334": rpc error: code = Canceled desc = context canceled?

Тогда артефакт который сбилдится в source ветке будет несоответствать коду в destination ветке

После слияния веток хеш коммита не меняется. Если вы мерджите со сквошем или ещё откуда берётся мердж коммит - откуда уверенность что артефакт из этой ветки выйдет такой же как в той что замерджили?

меняется на хеш мёрж-коммита

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

меняется на хеш мёрж-коммита

Можно мерджить без мердж коммита если не было конфликтов

это уже будет не мёрж :)

И если не делать сквош

А что?

хм, был не прав

Тогда артефакт который сбилдится в source ветке будет несоответствать коду в destination ветке

я так понимаю это как-то по разному в разных ci? ибо в gitlab у меня коммиты для мерджа складываются в один реквест. brainfck (

в любом случае в соседнем чате уже говорили что так себе идея

Коллеги подскажите пожалуйста как заставить Service принудительно рвать коннект с клиентом. Например если pod на который смотрит service упал поднялся другой pod с другим ip. А клиент об этом ни чего не знает. Что бы заставить клиента переконектится надо разорвать соединение. А оно висит пока не закончится timeout

я так понимаю это как-то по разному в разных ci? ибо в gitlab у меня коммиты для мерджа складываются в один реквест. brainfck (

эт как?

в гитлабе вообще сборка идет по бранчу)

как настроишь

Сервис это правило в iptables

Правило коннекшены рвать не умеет

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

фу скип сиай

Костя, чет мельчаешь)

dev - это как раз бранч

фу скип сиай

это тестовый проект, нет времени CI гонять, я с мерджем разбираюсь

поставь точку перед название жобы)

поставь точку перед название жобы)

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

https://docs.gitlab.com/ee/ci/yaml/#hidden-keys-jobs

https://docs.gitlab.com/ee/ci/yaml/#hidden-keys-jobs

вопросов больше нет

squash commits только для элитки, и в целом бажная вещь)

squash commits только для элитки, и в целом бажная вещь)

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

ребят, нужна помощь\совет, чот в отчаянии. Кто собирает образы в Gitlab(другие CI возможно также ведут себя). Как в одной ветке ссылаться на артефакт\образ из другой, чтобы не пересобирать образ для каждой ветки? Прям велосипедить начинаю, явно не туда иду

делается это через cache и artefacts

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

не поделитесь примером как "надо"? Всё же так все и делают - собирают и гоняют одинаковые тесты на каждой ветке?

в самом первом жобе пайплайна собираешь

все остальные используют GIT_STRATEGY: none

ребят, нужна помощь\совет, чот в отчаянии. Кто собирает образы в Gitlab(другие CI возможно также ведут себя). Как в одной ветке ссылаться на артефакт\образ из другой, чтобы не пересобирать образ для каждой ветки? Прям велосипедить начинаю, явно не туда иду

Женкинс - артефакты плюс апстримф

это означает, что ты не трогаешь диск

не поделитесь примером как "надо"? Всё же так все и делают - собирают и гоняют одинаковые тесты на каждой ветке?

мы гоняем все тесты на каждой ветке в гитлабе. маленькие сервисы, маленькие репозитории, быстрые тесты. вот и профит

момент

Коллеги подскажите пожалуйста как заставить Service принудительно рвать коннект с клиентом. Например если pod на который смотрит service упал поднялся другой pod с другим ip. А клиент об этом ни чего не знает. Что бы заставить клиента переконектится надо разорвать соединение. А оно висит пока не закончится timeout

с этим вопросом я так понял мне ни кто не поможет ?

в самом первом жобе пайплайна собираешь

ты троллишь меня или серьёзно это всё пишешь?

мы гоняем все тесты на каждой ветке в гитлабе. маленькие сервисы, маленькие репозитории, быстрые тесты. вот и профит

видимо и мне туда дорога, но это же не то совсем((

спасибо

видимо и мне туда дорога, но это же не то совсем((

можно попробовать вокруг вот этого поплясать: https://docs.gitlab.com/ee/ci/yaml/#cache но это уже такое, dark magic, имхо

в смысле

интеграцию запускаешь на мерже в мастер через only: master

юниты летают на каждый коммит через only: branches