#Руководство по лучшим практикам

#Обзор

Как де-факто стандарт для кэширования и хранения ключ-значение в облачно-нативных архитектурах, Redis удовлетворяет основные требования для операций с высокой конкуренцией чтения/записи и низкой задержкой. Запуск stateful-сервисов Redis в контейнеризованной среде Kubernetes предъявляет уникальные вызовы, отличающиеся от традиционных физических машин, включая стабильность персистентности, динамические изменения сетевой топологии и изоляцию ресурсов и планирование.

Данный документ с лучшими практиками предназначен для предоставления стандартизированного справочного руководства по развертыванию Redis в продуктивных средах. Он охватывает полный жизненный цикл управления от выбора архитектуры, планирования ресурсов, интеграции клиентов до наблюдаемости и эксплуатации. Следуя этому руководству, пользователи смогут построить корпоративный сервис данных Redis с характеристиками Высокой Доступности (HA), Высокой Производительности и Поддерживаемости.

#Выбор архитектуры

Full Stack Cloud Native Open Platform предлагает две стандартные архитектуры управления Redis, основанные на масштабе бизнеса клиента и требованиях SLA:

#Режим Sentinel

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

Режим Sentinel основан на нативном механизме репликации master-replica Redis. Путём развертывания независимых групп процессов Sentinel для мониторинга состояния master и replica узлов, он автоматически выполняет Failover и уведомляет клиентов при сбое master-узла.

• Плюсы: Простая архитектура, зрелая эксплуатация, низкие требования к протоколам клиентов.
• Минусы: Пропускная способность записи ограничена одним узлом; ёмкость хранения не масштабируется горизонтально.

#Режим Cluster

Позиционирование: Распределённая архитектура шардирования, подходит для крупномасштабного бизнеса с высокой конкуренцией.

Режим Cluster автоматически шардирует данные по множеству узлов с помощью Hash Slots, обеспечивая горизонтальное масштабирование (Scale-out) ёмкости хранения и производительности чтения/записи.

• Плюсы: Истинно распределённое хранилище с высокой доступностью, поддерживает динамическое перераспределение шардов (Resharding).
• Минусы: Сложный клиентский протокол; некоторые мульти-ключевые команды (например, MGET) ограничены распределением по слотам.

#Руководство по выбору

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

Рекомендации:

• Если объём данных небольшой (вмещается в память одного узла) и приоритет — простота и стабильность, предпочтителен режим Sentinel.
• Если объём данных огромен или нагрузка на запись очень высокая и не может быть обеспечена одним узлом, выбирайте режим Cluster.

#Выбор версии

Alauda Cache Service for Redis OSS в настоящее время поддерживает стабильные версии 5.0, 6.0 и 7.2. Все три версии прошли полное автоматизированное тестирование и проверку в продакшене.

Для новых развертываний настоятельно рекомендуем выбирать Redis 7.2:

1. Жизненный цикл

   • 5.0 / 6.0: Версии сообщества достигли End of Life (EOL) и больше не получают новые функции или патчи безопасности. Рекомендуются только для совместимости с устаревшими приложениями.
   • 7.2: Текущая версия с долгосрочной поддержкой (LTS), имеет самый длительный жизненный цикл, обеспечивая стабильность эксплуатации и обновления безопасности на годы вперёд.

2. Совместимость

   • Redis 7.2 сохраняет высокую совместимость с командами данных 5.0 и 6.0. Большинство бизнес-кода может мигрировать плавно без изменений.
   • Примечание: Формат файла RDB (v11) не обратно совместим (т.е. RDB, созданный 7.2, не может быть загружен 6.0), но это не влияет на новые сервисы.

3. Ключевые возможности

   • ACL v2: Предоставляет детальный контроль доступа (селекторы разрешений на основе ключей), значительно повышая безопасность в мультиарендных средах.
   • Redis Functions: Вводит стандарты серверного скриптинга, решая проблемы потери Lua-скриптов и репликации, позволяя держать логику ближе к данным.
   • Шардированный Pub/Sub: Решает проблему сетевых штормов, вызванных широковещанием Pub/Sub в режиме Cluster, значительно улучшая масштабируемость сообщений через шардирование.
   • Оптимизация производительности: Глубокие оптимизации в структурах данных (особенно Sorted Sets) и управлении памятью обеспечивают более высокую пропускную способность и меньшую задержку.

Для подробностей о функциях Redis 7.2 смотрите официальные Redis 7.2 Release Notes.

