Автоматическое масштабирование групп экземпляров¶

https://cloud.google.com/compute/docs/autoscaler

Выполняется путем добавления дополнительных виртуальных машин в MIG при увеличении нагрузки (масштабирование, иногда называемое увеличением масштаба) и удаления виртуальных машин при уменьшении потребности в виртуальных машинах (увеличение или уменьшение масштаба).

Технические характеристики¶

Автоматическое масштабирование работает только с группами управляемых экземпляров (MIG). Неуправляемые группы экземпляров не поддерживаются.
Если вы хотите автоматически масштабировать региональный MIG, применяются следующие ограничения:

Вы должны установить для целевой формы распределения группы EVEN значение.
Для увеличения и уменьшения масштаба необходимо включить упреждающее перераспределение экземпляров ( proactive instance redistribution). Если вы настроили режим автоматического масштабирования только на scale, то вам не нужно включать упреждающее распространение экземпляров.

Вы не можете создавать экземпляры с определенными именами, пока включено автоматическое масштабирование. Однако вы можете включить автоматическое масштабирование после создания экземпляров виртуальных машин с определенными именами.
Вы не можете использовать автоматическое масштабирование, если ваш MIG имеет конфигурацию statefull.
Не используйте автоматическое масштабирование Compute Engine с MIG, принадлежащими Google Kubernetes Engine. Для групп движка Google Kubernetes вместо этого используйте автоматическое масштабирование кластера.
Средство автоматического масштабирования может принимать решения о масштабировании на основе нескольких показателей, но оно может обрабатывать только один сигнал для каждого типа показателей, за исключением показателей облачного мониторинга; средство автоматического масштабирования может обрабатывать до пяти сигналов на основе показателей мониторинга. Средство автоматического масштабирования вычисляет рекомендуемое количество виртуальных машин для каждого сигнала, а затем масштабирует на основе сигнала, который обеспечивает наибольшее количество виртуальных машин в группе.
Автоматическое масштабирование работает независимо от autohealing. Если вы настроили автоматическое лечение для своей группы, и экземпляр не прошел проверку работоспособности, средство автоматического лечения попытается воссоздать экземпляр. Повторное создание экземпляра может привести к тому, что количество экземпляров в группе упадет ниже указанного вами порога автоматического масштабирования (MINNUMREPLICAS).
Если вы автоматически масштабируете региональный MIG, экземпляр может быть добавлен, а затем немедленно удален из одной из зон. Это происходит, когда использование в зоне вызывает масштабирование, но общее использование в региональном MIG не требует дополнительного экземпляра или дополнительный экземпляр требуется в другой зоне.

Автоматическое масштабирование использует следующие основные концепции и сервисы.

Группы управляемых экземпляров¶

Автоматическое масштабирование - это функция групп управляемых экземпляров (MIGS). Группа управляемых экземпляров - это коллекция экземпляров виртуальных машин (ВМ), созданных на основе общего шаблона экземпляра. Средство автоматического масштабирования добавляет или удаляет экземпляры из группы управляемых экземпляров на основе политики автоматического масштабирования группы. Хотя в Compute Engine есть как управляемые, так и неуправляемые группы экземпляров, с автомасштабером можно использовать только управляемые группы экземпляров.

Политика автоматического масштабирования¶

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

Целевые показатели использования¶

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

Средняя загрузка процессора.
Пропускная способность балансировки нагрузки HTTP, которая может быть основана либо на использовании, либо на запросах в секунду.
Показатели облачного мониторинга.

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

Целевой уровень использования - это уровень, на котором вы хотите поддерживать экземпляры виртуальной машины (ВМ). Например, если вы масштабируете на основе загрузки ЦП, вы можете установить целевой уровень загрузки на уровне 75%, и средство автоматического масштабирования будет поддерживать загрузку ЦП указанной группы экземпляров на уровне или близком к 75%. Уровень использования для каждой метрики интерпретируется по-разному в зависимости от политики автоматического масштабирования.

