Еще в 2016 году мы в Buffer
перешли на Kubernetes, и сейчас около 60 нод (на AWS) и 1500 контейнеров трудятся на нашем k8s-кластере под управлением
kops. Тем не менее, на микросервисы мы переходили методом проб и ошибок, и даже после нескольких лет нашей работы с k8s мы до сих пор сталкиваемся с новыми для себя проблемами. В этом посте мы поговорим про
процессорные ограничения: почему мы считали их хорошей практикой и почему в итоге они оказались не столь хороши.
Процессорные ограничения и троттлинг
Как и многие другие пользователи Kubernetes,
Google очень рекомендует настраивать процессорные ограничения. Без такой настройки контейнеры в ноде могут занять все мощности процессора, из-за чего, в свою очередь, важные Kubernetes-процессы (например
kubelet
) перестанут реагировать на запросы. Таким образом, настройка процессорных ограничений это хороший способ защиты ваших нод.
Процессорные ограничения задают контейнеру максимальное процессорное время, которым он может воспользоваться за конкретный период (по умолчанию 100мс), и контейнер никогда не перешагнет этот предел. В Kubernetes для
троттлинга контейнера и недопущения превышения им предела используется особый инструмент
CFS Quota, однако в итоге такие искусственные процессорные ограничения занижают производительность и увеличивают время отклика ваших контейнеров.