#Планирование ресурсов

#Настройка ядра

Для обеспечения стабильности и высокой производительности в продакшене рекомендуется оптимизировать следующие параметры ядра на уровне узла Kubernetes:

1. Выделение памяти (vm.overcommit_memory)

   • Рекомендуется: 1
   • Объяснение: Установка в 1 (Всегда) гарантирует, что ядро позволит выделять память во время операций Fork Redis (снимки RDB/перезапись AOF), даже если физической памяти кажется недостаточно. Это эффективно предотвращает сбои персистентности из-за ошибок выделения памяти.

2. Очередь соединений (net.core.somaxconn)

   • Рекомендуется: 2048 или выше
   • Объяснение: По умолчанию tcp-backlog Redis равен 511. При высокой конкуренции системный параметр net.core.somaxconn следует увеличить, чтобы избежать отбрасывания клиентских запросов на соединение.

3. Transparent Huge Pages (THP)

   • Действие: Отключить (never)
   • Объяснение: THP вызывает значительные всплески задержки при выделении памяти в Redis, особенно при Copy-on-Write (CoW) после Fork. Рекомендуется отключить на хосте или через скрипты запуска.

#Спецификации памяти

Redis использует механизм снимков для асинхронной репликации данных из памяти на диск для долговременного хранения. Это сохраняет высокую производительность Redis, но несёт риск потери данных между снимками.

В контейнеризованной среде Kubernetes рекомендуется многоуровневая стратегия управления памятью:

• ✅ Стандартные спецификации (< 8GB): Настоятельно рекомендуется. Обеспечивает крайне низкую задержку Fork и быстрое восстановление после сбоев (RTO < 60с); самый надёжный выбор для продакшена.
• ⚠️ Высокопроизводительные спецификации (8GB - 16GB): Допустимо. Требует высокопроизводительного хоста и обязательное отключение THP. Fork контролируем, но может вызывать ~100мс джиттер под высокой нагрузкой.
• ❌ Высокорисковые спецификации (> 16GB): Не рекомендуется. Точка отказа слишком велика, полная синхронизация может легко перегрузить сетевой канал. Рекомендуется горизонтальное разделение в режим Cluster.

#Почему ограничение 8GB?

Хотя на физических машинах одиночные инстансы часто работают с 32GB+, ограничение 8GB в облачно-нативных средах основано на "Золотом Правиле" этих ключевых технологий:

1. Блокировка Fork и копирование таблиц страниц

   • Redis вызывает fork() при RDB/AOF Rewrite. Хотя страницы памяти CoW, таблицы страниц процесса должны быть полностью скопированы, блокируя главный поток.
   • Оценка: 10GB памяти ≈ 20MB таблицы страниц ≈ 10–50мс блокировки (в зависимости от виртуализации). Превышение 8GB резко увеличивает риск блокировки, влияя на SLA.

2. Эффективность восстановления после сбоев (RTO)

   • Перезапуск контейнера с загрузкой RDB — это однопоточная CPU-задача (десериализация объектов). Тесты показывают, что загрузка 8GB занимает 30-50с (даже с SSD). Поддержание 32GB может привести к многоминутным задержкам запуска, противоречащим философии K8s "быстрого самовосстановления".

#Лучшие практики конфигурации памяти

Чтобы избежать OOM (OOM Kill) при персистентности из-за расширения памяти, необходимо строго соблюдать следующие принципы:

1. Установить MaxMemory: Не устанавливайте maxmemory в 100% от лимита памяти контейнера. Рекомендуется 70%–80% от лимита.
2. Резервировать пространство для CoW: Redis форкает дочерний процесс при RDB/AOF Rewrite. При интенсивных записях механизм Copy-on-Write ОС дублирует страницы памяти; в крайних случаях использование памяти может удвоиться с 8GB до 16GB.
3. Конфигурация Overcommit: Убедитесь, что на хосте vm.overcommit_memory = 1, чтобы ядро разрешало форки без запроса эквивалентной физической памяти (опираясь на CoW), предотвращая сбои fork.

#CPU ресурсы

Основное выполнение команд Redis однопоточное, но персистентность (Fork) и другие операции требуют дочерних процессов. Поэтому выделяйте не менее 2 ядер на экземпляр Redis:

• Ядро 1: Обрабатывает основной поток запросов и команд.
• Ядро 2: Обрабатывает fork для персистентности, фоновые задачи и системные накладные расходы.

#Многопоточность