Расписания¶

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

Емкость: минимально необходимые экземпляры виртуальных машин Расписание: время начала, продолжительность и повторяемость (например, один раз, ежедневно, еженедельно или ежемесячно)

Каждое расписание масштабирования активно с момента его запуска и в течение настроенной продолжительности. В течение этого времени autoscaler масштабирует группу, чтобы иметь по крайней мере столько экземпляров, сколько определено расписанием масштабирования.

Период охлаждения¶

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

Для принятия решений о масштабировании средство автоматического масштабирования учитывает данные об использовании всех экземпляров, даже экземпляра, который все еще находится в пределах периода охлаждения. Средство автоматического масштабирования рекомендует удалять экземпляры, если среднее использование всех экземпляров меньше целевого использования.
При принятии решений о масштабировании средство автоматического масштабирования игнорирует данные об использовании экземпляров, которые все еще находятся в периоде охлаждения.
Если вы включаете прогнозирующий режим, период охлаждения сообщает прогнозирующему автомасштаберу о дальнейшем масштабировании до ожидаемой нагрузки, чтобы приложения инициализировались при поступлении нагрузки. Например, если вы установите период охлаждения равным 300 секундам, то прогностический автоскалер создаст виртуальные машины на 5 минут раньше прогнозируемой загрузки.

Укажите период охлаждения, чтобы указать, сколько времени требуется приложениям на вашем экземпляре для инициализации. По умолчанию период охлаждения составляет 60 секунд.

Фактическое время инициализации варьируется в зависимости от множества факторов. Мы рекомендуем вам проверить, сколько времени требуется для инициализации вашего приложения. Для этого создайте экземпляр и рассчитайте время запуска с момента запуска экземпляра до тех пор, пока приложение не будет готово.

Если вы зададите значение периода охлаждения, которое значительно превышает время, необходимое для инициализации экземпляра, то ваш авторазмер может игнорировать допустимые данные об использовании и может недооценить требуемый размер вашей группы, что приведет к задержке масштабирования.

Период стабилизации¶

Для целей масштабирования автоскалер вычисляет рекомендуемый целевой размер группы на основе пиковой нагрузки за последние 10 минут. Эти последние 10 минут называются периодом стабилизации.

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

Этот 10-минутный период стабилизации может показаться задержкой при масштабировании, но на самом деле это встроенная функция автоматического масштабирования. Задержка гарантирует, что меньшего размера группы будет достаточно для поддержки пиковой нагрузки за последние 10 минут.

Режим автоматического масштабирования¶

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

Прогнозное автоматическое масштабирование¶

Если вы включите прогнозирующее автоматическое масштабирование для оптимизации MIG для обеспечения доступности, средство автоматического масштабирования прогнозирует будущую нагрузку на основе исторических данных и масштабирует MIG до прогнозируемой нагрузки, чтобы новые экземпляры были готовы к обслуживанию при поступлении нагрузки.

Прогнозное автоматическое масштабирование работает лучше всего, если ваша рабочая нагрузка соответствует следующим критериям:

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

Элементы управления масштабированием¶

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

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

Чтобы настроить элементы управления масштабированием, задайте следующие свойства в политике автоматического масштабирования.

Максимально допустимое снижение. Количество экземпляров виртуальной машины, которые ваша рабочая нагрузка может позволить себе потерять (из-за своего максимального размера) в течение указанного конечного временного окна. Используйте этот параметр, чтобы ограничить масштабирование вашей группы, чтобы вы все еще могли обслуживать вероятный скачок нагрузки, пока не начнут обслуживать больше экземпляров. Чем меньше вы установите максимально допустимое сокращение, тем больше времени потребуется для масштабирования вашей группы.
Конечное временное окно. История, в рамках которой авторазмер отслеживает максимальный размер, необходимый для вашей рабочей нагрузки. Автоскалер не будет изменять размер ниже максимально допустимого уменьшения, вычитаемого из пикового размера, наблюдаемого в этот период. Вы можете использовать этот параметр, чтобы определить, как долго автоскалер должен ждать перед удалением экземпляров, как определено максимально допустимым уменьшением. При более длительном временном интервале автоскейлер учитывает больше исторических пиков, делая масштабирование более консервативным и стабильным.

