自从我搬到GCE大约一个月后，我注意到我的所有stream程或容器都会停机，卷被卸载，最近系统会重新启动。
有没有人遇到过Google云端平台的计算实例意外重启的问题？
重启发生在8月16日22:25:27
重启时的日志显示什么都没有，一切正常，然后机器再次启动
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 某些Pod可能会消耗大量内存，因此设置内存限制可能有助于解决此问题，如本帮助中心文章中所述，或者有时增加实例资源也可以提供帮助。 另一个build议是监视节点健康情况，这可能有助于未来的问题debugging 。 “kubectl描述节点NODE-NAME”可以给你一些有关节点状态的信息，以及可能导致它重新启动的信息。 有时这可能是由于Google云端平台上的一些维护事件造成的，而这些事件在操作日志中可以看到。