IKuznetsov в 18:33, 24 ноября 2025

2025-11-24T18:33:52Z

← Предыдущая версия		Версия от 18:33, 24 ноября 2025
Строка 232:		Строка 232:
	containers:		containers:

	- name: ~~dynatrace~~-operator		- name: astromkey-operator

	resources:		resources:

IKuznetsov: Новая страница: «Правильно настроенные ограничения ресурсов обеспечивают оптимальную производительнос...»

2025-11-24T18:33:34Z

Новая страница: «Правильно настроенные ограничения ресурсов обеспечивают оптимальную производительнос...»

Новая страница

Правильно настроенные ограничения ресурсов обеспечивают оптимальную производительность и стабильность компонентов Ключ-АСТРОМ '''Operator''', предотвращая при этом конфликт ресурсов в кластере '''Kubernetes'''. Это руководство поможет вам понять, как установить правильные ограничения ресурсов в зависимости от размера вашей среды и особенностей использования.

== Базовый уровень ограничений ресурсов по умолчанию ==
Предусмотренные по умолчанию ограничения ресурсов были проверены в ходе тестирования производительности. Эти значения хорошо зарекомендовали себя в следующих условиях:

* 25 нодов (тип узла e2-standard-32 на Google Kubernetes Engine)
* 20 DynaKubes
* 2500 пространств имен
* 5000 подов

== Факторы потребления ресурсов ==
Следующие пять ключевых показателей влияют на потребление ресурсов различными компонентами Ключ-АСТРОМ '''Operator''':
{| class="wikitable"
!Индикатор
!Ключ-АСТРОМ Operator
!Webhook
!CSI driver
|-
|Пространства имен
| +
| +
|
|-
|Ноды
| +
|
|
|-
|DynaKubes
| +
|
| +
|-
|Поды
|
| +
| +
|-
|Количество версий ЕдиногоАгента
|
|
| +
|}

=== Описание показателей воздействия ===

* '''Пространства имен''' : большее количество пространств имен увеличивает нагрузку на оператора и веб-перехватчик, поскольку им необходимо отслеживать и управлять ресурсами во всех пространствах имен.
** Влияние:
*** Увеличивает использование ЦП/памяти оператора
*** Увеличивает загрузку ЦП вебхука
* '''Ноды''' : Дополнительные ноды требуют больше ресурсов, поскольку оператор ведет список всех доступных нод в кластерах Kubernetes и проверяет их соответствие доступным хостам на сервере Ключ-АСТРОМ.
** Влияние:
*** Увеличивает использование ЦП/памяти оператора
* '''DynaKubes''' : каждый ресурс DynaKube представляет собой отдельное развертывание Ключ-АСТРОМ, требующее индивидуального управления.
** Влияние:
*** Увеличивает использование ЦП/памяти оператора
*** Увеличивает использование ЦП/памяти веб-перехватчиком
*** Увеличивает использование ЦП/памяти драйвером CSI
* '''Поды''' : веб-перехватчик обрабатывает запросы на допуск для каждого пода, в то время как драйвер CSI управляет монтированием тома для подов с помощью ЕдиногоАгента.
** Влияние:
*** Увеличивает использование ЦП/памяти сервера драйверов CSI/пробы активности/регистратора
* '''Версии ЕдиногоАгента''' : Драйвер CSI должен управлять различными версиями ЕдиногоАгента и предоставлять к ним доступ, что требует дополнительных ресурсов хранения и обработки.
** Влияние:
*** Увеличивает использование ЦП/памяти драйвером CSI

=== Минимизировать влияние большого количества узлов ===
По умолчанию Ключ-АСТРОМ '''Operator''' отслеживает доступность хостов в кластере, чтобы обнаружить ожидаемое удаление модулей ЕдиногоАгента, особенно в сценариях масштабирования. Этот мониторинг не требуется в бессерверных средах.

