Реальность больших кластеров и почему обычные практики тут ломаются

Описание

k get nodes | wc -l
10000

обычно прежде чем увидеть результат команды, я немного жду, совсем немного, примерно

real 0m6.729s

сейчас облако это несколько кластеров k8s и самый большой из них содержит больше 10000 воркеров


если спросить у AI (claude sonet 4.5 )

# Оптимизация Kubernetes кластера на 10000 узлов

Такой масштаб требует специальной настройки. Вот ключевые действия:

мы увидим

**Критичные лимиты Kubernetes**

- Max pods per node: 110 (по умолчанию)
- Max nodes: 5000 (официальный лимит)
- **Для 10K узлов нужна кастомная сборка или федерация**

## Рекомендация

**10000 узлов в одном кластере - за пределами официальных лимитов.**

Лучшие варианты:
1. **Разделите на 2-3 кластера** (по 3-5K узлов)
2. Используйте **multi-cluster management** (Rancher, GKE Hub, etc.)
3. Рассмотрите **edge computing** решения

Какую задачу решаете? Возможно, есть архитектурные альтернативы.

Проблема

'''
k get nodes | wc -l
10240
'''

https://kubernetes.io/docs/setup/best-practices/cluster-large/

No more than 110 pods per node
No more than **5,000 nodes**
No more than 150,000 total pods
No more than 300,000 total containers

k get pods -A | wc -l
12552

k get jobs -A | wc -l
23330

ключевая проблема, что нам нужна очень высокая надежность и доступность этих кластеров

- мониторинг
нельзя управлять без наблюдения, расскажу как наблюдать за большим количеством узлов в кластере и почему стандартный prometheus тут не поможет

- обвновления
базовая операция такая как обновление на нашем объеме кластера становится сложной задачей и расскажу как обычное обновление kubelet или сертификата становиться настоящим квестом.

- сетап etcd
узкое место любого кластера это база, а именно etcd, расскажу как мы подошли к решению этого вопроса

- конфиг apiserver
любое действие в кластере "трогает apiserver", расскажу как мы тюним параметры на что стоит обратить внимание.
Расскажу почему "просто спрятать за балансером" мы не можем и как это обойти