TL;DR: Для масштабирования gRPC в K8s, следует взять linkerd или нечто подобное.

Есть некий клиент (c) и некий сервер (s) в K8s, линия обозначает TCP соединение.

+--+   +--+
|c +---> s|
+--+   +--+

Используя K8s можно достаточно легко горизонтально масштабировать приложение:
- Руками изменить scale.
- Настроить HPA (Horizontal Pod Autoscaling)

И вроде все хорошо — у нас n-ое количество подов, и нагрузка должна автоматом распределятся по round-robin, ведь так?

+--+   +--+         
|c +---> s|         
+--+   +--+         
 |     +--+         
 +-----> s|         
 |     +--+         
 |     +--+         
 +-----> s|         
       +--+         

Тут уже начинаются детали.

Распределение нагрузки будет работать, в зависимости от того, по какому именно транспорту будут общаться сервисы.

K8s использует iptables как балансировщик, а он работает на уровне TCP соединений, то есть может балансировать TCP соединения.

HTTP/1.1: TCP соединения переиспользуются только после завершения HTTP запроса, то есть: в одно и тоже время в одном TCP соединении может обрабатываться только один HTTP запрос.
HTTP/2: Позволяет использовать одно и тоже TCP соединения для нескольких одновременных HTTP запросов (multiplexing).

Следовательно, при HTTP/2 у нас используется одно TCP соединение, внутри которого проходят множество запросов.

Балансировка будет выглядеть так:

+--+   +--+         
|c +---> s|         
+--+   +--+         
       +--+         
       | s|         
       +--+         
       +--+         
       | s|         
       +--+

Все запросы будут идти на первый сервер.

А gRPC использует HTTP/2 для транспорта.

——
То есть: балансировщик из коробки в K8s для gRPC трафика будет некорректно балансировать нагрузку, иначе говоря: балансировать TCP соединения, а не gRPC запросы.
——

Что делать?
Есть пару вариантов:
1. Взять Linkerd, он умеет балансировать gRPC с коробки.
*ИМХО самый корректный*

2. Так же, можно чуть чаще пересоздавать gRPC соединения, тут про это пишут.
*ИМХО самый простой*

2. Внутри самого сервиса: README.md.
*ИМХО самый странный*

Женщины: мужики хотят только одного

Мужики:

#go

Мамой клянусь

Source

Открыточка фронтендерам:

<center><div></div></center>

#prog #js #article

Speeding up the JavaScript ecosystem - one library at a time

Серия из десяти (на момент написания) статей о изменениях в библиотеках для JavaScript, которые ускоряют за счёт убирания лишней работы. Некоторые не привязаны конкретно к JavaScript.

#prog

protohackers.com

Задачи на программирование в духе Advent of Code, но тестирующие реализации кастомных сетевых протоколов. Есть своя автоматическая система тестирования, которая требует предоставить лишь публичный IP-адрес и порт.

(thanks @daily_ponv)

#prog #трудовыебудни

Прикидывал, как по работе в коде хранить данные. Подумал и решил, что наконец нашёл юзкейс для sync::Weak.

Потом подумал ещё и понял, что можно легко обойтись без этого.

"Мужчины не плачут!"
(а зря).

На днях мне попалась статья про способы снижения уровня кортизола (гормон стресса), один из способов – плач. Я и раньше об этом знал, но впервые узнал, что со слезами кортизол буквально физически вымывается через слезные железы.

Но не все так просто, недостаточно просто порезать лук, чтобы снять стресс. Оказывается слезы бывают аж трёх типов:

Базальные – защищают и увлажняют глаза.
Рефлекторные – появляются при раздражении (от попадания раздражителя на поверхность глаза).
Эмоциональные – выделяются при переживании сильных эмоций.

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

Еще есть информация о более косвенном влиянии плача на снижение кортизола и стресса. Плач помогает активировать парасимпатическую нервную систему, которая отвечает за расслабление и восстановление. Это приводит к снижению частоты сердечных сокращений и артериального давления, что, в свою очередь, косвенно влияет и на уровень кортизола.

А вот три искажения, которые могут мешать выражать эмоции:

1. Чтение мыслей — искажение, при котором человек думает, что другие осудят его за проявление эмоций. Например, «если я заплачу, подумают, что я слабый». Такое мышление часто усиливает стресс.

2. Катастрофизация — человек преувеличивает последствия плача, полагая, что он потеряет контроль, вызовет у окружающих разочарование или покажет свою уязвимость.

3. Черно-белое мышление — человек считает, что эмоции нужно либо полностью контролировать, либо «выплескивать» с агрессией. Обходите крайности стороной.

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

#psy и немного #bio, пожалуй

LLMоиды придумали утилиту file с libmagic

Пробка (жен. род, ед. число) — уменьш.-ласк. Проба

#cpp #meme

#ml ещё далеко до разумности

#prog #rust #rustasync #article

How big is your future?

О способах отслеживания больших футур, и в рантайме, и на этапе компиляции. Кстати, вы знали, что tokio::spawn автоматически боксит большие футуры, и через tokio-console можно получить информацию об этом?

#prog #rust #csharp #article

A comparison of Rust’s borrow checker to the one in C#

В C# есть явно ссылочные аргументы функций, переменные и поля, которые объявляются с префиксом ref. Помимо всего прочего, это позволяет передавать ссылки на размещённые на стеке данные. Разумеется, при отсутствии каких-либо проверок это небезопасно и позволяет получить висячую ссылку.

Для того, чтобы не допустить подобного, в C# есть свой статический анализатор. В данной статье автор сравнивает этот анализатор с borrow checker из Rust и разбирает, в чём этот анализатор слабее (и в чём неожиданно сильнее).

Лично мне напомнило немного про Oxidizing Ocaml, но в C# способов управления ссылками поменьше.