1. Агрегированные показатели для пользовательского мониторинга
Помимо стандартных возможностей мониторинга использования процессора и памяти, Kubernetes поддерживает сбор пользовательских показателей. Это позволяет вам определять и собирать то, что имеет отношение к производительности и работоспособности вашего приложения — так вы можете адаптировать стратегии автоматического масштабирования и мониторинга к вашим операционным требованиям.
Что такое агрегированные показатели, определяемые пользователем?
Они могут включать в себя все, что угодно, от количества активных пользователей и пропускной способности транзакций до частоты ошибок. Эти показатели объединяют данные из нескольких источников и дают целостное представление о поведении системы.
Как использовать пользовательские агрегированные показатели
Обычно для этого нужна интеграция с решением для мониторинга, поддерживающим пользовательские показатели, таким как Prometheus. После чего Kubernetes настраивается на использование этих показателей для HPA или для мониторинга и оповещения.
Сбор метрик с помощью Prometheus: во-первых, убедитесь, что Prometheus действительно собирает пользовательские метрики из вашего приложения. Это можно настроить:
from prometheus_client import start_http_server, Summary
import random
import time
# Create a metric to track time spent and requests made.
REQUEST_TIME = Summary('request_processing_seconds', 'Time spent processing request')
# Decorate function with metric.
@REQUEST_TIME.time()
def process_request(t):
"""A dummy function that takes some time."""
time.sleep(t)
if __name__ == '__main__':
# Start up the server to expose the metrics.
start_http_server(8000)
# Generate some requests.
while True:
process_request(random.random())Поскольку Prometheus собирает ваши показатели, вы можете настроить Kubernetes HPA для масштабирования вашего развертывания Kubernetes на основе этих показателей. Это про развертывание Prometheus Adapter для API метрик Kubernetes, который позволяет HPA запрашивать у Prometheus ваши пользовательские метрики.
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: myapp-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp
minReplicas: 1
maxReplicas: 10
metrics:
- type: Pods
pods:
metric:
name: request_processing_seconds
target:
type: AverageValue
averageValue: 500msКогда использовать определяемые пользователем совокупные показатели
- Стандартные метрики не дают достаточного представления о производительности приложений.
- Вам необходимо отслеживать критически важные для бизнеса операции.
- Требуется настраиваемый режим масштабирования, который не могут обеспечить стандартные показатели
Рекомендации
- Четко определите метрики: убедитесь, что ваши пользовательские метрики четко определены, значимы и напрямую связаны с операционными целями или показателями эффективности.
- Избегайте перегрузки показателей. Собирайте только те показатели, которые вам нужны, чтобы не перегружать систему мониторинга и сосредоточить внимание на ключевых показателях эффективности.
- Регулярно проверяйте и корректируйте. По мере развития вашего приложения и эксплуатационных требований проверяйте метрики, чтобы убедиться, что они остаются актуальными, и корректируйте конфигурации мониторинга и масштабирования.
Дополнительно
- Prometheus Documentation
- Kubernetes Documentation on Horizontal Pod Autoscaler
- Prometheus Adapter for Kubernetes Metrics APIs
2. API Priority and Fairness (APF) для управления запросами
Функция APF гарантирует, что запросы к API-серверу Kubernetes обрабатываются правильно и эффективно, не допуская, чтобы пропускались важные запросы. Устанавливая приоритеты и изолируя запросы, Kubernetes может поддерживать стабильность управления кластера даже при высокой нагрузке.
Что такое API Priority and Fairness?
Функция классифицирует входящие запросы API по различным уровням приоритета. Затем каждый запрос ставится в очередь и обрабатывается в соответствии с его приоритетом.
Как использовать APF
Вы должны определить объекты PriorityLevelConfiguration и FlowSchema. Эти объекты определяют, как запросы классифицируются и в каком порядке они обрабатываются.
Определение уровней приоритета: объекты конфигурации PriorityLevelConfiguration позволяют определять, например, создание уровня высокого приоритета:
apiVersion: flowcontrol.apiserver.k8s.io/v1beta1
kind: PriorityLevelConfiguration
metadata:
name: high-priority
spec:
type: Limited
limited:
assureConcurrencyShares: 100
limitResponse:
type: Queue
queuing:
queues: 50
handSize: 5
queueLengthLimit: 10Распределите запросы по категориям с помощью FlowSchema: как запросы соотносятся с уровнями приоритета. Вы можете создать FlowSchema для маршрутизации запросов от определенных пользователей или учетных записей служб на уровень высокого приоритета:
apiVersion: flowcontrol.apiserver.k8s.io/v1beta1
kind: FlowSchema
metadata:
name: system-operations-high-priority
spec:
priorityLevelConfiguration:
name: high-priority
matchingPrecedence: 500
rules:
- subjects:
- kind: Group
name: "system:masters"
resourceRules:
- verbs: ["*"]
apiGroups: ["*"]
resources: ["*"]Когда использовать APF
- Большие кластеры с высокой степенью автоматизации и многочисленными параллельными операциями.
- Среды, в которых критически важным операциям должны быть гарантированы ресурсы, независимо от общей нагрузки.
- Кластеры испытывают проблемы с производительностью из-за несущественных операций, потребляющих чрезмерное количество ресурсов сервера API.
Лучшие практики для APF
- Мониторинг производительности API-сервера: чтобы понять, как приоритизация запросов влияет на работу кластера в целом.
- Убедитесь, что priority levels and flow schemas настроены таким образом, чтобы отражать истинную важность различных операций.
- Регулярно проверяйте и корректируйте конфигурации: по мере изменения рабочей нагрузки вашего кластера пересматривайте конфигурации APF, чтобы убедиться, что они по-прежнему эффективно отвечают вашим операционным потребностям.
Дополнительно
- Kubernetes Official Documentation on API Priority and Fairness
- A Deep Dive into Kubernetes API Priority and Fairness
- Configuring API Priority and Fairness in Kubernetes
3. Мультикластерные сервисы с Submariner
Submariner — это инструмент, который устраняет сетевой разрыв между отдельными кластерами Kubernetes, связывает их безопасно и эффективно. Submariner позволяет модулям и сервисам в разных кластерах взаимодействовать так, как если бы они находились в одном кластере, упрощая архитектуру.
Что такое Submariner
Он создает зашифрованный туннель между кластерами, используя базовую сетевую инфраструктуру, сохраняя при этом безопасность и изоляцию.
Как использовать Submariner
Для развертывания Submariner вам понадобятся два или более кластера Kubernetes. Вот упрощенный обзор настройки Submariner (установите его минимум в два кластера):
subctl install --kubeconfig <путь к -kubeconfig> --clusterid <уникальный-cluster-id>После установки оператора используйте subctl для присоединения каждого кластера к mesh network:
subctl join --kubeconfig <путь к -kubeconfig>broker-info .subm --clusterid < уникальный -cluster-id>Эта команда настраивает кластер для участия в оверлейной сети Submariner, подключая его к другим кластерам.
Когда использовать Submariner
Submariner особенно полезен в таких сценариях, как:
- Развертывания в нескольких облаках: когда ваши кластеры Kubernetes распределены между разными облачными провайдерами.
- Гибридное облако и локальные среды: подключение кластеров в локальных центрах обработки данных и облачных средах.
- Аварийное восстановление: упрощение синхронизации и резервного копирования между кластерами в разных географических регионах, для обеспечения высокой доступности.
Лучшие практики для Submariner
- Убедитесь, что между кластерами нет перекрытий в Pod и Service CIDR, чтобы избежать сетевых конфликтов.
- Используйте встроенное шифрование Submariner для защиты межкластерного трафика.
- Реализуйте мониторинг и ведение журналов, чтобы отслеживать поток трафика между кластерами для устранения неполадок и анализа производительности.
Дополнительно