Экземпляры GCP f1-micro работают только за несколько часов до замены
У меня есть кластер GKE (k8) с 3-6 экземплярами f1-micro, который постоянно страдает от повторного создания экземпляров f1-micro.
Теперь, глядя на кластер, он масштабируется до 3 экземпляров со следующими периодами безотказной работы: 10 часов, 3 часа, 1 час.
Почему мои экземпляры постоянно взбивают? Как я могу отладить "почему" экземпляров, которые постоянно добавляются и удаляются из группы экземпляров?
Экземпляры НЕ выгружаются. Я заметил, что в GCP у них установлен автоматический перезапуск в разделе "доступность".
Любая помощь высоко ценится.
Дополнительная информация:
Мое подозрение - причина, по которой я вижу, что я пытаюсь запустить GKE на экземплярах f1-micro. Вместо этого я переключился на экземпляр g-small, и он уже кажется более стабильным.
Я заметил, что в обзоре мониторинга стековых драйверов ( http://app.google.stackdriver.com/) у меня много "gke-my-instance-xzy в кластере X не готов" в поле "События". Это первое место в журналах, где мне удалось найти такое сообщение. Таким образом, я бы пришел к выводу, что экземпляры сообщают о нездоровых на каком-то уровне и в конечном итоге убивают Я часто вижу в журналах пересоздание экземпляра (или что-то подобное).
Какие журналы искать, чтобы найти правильную проверку здоровья, которую я не мог определить. Я заметил это в одном наборе журналов --eviction-hard=memory.available<100Mi если это означает случаи жесткого отключения, когда они имеют менее 100 МБ памяти, то я думаю, что я ударил это. Я до сих пор не вижу сообщений типа "проверка работоспособности" ни в одном журнале.
Дополнительная информация:
Я подтвердил, что при переходе к одному небольшому экземпляру вся нестабильность исчезает. Казалось бы, запускать GKE на экземплярах f1-micro в настоящее время не очень хорошая идея.
Я оставляю вопрос открытым, потому что речь идет о том, как я мог отладить, почему мои экземпляры f1-micro воссоздались так часто, и ответ Санни не привел меня к сообщению "почему" где-либо в журналах.
Решение
В практическом смысле переход к большему размеру узла решил проблему, как отмечено выше. В комментариях ОП @Daniel предоставил ссылку на страницу, которая предоставляет команду, необходимую для просмотра журналов.
gcloud container operations list
Я могу видеть в выводе этой команды все события авторемонта, которые убивали мои узлы.
1 ответ
Automatic restart всегда является необязательной политикой доступности, которую можно установить для шаблона экземпляра, используемого в группе экземпляров. Если установлено, это позволит вычислительному механизму автоматически перезапускать экземпляры виртуальных машин, если они завершаются по не вызванным пользователем причинам, таким как (событие технического обслуживания, аппаратный сбой, программный сбой и т. Д.), Поэтому вряд ли это будет результатом политика, что экземпляры добавляются и удаляются из вашей группы экземпляров.
Как описано в следующей документации, когда вашим приложениям требуются дополнительные вычислительные ресурсы, группы управляемых экземпляров могут автоматически масштабировать количество экземпляров в группе.
Кроме того, группы управляемых экземпляров могут автоматически идентифицировать и воссоздавать нездоровые экземпляры в группе, чтобы обеспечить оптимальную работу всех экземпляров.
В заключение;
Если экземпляр в группе останавливается, падает или удаляется действием, отличным от команд групп экземпляров, группа управляемого экземпляра автоматически воссоздает экземпляр, чтобы он мог возобновить свои задачи обработки. Воссозданный экземпляр использует то же имя и тот же шаблон экземпляра, что и предыдущий, даже если группа ссылается на другой шаблон экземпляра.
Вы также можете просмотреть журналы автоматического масштабирования, как описано в этой общедоступной документации, чтобы подтвердить, стоит ли за этим поведение автоматическое масштабирование.
ИЛИ ЖЕ
Преобразуйте поле "Фильтровать по меткам в Stackdriver" в расширенный фильтр и определите следующие фильтры
resource.type="gce_autoscaler"
protoPayload.methodName="v1.compute.autoscalers.insert"
Для списка всех экземпляров, созданных Autoscaler
А ТАКЖЕ
resource.type="gce_autoscaler"
protoPayload.methodName="v1.compute.autoscalers.delete"
Для удаленных экземпляров.