А вы когда-нибудь задумывались о границах масштабируемости Kubernetes? Для тех, кого порой посещают такие мысли, мы решили опубликовать перевод заметки "Kubernetes Scalability thresholds", вам точно будет интересно ознакомиться.  В перевод заметки для наглядности мы добавили слайды презентации Kubernetes Scalability: A multi-dimensional analysis. На самом деле, ответ на вопрос о границах масштабируемости, или, о пороговых значениях Kubernetes совсем не прост, и эта мысль красной нитью следует через всю заметку, заставляя мозг скрипеть и скрежетать в нелегких размышлениях. Также в этом небольшом материале представлены достаточно интересные цифры о Kubernetes. Достичь таких показателей могут, конечно, далеко не многие компании. Кстати, если говорить о выдерживании компанией соглашения SLO в рамках проекта, то часто возникают казусные ситуации, при которых бизнес вопреки всему стремится максимально сократить издержки на инфраструктуру, и тем самым стремит показатель SLO в бесконечность, что приводит к регулярным нарушением SLA. Каких либо универсальных инструкций на этот счет нет, просто нужно рационально подходить к вопросу о масштабировании и пренебрегать конкретными SLO. Итак, поехали. Делитесь в комментариях, какие у вас мысли по этой непростой теме.  Как уже было описано в заметке “Как мы определяем масштабируемость”,  в среднестатистической ситуации предоставить какие-либо гарантии невозможно. Одно из условий выполнения SLO - это сохранение нагрузки в кластере в рамках рекомендуемых границ. Эта заметка - попытка более точно определить измерения и их границы. Границы масштабирования и пороговые значения - это весьма сложный вопрос. На деле конфигурации, которые 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 Управляющий партнер / CVO @ Nixys