Рекомендации по песочнице Pod

Для развертываний песочницы Pod в службе Azure Kubernetes (AKS) существует несколько элементов, которые следует рассмотреть в отношении управления ресурсами, управления памятью, управления ЦП и безопасности.

Управление ресурсами

Поведение управления памятью и ЦП при использовании sandboxing Pod может быть незнакомо некоторым пользователям. Эти соображения важны при указании ресурсов в развертывании, особенно для более крупных и чувствительных к ресурсам рабочих нагрузок.

Компоненты Kata

В развертывании Kata обычно развёртываются две группы компонентов. У вас есть компоненты узла и гостевые компоненты.

• Основные компоненты узла состоят из Kata Shim, Cloud Hypervisor и virtiofsd.
  • Kata shim управляет жизненным циклом виртуальной машины pod.
  • Облачный гипервизор — это монитор виртуальных машин (VMM), используемый оболочкой Kata.
  • virtiofsd — это управляющая программа, используемая для обмена файлами между каждой виртуальной машиной Pod и его узлом контейнера.
• Основные гостевые компоненты включают рабочие нагрузки пользователя, ядро виртуальной машины pod и агент Kata.
  • Агент Kata управляет контейнерами внутри виртуальных машин Pod

Управление памятью

С помощью модулей Pod Kata вы можете указать объем памяти виртуальной машины Pod, в которую размещаются рабочие нагрузки. Важно настроить значения соответствующим образом, чтобы pod было достаточно ресурсов и не выделялась неиспользуемая память.

Размер памяти виртуальной машины Pod

Существует объем памяти, выделенной для каждой виртуальной машины pod, которая запускает контейнер. Этот размер памяти виртуальной машины включает все памяти, необходимые для запуска гостевых компонентов Kata. Пользователи должны заботиться о том, чтобы они буферизули некоторую дополнительную память за пределы ожидаемого потребления рабочих нагрузок для учета использования других гостевых компонентов, таких как агент kata или ядро виртуальной машины. Примеры приведены на типичных значениях памяти позже в этой статье.

Размер памяти виртуальной машины pod эквивалентен ограничению памяти pod Kubernetes , указываемого пользователем. Пользователь может изменить значение, изменив ограничение памяти pod; Если значения не указаны, применяется размер по умолчанию 512Mi. После запуска pod этот размер становится фиксированным.

По мере увеличения размера памяти виртуальной машины pod объем памяти класса среды выполнения должен увеличиваться вместе с ним.

Затраты на память класса среды выполнения

Рабочие нагрузки песочниц Pod поставляются с используемым по умолчанию классом среды выполнения kata,kata-vm-isolation который имеет накладные расходы по умолчанию для ресурсов. Пользователи, которые хотят более точного контроля над квотами ресурсов, могут настроить пользовательский класс среды выполнения с определенными затратами на ресурсы. При этом пользователи должны убедиться, что значение накладных расходов на память класса среды выполнения достаточно, чтобы охватить все ожидаемое использование для компонентов узла развертывания kata. Затраты на память класса среды выполнения не должны учитывать ожидаемое потребление памяти гостевых компонентов.

Вы можете создать специализированную среду выполнения и указать затраты на память в классе среды выполнения с помощью overhead поля в манифесте RuntimeClass . В качестве примера предположим, что я хочу создать среду выполнения для рабочих нагрузок, которые я ожидаю, будет меньше в потреблении:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: small-kata-pods
handler: kata
overhead:
  podFixed:
    memory: "120Mi"

Указание накладных расходов не требуется и рекомендуется, если требуется более точное управление ресурсами, отложенными для рабочих нагрузок. Если вы используете класс среды выполнения kata-vm-isolation по умолчанию и не указываете никакие накладные расходы в YAML, то накладные расходы на размер виртуальной машины Pod по умолчанию равны 512Mi, а накладные расходы для класса среды выполнения равны 600Mi. Эта нагрузка на среду выполнения по умолчанию вычисляется с размером виртуальной машины pod по умолчанию (512Mi) и приблизительной памятью, необходимой для компонентов узла для такого размера виртуальной машины (~88Mi).

Рабочие нагрузки пользователей

Когда пользователь развертывает рабочую нагрузку Kata, он может использовать память до настроенного размера памяти виртуальной машины pod минус другие гостевые компоненты, такие как агент Kata или ядро гостевой виртуальной машины.

Если вы хотите получить приблизительное представление памяти, используемой этими компонентами:

1. Подключитесь к виртуальной машине (VM) pod через kubectl exec или kubectl debug, чтобы открыть оболочку внутри вашего pod.
2. Выполните команду free.
3. Проверьте столбец "использованный" в выходных данных, чтобы получить представление о памяти, потребляемой гостевым ядром или агентом ката.

Контрольные группы памяти

Когда модуль Kata запланирован на запуск, kubelet назначает модуль памяти cgroup. Это cgroup применяет ограничения и запросы на использование памяти для пода, позволяя пользователю определять квоты ресурсов, доступные для пода.

В памяти cgroupследует учитывать два важных поля:

• memory.current определяет, сколько байтов памяти выделяет компоненты узла и размер памяти виртуальной машины pod.
• memory.max необязательный, определяемый пользователем верхний предел памяти.current для модулей pod, в которых пользователи хотят наложить ограничение памяти.
  • Kubelet вычисляет это значение в виде суммы ограничения памяти pod и ее нагрузки на память класса среды выполнения.

В любой момент, если значение memory.current превышает значение memory.max, ядро может активировать OOMKill на поде, если обнаружено давление памяти.

Справочные значения использования

Пользователи могут использовать эти значения, чтобы служить ссылкой для типичного использования памяти и значений в различных переменных, описанных. Размеры памяти виртуальной машины Pod менее 128Mi не поддерживаются.

