Сочетание вытесняемых и не вытесняемых экземпляров виртуальной машины в облаке Google

#amazon-web-services #amazon-ec2 #google-cloud-platform #cloud #google-compute-engine

#amazon-веб-сервисы #amazon-ec2 #google-облачная платформа #облако #google-compute-engine

Вопрос:

Я довольно новичок в GCP, ранее я использовал AWS и тестирую GCP для некоторых своих проектов.

В группах автоматического масштабирования AWS была отличная небольшая функция, в которой вы могли указать разделение экземпляров Spot / On-demand в группе автоматического масштабирования и, что более важно, возможность иметь базовые экземпляры по требованию, что я ищу в GCP.

Я просматривал документацию и в целом искал в Google, как этого добиться, но я не нашел конкретных ответов о том, как это сделать, или если это вообще возможно. В шаблоне экземпляра есть только двоичная опция выбора «да» или «нет».

Я бы хотел, чтобы в MIG было хотя бы несколько не вытесняющих экземпляров, поскольку я никогда не хочу, чтобы мой сервис был полностью отключен. Итак, что произойдет, если возникнет нехватка не вытесняющих экземпляров? Добавляются ли в группу более дорогостоящие экземпляры без вытеснения, чтобы убедиться, что у MIG все еще достаточно возможностей для обслуживания запросов? Или у моего MIG просто заканчиваются экземпляры, и мой сервис отключается?

Может ли кто-нибудь мне помочь или даже указать на некоторые ресурсы, которые помогут в этой ситуации?

Комментарии:

1. Создайте два шаблона экземпляра и два MIGS, по одному для каждого типа экземпляра.

2. @JohnHanley это была моя первоначальная идея, но я не нашел никаких параметров потока трафика в настройках балансировщика нагрузки. Как мне контролировать свой трафик, чтобы перейти к не вытесняющему MIG, если у вытесняющего MIG нет экземпляров. Разве я не потерял бы половину трафика?

3. Если бы МИГ не был исправен, трафик перетекал бы на другие МиГи. Вы можете управлять этим с помощью политик автоматического масштабирования и проверок работоспособности.

Ответ №1:

Как уже упоминалось, вы можете создать два MIGS (один стандартный и один вытесняемый) и балансировщик нагрузки.
Затем примените проверки работоспособности, которые будут отслеживать эти группы. Если группа вытесняемых экземпляров исчерпана, проверка работоспособности не будет выполнена, и запросы будут отправляться только другой группе.

Ответ №2:

Вы читали это? Документация

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

Затем вы настраиваете привязку к узлу в своей службе, которая может выглядеть следующим образом:

 affinity:
nodeAffinity: 
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
    - matchExpressions:
      - key: cloud.google.com/gke-preemptible
        operator: DoesNotExist
 

Лично я использую статический пул для своих вспомогательных служб, таких как vault и linkerd. Или, может быть, какое-то базовое развертывание (вам нужно отдельно развернуть как в статическом, так и в динамическом пуле).

Комментарии:

1. Так что я пока не рассматривал возможность использования kubernetes, поскольку это был просто довольно простой сервис, а группа автоматического масштабирования в AWS отлично обслуживала меня, не усложняя ситуацию. Я просто хотел узнать, есть ли что-то подобное в MIGs, прежде чем погрузиться в GKE.