Redis 6.0+ ввёл многопоточный ввод-вывод (по умолчанию отключён) для преодоления узкого места однопоточного сетевого ввода-вывода.

• Когда включать?

  • Анализ узких мест: Когда загрузка CPU Redis близка к 100%, и анализ показывает, что время тратится на сетевой ввод-вывод в состоянии ядра (System CPU), а не на выполнение команд в пользовательском пространстве.
  • Профиль трафика: Обычно полезно при QPS одного инстанса > 80,000 или большом сетевом трафике (> 1GB/s).
  • Ресурсные условия: Убедитесь, что узел имеет достаточное количество ядер CPU (минимум 4 ядра).

• Лучшие практики конфигурации:

  • Количество потоков: Рекомендуется 4–8 потоков ввода-вывода. Более 8 потоков редко даёт значительный прирост.
  • Пример конфигурации:

    io-threads 4
    io-threads-do-reads yes
  • Примечание: Многопоточный ввод-вывод улучшает только пропускную способность сети; он НЕ улучшает скорость выполнения одиночных сложных команд (например, SORT, KEYS).

#Планирование хранилища

#Планирование ёмкости

Режим персистентности напрямую определяет требования к дисковому квотированию. Смотрите формулы расчёта:

#Требования к производительности

• С AOF: Производительность диска критична. Недостаток IOPS или высокая задержка fsync напрямую блокируют главный поток (при appendfsync everysec).
• Носители: В продакшене настоятельно рекомендуются SSD/NVMe локальные диски или высокопроизводительные облачные диски.

#Конфигурация параметров

Параметры Alauda Cache Service for Redis OSS задаются через поля Custom Resource (CR).

#Встроенные шаблоны

Alauda Cache Service for Redis OSS предоставляет несколько шаблонов параметров для разных бизнес-сценариев. Выбор зависит от компромисса между персистентностью (Diskless/AOF/RDB) и производительностью.

<version> обозначает версию Redis, например, 6.0, 7.2.

Ключевые различия параметров:

#Рекомендации по выбору персистентности

1. Чистый кэш: Выбирайте Diskless Template. Данные восстанавливаемы, нет накладных расходов, максимальная производительность.
2. Общий бизнес: Выбирайте RDB Template. Периодические снимки обеспечивают RPO на уровне минут, умеренное использование ресурсов.
3. Финансы/Высокая надёжность: Выбирайте AOF Template с appendfsync everysec для защиты на уровне секунд.

#Обновление параметров

Параметры Redis классифицируются по способу применения:

#Примеры изменений

Обновление параметров узла данных: настраивается через spec.customConfig.

# Пример: изменить стратегию save (горячее обновление)
kubectl -n <namespace> patch redis <instance-name> --type=merge --patch='{"spec": {"customConfig": {"save":"600 1"}}}'

Обновление параметров узла Sentinel: настраивается через spec.sentinel.monitorConfig.

В настоящее время поддерживаются down-after-milliseconds, failover-timeout, parallel-syncs.

# Пример: изменить таймаут failover
kubectl -n <namespace> patch redis <instance-name> --type=merge --patch='{"spec": {"sentinel": {"monitorConfig": {"down-after-milliseconds":"30000"}}}}'

#Спецификации ресурсов

Разворачивайте ресурсы в соответствии с реальными бизнес-сценариями.

#Спецификации режима Sentinel

#Спецификации режима Cluster

<version> обозначает версию Redis, например, 6.0, 7.2.

#Планирование размещения (Scheduling)

Alauda Cache Service for Redis OSS предлагает гибкие стратегии планирования, поддерживая выбор узлов, толерантность к taint и различные конфигурации anti-affinity для обеспечения высокой доступности в разных ресурсных условиях.

#Выбор узла

Вы можете использовать поле spec.nodeSelector для указания узлов, на которых должны запускаться Pod’ы Redis. Обычно используется с Kubernetes Node Labels для изоляции баз данных на выделенных пулах узлов.

#Толерантность к taint

Используйте spec.tolerations, чтобы разрешить Pod’ам Redis терпеть taint узлов. Это позволяет размещать Redis на выделенных узлах с определёнными taint (например, key=redis:NoSchedule), предотвращая запуск других некритичных нагрузок.

#Anti-Affinity

Для предотвращения единой точки отказа Alauda Cache Service for Redis OSS предоставляет конфигурацию anti-affinity. Конфигурация различается в зависимости от режима архитектуры.

