Что такое лимиты и запросы ресурсов в Kubernetes
Что проверяют
Понимаете ли вы, что запросы это про планирование, а лимиты про принуждение, и что для сервиса на Go эти числа меняют поведение рантайма. Вопрос на стыке разработки и эксплуатации, и от разработчика ждут не команд, а последствий.
Как отвечать
Запросы (requests) это то, что планировщик резервирует на узле: под поедет туда, где сумма запросов помещается в ёмкость. Фактическое потребление планировщика не интересует, он считает по заявленным числам.
Лимиты (limits) это потолок во время работы, и два ресурса ведут себя по-разному. Процессор измеряется в долях ядра (100m это десятая часть) и поддаётся сжатию: превышение лимита не убивает контейнер, а тормозит его, растёт задержка. Память несжимаема: превышение лимита это OOMKilled и перезапуск по политике, а при нехватке памяти на узле kubelet вытесняет поды, начиная с тех, кто просил меньше всех.
Отсюда классы качества обслуживания: Guaranteed, когда лимиты равны запросам по обоим ресурсам, Burstable, когда задано что-то одно или значения различаются, BestEffort, когда не задано ничего. Класс определяет очередь на вытеснение.
Для Go есть отдельный слой, его и ждут от вас. Рантайм берёт GOMAXPROCS из числа ядер узла, а не из лимита контейнера: на большом узле сервис под лимитом в половину ядра разворачивает десятки исполнителей и получает рваные задержки. Лечится установкой значения по лимиту, руками или библиотекой. Сборщик мусора тоже не знает про лимит памяти, пока не задан GOMEMLIMIT, и пик выделений уносит контейнер в перезапуск.
Где спотыкаются
Ставят лимит процессора вплотную к запросу ради честности и получают торможение на коротких всплесках. Для памяти равенство запроса и лимита оправдано, для процессора лимит чаще вредит, чем помогает.
Подбирают числа на глаз. Нужны перцентили реального потребления за период: завышенный запрос это оплаченный и пустующий узел, заниженный это вытеснение в самый нагруженный час.
Разбирают перезапуск и не смотрят причину. Код завершения 137 и пометка про нехватку памяти в описании пода говорят о лимите, а не о баге; контейнер часто убит не утечкой, а числом, подобранным по потреблению в покое.