Kubernetes 部署/Pod/容器状态答案

【问题标题】：Kubernetes Deployment/Pod/Container statusesKubernetes 部署/Pod/容器状态
【发布时间】：2020-02-14 13:48:04
【问题描述】：

我目前正在开发一项监控服务，该服务将监控 Kubernetes 的部署及其 pod。我想在部署未运行预期数量的副本以及 pod 的容器意外重启时通知用户。这可能不是要监控的正确事情，我非常感谢一些关于我应该监控的内容的反馈。

无论如何，主要的问题是豆荚的所有状态之间的差异。当我说 Statuses 时，我指的是运行 kubectl get pods 时的 Status 列。有问题的状态是：

- ContainerCreating
- ImagePullBackOff
- Pending 
- CrashLoopBackOff 
- Error 
- Running

是什么导致 pod/容器进入这些状态？
对于前四个状态，这些状态是否可以在没有用户交互的情况下恢复？
CrashLoopBackOff 的阈值是多少？
Running 是唯一具有 Ready Condition 为 True 的状态吗？

任何反馈将不胜感激！

此外，在自动化脚本中使用kubectl 进行监控会是不好的做法吗？比如每分钟将kubectl get pods的结果记录到Elasticsearch？

【问题讨论】：

标签： kubernetes kubectl

【解决方案1】：

您可以在 k8s documentation 中查看 pod 生命周期详情。监控Kubernetes集群和应用的推荐方式是prometheus

【讨论】：

感谢您的回复。我已经查看了您提到的 k8s 文档，虽然它确实为我的部分问题提供了极好的信息，但它并没有深入探讨其他问题。
至于 Prometheus，我对此知之甚少，但我已经有了一个警报和日志记录解决方案。除非有其他一些优秀的特性使它非常适合 Kubernetes 监控，否则我想避免使用 Prometheus。

【解决方案2】：

我会试着说出我看到的隐藏在这些术语背后的东西

容器创建

当我们等待图像下载时显示容器将由 docker 或其他系统创建。

ImagePullBackOff

当我们无法从注册表下载图像时显示。例如，登录 docker hub 的凭据错误。

待处理

容器启动（如果启动需要时间）或启动但 redinessProbe 失败。

CrashLoopBackOff

此状态显示容器重新启动过于频繁。例如，我们有一个进程试图读取不存在的文件并崩溃。然后容器将由 Kube 重新创建并重复。

错误

这很清楚。我们在运行容器时遇到了一些错误。

正在运行

一切正常，容器运行良好，livenessProbe 正常。

【讨论】：