==== Когда следует отключать обнаружение доступности хоста ====
{| class="wikitable"
|Данная функциональность присутствует во всех версиях Operator до 1.6.0 и не может быть отключена.

Его можно отключить в версиях 1.6.3 и 1.7.3 или в более новых версиях Operator.
|}
<code>applicationMonitoring</code>

Вы можете сократить потребление ресурсов оператором, отключив определение доступности хоста, если ваш '''DynaKubes''':

* <u>использовать только</u> режимы мониторинга приложений и
* <u>не использовать</u> какие-либо функции мониторинга на базе хоста.

==== Как отключить определение доступности хоста ====
Чтобы отключить определение доступности хоста, задайте следующее значение '''Helm''':
{| class="wikitable"
|operator:

hostAvailabilityDetection: false
|}
Такая оптимизация может снизить использование ЦП и памяти оператора, особенно в больших кластерах с большим количеством нодов.
{| class="wikitable"
|Настройка на уровне кластера : <code>operator.hostAvailabilityDetection</code> влияет на все объекты DynaKube, управляемые оператором. Отключайте эту настройку только в том случае, если вы уверены, что ни один из ваших объектов DynaKube не требует мониторинга на уровне хоста. Отключение этой настройки, когда требуются ЕдиныеАгенты на хосте, может привести к ложным срабатываниям предупреждений об отсутствии хоста при масштабировании нодов или других операциях, связанных с нодами.
|}

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

=== Helm ===

* '''Ключ-АСТРОМ Operator'''

{| class="wikitable"
|operator:

requests:

cpu: 50m

memory: 64Mi

limits:

cpu: 100m

memory: 128Mi
|}

* '''WebHook'''

{| class="wikitable"
|webhook:

requests:

cpu: 300m

memory: 128Mi

limits:

cpu: 300m

memory: 128Mi
|}

* '''CSI driver'''

{| class="wikitable"
|csidriver:

csiInit:

resources:

requests:

cpu: 50m

memory: 100Mi

limits:

cpu: 50m

memory: 100Mi

server:

resources:

requests:

cpu: 50m

memory: 100Mi

limits:

cpu: 50m

memory: 100Mi

provisioner:

resources:

requests:

cpu: 300m

memory: 100Mi

limits:

cpu: 300m

memory: 100Mi

registrar:

resources:

requests:

cpu: 20m

memory: 30Mi

limits:

cpu: 20m

memory: 30Mi

livenessprobe:

resources:

requests:

cpu: 20m

memory: 30Mi

limits:

cpu: 20m

memory: 30Mi
|}

==== YAML ====

* '''Ключ-АСТРОМ Operator'''

{| class="wikitable"
|spec:

template:

spec:

containers:

- name: dynatrace-operator

resources:

requests:

cpu: 50m

memory: 64Mi

limits:

cpu: 100m

memory: 128Mi
|}

* '''WebHook'''

{| class="wikitable"
|spec:

template:

spec:

containers:

- name: webhook

resources:

requests:

cpu: 300m

memory: 128Mi

limits:

cpu: 300m

memory: 128Mi
|}

* '''CSI driver'''
** <code>csi-init</code>

{| class="wikitable"
|spec:

template:

spec:

initContainers:

- name: csi-init

resources:

requests:

cpu: 50m

memory: 100Mi

limits:

cpu: 50m

memory: 100Mi
|}

** <code>server</code>

{| class="wikitable"
|spec:

template:

spec:

containers:

- name: server

resources:

limits:

cpu: 50m

memory: 100Mi

requests:

cpu: 50m

memory: 100Mi
|}

** <code>provisioner</code>

{| class="wikitable"
|spec:

template:

spec:

containers:

- name: provisioner

resources:

limits:

cpu: 300m

memory: 100Mi

requests:

cpu: 300m

memory: 100Mi
|}

** <code>registrar</code>

