В документации Kubernetes есть краткое обсуждение Kubernetes Scheduler . Как правило, планирование довольно непрозрачно, но вы также стремитесь к довольно хорошо загруженным узлам; с точки зрения вашего приложения важно установить соответствующий ресурс requests: в спецификации вашего модуля. Если на каждом узле достаточно места для удовлетворения запросов на ресурсы, обычно не имеет значения, какой узел выбран.
В описываемом вами сценарии (1) возможно, что две реплики будет размещен на одном и том же узле, поэтому два узла go не будут использоваться. Это особенно верно, если узлы не идентичны и имеют ограничения по ресурсам: если вашим модулям требуется 4 ГБ ОЗУ, но у вас есть узлы, у которых меньше этого (после учета системных модулей и пакетов демона), модули могут не запланировано там.
Если узел выходит из строя (2) Kubernetes автоматически перепланирует модули, работающие на этом узле, если это возможно. «Отказ» является широким случаем и может включать в себя узел, намеренно остановленный для обновления или замены. В этом последнем случае вы имеете некоторый контроль над поведением кластера; см. Сбои в документации.
Во многих средах будет запущен кластерный автоскалер . Это может привести к тому, что узлы будут приходить автоматически и go: если вы попытаетесь запланировать модуль, и он не будет соответствовать, автоскалер выделит новый узел, а если узел загружен менее чем на 50%, он будет удален (и его стручки перенесены). В вашем первом сценарии вы могли бы начать только с одного узла, но когда реплики модуля не все подходят, автоскалер создаст новый узел, и как только он станет доступным, там могут быть запланированы лишние модули.