Переезд на bare-metal не отменяет талон на процессор. Разберём типовой отказ K3s: средняя загрузка узла невысока, а p99 API вылетает за SLO во время всплесков. Поверхностный диагноз — «виртуализация тормозит, нужна своя машина». Но свободный CPU узла ещё не означает, что контейнеру разрешено его использовать. На cgroup v2 проверяем конкретный контейнер: kubectl exec -n prod api-0 -- cat /sys/fs/cgroup/cpu.max и kubectl exec -n prod api-0 -- cat /sys/fs/cgroup/cpu.stat. Здесь prod и api-0 — пример namespace и pod. Значение cpu.max «100000 100000» задаёт квоту в одно ядро; несколько потоков могут потратить её раньше конца периода. Снимаем дельты nr_periods, nr_throttled и throttled_usec на интервале деградации. Доля периодов с throttling — не процент потерянной производительности. Причинность проверяем повтором нагрузки с увеличенным CPU limit и сравнением p99. Если после изменения квоты хвост задержек сжался при прежней нагрузке, покупка железа лечила бы неверный диагноз. Но снимать limits всем подряд — способ передать аварию соседним сервисам. Requests, доступная ёмкость и запас на потерю узла должны соответствовать нагрузке. K3s облегчает дистрибутив Kubernetes, а не отменяет планировщик Linux. Реальная юнит-экономика — полная стоимость за период, делённая на число успешных запросов в пределах SLO. Для bare-metal считаем амортизацию, размещение, сеть, запасные детали и дежурства; для облака — вычисления, диски, балансировщики, трафик и эксплуатацию. Сравниваем при одинаковых данных, профиле нагрузки и требованиях к отказоустойчивости. Облачный счёт не доказывает надёжность, собственный сервер не гарантирует latency. Практика эксплуатации: https://ftops.space/?utm_source=telegram&utm_medium=smm&utm_campaign=ftops&utm_content=bare-metal-k3s-vs-hyperscalers-real.