Управление ЦП

Аналогично памяти можно также выделить ресурсы ЦП для рабочих нагрузок Kata. Это рекомендуется; без объявления ограничения ЦП для модуля Kata pod компоненты узла Kata могут использовать любую емкость ЦП, доступную на узле.

Резервирование ЦП

При резервировании ЦП для рабочих нагрузок Kata, вы можете задать два поля.

• Затраты на ЦП класса среды выполнения
• Ограничение на использование процессора для pod

Если указан хотя бы один из двух значений, плоскость управления резервирует указанное количество ЦП на узле для рабочей нагрузки. Другие pod на том же узле не могут получить доступ к этой зарезервированной емкости.

Ограничение ЦП pod

Вы можете указать ограничение pod по ЦП в манифесте приложения. Указанное ограничение ЦП pod определяет ограничение ЦП, которые контейнеры в связанной виртуальной машине pod могут использовать.

Если вы указываете доли CPU для лимита CPU pod, указанные дроби будут округлены до следующего целого числа. Округленное число становится числом виртуальных ЦП, выделенных виртуальной машине Pod, но cgroup ограничит рабочую нагрузку, позволяя использовать только ту часть, которая указана в ограничении CPU Pod.

Если число не объявлено, один виртуальный ЦП будет выделен виртуальной машине pod, если емкость доступна на узле. Нет ограничений на потребление ЦП компонентов узла Kata.

Затраты на ЦП класса среды выполнения

Затраты на класс среды выполнения следует указать, если вы хотите заранее зарезервировать некоторую емкость узла для компонентов узла Kata.

Вы можете указать расходы на память в классе среды выполнения с помощью overhead поля в манифесте RunTimeClass . В качестве примера:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: custom-kata-runtime
handler: kata
overhead:
  podFixed:
    cpu: "250m"

Лучшие практики

Управление памятью

• Убедитесь, что вы указываете размеры памяти виртуальной машины pod (определенные limits.memory в манифесте) и подходящие квоты ресурсов для всех развертываний.
  • Убедитесь, что вы используете ненулевой запрос pod , если вы хотите убедиться, что для виртуальной машины pod будет зарезервирована некоторая емкость узла перед запуском этой виртуальной машины. Запрос должен учитывать виртуальную машину pod и её контейнеры, которые должны запускаться на ней.
  • Убедитесь, что вы используете ненулевой накладной расход класса времени выполнения, если хотите зарезервировать некоторую емкость ноды для компонентов хоста Kata перед запуском этих компонентов.
• Если вы ожидаете, что нагрузки pod будут особенно требовательными к ресурсам, можно указать ограничения, соответствующие виртуальным машинам, где размещен pod, чтобы обеспечить наличие достаточного объема ресурсов для ваших нагрузок.
• Объявите подходящую нагрузку на память класса среды выполнения, чтобы она предоставляла достаточно памяти для компонентов узла, но не занимает слишком много времени, чтобы избежать выделения неиспользуемой памяти.

Управление ЦП

• Если узел обычно имеет много свободной емкости ЦП, эти резервирования могут быть ненужными.

• Если ваши узлы обычно работают на пределе потребления ЦП, то резервирование ненулевого уровня гарантирует возможность более надежного выполнения подов.

  • Вы можете использовать запросы ЦП pod, чтобы гарантировать, что некоторые ресурсы узла ЦП зарезервированы для компонентов узла Kata. Зарезервированная емкость для определенной рабочей нагрузки недоступна для других рабочих нагрузок на узле.

• Убедитесь, что вы указали запросы ЦП, которые может разместить ваша инфраструктура. Если доступная емкость близка к 0 или запрос слишком велик, рабочие нагрузки могут не запускаться

• Выровняйте запросы ЦП с ограничениями ЦП. Ката схим не имеет доступа к запросам. Таким образом, если ограничение ЦП не объявлено, виртуальная машина pod ограничена одним виртуальным ЦП. Компоненты узла Kata, которые имеют видимость значений запросов, потребляют остальную часть запрошенного количества ЦП и не ограничивают потребление ЦП.

• Зарезервированная емкость для определенной рабочей нагрузки недоступна для других рабочих нагрузок на узле.

Примеры объявлений

Безопасность

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

Привилегированные модули pod

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

Использование привилегированных контейнеров приводит к корневому доступу на гостевой виртуальной машине, но остается изолированным от узла.

Привилегированные модули pod, даже в песочнице Pod, должны использоваться только при необходимости. Привилегированные pod должны продолжать управляться доверенными пользователями.

Хранилище томов по локальным путям хоста

hostPath Тома можно подключить к модулям Pod Kata. В песочнице Pod использование hostPath томов может потенциально подорвать изоляцию, которую обеспечивает Kata; поскольку часть файловой системы хоста открывается непосредственно контейнеру, создается потенциальный вектор атаки. Предупреждения, поступающие от предыдущих этапов, также следует рассматривать как относящиеся к песочнице Pod.

Существуют некоторые исключения; файлы под /dev подключаются к контейнеру из гостевой системы, а не из хост-системы. Это помогает поддерживать изоляцию пода в ситуациях, когда этот путь должен быть смонтирован для работы.

Блокировка hostPath с помощью политики Azure

Политика Azure позволяет пользователям применять масштабные принудительные меры и меры защиты для компонентов кластера централизованно и согласованно.

Существует набор встроенных политик для AKS, которые обеспечивают соблюдение наилучших практик. Пользователи могут воспользоваться одним из этих политик, чтобы заблокировать развертывания, которые пытаются подключить hostPaths.

Дальнейшие шаги

Когда вы будете готовы, узнайте, как развернуть песочницу pod в AKS.