我目前正在研究一项监视服务，该服务将监视Kubernetes的部署及其Pod。我想在部署未运行预期数量的副本以及Pod的容器意外重启时通知用户。这可能不是正确的监视对象，对于我应该监视的内容，我将不胜感激。
无论如何，主要问题是所有广告连播的状态之间的差异。当我说 Statuss 时，我指的是运行kubectl get pods时的“状态”列。有问题的状态是：
- ContainerCreating
- ImagePullBackOff
- Pending
- CrashLoopBackOff
- Error
- Running
是什么原因导致吊舱/容器进入这些状态？
对于前四个状态，这些状态是否可以在没有用户交互的情况下恢复？
CrashLoopBackOff的阈值是多少？
Running是唯一具有Ready Condition为True的状态吗？
任何反馈将不胜感激！
另外，在自动化脚本中使用kubectl进行监视是否是不好的做法？例如，每分钟将kubectl get pods的结果记录到Elasticsearch吗？
答案 0 :(得分：1)
您可以在k8s documentation中查看Pod生命周期的详细信息。 建议使用prometheus
来监视kubernetes集群和应用程序。答案 1 :(得分：0)
我将尽力告诉我这些条款背后隐藏的内容
显示我们何时等待下载图像以及 容器将由docker或其他系统创建。
显示何时无法从注册表下载图像。例如，错误的凭据登录到Docker中心。
容器启动（如果启动需要时间）或已启动，但是redinessProbe失败。
此状态显示何时重新启动容器的次数过多。例如，我们有尝试读取不存在的文件并崩溃的进程。然后，该容器将由Kube重新创建并重复。
这很清楚。我们在运行容器时遇到一些错误。
一切正常，容器运行良好，livenessProbe正常。