Управление ресурсами в Kubernetes немного напоминает зефирный тест, который иногда выходит из-под контроля. Если тщательно не лимитировать, сколько ресурсов может потреблять контейнер, он пойдёт вразнос, примерно как малыш, способный слопать большую пачку Skittles за один присест.

С другой стороны, если вы постоянно лишаете контейнер минимального объёма ресурсов, который нужен ему для корректной работы, то словно постоянно не подпускаете ваших детей к сладостям. Контейнер будет влачить жалкое существование и работать вполсилы.

Вот почему настолько важно правильно настроить в Kubernetes лимиты и работу с запросами. Понимая, какова роль запросов и лимитов при управлении ресурсами и производительностью в Kubernetes, а также умея настраивать и/или задавать запросы и лимиты, вы гарантируете, что на обработку каждой рабочей нагрузки будет выделено ровно столько ресурсов, сколько нужно — ни больше, ни меньше.

Далее в этой статье подробно рассказано, как в Kubernetes организована работа с запросами и лимитами, как они используются для управления ресурсами. В любой организации чрезвычайно важно управление ресурсами в Kubernetes и роль такого управления. Разберём управление ресурсами в Kubernetes и начнём с самых азов.

Программистам требуется судить о том, насколько дорого обходится тестирование конкретной системы, будь то модульное, интеграционное или функциональное тестирование. Каждый последующий из этих этапов в некотором смысле «дороже», чем предыдущий.

Как именно вы спроектировали бы оптимизирующий компилятор? Точнее, как именно вы спроектировали и реализовали бы конкретные оптимизации? Попытка решить эту задачу за один присест — дело ошеломительно сложное и, пожалуй, даже невозможное, так как оптимизации компилятора во многом заключаются в следующем...

В тех инженерных организациях, где применяются инструменты для программирования инфраструктуры (IaC), например, Terraform, они обычно используются вполсилы. В этой статье разобрано не менее трёх вариантов использования Terraform и автоматизации в духе IaC, которые не связаны напрямую с традиционной инфраструктурой, отвечающей за управление рабочей нагрузкой приложений.

Мы заметили, что через работу многих команд, занятых администрированием платформ красной нитью проходит явная пробуксовка с освоением философии «as code». Естественно, там используются OpenTofu или Terraform (здесь и далее я буду называть их в совокупности “TF”) для управления вычислительными и прочими облачными ресурсами, но при этом команда обычно не переходит к применению тех же принципов во всех аспектах, связанных с эксплуатацией предметной области.

Что касается абсолютного большинства устройств, поддерживаемых в ядре Linux, от вас не требуется почти никакого вмешательства, чтобы пустить их в работу. Пожалуй, устройство потребуется включить (например, при помощи регулятора), отменить команду сброса или обратиться к нескольким конфигурационным регистрам. Но среди устройств есть и достаточно сложные; чтобы в полной мере использовать имеющиеся в них функции или добавлять собственные, для таких устройств требуется специализированная прошивка. Некоторые подобные устройства изначально рассчитаны на подключение заранее запрограммированной персистентной памяти, но в других предусматривается механизм, получающий им подтягивать прошивку из какого-либо приложения. Есть даже такие устройства, в которых одновременно предоставляются обе эти возможности.

❯ Кэши для отдельных ядер процессора