Повышение стабильности Kubernetes для крупных кластеров
Это руководство помогает операторам кластеров и SRE снизить нагрузку на control-plane, повысить надежность и ограничить радиус поражения в крупных кластерах Kubernetes.
Содержание
Примечания
- Настройка сети, хранилища, балансировщиков нагрузки, логирования и мониторинга не рассматривается; смотрите документацию поставщиков для этих компонентов.
WARNING
- Тестируйте изменения конфигурации перед использованием в продакшене.
- Избегайте одного большого кластера при высоком риске; рассмотрите управление несколькими кластерами для уменьшения радиуса поражения.
| Проблема | Описание | Оптимизация |
|---|---|---|
| etcd диск | etcd очень чувствителен к дисковым операциям ввода-вывода в больших кластерах. | Используйте выделенный NVMe SSD для каталога данных etcd. |
| Размер БД etcd | Базы данных размером более ~8 ГБ значительно ухудшают задержки, использование ресурсов и время восстановления. | Поддерживайте размер БД etcd ≤ 8 ГБ; удаляйте неиспользуемые объекты и держите часто обновляемые объекты маленькими (~≤100 КБ). |
| Частая смена ключей etcd | Высокая частота чтения/записи ключей нагружает etcd. | Анализируйте метрики etcd для выявления и снижения нагрузки на горячие ключи. |
| Размер данных по типу ресурса в etcd | Большие объемы данных по типу ресурса делают операции полного списка дорогими и могут блокировать контроллеры. | Поддерживайте общий объем данных по каждому типу ресурса ≤ 800 МБ; очищайте неиспользуемые Deployments/Services. 1 |
| Пропускная способность и соединения LB API-сервера | Ограничения пропускной способности или количества соединений балансировщика нагрузки могут привести к состоянию NotReady у узлов. | Мониторьте и заранее обеспечивайте балансировщик нагрузки API-сервера. |
| Сервисы на namespace | Большое количество сервисов вызывает значительную инъекцию переменных окружения в Pods и замедляет их запуск. | Поддерживайте количество сервисов на namespace < 5,000 или установите enableServiceLinks: false. 2 |
| Общее количество сервисов в кластере | Избыточное количество сервисов увеличивает правила kube-proxy и ухудшает производительность. | Поддерживайте общее количество сервисов < 10,000 и удаляйте неиспользуемые. 1 |
| CoreDNS | Большое количество Pod может ухудшать производительность CoreDNS. | Используйте NodeLocal DNSCache (nodelocaldns). |
| Частота обновлений Pod | Высокая частота обновлений вызывает распространение изменений Endpoint/EndpointSlice на все узлы и может вызывать штормы. | Снизьте churn Pod; для RollingUpdate установите консервативные значения maxUnavailable/maxSurge. |
| Монтирование токенов ServiceAccount | Каждый токен Secret может создавать watch; большое количество watch нагружает control plane. | Для Pod, которым не нужен доступ к API, установите automountServiceAccountToken: false. 3 |
| Количество/размер объектов | Накопленные ConfigMaps, Secrets, PVC и др. увеличивают нагрузку на control-plane. | Ограничьте историю ReplicaSet (revisionHistoryLimit) и используйте ttlSecondsAfterFinished для Jobs/CronJobs. |
| Запросы/лимиты Pod | Большие разрывы между запросами и лимитами могут вызвать каскадные сбои при потере узла. | По возможности устанавливайте запросы равными лимитам. |
| Перезапуски контроллеров и мониторинг | Перезапуски контроллеров или API-сервера вызывают повторные листинги, которые могут перегрузить API-сервер. | Мониторьте контроллеры, задавайте адекватные ресурсы для избежания перезапусков и снижайте ненужные операции control-plane. |
Footnotes
-
https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md ↩ ↩2
-
https://kubernetes.io/docs/tutorials/services/connect-applications-service/#accessing-the-service ↩
-
https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#opt-out-of-api-credential-automounting ↩