#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.