{| class="wikitable"
|spec:

template:

spec:

containers:

- name: registrar

resources:

limits:

cpu: 20m

memory: 30Mi

requests:

cpu: 20m

memory: 30Mi
|}

** <code>liveness-probe</code>

{| class="wikitable"
|spec:

template:

spec:

containers:

- name: liveness-probe

resources:

limits:

cpu: 20m

memory: 30Mi

requests:

cpu: 20m

memory: 30Mi
|}

=== Масштабирование ограничений ресурсов для различных сред ===
Запросы/ограничения ресурсов по умолчанию рассчитаны на среды среднего масштаба. Для корректировки ограничений в зависимости от размера среды следуйте следующим рекомендациям:
{| class="wikitable"
|Это лишь начальные рекомендации. Всегда отслеживайте фактическое использование ресурсов в вашей среде и корректируйте его соответствующим образом.
|}
{| class="wikitable"
|'''Классы качества обслуживания Pod''' : для некоторых компонентов лимиты и запросы установлены на одинаковые значения, чтобы обеспечить ''[https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/#guaranteed гарантированное качество обслуживания Pod]''. При масштабировании лимитов таких компонентов всегда масштабируйте запросы пропорционально.

'''Пропорциональное распределение ресурсов''' : Низкое количество запросов к ЦП в контейнере может привести к троттлингу из-за политики управления ЦП нода. Запросы служат минимальной гарантией. Таким образом, на высоконагруженном узле контейнеры с меньшими запросами будут подверженны троттлингу сильнее, чем контейнеры с большими запросами, независимо от их лимита. При масштабировании лимитов всегда учитывайте и масштабирование запросов
|}

==== Большие среды (> 50 nodes, > 10,000 pods) ====
Увеличьте запросы/лимиты по умолчанию на 50–100%:

* '''Ключ-АСТРОМ Operator:'''
** Request: CPU 100m, Memory 128Mi
** Limits: CPU 200m, Memory 256Mi
* '''Webhook''':
** Requests: CPU 600m, Memory 256Mi
** Limits: CPU 600m, Memory 256Mi
* '''CSI driver provisioner:'''
** Requests: CPU 600m, Memory 200Mi
** Limits: CPU 600m, Memory 200Mi
* '''CSI driver server:'''
** Requests: CPU 100m, Memory 200Mi
** Limits: CPU 100m, Memory 200Mi
* '''CSI driver liveness-probe:'''
** Requests: CPU 30m, Memory 50Mi
** Limits: CPU 30m, Memory 50Mi
* '''CSI driver registrar:'''
** Requests: CPU 30m, Memory 50Mi
** Limits: CPU 30m, Memory 50Mi

==== Корпоративные среды (> 100 nodes, > 25,000 pods) ====
Увеличьте запросы/лимиты по умолчанию на 100–200%:

* '''Ключ-АСТРОМ Operator''': CPU 400m, Memory 512Mi
** Request: CPU 200m, Memory 256Mi
** Limits: CPU 400m, Memory 512Mi
* '''Webhook''':
** Requests: CPU 1000m, Memory 512Mi
** Limits: CPU 1000m, Memory 512Mi
* '''CSI driver provisioner''':
** Requests: CPU 900m, Memory 300Mi
** Limits: CPU 900m, Memory 300Mi
* '''CSI driver server:'''
** Requests: CPU 150m, Memory 300Mi
** Limits: CPU 150m, Memory 300Mi
* '''CSI driver liveness-probe:'''
** Requests: CPU 50m, Memory 70Mi
** Limits: CPU 50m, Memory 70Mi
* '''CSI driver registrar:'''
** Requests: CPU 50m, Memory 70Mi
** Limits: CPU 50m, Memory 70Mi

Ограничения ресурсов Ключ-АСТРОМ Operator - История изменений

IKuznetsov в 18:33, 24 ноября 2025

IKuznetsov: Новая страница: «Правильно настроенные ограничения ресурсов обеспечивают оптимальную производительнос...»