在 Kubernetes（Google 容器引擎）中对复制控制器执行 kubectl rolling-update 时，Google（Stackdriver）日志记录代理不会获取新部署的 pod。日志卡在旧 pod 生成的最后一条消息处。
因此，复制控制器的日志会过期，直到我们手动重启（即kubectl scale 和 kubectl delete）pod 并且日志会再次更新。
其他人可以确认这种行为吗？有解决办法吗？
【问题讨论】：
标签： kubernetes google-cloud-platform google-kubernetes-engine stackdriver
我可以尝试重现该行为，但您可以先尝试在执行滚动更新后在新创建的 pod 上运行 kubectl logs <pod-name> 以验证您的应用程序的新版本是否正在生成日志？
这听起来更像是一个应用程序问题而不是基础架构问题，但如果您能确认这是一个基础设施问题，我很乐意深入了解它。
【讨论】：
docker logs 确认已生成日志（kubectl logs 将要求我打开 SSH 隧道）。鉴于他们是无国籍和独立的，我会说这是意料之中的。我怀疑这个错误与滚动更新期间的重命名过程有关。
gcloud container clusters list 应该在 NODE_VERSION 列中显示节点的版本。我第一次尝试在节点为 1.2.0 的集群上重现此操作失败（意味着来自新 pod 的日志有效）。
kubectl version
arob at google dot com。