我在GKE中有一个测试集群（它运行我的非必要开发服务）。我正在为群集使用以下GKE功能：
我创建了可抢占的节点池（在3个区域内自动缩放3到6个实际节点）：
gcloud beta container node-pools create default-pool-f1-micro-preemptible \
--cluster=dev --zone us-west1 --machine-type=f1-micro --disk-size=10 \
--preemptible --node-labels=preemptible=true --tags=preemptible \
--enable-autoupgrade --enable-autorepair --enable-autoscaling \
--num-nodes=1 --min-nodes=0 --max-nodes=2
大部分时间都很好用。但是，每天大约3到4次，我会收到有关在可抢占节点上运行的某些服务的停机时间的健康检查通知。 （确切地说，当节点被回收/再生时，我会期望每24小时ONCE。但不会超过3次。）
当我收到电子邮件通知时，群集已经恢复，但在检查kubectl get nodes时，我可以看到＆＃34; age＆＃34;在一些pre-emptible节点上约5分钟，匹配约。停电的时间。
我不知道在哪里可以找到正在发生的事情的日志，或者为什么重置被触发（设置不当resources设置？意外的预先调度？＆＃34;自动修复＆＃34; ？）我希望这可以在某个地方使用stackdriver，但我无法找到WHERE。 Kubernetes / GKE日志非常繁琐，一切都在INFO级别（隐藏错误文本，或错误日志在其他地方）。
我必须说，我确实喜欢这种设置的自我修复特性，但在这种情况下，我希望能够在它们被回收之前检查破碎的豆荚/节点。我还希望在不拆除/重建群集的情况下进行故障排除，尤其是为了避免额外费用。
答案 0 :(得分：2)
我能够通过暴力破解过程解决这个问题，在GKE中创建多个运行相同工作负载的测试节点池（我没有打扰连接入口，DNS等），并改变提供的选项到gcloud beta container node-pools create。
由于我为这些实验付费，我并没有同时运行它们，尽管这会产生更快的答案。我也更喜欢保留--preemptible选项的测试，因为这会显着影响成本。
我的结果确定该问题与--enable-autorepair参数有关，并且删除它会将失败的运行状况检查减少到可接受的级别（预期的可抢占节点）。
答案 1 :(得分：1)
可抢占虚拟机提供与常规计算实例相同的计算机类型和选项，最长可达24小时。
这意味着可抢占的实例每24小时会死不少于一次，但3-4次仍远远超出预期。先发制人并不保证也不会在任何地方声明只有一次。