Gcloud kubernetes/docker deploy 工作，但 10 分钟后停止响应

Question

所以我在 google 容器引擎上进行了部署，但遇到了一个奇怪的行为，我真的不知道如何调试。我正在使用 docker 和 kubernetes 部署一个 ruby​​ on rails 应用程序。

我基本上遵循本教程： https://cloud.google.com/container-engine/docs/tutorials/hello-node#step_2_create_a_docker_container_image 跳过旋转副本部分，它可以工作。我可以在构建/部署后转到外部 IP，并且我的应用程序按预期方式运行。但是，大约 10 分钟后，它停止了。请求永远旋转。

我发现日志文件相对没有帮助，只看到以下会发出提示的内容：

{
"log": "2015/11/10 05:35:18 Worker running nslookup kubernetes.default.svc.cluster.local localhost >/dev/null\n",
"stream": "stderr"
}

{
"log": "2015/11/10 05:35:19 Client ip xx.xxx.x.x:xxxxx requesting    /healthz probe servicing cmd nslookup kubernetes.default.svc.cluster.local     localhost >/dev/null\n",
"stream": "stderr"
}

我已经通过了这个页面上的大部分调试建议： https://cloud.google.com/container-engine/docs/debugging/

kubectl 记录 ${pod}：

[2015-11-10 05:07:44] INFO  WEBrick 1.3.1
[2015-11-10 05:07:44] INFO  ruby 2.1.6 (2015-04-13) [x86_64-linux]
[2015-11-10 05:07:44] INFO  WEBrick::HTTPServer#start: pid=1 port=80

kubectl 记录 $pod $instance 令人不安地返回：

Container "x" not found in Pod "x"

Dockerfile 几乎直接来自谷歌：

FROM google/ruby

# [START postgres-dep]
RUN apt-get update && \
apt-get install -qy --no-install-recommends libpq-dev && \
apt-get clean
# [END postgres-dep]

ENV RACK_ENV production

WORKDIR /app
ADD Gemfile /app/Gemfile
ADD Gemfile.lock /app/Gemfile.lock
RUN /usr/bin/bundle install --deployment --without development:test
ADD . /app
RUN bundle exec rake assets:precompile
RUN bundle exec rake db:migrate
EXPOSE 8080
ENV RACK_ENV production
CMD ["/usr/bin/bundle", "exec", "rackup", "-p", "80", "/app/config.ru", "-s", "webrick", "-E", "production"]

ping 会返回以下内容：

PING xxxxx (xxxxx): 56 data bytes
64 bytes from xxxx: icmp_seq=0 ttl=49 time=48.462 ms
64 bytes from xxxx: icmp_seq=1 ttl=49 time=48.177 ms
64 bytes from 1xxxx: icmp_seq=2 ttl=49 time=48.181 ms
64 bytes from xxxx: icmp_seq=3 ttl=49 time=48.240 ms
64 bytes from 1xxxxx: icmp_seq=4 ttl=49 time=48.337 ms
64 bytes from xxxxx: icmp_seq=5 ttl=49 time=48.149 ms 
64 bytes from xxxxx: icmp_seq=6 ttl=49 time=48.053 ms
64 bytes from xxxx: icmp_seq=7 ttl=49 time=47.958 ms
64 bytes from xxxxx: icmp_seq=8 ttl=49 time=48.137 ms

延迟看起来很糟糕。在永远之后，它确实指向了死亡的红色轨道'

问题： 我该死的应用程序日志在哪里？我在开发人员控制台中看不到任何轨道，也无法通过 ssh 找到它们。我有点认为这是一个平衡器/pod 配置问题，但无论如何我都会很高兴知道。 为什么它最初可以工作，一段时间后停止工作？当一切都说它有绿灯而没有关键日志时，我该从哪里开始对此类行为进行故障排除？
滚动更新（https://cloud.google.com/container-engine/docs/rolling-updates）是重新部署代码更改而不旋转/重新创建所有内容的过程吗？ 提前致谢

Answer 1

我该死的应用程序日志在哪里？

kubectl logs 将抓取任何写入 stdout / stderr 的日志。如果您的应用程序记录到一个文件，那么您需要直接查看该文件以查看您的日志。尝试kubectl exec 在您的 pod 中获取一个 shell，然后使用您最喜欢的工具（cat、grep、less 等）查看日志文件（如果您还没有看到 kubectl 的一些巧妙用法，请查看this blog post ，包括kubectl exec 的示例）。

为什么它最初可以工作，一段时间后停止工作？

这可能取决于您的应用程序。一旦你得到日志，你应该能够分辨出来。

rolling updates 是重新部署代码更改而不旋转/重新创建所有内容的过程吗？

是的。