Дополнительные сведения см. в разделе Настройка элементов управления масштабированием и Общие сведения о решениях по автоматическому масштабированию.

Ценообразование¶

Дополнительная плата за настройку политики автоматического масштабирования не взимается. Средство автоматического масштабирования динамически добавляет или удаляет экземпляры виртуальных машин, поэтому с вас взимается плата только за ресурсы, которые использует ваш MIG. Вы можете контролировать стоимость ресурсов, настраивая минимальное и максимальное количество экземпляров в политике автоматического масштабирования.

Scaling based on CPU utilization¶

Простейшей формой автоматического масштабирования является масштабирование группы управляемых экземпляров (MIG) на основе загрузки ЦП ее экземпляров.

Вы также можете масштабировать MIG на основе пропускной способности внешнего балансировщика нагрузки HTTP(S) или показателей мониторинга.

Масштабирование на основе загрузки ЦП¶

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

Средство автоматического масштабирования обрабатывает целевой уровень загрузки ЦП как долю от среднего использования всех vCPU с течением времени в группе экземпляров. Если среднее использование общего числа VCPU превышает целевое использование, средство автоматического масштабирования добавляет больше экземпляров виртуальных машин. Если среднее использование ваших общих VCPU меньше целевого использования, средство автоматического масштабирования удаляет экземпляры. Например, установка целевого показателя использования 0,75 указывает автомасштаберу поддерживать среднее значение использования 75% среди всех VCPU в группе экземпляров.

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

Enable autoscaling based on CPU utilization¶

https://cloud.google.com/compute/docs/instance-groups/autohealing-instances-in-migs

Группы управляемых экземпляров (MIG) поддерживают высокую доступность ваших приложений, активно поддерживая доступные экземпляры виртуальных машин (ВМ), что означает, что они находятся в состоянии RUNNING. Если управляемый экземпляр прекращает работу, но изменение состояния не было инициировано MIG, то MIG автоматически воссоздает этот экземпляр. С другой стороны, если MIG намеренно останавливает запуск экземпляра — например, когда средство автоматического масштабирования удаляет экземпляр, — то MIG не воссоздает этот экземпляр.

Изменения состояния экземпляра, которые не инициируются MIG, включают:

Аппаратные сбои.
Завершение вытесняемого экземпляра.
События обслуживания инфраструктуры, когда экземпляр виртуальной машины не настроен на динамическую миграцию.

Удаление экземпляра MIG с помощью одного из следующих методов: * instances.delete метод API * Команда gcloud compute instances delete

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

Для дальнейшего повышения доступности вашего приложения и проверки того, отвечает ли ваше приложение, вы можете настроить политику автоматического восстановления для вашего MIG.

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

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

Поведение при автоматическом лечении (Autohealing)¶

Автоматическое восстановление восстанавливает неработоспособные виртуальные машины с использованием исходного шаблона экземпляра, который использовался для создания виртуальной машины (не обязательно текущего шаблона экземпляра в MIG). Например, если виртуальная машина была создана с использованием instance-template-a, а затем вы обновили MIG для использования instance-template-b в OPPORTUNISTIC режиме, автоматическое лечение по-прежнему использует instance-template-a для воссоздания виртуальной машины. Это связано с тем, что повторные сеансы автоматического восстановления не инициируются пользователем, поэтому Compute Engine не предполагает, что виртуальная машина должна использовать новый шаблон. Если вы хотите применить новый шаблон, см. раздел Изменение шаблона экземпляра для MIG (https://cloud.google.com/compute/docs/instance-groups/creating-groups-of-managed-instances#set_group_template)

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

Автоматическое восстановление не создает виртуальную машину заново в течение периода инициализации этой виртуальной машины. Для получения дополнительной информации см. свойство autoHealingPolicies[].initialdelaysec. Этот параметр задерживает автоматическое восстановление после проверки и потенциально преждевременного повторного создания виртуальной машины, если виртуальная машина находится в процессе запуска. Таймер начальной задержки запускается, когда MIG изменяет текущее поле действия виртуальной машины на ПРОВЕРКУ.

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

Autohealing and disks¶

При воссоздании виртуальной машины на основе ее шаблона средство автоматического восстановления обрабатывает различные типы дисков по-разному. Некоторые конфигурации дисков могут привести к сбою средства автоматического исцеления при попытке воссоздать виртуальную машину.

Средство autohealer не подключает диски, которые не указаны в шаблоне экземпляра, например диски, которые вы подключили к виртуальной машине вручную после создания виртуальной машины.

Чтобы сохранить важные данные, записанные на диск, примите меры предосторожности, такие как:

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

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

Настройка проверки работоспособности и политики автоматического восстановления¶

Вы можете установить максимум одну политику автоматического лечения для каждого пользователя.

Вы можете применить одну проверку работоспособности максимум к 50 мигам. Если у вас более 50 групп, создайте несколько проверок работоспособности. Пример настройки проверки работоспособности

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

После завершения создания группы или обновления конфигурации проверки работоспособности может потребоваться 30 минут, прежде чем автоматическое восстановление начнет мониторинг экземпляров в группе. Как только начинается мониторинг, Compute Engine начинает помечать экземпляры как исправные (или воссоздает их заново) на основе вашей конфигурации автоматического восстановления. Например, если вы настроите начальную задержку в 5 минут, интервал проверки работоспособности в 1 минуту и порог работоспособности в 1 проверку, временная шкала будет выглядеть следующим образом:

30-минутная задержка перед началом автоматического исцеления для мониторинга экземпляров в группе + 5 минут для настроенной начальной задержки + 1 минута для интервала проверки * порог работоспособности (60 секунд * 1) = 36 минут до того, как экземпляр будет помечен как исправный или будет воссоздан заново

Проверка статуса¶

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

Если вы настроили автоматическое лечение для своего MIG, вы можете просмотреть состояние работоспособности каждого управляемого экземпляра.

Проверьте состояние работоспособности управляемого экземпляра, чтобы:

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

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

Обнаружение ошибок конфигурации проверки работоспособности. Например, вы можете обнаружить неправильно настроенные правила брандмауэра или недопустимую конечную точку проверки работоспособности приложения, если экземпляр сообщает о состоянии работоспособности по истечении времени TIMEOUT.
Определите начальное значение задержки для настройки, измеряя промежуток времени между переходом виртуальной машины в состояние RUNNING и переходом виртуальной машины в HEALTHY состояние. Вы можете измерить этот разрыв, опросив метод list-instances.

Health states

Доступны следующие состояния работоспособности виртуальной машины:

HEALTHY: Виртуальная машина доступна, может быть установлено соединение с конечной точкой проверки работоспособности приложения, и ответ соответствует требованиям, определенным при проверке работоспособности..
DRAINING: Виртуальная машина сливается. У существующих подключений к виртуальной машине есть время для завершения, но в новых подключениях отказано.
UNHEALTHY: Виртуальная машина доступна, но не соответствует требованиям, определенным при проверке работоспособности.
TIMEOUT: Виртуальная машина недоступна: не удается установить соединение с конечной точкой проверки работоспособности приложения или сервер на виртуальной машине не отвечает в течение указанного времени ожидания. Например, это может быть вызвано неправильно настроенными правилами брандмауэра или перегруженным серверным приложением на виртуальной машине.
UNKNOWN: Система проверки работоспособности не знает о виртуальной машине или ее работоспособность в данный момент неизвестна. Для начала мониторинга новых виртуальных машин в MIG может потребоваться 30 минут.

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

Будет ли виртуальная машина восстановлена, зависит от ее состояния работоспособности:

Если виртуальная машина находится в UNHEALTHY or TIMEOUT, и у нее прошел период инициализации, служба автоматического восстановления немедленно попытается ее восстановить.

Если состояние работоспособности виртуальной машины UNKNOWN, то она не будет восстановлена немедленно. Это делается для предотвращения ненужного ремонта виртуальной машины, для которой сигнал проверки работоспособности временно недоступен.

Попытки автоматического исцеления могут быть отложены, если:

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

Мы хотим узнать о ваших вариантах использования, проблемах или отзывах о значениях состояния работоспособности виртуальной машины. Пожалуйста, поделитесь своими отзывами с нашей командой по адресу mig-discuss@google.com .

Просмотр текущих действий на виртуальных машинах¶

Когда MIG в настоящее время находится в процессе создания экземпляра виртуальной машины, MIG устанавливает для этого поля currentAction, доступного только для чтения, значение CREATING. Если к группе присоединена политика автоматического восстановления, то после создания и запуска виртуальной машины MIG устанавливает текущее действие экземпляра на VERIFYING, и средство проверки работоспособности начинает проверять приложение виртуальной машины. Если приложение проходит эту начальную проверку работоспособности в течение времени, необходимого для запуска приложения, виртуальная машина проверяется, и MIG изменяет поле currentAction виртуальной машины на NONE.

Используйте средство командной строки gcloud или API Compute Engine, чтобы просмотреть подробные сведения об экземплярах в группе управляемых экземпляров. Подробные сведения включают статус экземпляра и текущие действия, которые группа выполняет над своими экземплярами.

gcloud compute instance-groups managed list-instances INSTANCE_GROUP_NAME [--zone=ZONE | --region=REGION]

Команда возвращает список экземпляров в группе, включая их статус, текущие действия и другие сведения:

NAME ZONE STATUS HEALTH_STATE ACTION INSTANCE_TEMPLATE VERSION_NAME LAST_ERROR vm-instances-9pk4 us-central1-f CREATING my-new-template vm-instances-h2r1 us-central1-f STOPPING DELETING my-old-template vm-instances-j1h8 us-central1-f RUNNING NONE my-old-template vm-instances-ngod us-central1-f RUNNING NONE my-old-template

    gcloud compute instance-groups managed describe-instance INSTANCE_GROUP_NAME \
--instance INSTANCE_NAME \
[--zone=ZONE | --region=REGION]

Команда возвращает сведения об экземпляре, включая статус экземпляра, текущее действие и, для мигов с отслеживанием состояния, сохраненное состояние:

currentAction: NONE id: ‘6789072894767812345’ instance: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/instances/example-mig-hz41 instanceStatus: RUNNING name: example-mig-hz41 preservedStateFromConfig:

metadata:
example-key: example-value

preservedStateFromPolicy:

disks:

persistent-disk-0:: autoDelete: NEVER mode: READ_WRITE source: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/disks/example-mig-hz41

version:

instanceTemplate: https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template

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

Какая проверка явлется хорошей¶

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

unhealthy-threshold (нездоровый - порог). Должно быть больше 1. В идеале установите это значение равным 3 или более. Это защищает от редких сбоев, таких как потеря сетевых пакетов.
healthy-threshold. Для большинства приложений достаточно значения 2.
timeout. Установите это значение времени на большую величину (в пять или более раз больше ожидаемого времени отклика). Это защищает от неожиданных задержек, таких как загруженные экземпляры или медленное сетевое подключение.
check-interval (контрольный интервал). Это значение должно составлять от 1 секунды до двух таймаутов (не слишком длинных и не слишком коротких). Когда значение слишком велико, неудачный экземпляр не будет обнаружен достаточно быстро. Когда значение слишком мало, экземпляры и сеть могут быть значительно загружены, учитывая большое количество проверок работоспособности, отправляемых каждую секунду.

Пример: Using autohealing for highly available apps¶

https://cloud.google.com/compute/docs/tutorials/high-availability-autohealing