Когда Kubernetes уже не при чём: три расследования масштабируемости в облаке

Managed Kubernetes проходит выбранный профиль scalability-тестов на тысячах нод — и всё равно начинает деградировать на существенно меньшем масштабе. Причина зачастую оказывается не в самом Kubernetes, а в компонентах вокруг него: распределённом хранилище, сетевом dataplane, cloud-controller-manager или облачном API. Kubernetes продолжает работать корректно, но реальные пределы масштабирования определяются уже всей цепочкой инфраструктуры.

В докладе я разберу три реальных production-расследования, возникших при тестировании масштабируемости Managed Kubernetes. На примере etcd покажу, почему benchmark, демонстрирующий около 27 000 PUT RPS, в реальном сценарии с watch-нагрузкой превращается в 3000–6000 RPS, и почему результаты подобных тестов нельзя переносить между стендами без учёта характеристик сети и дисковой подсистемы. Затем расскажу, как при масштабировании кластера до 2 000–3 000 узлов ограничением оказался dataplane Cilium, а не Kubernetes. В завершение разберу массовое создание LoadBalancer-сервисов, где уже при 300–400 сервисах начали проявляться проблемы со сходимостью, а при 500–600 время полной реконсиляции превысило час, несмотря на то что Kubernetes продолжал быстро принимать изменения.

Все три расследования объединяет одна идея: в облаке масштабируется не только Kubernetes, а вся цепочка — от control plane до сетевого dataplane, cloud-controller-manager и облачного API. На реальных метриках и результатах расследований я покажу, как отличить проблему Kubernetes от ограничений окружающей инфраструктуры, где искать настоящие узкие места и какие признаки позволяют быстро определить компонент, который первым перестаёт выдерживать рост нагрузки.

Доклад будет полезен platform-инженерам, SRE и инженерам, эксплуатирующим или разрабатывающим Managed Kubernetes, а также всем, кто проводит или планирует проводить scalability-тестирование кластеров от сотен до тысяч узлов.