Comments 6
Во-первых, спасибо за статью. Очень познавательно, особенно когда сам не работал с кластерами более 1000 подов.
Есть ряд вопросов, если изволите.
Сколько нодов в кластере?
Все ли ноды одинаковы по ресурсам?
Какие спеки у нод? Кол-во ядер и памяти?
Сколько нод выделено для мастеров?
Есть ли ноды с тейнтами? Как используются?
Пользуетесь ли квотами неймспесов?
Используете ли какие-нибудь приложения для аудита? Например чтобы аннотации были, или чтобы много ресурсов не указывали?
Какие рекомендации можете дать по запросу ресуров контейнерами requests / limits?
Для таких больших кластеров, используете ли nodePort или IP подов для распределения нагрузки?
Разрешаете ли overcommit на самих нодах? Используете ли swap?
Очень интересно узнать ваш опыт.
В кластере более 600 нод, они разделены на роли и сконфигурированы под конкретные задачи, например, есть ноды с GPU. У нод до 2Тб оперативной памяти и 256 потоков.
Для мастеров выделено от 3 до 9 нод, при этом часть из их выполняет и другие роли, например, мониторы Ceph. Все ноды имеют как минимум тейнты с ролями сервера.
На больших продакшен кластерах квоты неймспейсов не используем, но надо учесть, что там никто ничего не создает без участия CI/CD пайплайнов, которые предварительно проходят все стадии тестирования на других окружениях.
Подробнее о системах мониторинга и логирования можно почитать в статьях блога dBrain.cloud (тут и тут). У нас есть собственные контроллеры, проставляющие необходимые аннотации в определенные ресурсы, о чем мы также уже рассказывали.
Как правило, для больших кластеров балансировка осуществляется либо через сервисы типа ClusterIP (внутри кластера), либо через LoadBalancer / Ingress для входящего трафика. IP подов используются только для работы механизмов cluster discovery и только в составе headless сервисов. NodePort вообще не используем, т.к. это не очень хорошая практика. Но клиенты при желании могут использовать сервисы типа NodePort.
SWAP везде отключен, overcommit, особенно по CPU, допускается использовать, если пики нагрузки на различные типы микросервисов разнесены во времени.
Что касается рекомендаций: необходимо следить за своим приложением и выставлять согласно результатам нагрузочного тестирования.
Спасибо большое за ответ!
Обязательно почитаю остальные статьи.
Если можно, еще немного вопросов.
Как балансировщики нагрузок узнают IP пода куда направлять трафик?
Более интересен overcommit по памяти. Видел сценарий, когда обычная команда grep убивала все поды на ноде посредством OOM killer. При memory overcommit = 0 такого не происходит.
Уточню по ресурсы подов. Допускаете ли разные request и limits по памяти или по процессору? Видел рекомендации, что по памяти request и limit должны быть одинаковые, а по процессору нужно иметь request (желательно целочисленный),а limit опустить.
Используете ли Rancher?
Заранее благодарен;)
"Как балансировщики нагрузок узнают IP пода куда направлять трафик"?
- По лейблам
"Более интересен overcommit по памяти. Видел сценарий, когда обычная команда grep убивала все поды на ноде посредством OOM killer. При memory overcommit = 0 такого не происходит".
- По памяти: overcommit практически не используем, в редких случаях на тестовых средах это допустимо.
"Уточню по ресурсы подов. Допускаете ли разные request и limits по памяти или по процессору? Видел рекомендации, что по памяти request и limit должны быть одинаковые, а по процессору нужно иметь request (желательно целочисленный),а limit опустить".
- Аналогично предыдущему ответу: допускаются все возможные варианты и их комбинации в зависимости от поставленной задачи - надежность vs экономия ресурсов.
"Используете ли Rancher?"
- Нет, наша платформа лучше:)
Как ускорить кластер Kubernetes на 100 тысяч подов в 10 раз