#Режим Cluster

В режиме Cluster система отдаёт приоритет spec.affinityPolicy. Alauda Cache Service for Redis OSS использует этот enum для абстрагирования сложных топологических правил, автоматически генерируя правила affinity для StatefulSet каждого шарда.

• Приоритет: spec.affinityPolicy > spec.affinity.
• Если affinityPolicy не задан: система проверяет spec.affinity. Если нужны кастомные топологические правила, выходящие за рамки перечисленных ниже, оставьте affinityPolicy пустым и настройте нативный spec.affinity.

#Режим Sentinel

Важно Режим Sentinel не поддерживает spec.affinityPolicy.

Для режима Sentinel узлы данных Redis и узлы Sentinel требуют отдельных нативных правил Affinity Kubernetes:

• Узлы данных Redis: настраиваются через spec.affinity.
• Узлы Sentinel: настраиваются через spec.sentinel.affinity.

Необходимо вручную прописывать полные правила Affinity. Пример жёсткого anti-affinity для узлов данных и Sentinel:

spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app.kubernetes.io/component
            operator: In
            values:
            - redis
          - key: redisfailovers.databases.spotahome.com/name
            operator: In
            values:
            - <instance name>
        topologyKey: kubernetes.io/hostname
  sentinel:
    affinity:
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app.kubernetes.io/component
              operator: In
              values:
              - sentinel
            - key: redissentinels.databases.spotahome.com/name
              operator: In
              values:
              - <instance name>
          topologyKey: kubernetes.io/hostname

Для жёсткого anti-affinity по всем узлам (данные + Sentinel) смотрите:

spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: middleware.instance/type
            operator: In
            values:
            - redis-failover
          - key: middleware.instance/name
            operator: In
            values:
            - <instance name>
        topologyKey: kubernetes.io/hostname
  sentinel:
    affinity:
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: middleware.instance/type
              operator: In
              values:
              - redis-failover
            - key: middleware.instance/name
              operator: In
              values:
              - <instance name>
          topologyKey: kubernetes.io/hostname

#Управление пользователями

Alauda Cache Service for Redis OSS (v6.0+) предоставляет декларативное управление пользователями через CRD RedisUser, поддерживая ACL.

#Профили разрешений

Платформа предопределяет профили разрешений для распространённых сценариев:

Для кастомных ACL смотрите Redis ACL Documentation.

#Механизмы безопасности

1. Принудительное удаление ACL: Все создания/обновления RedisUser проходят валидацию Webhook, которая принудительно удаляет права acl, предотвращая повышение привилегий.
2. Внедрение команд кластера: Для режима Cluster Alauda Cache Service for Redis OSS автоматически добавляет команды топологии: cluster|slots, cluster|nodes, cluster|info, cluster|keyslot, cluster|getkeysinslot, cluster|countkeysinslot для обеспечения осведомлённости клиента.
3. Совместимость обновления 6.0 -> 7.2: При обновлении 6.0 -> 7.2 оператор добавляет разрешение &* (канал Pub/Sub) для согласованности с новыми ACL каналов в 7.x.

#Системный аккаунт

Каждый экземпляр Redis автоматически создаёт системный аккаунт с именем operator. Его роли:

1. Инициализация кластера: Назначение слотов, присоединение узлов.
2. Упрощение конфигурации: Единый системный аккаунт снижает сложность настройки пользователей.
3. Операции: Используется для проверки здоровья, failover, масштабирования.
4. Избежание перезапусков: Обновление паролей бизнес-пользователей не влияет на этот аккаунт, избегая перезапусков.

#Лучшие практики для продакшена

1. Изоляция приложений: Создавайте отдельные учётные записи пользователей для каждого приложения/микросервиса. Избегайте совместного использования для аудита и изоляции.
2. Принцип наименьших привилегий:
   • Только чтение: используйте ReadOnly.
   • Чтение-запись: используйте ReadWrite.
   • Операционные инструменты: используйте NotDangerous или кастомные разрешения.
   • Избегайте Administrator, если не требуется.
3. Изоляция пространств имён ключей: Используйте ACL-паттерны ключей (например, ~app1:*), чтобы ограничить приложения определёнными префиксами ключей.
4. Ротация паролей: Организуйте регулярную смену паролей приложений.

Для операций смотрите User Management Docs.

#Доступ клиентов

#Обнаружение топологии

Оба режима — Sentinel и Cluster — полагаются на активное обнаружение и подключение клиентов к узлам данных, в отличие от традиционных режимов с LB-прокси:

#Режим Sentinel

1. Клиент подключается к узлу Sentinel.
2. Клиент отправляет SENTINEL get-master-addr-by-name mymaster для получения IP/порта мастера.
3. Клиент напрямую подключается к мастеру.
4. При failover Sentinel уведомляет клиента (или клиент опрашивает) для переключения на нового мастера.

#Режим Cluster

1. Клиент подключается к любому узлу кластера.
2. Отправляет CLUSTER SLOTS / CLUSTER NODES для получения распределения слотов.
3. Вычисляет хэш-слот ключа и напрямую подключается к целевому узлу.
4. Если слот мигрирует, узел возвращает MOVED/ASK; клиент должен обновить топологию.

Оба протокола возвращают реальные IP узлов. Если используется обратный прокси (HAProxy/Nginx), клиенты всё равно получают реальные IP бэкенда, которые могут быть недоступны извне кластера. Поэтому каждому Pod Redis нужен независимый внешний адрес (NodePort/LoadBalancer), а не единый адрес прокси.

#Стратегии сетевого доступа

Alauda Cache Service for Redis OSS поддерживает несколько методов доступа:

#Режим Sentinel

#Режим Cluster

#Примеры кода

Мы предоставляем примеры лучших практик для go-redis, Jedis, Lettuce и Redisson:

• Доступ к Sentinel: Как получить доступ к экземпляру Sentinel
• Доступ к Cluster: Как получить доступ к экземпляру Cluster

#Лучшие практики надёжности клиента

1. Таймауты

   • Connect Timeout: отличается от Read Timeout. Рекомендуется 1-3 секунды.
   • Read/Write Timeout: зависит от SLA, обычно сотни миллисекунд.

2. Стратегия повторных попыток

   • Экспоненциальный бэкофф: не повторять сразу при ошибке; использовать задержки (100мс, 200мс и т.д.) для предотвращения штормов повторных попыток.

3. Пул соединений

   • Повторное использование: всегда используйте пул (JedisPool, go-redis Pool) для экономии затрат на рукопожатие.
   • Максимум соединений: разумно задавайте MaxTotal, чтобы не превышать maxclients Redis.

4. Обновление топологии (Cluster)

   • Автообновление: убедитесь, что клиент обрабатывает MOVED/ASK.
   • Периодическое обновление: в нестабильных или масштабируемых средах настройте периодическое обновление (например, 60с) для проактивного обнаружения изменений.

#Наблюдаемость и эксплуатация

#Резервное копирование и безопасность

Центр резервного копирования платформы предоставляет удобное управление данными. Вы можете создавать резервные копии экземпляров, централизованно управлять ими и поддерживать выгрузку в S3. Поддерживается восстановление истории в конкретные экземпляры.

Смотрите Backup & Restore.

#Обновление и масштабирование

#Обновление

Смотрите Upgrade.

#Примечания по масштабированию

При изменении спецификаций (CPU/память) или расширении:

1. Оцените ресурсы: убедитесь, что в кластере достаточно ресурсов.
2. Пошагово: используйте rolling update для минимизации прерываний.
3. Вне пиков: выполняйте операции в периоды низкой нагрузки.

#Мониторинг

Alauda Cache Service for Redis OSS имеет встроенные метрики, интегрированные с Prometheus.

#Встроенные метрики

Переменные {{.namespace}} и {{.name}} должны быть заменены на реальные значения.

#Коэффициент попаданий в кэш (Hit Rate)

• Описание: Коэффициент попадания в кэш.
• Единицы: %
• Выражение:

  1/(1+(avg(irate(redis_keyspace_misses_total{namespace=~"{{.namespace}}", pod=~"(drc|rfr)-({{.name}})-.*"}[5m])) by(namespace,service) / (avg(irate(redis_keyspace_hits_total{namespace=~"{{.namespace}}", pod=~"(drc|rfr)-({{.name}})-.*"}[5m])) by(namespace,service)+1)))

#Среднее время отклика

• Описание: Средняя задержка команд. Высокое значение = медленные запросы/узкие места.
• Единицы: с
• Выражение:

  avg((redis_commands_duration_seconds_total{namespace=~"{{.namespace}}", pod=~"(drc|rfr)-({{.name}})-.*"} / redis_commands_total{namespace=~"{{.namespace}}", pod=~"(drc|rfr)-({{.name}})-.*"})) by (namespace,service)

