А вы когда-нибудь задумывались о границах масштабируемости 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).

Ниже описаны некоторые замечания к пороговым значениям, указанным в таблице ниже:

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

  2. Многие пороговые значения (в рамках кластера) даны для наибольшего возможного кластера. Для меньших кластеров лимиты пропорционально меньше. 

  3. Пороговые значения могут различаться (надеюсь, они не уменьшаются) в разных версиях Kubernetes. Те, что представлены ниже - даны для Kubernetes head.

    TODO: Мы планируем начать делать таблицу по версиям, но пока что такой нет. 

  4. Учитывая, что конфигурация влияет на лимиты, мы предполагаем, что используется стандартная версия 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

Комментарии (1)


  1. amarao
    23.02.2022 14:44

    Мне кажется, надо делать...

    А, это перевод. Тогда кажется, не важно.