Планировщик кубернетов поддерживает анти-сродство?

Question

Я смотрю на развертывание Kubernetes поверх кластера CoreOS, но я думаю, что я столкнулся с разрывом сделки.

Если я использую только CoreOS и флот, я могу указать в файлах модулей, что я хочу, чтобы определенные службы не запускались на том же физическом компьютере, что и другие службы (анти-сродство). Это очень важно для высокой доступности. Но это не похоже, что у кубернетов есть эта функциональность.

В моем конкретном прецеденте мне нужно будет запустить несколько кластеров машин elasticsearch, которые всегда должны быть доступны. Если по какой-либо причине kubernetes решает запланировать все мои контейнеры из списка elasticsearch для данного кластера ES на одной машине (или даже большинство на одной машине), и эта машина умирает, тогда мой кластер elasticsearch умрет вместе с ним , Этого нельзя допустить.

Кажется, что могут быть рабочие места. Я мог бы настроить требования к ресурсам и спецификации машин таким образом, чтобы на каждый компьютер мог поместиться только один экземпляр elasticsearch. Или я мог бы, вероятно, использовать метки каким-то образом, чтобы указать, что определенные контейнеры elasticsearch должны идти на определенных машинах. Я мог бы просто предоставить больше машин, чем необходимо, и сделать больше узлов ES, чем необходимо, и предположить, что кубернеты будут распространять их достаточно, чтобы быть достаточно уверенными в высокой доступности.

Но все это кажется неудобным. Это гораздо более элегантно с точки зрения управления ресурсами, чтобы просто указать необходимое оборудование и анти-сродство, и пусть планировщик оптимизируется оттуда.

Так что Kubernetes поддерживает анти-сродство каким-то образом я не мог найти? Или кто-нибудь знает, скоро ли это произойдет?

Или я должен думать об этом по-другому? Должен ли я писать собственный планировщик?

Answer 1

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

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

После этого кубернеты распространяют контейнеры контроллером репликации, пытаясь сохранить разные экземпляры, созданные данным контроллером репликации на разных узлах.

Похоже, недавно был реализован метод планирования, который рассматривает сервисы и различные другие параметры. https://github.com/GoogleCloudPlatform/kubernetes/pull/2906 Хотя я не совсем понимаю, как это использовать. Возможно, в координации с этой конфигурацией планировщика? https://github.com/GoogleCloudPlatform/kubernetes/pull/4674

Вероятно, для меня самым интересным вопросом является то, что ни один из этих приоритетов планирования не рассматривается во время масштабирования, только масштабирование. https://github.com/GoogleCloudPlatform/kubernetes/issues/4301 Это немного сложнее, похоже, со временем вы можете странно распределить стручки, потому что они остаются там, где они изначально размещены.

---

В целом, я думаю, что ответ на мой вопрос, на данный момент является то, что это является областью kubernetes, которая находится в постоянном движении (как и следовало ожидать с предварительной v1). Тем не менее, похоже, что многое из того, что мне нужно, будет выполняться автоматически с достаточным количеством узлов и правильное использование контроллеров репликации и служб.