Как стать автором
Обновить

Опыт масштабирования Kubernetes на 2k узлов и на 400k подов

Уровень сложностиСложный
Время на прочтение8 мин
Количество просмотров11K
Всего голосов 29: ↑24 и ↓5+29
Комментарии10

Комментарии 10

Без цифр нагрузки не интересно.

Сколько запросов в минуту?

Сколько процессорного времени занимает один запрос?

Сомнения большие в ваших архитектурных решениях

Вы пытаетесь задавать вопросы переводчику: ПУБЛИКАЦИИ 43 КОММЕНТАРИИ 1

На самом деле интересно. Вот у нас сопоставимых размеров хадуп, к примеру. И что я тут для себя вынес - то что большой кластер k8s упирается в отдельный сервис, в данном случае например в etcd. А у нас хадуп упирался скажем в керберос, или в DNS. В общем, в какие-то отдельные критически важные для жизни сервисы, которые при этом недостаточно хорошо масштабируются.

Etcd как раз масштабируется прекрасно. Об этом говорится в статье

Тут пол статьи как раз о том, как они масштабировали etcd. Может это конечно и легко, но таки автор оригинала решил про это статью написать. Видимо для него это было не слишком просто сделать.

Для себя вынес - Google создал замечательный оркестратор для нагрузок уровня Google и PayPal.
Для мелких нагрузок (моих) k8s зачастую overkill.

Нагрузки что PayPal, что Google далеко за пределами возможностей единичного кластера k8s.

Увидел "дросселирование" и бросил читать. Разве про тротлинг так говорят? Может я и моё окружение какое-то неправильное?

там ещё есть " плоскости управления Kubernetes"

Этот перевод хорошо настоялся, почти ровно два года исполнилось оригинальной статье. Не надо останавливаться, можно ещё вторую статью на английском о кластерах подобных масштабов перевести (ну, так было на январь 2023-го; статья от OpenAI как помнится). Ждём через пару лет.

на "плоскости управления" в первом предложении пытаться читать можно заканчивать %)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий