Instância do GCE reinicializada aleatoriamente

Question

Faz cerca de um mês desde que me mudei para o GCE e estou percebendo que, de vez em quando, todos os processos ou contêineres estão inativos, os volumes são desmontados e o sistema registra uma reinicialização recentemente.

Alguém teve algum problema com o Google Cloud Platform no qual as instâncias de computação foram reinicializadas inesperadamente?

O recomeço aconteceu em 16 de agosto 22:25:27

Os logs em torno da hora da reinicialização não indicam nada, tudo está normal, então a máquina inicia a inicialização novamente

Aug 16 20:22:36 dva kernel: [1612872.963240] init: google-clock-sync-manager main process (13004) terminated with status 1
Aug 16 20:22:36 dva kernel: [1612872.963258] init: google-clock-sync-manager main process ended, respawning
Aug 16 20:22:36 dva google-clock-sync: INFO Starting GCE clock sync
Aug 16 21:17:01 dva CRON[15754]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 16 21:22:36 dva kernel: [1616473.015336] init: google-clock-sync-manager main process (14413) terminated with status 1
Aug 16 21:22:36 dva kernel: [1616473.015345] init: google-clock-sync-manager main process ended, respawning
Aug 16 21:22:37 dva google-clock-sync: INFO Starting GCE clock sync
Aug 16 22:17:01 dva CRON[17329]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 16 22:25:27 dva rsyslogd: [origin software="rsyslogd" swVersion="7.4.4" x-pid="895" x-info="http://www.rsyslog.com"] start
Aug 16 22:25:27 dva rsyslogd-2307: warning: ~ action is deprecated, consider using the 'stop' statement instead [try http://www.rsyslog.com/e/2307 ]
Aug 16 22:25:27 dva rsyslogd: rsyslogd's groupid changed to 104
Aug 16 22:25:27 dva rsyslogd: rsyslogd's userid changed to 101
Aug 16 22:25:27 dva kernel: [    0.000000] Initializing cgroup subsys cpuset
Aug 16 22:25:27 dva kernel: [    0.000000] Initializing cgroup subsys cpu
Aug 16 22:25:27 dva kernel: [    0.000000] Initializing cgroup subsys cpuacct
Aug 16 22:25:27 dva kernel: [    0.000000] Linux version 3.19.0-66-generic (buildd@lgw01-40) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #74~14.04.1-Ubuntu SMP Tue Jul 19 19:56:11 UTC 2016 (Ub\
untu 3.19.0-66.74~14.04.1-generic 3.19.8-ckt22)
Aug 16 22:25:27 dva kernel: [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.19.0-66-generic root=UUID=5e5ef9d5-0969-4eaa-82ad-0234a67a2e9f ro console=ttyS0
Aug 16 22:25:27 dva kernel: [    0.000000] KERNEL supported cpus:
Aug 16 22:25:27 dva kernel: [    0.000000]   Intel GenuineIntel
Aug 16 22:25:27 dva kernel: [    0.000000]   AMD AuthenticAMD
Aug 16 22:25:27 dva kernel: [    0.000000]   Centaur CentaurHauls
Aug 16 22:25:27 dva kernel: [    0.000000] e820: BIOS-provided physical RAM map:
Aug 16 22:25:27 dva kernel: [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
Aug 16 22:25:27 dva kernel: [    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved

    

Answer 1

É possível que alguns pods estejam consumindo muita memória, portanto, configurar um limite de memória provavelmente poderá ajudar a resolver esse problema, conforme mencionado nesta Central de Ajuda article ou, às vezes, aumentando os recursos da instância podem ajudar também. Outra sugestão será monitorar a saúde do nó que pode ajudar na depuração dos futuros problemas. O "kubectl describe node NODE-NAME" pode fornecer informações sobre o status do nó e o que pode ter causado sua reinicialização. Às vezes, isso pode ser causado por alguns eventos de manutenção no Google Cloud Platform, que podem estar visíveis nos registros de operações.