#Переключения ролей

• Описание: Количество переключений Master-Replica за 5 минут. Не ноль = произошёл failover.
• Единицы: количество
• Выражение:

  sum by(namespace,service) (changes((sum by(namespace,service,pod)(redis_instance_info{namespace=~"{{.namespace}}",pod=~"(drc|rfr)-({{.name}})-.*",role="master"}) OR (sum by(namespace,service,pod)(redis_instance_info{namespace=~"{{.namespace}}",pod=~"(drc|rfr)-({{.name}})-.*",}) * 0))[5m:10s]))

#Статус экземпляра

• Описание: Статус здоровья. 0 = аномалия.
• Выражение:

  ((count by(namespace,service)(redis_instance_info{namespace=~"{{.namespace}}",service=~"{{.name}}",redisarch="cluster"}) % count by(namespace,service)(redis_instance_info{namespace=~"{{.namespace}}",service=~"{{.name}}",redisarch="cluster",role="master"})) == bool 0 and count by(namespace,service)(redis_instance_info{namespace=~"{{.namespace}}",service=~"{{.name}}",redisarch="cluster",role="master"}) >= bool 3) or (count by(namespace,service)(redis_instance_info{namespace=~"{{.namespace}}",service=~"rfr-({{.name}})",redisarch="sentinel",role="master"})) > bool 0

#Входящий трафик узла

• Описание: Пиковый входящий трафик.
• Единицы: байт/с
• Выражение:

  max by(namespace,service)(irate(redis_net_input_bytes_total{namespace=~"{{.namespace}}", pod=~"(drc|rfr)-({{.name}})-.*"}[5m]))

#Исходящий трафик узла

• Описание: Пиковый исходящий трафик.
• Единицы: байт/с
• Выражение:

  max by(namespace,service)(irate(redis_net_output_bytes_total{namespace=~"{{.namespace}}", pod=~"(drc|rfr)-({{.name}})-.*"}[5m]))

#Подключения узла

• Описание: Пиковое количество клиентских подключений. Следите, если близко к maxclients.
• Единицы: количество
• Выражение:

  max by(namespace,service)(redis_connected_clients{namespace=~"{{.namespace}}",pod=~"(drc|rfr)-({{.name}})-.*"})

#Использование CPU

• Описание: Использование CPU узла. Длительно высокое = влияние на производительность.
• Единицы: %
• Выражение:

  avg by(namespace,pod_name)(irate(container_cpu_usage_seconds_total{namespace=~"{{.namespace}}",pod_name=~"(drc|rfr)-({{.name}})-.*",container_name="redis"}[5m]))/avg by(namespace,pod_name)(container_spec_cpu_quota{namespace=~"{{.namespace}}",pod_name=~"(drc|rfr)-({{.name}})-.*",container_name="redis"})*100000

#Использование памяти

• Описание: Использование памяти узла. >80% — сигнал к масштабированию.
• Единицы: %
• Выражение:

  avg by(namespace,pod_name)(container_memory_usage_bytes{namespace=~"{{.namespace}}", pod_name=~"(drc|rfr)-({{.name}})-.*",container_name="redis"} - container_memory_cache{namespace=~"{{.namespace}}", pod_name=~"(drc|rfr)-({{.name}})-.*",container_name="redis"}) / avg by(namespace,pod_name)(container_spec_memory_limit_bytes{namespace=~"{{.namespace}}", pod_name=~"(drc|rfr)-({{.name}})-.*",container_name="redis"})

#Использование хранилища

• Описание: Использование PVC. Полное заполнение = сбой персистентности.
• Единицы: %
• Выражение:

  avg(kubelet_volume_stats_used_bytes{namespace=~"{{.namespace}}",persistentvolumeclaim=~"redis-data-(drc|rfr)-({{.name}})-.*"}) by(namespace,persistentvolumeclaim) / avg(kubelet_volume_stats_capacity_bytes{namespace=~"{{.namespace}}",persistentvolumeclaim=~"redis-data-(drc|rfr)-({{.name}})-.*"}) by(namespace,persistentvolumeclaim)

#Ключевые метрики и рекомендации по алертам

Рекомендуемые алерты для продакшена:

#Устранение неполадок

По конкретным проблемам ищите решения на Customer Portal.

#Ссылки

• Высокая доступность с Redis Sentinel
• Спецификация Redis Cluster
• Персистентность Redis
• Масштабирование с Redis Cluster
• Оптимизация Redis