А вы когда-нибудь задумывались о границах масштабируемости Kubernetes? Для тех, кого порой посещают такие мысли, мы решили опубликовать перевод заметки "Kubernetes Scalability thresholds", вам точно будет интересно ознакомиться.
В перевод заметки для наглядности мы добавили слайды презентации Kubernetes Scalability: A multi-dimensional analysis.
На самом деле, ответ на вопрос о границах масштабируемости, или, о пороговых значениях Kubernetes совсем не прост, и эта мысль красной нитью следует через всю заметку, заставляя мозг скрипеть и скрежетать в нелегких размышлениях. Также в этом небольшом материале представлены достаточно интересные цифры о Kubernetes. Достичь таких показателей могут, конечно, далеко не многие компании.
Кстати, если говорить о выдерживании компанией соглашения SLO в рамках проекта, то часто возникают казусные ситуации, при которых бизнес вопреки всему стремится максимально сократить издержки на инфраструктуру, и тем самым стремит показатель SLO в бесконечность, что приводит к регулярным нарушением SLA. Каких либо универсальных инструкций на этот счет нет, просто нужно рационально подходить к вопросу о масштабировании и пренебрегать конкретными SLO.
Итак, поехали. Делитесь в комментариях, какие у вас мысли по этой непростой теме.
Пороговые значения масштабируемости Kubernetes
Предыстория
Как уже было описано в заметке “Как мы определяем масштабируемость”, в среднестатистической ситуации предоставить какие-либо гарантии невозможно. Одно из условий выполнения SLO - это сохранение нагрузки в кластере в рамках рекомендуемых границ. Эта заметка - попытка более точно определить измерения и их границы.
Пределы Kubernetes
Границы масштабирования и пороговые значения - это весьма сложный вопрос. На деле конфигурации, которые Kubernetes поддерживает, создают своего рода пространство масштабируемости:
Вот некоторые свойства этой оболочки:
1. Она НЕ является кубом, так как измерения иногда не независимые.
2. Она НЕ является сферой.
3. Пока вы двигаетесь по одному измерению, зона пересечения с другими измерениями становится меньше.
4. Она ограничена.
5. Ее можно разбить на более мелкие оболочки.
Вы можете узнать больше об этом в Kubecon talk (или Kubecon slides).
Ниже описаны некоторые замечания к пороговым значениям, указанным в таблице ниже:
В большинстве случаев, пределы это НЕ жесткие ограничения - пересечение лимита приведет к снижению производительности, а не к немедленному падению кластера.
Многие пороговые значения (в рамках кластера) даны для наибольшего возможного кластера. Для меньших кластеров лимиты пропорционально меньше.
-
Пороговые значения могут различаться (надеюсь, они не уменьшаются) в разных версиях Kubernetes. Те, что представлены ниже - даны для Kubernetes head.
TODO: Мы планируем начать делать таблицу по версиям, но пока что такой нет.
Учитывая, что конфигурация влияет на лимиты, мы предполагаем, что используется стандартная версия Kubernetes.
Таблица ниже не исчерпывающая, больше информации появится позже.
Quantity |
Threshold scope=namespace |
Threshold: scope=cluster |
---|---|---|
#Nodes |
n/a |
5000 |
#Namespaces |
n/a |
10000 |
#Pods |
3000 |
150000 |
#Pods per node |
min(110, 10*#cores) |
min(110, 10*#cores) |
#Services |
5000 |
10000 |
#All service endpoints |
TBD |
TBD |
#Endpoints per service |
250 |
n/a |
#Secrets |
TBD |
TBD |
#ConfigMaps |
TBD |
TBD |
#Deployments |
2000 |
TBD |
#DaemonSets |
TBD |
TBD |
#Jobs |
TBD |
TBD |
#StatefulSets |
TBD |
TBD |
#AccessTokens |
2000 |
2000 |
#AccessTokens verifications |
5000 QPS |
5000 QPS |
Существуют также пороговые значения, которые зависят от окружения/поставщика облачных услуг. НЕ законченный список включает:
Quantity |
Threshold scope=namespace |
Threshold: scope=cluster |
---|---|---|
#Ingresses |
TBD |
TBD |
#PersistentVolumes |
n/a |
TBD |
#PersistentVolumeClaims |
TBD |
TBD |
#PersistentVolumeClaims per node |
TBD |
TBD |
amarao
Мне кажется, надо делать...
А, это перевод. Тогда кажется, не важно.