Size: a a a

2020 February 13

ВС

Валентин С in Go-go!
Многопоточность отстой, уже давно рулит асинхронность.
источник

ЕО

Евгений Омельченко in Go-go!
Валентин С
Многопоточность отстой, уже давно рулит асинхронность.
Какой-то слабенький наброс
источник

N

Nikita in Go-go!
ребят у кого видел уроки otus Go ?
источник

ВС

Валентин С in Go-go!
У го канкарренси вынесен на уровень корутин что кстати гениальная идея. Просто абстрагируешься от канкарренси и мыслишь однопоточно.
источник

ЕО

Евгений Омельченко in Go-go!
Rokker Ruslan
С graceful shutdown в гошке есть проблема, но напрямую не связанная, если какой нибудь systemd справляется отлично, то кубер (в котором чаще всего крутятся приложухи) в этот самый graceful shutdown не умеет.
Умеет, но гошка тут не при чём
источник

ЕО

Евгений Омельченко in Go-go!
Валентин С
У го канкарренси вынесен на уровень корутин что кстати гениальная идея. Просто абстрагируешься от канкарренси и мыслишь однопоточно.
Просто абстрагируешься от потоков с помощью потоков. Это что-то новое
источник

RR

Rokker Ruslan in Go-go!
если затрагивать минимально возможное кол-во ресурсов то кратко описать можно так: при остановке подов (находящихся под нагрузкой) мы всё равно получаем ошибки при чтении на сокетах. Воспроизвести можно так:
1. Берём кластер (желательно на до или ему подобных)
2. Приложение(пускай отдаёт хелоу ворлд) на го, умеющее останавливать accept(по сигналу), при продолжении обработки существующих соединений.
3. Два ресурса, деплоймент и сервис (для простоты берём node port), при этом деплой мент умеет сигнализировать приложению об остановке и ждать завершения работы подов (так же настроен readness параметр).
После этого запускаешь один под и натравливешь на него вкр, пока без перезапуска) Если нет ошибок можно приступить к тестированию.

Поднимаешь n подов, натравливаешь wrk, останавливаешь m, m меньше чем n. Наблюдаешь ошибки при чтении, а значит кубер отключает от сервиса поды ранее чем они завершили работу. Как то так.
источник

RR

Rokker Ruslan in Go-go!
А, да забыл, настроить кубер так чтобы он сначала поднимал m подов новых, а только потом останавливал старые
источник

RR

Rokker Ruslan in Go-go!
если тестить курлом можно и не попасть в этот момент, но ты попробуй сам
источник

ЕО

Евгений Омельченко in Go-go!
Rokker Ruslan
если затрагивать минимально возможное кол-во ресурсов то кратко описать можно так: при остановке подов (находящихся под нагрузкой) мы всё равно получаем ошибки при чтении на сокетах. Воспроизвести можно так:
1. Берём кластер (желательно на до или ему подобных)
2. Приложение(пускай отдаёт хелоу ворлд) на го, умеющее останавливать accept(по сигналу), при продолжении обработки существующих соединений.
3. Два ресурса, деплоймент и сервис (для простоты берём node port), при этом деплой мент умеет сигнализировать приложению об остановке и ждать завершения работы подов (так же настроен readness параметр).
После этого запускаешь один под и натравливешь на него вкр, пока без перезапуска) Если нет ошибок можно приступить к тестированию.

Поднимаешь n подов, натравливаешь wrk, останавливаешь m, m меньше чем n. Наблюдаешь ошибки при чтении, а значит кубер отключает от сервиса поды ранее чем они завершили работу. Как то так.
Вы просто не уложились в грейс период, либо проваливаете риднеспробу раньше чем закроете соединения, но это не чат про кубернетис
источник

RR

Rokker Ruslan in Go-go!
Так или иначе сделал я всё по документации кубера и получил такой результат, если вы пробовали сами (а не просто статьи читали) я бы с радостью взглянул на результат (кубер ресурсы)
источник

RR

Rokker Ruslan in Go-go!
На stackoverflow мне сказали что это нормально
источник

DP

Daniel Podolsky in Go-go!
так а это нормально
источник

RR

Rokker Ruslan in Go-go!
Просто я ожидал что произойдёт примерно следующее. Сначала кубер завершит поды, потлм отключит от сервиса. И клиент не получит ошибку при чтении. Но нет
источник

RR

Rokker Ruslan in Go-go!
Возможно я не понимаю как это должно работать
источник

ЕО

Евгений Омельченко in Go-go!
Rokker Ruslan
Просто я ожидал что произойдёт примерно следующее. Сначала кубер завершит поды, потлм отключит от сервиса. И клиент не получит ошибку при чтении. Но нет
Нет, поды будут отключены от сервиса когда провалятся риднеспробы
источник

ЕО

Евгений Омельченко in Go-go!
А если вы сначала их проваливаете, а потом закрываете сокеты. Ну.. Тогда ловите RST
источник

RR

Rokker Ruslan in Go-go!
Евгений Омельченко
А если вы сначала их проваливаете, а потом закрываете сокеты. Ну.. Тогда ловите RST
Именно поэтому нет смысла настраивать graceful в приложении
источник

АП

Александр Попов in Go-go!
итог дискуссии: мы все умрем
источник

АП

Александр Попов in Go-go!
готышно
источник