В основе построения высокопроизводительного и экономичного кластера Kubernetes лежит искусство эффективного управления ресурсами путем адаптации рабочих нагрузок Kubernetes.
Оптимизация использования ресурсов является всеобщим стремлением, но достичь его значительно сложнее, чем можно выразить простыми словами. Этот процесс требует тщательного тестирования производительности, точной настройки сервера и многочисленных корректировок характеристик ресурсов. Разработчики компании DST Global считают что эти проблемы сохраняются и действительно становятся более тонкими в средах Kubernetes, чем в традиционных системах. В основе построения высокопроизводительного и экономичного кластера Kubernetes лежит искусство эффективного управления ресурсами путем адаптации рабочих нагрузок Kubernetes.
Вникая в тонкости Kubernetes, важно понимать различные компоненты, которые взаимодействуют при развертывании приложений в кластерах k8s.
Прежде чем мы продолжим, крайне важно ознакомиться с терминологией, которая будет преобладать в этой статье. Этот основополагающий раздел предназначен для того, чтобы снабдить читателя необходимыми знаниями для дальнейшего детального изучения.
Понимание основ
- Pod: Pod представляет собой наименьшую развертываемую единицу, которую можно создать и которой можно управлять в Kubernetes, состоящую из одного или нескольких контейнеров, которые совместно используют хранилище, сеть и сведения о том, как запускать контейнеры.
- Реплики. Реплики в Kubernetes — это несколько экземпляров пода, поддерживаемые контроллером для обеспечения избыточности и масштабируемости, чтобы гарантировать, что желаемое состояние соответствует наблюдаемому состоянию.
- Развертывание. Развертывание в Kubernetes — это абстракция более высокого уровня, которая управляет жизненным циклом модулей Pod и гарантирует, что определенное количество реплик работает и обновляется.
- Узлы. Узлы — это физические или виртуальные машины, составляющие кластер Kubernetes, каждая из которых отвечает за запуск модулей или рабочих нагрузок и предоставление им необходимых серверных ресурсов.
- Планировщик Kube. Планировщик Kube — это важнейший компонент Kubernetes, который выбирает наиболее подходящий узел для запуска пода на основе доступности ресурсов и других критериев планирования.
- Kubelet: Kubelet запускается на каждом узле кластера Kubernetes и гарантирует, что контейнеры работают в поде, как указано в файле манифеста пода. Он также управляет жизненным циклом контейнеров, контролирует их работоспособность и обрабатывает инструкции по запуску и остановке контейнеров, направляемые плоскостью управления.
Понимание управления ресурсами Kubernetes
В Kubernetes во время развертывания модуля вы можете указать необходимый процессор и память — решение, которое влияет на производительность и стабильность ваших приложений. Планировщик kube использует заданные вами запросы ресурсов, чтобы определить оптимальный узел для вашего модуля. В то же время kubelet обеспечивает соблюдение ограничений ресурсов, гарантируя, что контейнеры работают в пределах выделенной им доли.
- Запросы ресурсов. Запросы ресурсов гарантируют, что контейнеру будет доступен минимальный объем процессора или памяти. Планировщик kube рассматривает эти запросы, чтобы убедиться, что узел имеет достаточные ресурсы для размещения модуля, стремясь к равномерному распределению рабочих нагрузок.
- Ограничения ресурсов. С другой стороны, ограничения ресурсов служат защитой от чрезмерного использования. Если контейнер превышает эти ограничения, он может столкнуться с такими ограничениями, как регулирование ЦП или, в случае с памятью, завершение работы, чтобы предотвратить нехватку ресурсов на узле.
apiVersion: apps/v1
kind: Deployment
metadata:
name: example-deployment
spec:
replicas: 2
selector:
matchLabels:
app: example
template:
metadata:
labels:
app: example
spec:
containers:
- name: example-container
image: nginx:1.17
ports:
- containerPort: 80
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
Давайте разберем эти понятия на двух показательных случаях:
Случай 1 (ограничения не указаны)
Представьте себе модуль с запросом памяти 64 МБ и запросом ЦП 250 М на узле с достаточными ресурсами — 4 ГБ памяти и 4 ЦП. Этот модуль может использовать больше ресурсов, чем запрошено, без определенных ограничений, заимствуя излишки узла. Однако эта свобода имеет потенциальные побочные эффекты; это может повлиять на доступность ресурсов для других модулей и, в крайних случаях, привести к тому, что системные компоненты, такие как kubelet, перестанут отвечать на запросы.
Случай 2 (с определенными запросами и ограничениями)
В другом сценарии под с запросом памяти 64 МБ и лимитом 128 МБ вместе с запросом ЦП 250 МБ и лимитом 500 МБ оказывается на одном и том же богатом ресурсами узле. Kubernetes зарезервирует запрошенные ресурсы для этого модуля, но строго соблюдает установленные ограничения. Превышение этих ограничений в случае с памятью может привести к перезапуску или завершению работы контейнера kubelet или регулированию использования его ЦП, если ЦП поддерживает гармоничный баланс на узле.
Палка о двух концах ограничений процессора
Ограничения ЦП предназначены для защиты узла от чрезмерной загрузки, но могут принести неоднозначную пользу. Они могут вызвать регулирование ЦП, что повлияет на производительность контейнера и время отклика. Это наблюдалось в Buffer , где контейнеры подвергались регулированию, даже если загрузка ЦП была ниже определенных пределов. Чтобы решить эту проблему, они изолировали службы «Без ограничений ЦП» на определенных узлах и точно настроили их запросы к ЦП и памяти посредством бдительного мониторинга. Хотя эта стратегия снизила плотность контейнеров, она также улучшила задержку обслуживания и производительность — деликатный компромисс в поисках оптимального использования ресурсов.
Понимание масштабирования Kubernetes
Теперь, когда мы рассмотрели критически важную роль запросов и ограничений при развертывании рабочей нагрузки, давайте изучим их влияние на автоматическое масштабирование Kubernetes. Kubernetes предлагает два основных метода масштабирования: один для реплик модулей, а другой для узлов кластера, оба из которых имеют решающее значение для максимального использования ресурсов, экономической эффективности и производительности.
Horizontal Pod Autoscaling (HPA)
Горизонтальное автомасштабирование модулей (HPA) в Kubernetes динамически регулирует количество реплик модулей в развертывании или наборе реплик на основе наблюдаемого использования ЦП, использования памяти или других заданных показателей. Это механизм, предназначенный для автоматического масштабирования количества модулей по горизонтали (не путать с вертикальным масштабированием), которое увеличивает ресурсы существующих модулей. HPA работает в пределах определенных минимальных и максимальных параметров реплики и полагается на метрики, предоставляемые сервером метрик кластера, для принятия решений о масштабировании. Очень важно указать запросы ресурсов для ЦП и памяти в спецификациях вашего модуля, поскольку они информируют HPA о понимании использования ресурсов каждого модуля и определяют его действия по масштабированию. HPA через регулярные промежутки времени оценивает использование ресурсов, увеличивая или уменьшая количество реплик для эффективного достижения желаемых целевых показателей. Этот процесс гарантирует, что ваше приложение сохранит производительность и доступность, даже если требования к рабочей нагрузке колеблются.
В приведенном ниже примере автоматически корректируется количество реплик модулей в диапазоне от 1 до 10 в зависимости от загрузки ЦП, стремясь поддерживать среднюю загрузку ЦП на уровне 50 % для всех модулей.
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: example-hpa
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: example-deployment
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
Кластерное автомасштабирование
Cluster Autoscaler может автоматически регулировать размер узлов кластера, чтобы у всех модулей было место для запуска и не было ненужных узлов. Он работает путем увеличения количества узлов во время высокого спроса, когда модули не запускаются из-за нехватки ресурсов, и уменьшает количество, когда узлы используются недостаточно. Автомасштабирование оценивает необходимость масштабирования узлов на основе запросов ресурсов модулей — модули, которые невозможно запланировать из-за нехватки ресурсов, заставят автомасштабирование добавить узлы. Напротив, узлы, которые использовались недостаточно в течение определенного периода времени и имеют модули, которые можно удобно переместить на другие узлы, будут рассматриваться для удаления. Это обеспечивает экономичную и оптимизированную по производительности работу кластера.
Заключение
Оптимизация — это не разовое мероприятие, а непрерывный процесс. Тщательное нагрузочное тестирование необходимо для понимания того, как приложение работает при различных уровнях спроса. Использование инструментов наблюдения, таких как NewRelic, Dynatrace или Grafana, может выявить закономерности потребления ресурсов. Возьмите среднее значение использования ресурсов из нескольких нагрузочных тестов и рассмотрите возможность добавления буфера 10–15 % для компенсации неожиданных пиков, корректируя его по мере необходимости в соответствии с потребностями вашего конкретного приложения. После того как вы определите базовые потребности в ресурсах, разверните рабочие нагрузки с соответствующим образом настроенными запросами и ограничениями ресурсов. Постоянный мониторинг имеет первостепенное значение для обеспечения эффективного использования ресурсов. Настройте комплексные системы оповещения, чтобы уведомлять вас о недостаточном использовании и потенциальных проблемах с производительностью, таких как регулирование. Такая бдительность гарантирует, что ваши рабочие нагрузки не просто выполняются, а работают оптимально. Разработчики DST Global советуют - организуйте свою инфраструктуру, создавая отдельные группы узлов, адаптированные для разных типов приложений, например тех, которые требуют графических процессоров или большого объема памяти. В облачных средах разумное использование спотовых инстансов может привести к существенной экономии средств. Однако всегда отдавайте приоритет некритическим приложениям для этих экземпляров, чтобы обеспечить непрерывность бизнеса, если поставщику облачных услуг потребуется вернуть ресурсы.
